Pull to refresh

Comments 163

Почему то всегда называл маржин и браузер.

Если внутреннему блоку поставить position: absolute, то в хроме margin-top: n% начинает считаться от высоты родительского блока.
по поводу названий не проверял :)
а вот position здесь, как вы видите, не описывал.
При установке position:absolute дочернему блоку, его проценты, в любом случае будет счатиться от родительского, не только в Хроме, но в остальных браузерах. Если я не ошибаюсь :)
В мозилле от ширины, а в хроме вертикальный margin от высоты:

Возможно, я, как уже писал position здесь не описываю, а только стандартное поведение margin согласно спецификации, а то что вы пишете — полезная вещь, но я не помню, чтобы подобное было написано в спецификации, это скорее прихоть браузеров.
Но вещь полезная, спасибо! Буду знать на будущее! :)
То есть то, что высотный маргин берётся от ширины — это часть спецификации? Мне почему-то всегда казалось что в HTML ширина и высота — как градусы и килограммы, ни в одной формуле не перемешиваются.
вы не единственный кому это казалось
Если значение width элемента div изменится, изменится также и верхнее поле. Кажется странным? Считаем, что высота большинства элементов в нормальном потоке (как мы предполагаем) такова, чтобы вместить их элементов потомков, включая поля. Если верхнее и нижнее поля элемента задать как процент от высоты родителя, это может привести к бесконечному циклу: высота родителя увеличивалась бы, чтобы вместить верхнее и нижнее поля, которые затем должны были бы увеличиться соответственно новой высоте и т. д.

Вместо того чтобы просто игнорировать процентные значения для верхнего и нижнего полей, авторы спецификации решили соотнести их с шириной родительского элемента, которая не меняется в зависимости от ширины его потомков.

Обработка процентных значений для верхнего и нижнего полей
абсолютно позиционированных элементов отличается и более
подробно рассмотрена в главе 10.
Eric A. Meyer «Cascading Style Sheets: The Definitive Guide»
Спасибо :) а я все искал, как же он пишется :)
Вроде бы хорошая статья, но читать невозможно. Переведите слова на русский, пожалуйста:
margin, «маргин» — поле
div, дви — блок

Соответственно, «маргин-топ» — верхнее поле, «маргин-боттом» — нижнее поле и т. д. Такое ощущение, что вы статью на коленке в метро писали. Спасибо, конечно, но хочется более ясного изложения ваших мыслей. Уважайте своих читателей.

А так и до середины не дочитал, дальше по диагонали просмотрел.
Обязательно отредактирую, только завтра :)
автор, прекрасная статья, не слушайте дурных советов)
<mithgol-mode>А браузер — на «обозреватель»</mithgol-mode>
Что это за чепуха? Вы когда-нибудь видели, чтобы я называл браузер «обозревателем»?
некоторые названия не стоит никак переводить, а лучше писать в оригинальном виде. В случае автора я бы порекомендовал, ещё и латиницей.

Иначе скоро мы придём к начинающим разработчикам которые будут спрашивать, почему так не работает?

