Запрет расширения блока
Вложений: 2
Есть к примеру 20 блоков <div> размером 300px. Они заполняются в цикле слева направо в выровненый по центру родительский блок <div>.
Задача: сделать родительский блок по ширине заполняемого контента. Использование для контентных блоков float:left или inline-block - без разницы (а может и ещё как можно). Чтобы было понятней, приведу пример кода (правильно работает только в Опере!):
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head><title></title>
<style>
.a {
border:2px solid aqua;
text-align:center;
min-width:1000px;
}
.b {
border:2px solid blue;
display:inline-block;
text-align:left;
}
.b div {
display:inline-block;
border:1px solid red;
}
div {
margin:5px;
}
</style>
</head>
<body>
<div class="a">
<div class="b">
<div style="width:800px;">1</div>
<div style="width:500px;">2</div>
</div>
<div>
</body>
</html>
Размеры поставил разные для наглядности. На рисунках видно, в Опере всё как надо, а остальные браузеры непонятно зачем растягивают родительский блок, хотя никакого контента там нет, только пустота. Есть предположение, что браузер пытается втиснусть элемент, расширяя родительский блок, затем при неудачной попытке переносит элемент на вторую строку, а родительский блок забывает поставить на место (ужать). Вобщем нужно так, как в Опере. Если с помощью css такое сделать нельзя, то видимо придётся задействовать скрипты и либо ужимать блок после отрисовки, либо изначально измерять блок, вычислять сколько в него влезет элементов и затем уже заполнять. |
элемент div всегда растягивался по ширине родительского окна, что у тебя и происходит див "а" растягивается, относительно боди, а див "б" относительно диву а. Решить эту проблему можно задав им необходимую ширину. Для этого можно использовать js, но надо заранее осознавать какая у тебя будет структура. А точнее, если ты будешь вставлять блоки со стилем float:left тогда надо знать, сколько блоков влезет в строку и высчитать их суммарную ширину. Всё из-за того, что блок является на странице отдельным элементом и блоки друг на друга не влияют, если есть предопределённые стили. Поставь ширину блока "а" и увидишь.
Ещё вариант использовать как контейнер для блоков другой элемент, допустим таблицу. Создай таблицу с одной ячейкой и получишь в принцепе тот же блок, но растягивающийся по содержимому. |
Все дивы в данном случае инлайновые элементы (за исключением "a", он просто висит для нагрузки), почему они должны растягиватся по экрану, а не по содержимому?
Всё тоже самое будет, если присвоить им float:left. |
они растягиваются по содержимому: если блоки поместяться в строку - все будет как надо. Но так как они не помещаются, b растягивается по максимуму в ff. Думаю, это поведение нигде не зафиксировано, поэтому браузеры ведут себя по-разному
Цитата:
попробуй table |
потому-что это блок и он при не имении фиксированной ширины растягивается по родителю, а не дочери. Почему спроси у разрабов.
А ответ я по моему тебе дал, делай таблицу и не мучай мозг. table + div залог успеха. |
Цитата:
|
Цитата:
|
С таблицей та же история, ничуть не лучше, так же оставляет пустоту справа.
Ладно, наверное скриптом будет проще измерить основной блок, посчитать сколько влезет в него элементов и задать фиксированый размер. + onresize приципить с перерасчётом. |
Цитата:
А вообще какого ты результата хочешь добиться? |
Цитата:
|
Вот навскидку рабочий вариант, только его надо допилить и облагородить.)
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=windows-1251">
<title>demo</title>
<style type="text/css">
* {margin:0px;padding:0px}
.a {border:2px solid aqua;overflow:hidden}
.b, .c {position:relative;float:left}
.b {left:-50%;border:2px solid blue}
.c {left:50%}
.d {clear:both}
.b div {border:1px solid red}
</style>
</head>
<body>
<body>
<div class="a">
<div class="c">
<div class="b">
<div style="width:800px;">1</div>
<div style="width:500px;">2</div>
</div>
</div>
<div class="d"><!-- ie такой ie --></div>
</div>
</body>
</html>
|
Aetae, внутренние div должны быть inline или вести себя подобный образом, т.е. их может быть несколько в строке
|
Ога, посмотрим) Посмотрели, подумали. Что-то первый пост о "несколько в одну строчку" не говорит: "двадцать болков 300px" и всё.
Не втыкаю в смысл того, о чём вы говорите, товарищ x-yuri: есть несколько блоков, которые должны помещаться на одной строке, но при этом не растягивать контейнер - что за ересь?) Если они должны быть в одной строке они должны растягивать контейнер. Если они не должны растягивать его, то они должны переноситься, очевидно же.) А если нужно непонятное извращение с переносом одних и не переносом других, то этого можно добиться только прописыванием конкретным блокам конкретного стиля.) P.S. Забейте в любой(флоат, илайн - пофиг) контейнер с не фиксированной шириной истинно инлайн элемент, т.е. обычный текст, понаблюдайте за результатом и проникнитесь. |
Вложений: 1
Блоки заполняются в строку с последующим автоматическим переносом (если имеют общие размеры больше предоставленого им контейнера) и имеют равный фиксированый размер каждого блока. Когда все блоки умещаются в одну строку, проблем никаких нет. Но как только общая ширина всех блоков становится больше ширины предоставленой им области (в нашем случае ширины окна браузера), то они переносятся на вторую строку, т.е. ниже. И в большинстве браузеров этот перенос сопровождается растяжением по ширине родительского блока (который тоже inline-block либо float и соответственно должен автоматом подстраиваться под внутренний контент) на всё окно браузера.
Получается по мнению создателей браузеров, перенос строк должен быть обязательно указан в разметке, иначе браузер будет вести себя так, как ему вздумается. Насчёт прикреплённой картинки - на ней видно, при заполнении в цикле 5-ти блоков, четвёртый блок в экран невместился и соответственно перескочил на строку ниже вместе с пятым. Синий блок при этом никуда не растянулся (он же inline-block / float, всё правильно сделал). На такой идеал наблюдается только в Опере. Вобщем вывод - без js такого сделать нельзя. Если все согласны с этим, то берусь за js. Сама первоначальная проблема - выровнять относительно родителя по центру синий блок, а автоматически заполняемый контент, который внутри него, выровнять по левому краю. Этому мешает только одно - растяжение синего блока. |
Тут уж ничего не поделаешь. Разница в подходе.) Опера, ие6 - как вам надо, фф, хром - как, имхо, удобнее в большинстве случаев.)
|
Если бы я хотел расширить синий блок по экрану, я бы просто убрал оттуда inline-block, оставив див как он есть.
А так, что есть float или inline-block у дива, что их нету, разницы никакой. имхо - глюк браузеров, тем более приходится использовать js для устранения данного эффекта. |
Цитата:
Цитата:
|
Что за спецификация?
|
либо с w3c, либо от производителя браузера (если мы о ff говорим, например). Ну или где-нибудь еще, где написано что должно быть так, как тебе нужно
|
w3c - не браузер, на отображение страницы не влияет, поэтому его даже не рассматриваем.
Остаётся только здравый смысл и браузер, вот по этим кретерям и определяем, что глюк, а что не глюк. Но правда и в том, что все эти философские рассуждения проблему не решат. |
Цитата:
Цитата:
во-вторых, какой здравый смысл? Что-то могли сделать из соображений производительности, что-то из принципа наименьшего удивления, что-то сложилось исторически, что-то просто удобно. Взять ту же ширину. Как по мне, логичнее включать в ширину padding, но почему-то оно не так. Это такой глобальный баг? ну и вообще, расклад пока такой: ты считаешь поведение ff лишенным здравого смысла, Aetae - наоборот, а я за то, чтобы во всех браузерах было одинаково :blink: Цитата:
|
Не один из браузеров не поддерживает w3c стандарты и вряд ли когда либо будет. Каждая команда разработчиков делает так, как считает нужным. w3c - всего лишь общие правила, как их видит сама команда w3. То, что в одной версии браузера свойство неподдерживалось, а в другой поддерживается - в этом есть заслуга w3c, не спорю, но основное решение остаётся за разработчиками. Microsoft как клали на все эти w3c, так и продолжают дальше :)
Насчёт здравого смысла - двойной margin в ie баг, все согласны? Паддинг внутри элемента, соответственно должен включаться в его ширину. Если возьмёте линейку и измерите книжный шкаф, его ширина уменьшится, если книги сместить к центру или неуменьшится? Я вот про этот здравый смысл. Желание сделать так, чтобы во всех браузерах было одинаково, хорошо, но мир не изменишь, как попыталась w3c, в итоге имеем что имеем. Вспомнился угол наклона элементов: -moz-transform: rotate(90deg); /* FF 3.5+ */ -o-transform: rotate(90deg); /* Opera 10.5 */ -webkit-transform: rotate(90deg); /* Saf 3.1+, Chrome */ filter: progid:DXImageTransform.Microsoft.BasicImage(rotation=3); /* IE */ Каждый производитель как хочет, так и делает :haha: |
Цитата:
Цитата:
Кроме того, вернемся к твоим inline-блокам. Есть у нас inline-блок с текстом... по мере добавления текста он расширяется... появилась вторая строка... Почему браузер должен ужать этот inline-блок по первой строке, а не растянуть на всю ширину контейнера (текст растянул inline-блок до упора)? Во-первых, это лишние действия, а во-вторых мне здравый смысл ничего не подсказывает (а должен?) теперь, пусть у нас есть список файлов (в виде иконок). Для такого содержимого, считаю, inline-блок должен ужиматься. Только список файлов - это частный случай, текст из однобуквенных слов написанных моноширинным шрифтом |
Цитата:
Цитата:
|
Поступать из своих интересов, неподдерживая стандарты - это разве не равно класть на них? :)
Вот в итоге и получилось, w3 сказали - фильтры зло, делайте вот так, MS в ответ - фиг вам, мы как поддерживали синтаксис фильтров, так и будем, остальное нас неволнует. Каждый свою линию гнёт, а верстальщикам сиди пиши, там filter:opacity, тут просто opacity, там html, а тут xhtml. Что мешает MS добавить параллельно к фильтрам те же самые свойства, но уже без надписи "filter" и прочего? Можно было также давно уже создавать xhtml-страницы, но ie как всегда устроил всем засаду по сегодняшний день. На тот момент ie был лучшим браузером, но уже 10 лет прошло и сейчас вряд ли кто-нибудь думает о его первенстве. Фильтры и прочее хорошая вещь, сам бы их использовал, выбросив jquery в корзину с его спецэффектами. Но если технологию поддерживает только один браузер, то какова ей цена? Всех на один браузер ведь непересадишь и разработчиков не заставишь делать одинаково. -webkit- и прочее убрать то уберут, но обратной совместимости со старыми версиями уже не будет. Для Сафари X пишем просто "transform", для Сафари 3-... "-webkit-transform", хорошо придумали дополнительную работу, ещё и по версиям сортировать где чего писать. Насчёт inline-block и float. Браузер должен был ужать основной блок по максимальной ширине внутреннего контента. Если бы я не хотел ничего ужимать, я бы просто убрал эти свойсва и блок автоматом бы растянулся на весь экран. В данном случае хоть пиши inline-block и float, хоть не пиши, результат один. inline элементы тоже себя так ведут, не вместилось второе длинное слово в экран, значит надо перенести его на вторую строку, а родительский блок растянуть до упора. Зачем? А вот фиг знает, захотелось так. P.S. Ужатие блока в моём случае нужно для его центрирования. |
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
|
Вам брррр, а мне фильтры нравятся, хорошие спецэффекты и без всяких скриптов, но тут как говорится на вкус и цвет.
Цитата:
Вобщем ждём IE9. Но самая беда в том, что у народа куча дисков с XP, Win2003 и т.д. с IE6. Если бы версии браузера чаще менялись в то время, думаю с вёрсткой под ie проблем было бы меньше, а так один только ie6 чего стоит. |
Цитата:
|
т.е. вам лучше качать сотни килобайт кода клиенту, чем использовать уже готовые фильтры браузера?
Эффекты в jquery схожие со сложными ie-фильтрами, работают на основе десятков килобайт js-кода. Угадал, не? :) Вот примеры фильтров: http://www.guestbook.ru/docs/filters...vealtrans.html http://www.guestbook.ru/docs/filters/ http://www.javascriptkit.com/filters/filters.shtml смотреть ссылки естественно в ie |
В стандартном наборе используется только фильтр Alpha для эмуляции CSS-свойства opacity. Для остальных вещей там никакие фильтры не нужны и код одинаковый для всех браузеров.
Цитата:
|
Анимацию и разные спецэффекты сделать можно, но как минимум 3 минуса по сравнению с фильтрами ie - самому делать сложно и долго (особенно кроссбраузерность), размер получившихся файлов не 5 байт, не всё можно сделать.
Но так как кроме ie, они нигде не работают, то смело ставим на них крест, оставляя только жизненно необходимые фильтры вроде прозрачности. В итоге получилась никому ненужная технология. Ладно, от главной темы мы уже далеко отклонились. |
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
|
Цитата:
|
Цитата:
|
Extensible
|
вообще, я имел в виду именно использование text/html, а не application/xml+xhtml. И, соответственно, смысл в том, чтобы даже ie понял, что от него хотят
кстати, Octane, а что дает расширяемость в контексте html? Лучшую валидацию, т.е. меньше ошибок? Но все протестировать не удастся, да и думаешь оно того стоит? Может еще что-нибудь? Rated XHTML (хотя, конечно, старая статья) ну и можешь все-таки высказаться о нашей с DMH беседе? |
Кстати, какие-нибудь браузеры поддерживают нынче html конструкции вида <br/> и прочее в таком роде?
Я про HTML Null End Tag: <br/> = <br>> <br/ = <br> <div/xxx/ = <div>xxx</div> Валидатор w3c то поддерживает, там код тот что слева валиден html 4.01, но вот современных браузеров с поддержкой оного что-то не примомню. А вообще интересно было бы, еслиб браузеры взялись вплотную за поддержку html, тогда бы и всплыла вся эта бутафория под названием "html как xhtml". |
Ой. Это я что-то не внимательно прочел. У XHTML, отдаваемого, как text/html нет никакой расширяемости, он парсится, как простой HTML. Тогда смысл только в том, чтобы придерживаться более строго синтаксиса и при необходимости иметь возможность переключится на application/xml+xhtml без особых проблем. Хотя я не понимаю, что мешало разработчикам браузеров сделать поддержку того же SVG в режиме text/html, VML в IE работает же.
Opera выдает более ожидаемый вариант, если посмотреть на то, что отображается, когда для всех блоков задан display:inline.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Untitled Document</title>
<style type="text/css">
body {
text-align: center;
}
.wrapper {
display: inline;
border: 5px dotted #f00;
}
.b {
display: inline;
border: 5px dashed #00f;
}
</style>
</head>
<body>
<div class="wrapper">
<div class="b">bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb</div>
<div class="b">aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa</div>
</div>
</body>
</html>
От inline-block ожидается того же, но с прямоугольными границами по ширине контента, а не по периметру текста. Но во всех браузерах, кроме Opera, получаем другой результат :(
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Untitled Document</title>
<style type="text/css">
body {
text-align: center;
}
.wrapper {
display: inline-block;
border: 5px dotted #f00;
}
.b {
display: inline;
border: 5px dashed #00f;
}
</style>
</head>
<body>
<div class="wrapper">
<div class="b">bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb</div>
<div class="b">aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa</div>
</div>
</body>
</html>
И у ТС последний div не закрыт) |
Точно, не закрыт :) В js переделывать пока пришлось. Естественно как всегда для ie один код, для всех остальных - другой (rules[i] vs cssRules[i]).
|
|
| Часовой пояс GMT +3, время: 15:45. |