Блок.Верхний_текст { нижнее-поле: 10см; }
Латиницей — идеальный вариант. Но если уж пишут кириллицей, так хотя бы слова русские надо использовать.
Ладно Вам, профресурс же, все поймут, что margin=маргин=поле.
Русские слова — это лапоть/водка/полено. Для айти IT не канает.
напомнило код на 1С :) Не дай Господь такого в веб-дизайне!
А компьютер вы называете ЭВМ?
Любую идею можно довести до абсурда.
Просто Мария машина. :)
Руки прочь от проф. жаргона, проклятые филологи.
Да ладно, зачем человека заминусовали — читать действительно сложно, такое впечатление, будто автор не из России, очень много опечаток и речевых, орфографических и пунктуационных ошибок.)
Иногда становится очень жаль, что статьи не просматривает корректор.
Уважаемый folgakauchuk во-первых к вашему сведенью, я не из России;
во-вторых: как вы хотели, чтоб я написал margin по-русски? некоторые здесь предлагали «поле», тоесть читалось бы намного лучше и понятнее, если б я писал поле-вверх, поле-слева и т.п. тогда по вашему мнению меня было бы проще понять?
в-третьих: если в статье и были ошибки, то только потому, что статья не маленькая, писалась быстро. Хорошие люди помогли, — видя ошибки — писали мне в личку — я их сразу исправлял.
Дождитесь пожалуйста продолжение статьи, там я учту все пожелания и напишу так, чтоб всем было приятно читать.
Спасибо
уважаемые читатели, определитесь пожалуйста на кокой именно термин мне исправить слово «маргин» и слово «браузер», а то ваши предпчтения расходятся :)
Margin — поле. Так написано в англо-русском словаре и в традициях книгопечатания (откуда и было выдернуто w3c в своё время).
Маргин (или марджин) вполне устоявшийся термин в среде веб-верстальщиков. Статья написана для начинающих, и думаю, что изначально нужно прививать им терминологию, на которой общается большинство в данной сфере. Не нужно пугать русифицированными вариантами «поле» (в случае с margin) или «отступ» (в случае с padding). И как-то тут все-таки веб-верстка, а не книгопечатание.
Статья очень хорошая и доходчивая. Спасибо.
проходя тест на intuit.ru я охренел, когда меня спросили как правильно задать отступ для блока и предложили выбрать либо margin, либо padding. у меня в голове отступ — это margin, а оказалось padding. ну нахер эти переводы, тех. литературу надо читать на английском.
UFO landed and left these words here
Вы же не пишете название компании Apple по-русски как Яблоко. Иногда можно встретить Эппл, чаще всего Apple, но никак не Яблоко. То же самое касается, например, Майкрософт. Мелкомягким его называют лишь в качестве шутки-юмора. Мне как верстальщику, куда более удобно читать «маргин» или «margin» чем поле. Поле, это там где скот пасут. У нас в вэбе это маргин/марджин.
Ничего не исправляйте, нормально читается без всякого напряга. Статья о верстке => целевая аудитория — верстальщики и иже с нами => менять «маргин» на «поле» глупо. Имхо.
да не надо ничего исправлять! В css пишется margin, а не «поле». Все правильно вы написали.
можно оставить как есть (но ни в коем случае не менять «маргин» на «поле»).
но с моей точки зрения лучше заменить «маргин» на «margin».
>лучше заменить «маргин» на «margin».

Поддерживаю, каждый прочитает это так, как ему удобнее.
ИМХО, Вы неверно указываете ширину блока first.

На рисунке в статье ширина блока first (от которой считается 30% вложенного блока) указана голубоватой стрелкой как расстояние от левого края блока до правого.

Но это неверно. Ширина блока не включает отступы (говорим про обычный, не quirks, режим).

Ширина блока в модели W3C это ширина content (без padding).

image

я и не имел в виду отступы паддинг, в этой статье все отступы паддинг обнулены
В первом примере:

padding: 100px;

?
Так было до IE5 включительно. В IE6 уже используется W3C Box Model. Если указан доктайп, Естественно.
Хотя мне всегда больше нравилась IE BM
Мне тоже)) Но теперь, слава богу есть box-sizing
А также, черт побери, -moz-box-sizing и -webkit-box-sizing. Но они есть и это уже прекрасно
хорошая статья, и явно не для филологов, я бы ничего не понял если бы слово маргин былобы переведено в «поле».
По-моему, читалось бы лучше:
Видя, когда новички верстая страницу за страницей, допускают кучу ошибок, делая поля (margin) и до конца не понимая, как эти самые поля на самом деле работают, я решил написать данную статью.
Есть устоявшиеся слова и выражения. Я подхожу к верстальщику и говорю — у тебя здесь маржин слишком большой. Если я скажу «поле», он будет искать форму на странице.
В разговоре (да даже в комментах) я скажу «лучше эту переменную спрятать на всякий пожарный», а в статье напишу «это свойство объекта должно быть инкапсулировано для избежания неотслеживаемых объектом модификаций».
По аналогии с комментарием:

«это свойство предмета (объекта) должно быть инкапсулировано для избежания неотслеживаемых предметом модификаций»

Я конечно не разбираюсь в ООП, но вот и я предложил называть объект предметом (от лат. objectum — предмет), так-же как поле вместо margin.
Вы закруглили мне гештальт!
С одной стороны, как минимум половина этих особенностей была в свое время набита лбом, с другой — на некоторые даже не натыкался.
Вы закруглили мне гештальт! — не совсем понял, что это значит, надеюсь, что помог вам :)
В будущем определенно помощь я почувствую.

А «закруглить гештальт» — означает, что какой-то мутный вопрос вдруг обрел чистоту и понятность.
Хотя буквальное значение несколько иное (если в словаре посмотреть), но используется эта роскошная фраза именно так.
UFO landed and left these words here
Не фига они не абсолютные. Поставляю одно разрешение — будет у них один физический размер, поставлю другое — будет другой.
UFO landed and left these words here
Как у абсолютной величины может меняться физический размер? Как одному физическому размеру на одном и том же устройстве может соответствовать разное количество одних и тех же абсолютных единиц? Или вы хотите сказать, что сантиметр или дюйм являются относительными величинами?
Если менять пространство, то да. очевидно же.
UFO landed and left these words here
Согласен, был неправ, действительно по CSS2.1 пиксель теперь абсолютная физическая величина. Но вот согласно спецификации он должен быть 1/96 дюйма, а не соответствовать физическому пикселю на мониторе. То, что сейчас пиксель в вёрстке всегда соответствует пикселю на мониторе, является нарушением спецификации. Причём браузеры прекрасно умеют работать с реальными разрешениями устройств вывода и не нарушают спецификацию например при печати, печатая страницу одним размером и при разрешении 300 dpi, и при 600, и при 1200, но почему-то игнорируя dpi монитора, нарушая спецификацию.
UFO landed and left these words here
А какая разница, если на принтере он 1/72 дюйма, а на экране 1.3(3) физических пикселя? Браузеры не только для px не проверяют разрешение, но и для pt, in, mm на мониторе считают, что оно 96 dpi, даже если ОС знает, что 114, например.

Нет рабочего способа изобразить на экране шрифт высотой 12pt (1/6 дюйма) — он будет 16 физических пикселей. Последним сдался из популярных браузеров Firefox, насколько я знаю. В угоду совместимости с остальным браузерами его разработчики тоже решили нарушить спецификацию и считать, что для media=«screen» разрешение всегда 96 dpi, а не то, что сообщает ОС.
margin-top: 10px; в любом месте страницы будет ровно 10px (абсолютно). Em, ex и % в зависимости от того где лежит целевой элемент (относительно).
Это раньше так было, в CSS 2. А в CSS 2.1 браузерные пиксели отвязаны от экранных и привязаны к дюймам.
UFO landed and left these words here
И сколько пикселей в дюйме?
Сам нашёл. Пиксель равен 0.75 пункта, то есть в дюйме 96 пикселей. То есть в нормальном браузере единица пиксель теперь не должна соответствовать физическому пикселю монитора…
…Однако, эксперимент показал, что это дюйм не соответствует физическому дюйму. Сделал блок высотой в 11in, как раз умещающийся на экране по вертикали, понизил разрешение монитора — и блок умещаться перестал. Значит или Firefox 4 не нормальный браузер, или пиксели всё-таки равны.
Не помню, когда он перестал быть нормальным в этом смысле. В 3.0 дюймы точно отображал нормально (если ОС сообщала правильные значения), в 4.0 уже точно считал, что не «логический» пиксель равен 1/96 физического дюйма, а что «логический» дюйм равен 96 физическим пикселям. Вебкит (хром, сафари) с рождения так считал, насчёт ИЕ не уверен, может ИЕ считает и правильно, да только ось всегда сообщает 96, а может как и в остальных захардкожено.
Зато я помню, проверял недавно. CSS 2 (а не CSS 2.1, устанавливающим, что дюйм равен 96 пикселям) в этом отношении следовали IE до 7-й версии включительно, Opera до 10-й версии включительно и Firefox до 3-й версии включительно.

Только на практике это не означало правильного отображения дюйма. На практике это означало тот же самый мнимый дюйм, но с поправкой на указанный в Windows экранный масштаб. То есть на моей домашней машине, где установлено значение 120 точек на дюйм, дюйм считается в этих браузерах на четверть больше (и соответственно ещё сильнее отклоняется от реального значения).
Моя ОС (Линукс/Убунту) сообщала правильные значения (115 dpi при 1600х1200) и дюймы отображались в ФФ нормально.
А у всех этих фактов есть какое-то логичное происхождение? Что высота считается в процентах от ширины, а атрибут А наследуется родителем (!), если у того не определен атрибут Б?
UFO landed and left these words here
Это формализация. Интересно, какова разумная причина.
UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words here
Специально для вас придумали тег

А в целом, отличная статья, уяснил для себя пару моментов, спасибо
Всё это выглядит полной дичью (сам механизм конечно, а не статья). Как такая простая вещь (это же отступ, обычный отступ!) может быть такой абсурдно сложной? И с div'ами такие сложности на каждом шагу. Иногда мне кажется, что верстальщики специально держатся за div'ы, чтобы быть незаменимыми, потому что это вероятно самый запутаный способ разметки в мире.
Конечно, именно для этого, сначала придумали таблицы, потом когда все научились верстать на таблицах прилюдно плюемся, и молимся на дивы. Представьте мы уже анимацию научились делать — все для того, чтобы быть незаменимыми.
Просто я не верю в то, что div'ы — это удобный способ разметки. Возможно он таковым задумывался, но в результате получилось чудовище с кучей всяких скрытых зависимостей, нюансов и обходных маневров, необходимых для самых простейших действий. Больше всего это напоминает кривую программу с миллионом багов, каждый из которых надо досконально изучить, прежде чем получится что-то сделать.
UFO landed and left these words here
Это не мессия, это предвестник апокалипсиса…
Поймете через пол года после реализации данного куска будущей спецификации.

Попробуйте сделать адаптивную разметку с этим драфтом.

UFO landed and left these words here
Как то меня попросили поправить верстку на сайте. Когда я открыл шаблон, увидел десяток вложенных друг в друга таблиц. Поиск по показал, что их в тексте до тысячи.

Сел и сверстал все на дивах, их получилось несколько десятков, и все понятно и просто.

На одной странице сайта использовались таблицы для вывода какой-то статистики. Их я оставил как было изначально. Там они использовались по назначению.
поиск по td показал… тег скушало
Возможно первый верстальщик просто плохо сверстал, а Вы хорошо. Потому что я, в свою очередь, тоже часто вижу верстку в которой миллионы дивов вложены друг в друга и ничего не понятно.

Я, вообще, то сам по себе не верстальщик, хотя и знаком с версткой не понаслышке. Сейчас я делаю Flex приложения и там для верстки используется язык MXML, который в миллион раз проще, понятнее и сверстать можно всё что угодно в любых вариантах. После этого на div'ы смотришь с недоумением.
Ну мне сложно судить о MXML, я его не знаю. Чтобы я мог оценить миллионную простоту, покажите, например, как будет в нем выглядеть что-то подобное:

Лень открывать редактор. Примерно будет так:

Повторяющиеся стили можно вынести в CSS и использовать вместо них styleName = «someStyle»
Вероятно мне не хватает кармы чтобы использовать теги. Тогда вот ссылка: pastebin.com/7nDLEDpJ
Не вижу особой простоты, возьмем те же дивы и css (замечу, что так-же задан размер шрифтов и тень). Разве в миллион раз сложнее MXML?

<style>
	div { 
		height:200px;
		width: 200px;
		position: absolute;
		background: rgba(0,0,0,0.3);
		font: 15px Arial;
	}

	.a {top: 7px; left: 135px;}
	.b {top: 47px; left: 13px;}
	.c {top: 104px; left: 188px;}

	.zashibis {
		background: transparent; 
		color: yellow;			 
		font: bold 40px Arial;
		top: 148px;
		left: 90px;
		text-shadow: 5px 5px 20px rgba(0,0,0,0.9);
	}
</style>

<div class="a">Проверка</div>
<div class="b">Проверка</div>
<div class="c">Проверка</div>
<div class="zashibis">Зашибись</div>
Заранее извиняюсь за код, я не верстальщик, немного знаю css, так-как приходится с верстальщиком взаимодействовать.
Вероятно это простой пример. Но суть в том, что у меня никогда не возникает вопроса, как что-то сверстать в MXML, при том, что на обучение достаточно пары дней.
Когда мне нужно было срочно сверстать страницу, я выучил все, что мне требовалось за три часа. Хотя css не мой профиль, я занимаюсь серверными скриптами.

В общем я так и не увидел ваших доводов к тому, что дивы — «чудовище с кучей всяких скрытых зависимостей, нюансов и обходных маневров, необходимых для самых простейших действий».

И «MXML, который в миллион раз проще».

Просто вы не разобрались в вопросе, и ваши утверждения голословны.
Вы оба неправы (: Во флексе есть тот же самый CSS и можно сделать один в один такой же код, только у вас будет BorderContainer вместо div. Штука флекса не в этом.

Штука флекса в том, что он сделан для разработки UI и наследует все хорошие практики из мира UI дева. Все блоки связаны между собой (ну кроме выноса с помощью абсолюта, естественно) и если вы любому блоку даёте высоту в процентах, то результат ВСЕГДА будет одинаковый — высота будет просчитана от высоты родителя. И не важно указывали мы родителю высоту, флоатится он или ещё что. Те же марджины всегда означают однозначную границу вокруг элемента. Они не схлопываются «рандомом» (как в HTML+CSS, в каких-то случаях складываются, в каких-то нет) — у них всегда одно поведение (если силой не поменять).

Если нам надо сделать двух-колоночную вёрстку так, чтобы обе колонки занимали всю высоту родителя, то в HTML только таблица, во флексе — никаких бубнов.
> Если нам надо сделать двух-колоночную вёрстку так, чтобы обе колонки занимали всю высоту родителя, то в HTML только таблица, во флексе — никаких бубнов.

Да хоть четыреx-колоночную:

<style>
.a, .b, .c, .d {
	height:100%;
	display: inline-block;
}
.a {background: #7CAFE7; width: 5%;}
.b {background: #E7897C; width: 10%;}
.c {background: #ABE77C; width: 20%;}
.d {background: #D37CE7; width: 40%;}
.parent {height: 800px;}
</style>

<div class="parent">
	<div class="a"></div>
	<div class="b"></div>
</div>
Забыл добавить в parent:

<div class="c"></div>
<div class="d"></div>
Кстати, любителям старины (ie 5+ и фф2) нужно добавить две строчки:

.a, .b, .c, .d {
	float:left;
	display:-moz-inline-box;
	...
Высота парента неизвестна и динамическая. Только табле-целлы и экспрешшены для IE. Это называется — костыли. Попробуйте сверстать какой-нибудь привычный для софта UI, например, UI Mozilla Thunderbird. Со всеми табами с авторесайзом и скроллингом и т.д.

Штука в том, что веб у нас контенто-ориентированный. Он наследует типографические традиции. Для UI он не предназначен в традиционном смысле. Вот верстать печать в Flex — это самоубийство (: А в HTML как нефиг делать.

Разные инструменты для разных задач.
Ну это пример, я на самом деле не представляю, где физически в вёрстке нужны колонки одинаковой высоты. Кроме как в таблицах, ну это, понятно, таблицами и решается.

Если же нужно визуально сделать одинаковыми, то ставим на бекграунд парента картинку-разделитель с repeat-y и пусть в реальности колонки будут разными — этого же никто не увидит.

Проблема, имхо, надумана.
Почему надумана? Я же говорю — сверстайте любое десктопное приложение для разминки.
Я представляю, что это такое. Просто для разных вещей разные инструменты. Если в десктопной вёрстке высота чаще всего ограничена высотой окна, то для веб это не нужно.
Ну зачем таблицы, задача уже давно решена, при том кроссбраузерно.
Не убедительно. На div'ах всё ТОЧНО так-же, отличаться будут только названия тегов и атрибутов. И тоже стили можно (а лучше нужно) описать классами и вынести в filename.css.

<div style="position: absolute; width: 200px; height: 200px; left: 0; top: 20px; background: #000; opacity: 0.3; z-index: по вкусу;">
<label>Проверка</label>
</div>
...
Просто вы не умеете их готовить ©
А разве не логично использовать текстовых блоков отступы в виде em?
Я все же не понимаю, почему вертикальный margin зависит от ширины родителя, а не от его высоты. Даже подумать о таком не мог, пока не прочитал в статье. Проверил — так и есть. Тут почитал, но все равно не понимаю.
потому что по задумке в3ц у правильных блоков нет жёсткой высоты — она вычисляется на основе ширины и содержимого. а раз нет высоты, то и вычислять относительно неё никак. поэтому margin-top:30% можно интерпретировать как угодно. решили интерпретировать так, чтобы одинаковые отступы (30%, 1em, 10px) для вертикальных полей и горизонтальных давали одинаковые результаты. так получается опрятней при резиновом вертикальном размере. я бы сделал по аналогии с height:30% — если у родителя вертикальный размер определён, то считается относительно него, если нет — включаем нашу магию.
а я в своё время изучение css начал со спецификаций 2.1 и с тех пор мне странно смотреть всякие «уроки для чайников». Официальные спецификации и понятнее же и обо всём же сразу. www.w3.org/TR/CSS21/
Вот-вот, и я о томже. В конце-то концов, CSS — язык разметки, а не программирования, и ничего сложного в нем нет. Давайте еще статьи про HTML писать. Например:«Для чего нужны теги Head и Body».
А где на русском?
UFO landed and left these words here
Я просил спецификацию, а не руководство.
«Внешний отступ» — почему-то нормально переводят в книгах тех же. Или я не прав?
Боже как все-таки как можно усложнить такие простые вещи, в верстке даже нельзя одной строчкой див по центру поставить и приходится городить огород, может появится когда-нибудь…
UFO landed and left these words here
" в верстке даже нельзя ОДНОЙ строчкой див по центру поставить". Я особенно в верстку не углублялся, но если есть float: left (right) почему нет center. И кстати, я имел ввиду по ширине, вот к примеру статья на эту тему, многие вещи в css можно упростить. Не пойму, почему за выражение личного мнения нужно обязательно минусовать карму.
В данном случае даже 0 не надо указывать. Просто margin: auto;
Я так понял, что нужно центрировать по горизонтали
Он и будет центрировать по горизонтали, если не указан position, где margin-top/bottom считает как top/bottom. Но тогда в данном случае 0 и есть то, что по дефолту, т.е. auto.
для этого надо указать ширину. а если она зависит от конента, то опаньки.
Я тоже всегда удивлялся. Если есть float: left (right) почему нет float: сверстать сайт как мне хочется;. Это было бы универсальным решением.
Спасибо за margin: auto раньше как-то пропускал этот момент, попадались методы выравнивания типа
#CenterBlock{
        width:400px;
        height:400px;
        position:absolute;
        top:50%;
        left:50%;
        margin:-200px 0 0 -200px;
    }
обычно этот метод используется для выравнивание по центру не только по горизонтали, но и по вертикали. И наверное самый простой
UFO landed and left these words here
UFO landed and left these words here
Только не надо этот страшный ужас показывать людям :)
Это же еще не стандарт.
UFO landed and left these words here
UFO landed and left these words here
Странно, что вам удалось опубликовать этот топик: ведь в заголовке вопиющая ошибка, которую, казалось бы, вы не должны были допустить, если прошли предварительный хабраquiz. ;-)

И таки-да, если уж калькировать слово margin на русский, правильнее будет «марджин». Я понимаю, что в русском языке есть слово «маргинал», но вот чтобы говорили «маргин» я, признаться, ни разу не слышал.
UFO landed and left these words here
Разумеется, инсталлирую. Кроме того, «инсталляция» — это вполне себе легитимное слово русского языка (хоть и заимствованное), имеющее отношение не только к IT. Впрочем, думаю, это вам известно.
UFO landed and left these words here
Вообще я не совсем верно выразился: вместо «кальки» в данном случае правильнее говорить о «транслитерации». Позволю себе короткую цитату из Википедии: «в технике перевода кальку следует отличать от морфологической передачи, когда иноязычное слово транслитерируется с последующим приспособлением его к морфологии родного языка», хотя сейчас мне кажется, что с этой точки зрения оба варианта одинаково неудачны.

В то же время я согласен, что вводить названия типа «НЖМД» или общие типа «поле» при наличии устоявшегося жаргона в предметной области вовсе не лучше, чем пытаться «выдумать» подходящий термин, который бы был сразу понятен и при этом «звучал».
[offtopic]Хаброкомьюнити как обычно больше интересуется правильным написанием слов, чем содержанием. Кажется это сайт лингвистов, а не айтишников.[/offtopic]

По сути: автор молодец, доходчиво всё описал. Не смотря на наличие стандартов, верстка сегодня остается «шаманством». Такие статьи немного облегчают жизнь. Спасибо!
UFO landed and left these words here
Если бы ещё разработчики браузеров её читали…
UFO landed and left these words here
UFO landed and left these words here
Вы конечно разбираетесь в вопросе, поэтому я не верю в искренность ваших слов. Держу пари, на вашем рабочем месте приклеено 120 бумажек с «популярными исключениями из правил».
UFO landed and left these words here
Всем спасибо за отзывы!
Я так понял, что продолжение писать стоит?
UFO landed and left these words here
Не говоря уже об очень странном русском языке, Вы допустили две ошибки.

Во-первых, кто Вам сказал, что «Px, em, ex, % — относительные единицы»? 1 px = 1/96 in, это абсолютная единица.

Во-вторых, ex — это не em пополам, а x-высота шрифта, зависящая, соответственно, не от браузера, а от шрифта.
Я сейчас пишу статью на эту тему. Через час можно будет обсудить этот вопрос в отдельном топике
UFO landed and left these words here
Вы только еще забыли упомянуть об одной «мелочи»: в ИЕ7, ИЕ6 (и ИЕ5.5. подозреваю тоже) сложение вертикальных маргинов у идущих друг за другом и вложенных элементов не подчиняется правилам CSS, а зависит от наличия layout. Более того, в некоторых ситуациях margin может складываться вопреки всем правилам даже с padding родительского элемента: www.brunildo.org/test/IEMarginCollapseLayout.html

Поэтому прежде чем радостно бежать применять эти трюки на своем сайте, стоит сначала проверить.а как это будет работать в самом веселом браузере. Это конечно не по стандартам, увы, но учитывать надо, так как эти баги никогда не будут исправлены.

особенности ИЕ будут описанны в следующей части
UFO landed and left these words here
UFO landed and left these words here
да доктайп буду указывать
и ИЕ6 тоже описывать
У вас пробелы не с той стороны скобок.
Я вот тоже не пойму, как можно, рассуждая о грамотной верстке, за целый день не найти несколько секунд и не исправить этот вырвиглазный заголовок.
Не только заголовок, везде в тексте так же.
Ой, и правда. Как же, интересно, автор прошел хабратест на правильное оформление топика? Там же, кажется, специальный пункт есть насчет скобок и пробелов.
Он использовал паддинг вместо уместного марджина. И этот человек нам лекции читает? :)
Если маргины одноименные( оба маргина или отрицательное или положительное число ), то в таком случае берется большое число по модулю, а меньшее не учитывается.

обновился у меня сегодня фаерфокс до пятерочки, а в нем… в нем это правило уже не действует %)
то есть он теперь не берет по модулю, а тупо складывает =(
кто-нибудь уже столкнулся с этим?
Only those users with full accounts are able to leave comments. Log in, please.