Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 163
Почему то всегда называл маржин и браузер.
Если внутреннему блоку поставить position: absolute, то в хроме margin-top: n% начинает считаться от высоты родительского блока.
Если внутреннему блоку поставить position: absolute, то в хроме margin-top: n% начинает считаться от высоты родительского блока.
по поводу названий не проверял :)
а вот position здесь, как вы видите, не описывал.
При установке position:absolute дочернему блоку, его проценты, в любом случае будет счатиться от родительского, не только в Хроме, но в остальных браузерах. Если я не ошибаюсь :)
а вот position здесь, как вы видите, не описывал.
При установке position:absolute дочернему блоку, его проценты, в любом случае будет счатиться от родительского, не только в Хроме, но в остальных браузерах. Если я не ошибаюсь :)
В мозилле от ширины, а в хроме вертикальный margin от высоты:
Возможно, я, как уже писал position здесь не описываю, а только стандартное поведение margin согласно спецификации, а то что вы пишете — полезная вещь, но я не помню, чтобы подобное было написано в спецификации, это скорее прихоть браузеров.
Но вещь полезная, спасибо! Буду знать на будущее! :)
Но вещь полезная, спасибо! Буду знать на будущее! :)
То есть то, что высотный маргин берётся от ширины — это часть спецификации? Мне почему-то всегда казалось что в HTML ширина и высота — как градусы и килограммы, ни в одной формуле не перемешиваются.
вы не единственный кому это казалось
Если значение width элемента div изменится, изменится также и верхнее поле. Кажется странным? Считаем, что высота большинства элементов в нормальном потоке (как мы предполагаем) такова, чтобы вместить их элементов потомков, включая поля. Если верхнее и нижнее поля элемента задать как процент от высоты родителя, это может привести к бесконечному циклу: высота родителя увеличивалась бы, чтобы вместить верхнее и нижнее поля, которые затем должны были бы увеличиться соответственно новой высоте и т. д.Eric A. Meyer «Cascading Style Sheets: The Definitive Guide»
Вместо того чтобы просто игнорировать процентные значения для верхнего и нижнего полей, авторы спецификации решили соотнести их с шириной родительского элемента, которая не меняется в зависимости от ширины его потомков.
Обработка процентных значений для верхнего и нижнего полей
абсолютно позиционированных элементов отличается и более
подробно рассмотрена в главе 10.
Специально для вас компания ABBYY записала правильное произношение слова margin: lingvo.yandex.ru/margin/
Вроде бы хорошая статья, но читать невозможно. Переведите слова на русский, пожалуйста:
margin, «маргин» — поле
div, дви — блок
Соответственно, «маргин-топ» — верхнее поле, «маргин-боттом» — нижнее поле и т. д. Такое ощущение, что вы статью на коленке в метро писали. Спасибо, конечно, но хочется более ясного изложения ваших мыслей. Уважайте своих читателей.
А так и до середины не дочитал, дальше по диагонали просмотрел.
margin, «маргин» — поле
div, дви — блок
Соответственно, «маргин-топ» — верхнее поле, «маргин-боттом» — нижнее поле и т. д. Такое ощущение, что вы статью на коленке в метро писали. Спасибо, конечно, но хочется более ясного изложения ваших мыслей. Уважайте своих читателей.
А так и до середины не дочитал, дальше по диагонали просмотрел.
Обязательно отредактирую, только завтра :)
<mithgol-mode>А браузер — на «обозреватель»</mithgol-mode>
некоторые названия не стоит никак переводить, а лучше писать в оригинальном виде. В случае автора я бы порекомендовал, ещё и латиницей.
Иначе скоро мы придём к начинающим разработчикам которые будут спрашивать, почему так не работает?
Блок.Верхний_текст { нижнее-поле: 10см; }
Иначе скоро мы придём к начинающим разработчикам которые будут спрашивать, почему так не работает?
Блок.Верхний_текст { нижнее-поле: 10см; }
А компьютер вы называете ЭВМ?
Руки прочь от проф. жаргона, проклятые филологи.
Да ладно, зачем человека заминусовали — читать действительно сложно, такое впечатление, будто автор не из России, очень много опечаток и речевых, орфографических и пунктуационных ошибок.)
Иногда становится очень жаль, что статьи не просматривает корректор.
Уважаемый folgakauchuk во-первых к вашему сведенью, я не из России;
во-вторых: как вы хотели, чтоб я написал margin по-русски? некоторые здесь предлагали «поле», тоесть читалось бы намного лучше и понятнее, если б я писал поле-вверх, поле-слева и т.п. тогда по вашему мнению меня было бы проще понять?
в-третьих: если в статье и были ошибки, то только потому, что статья не маленькая, писалась быстро. Хорошие люди помогли, — видя ошибки — писали мне в личку — я их сразу исправлял.
Дождитесь пожалуйста продолжение статьи, там я учту все пожелания и напишу так, чтоб всем было приятно читать.
Спасибо
во-вторых: как вы хотели, чтоб я написал margin по-русски? некоторые здесь предлагали «поле», тоесть читалось бы намного лучше и понятнее, если б я писал поле-вверх, поле-слева и т.п. тогда по вашему мнению меня было бы проще понять?
в-третьих: если в статье и были ошибки, то только потому, что статья не маленькая, писалась быстро. Хорошие люди помогли, — видя ошибки — писали мне в личку — я их сразу исправлял.
Дождитесь пожалуйста продолжение статьи, там я учту все пожелания и напишу так, чтоб всем было приятно читать.
Спасибо
уважаемые читатели, определитесь пожалуйста на кокой именно термин мне исправить слово «маргин» и слово «браузер», а то ваши предпчтения расходятся :)
Margin — поле. Так написано в англо-русском словаре и в традициях книгопечатания (откуда и было выдернуто w3c в своё время).
Маргин (или марджин) вполне устоявшийся термин в среде веб-верстальщиков. Статья написана для начинающих, и думаю, что изначально нужно прививать им терминологию, на которой общается большинство в данной сфере. Не нужно пугать русифицированными вариантами «поле» (в случае с margin) или «отступ» (в случае с padding). И как-то тут все-таки веб-верстка, а не книгопечатание.
Статья очень хорошая и доходчивая. Спасибо.
Статья очень хорошая и доходчивая. Спасибо.
Вы же не пишете название компании Apple по-русски как Яблоко. Иногда можно встретить Эппл, чаще всего Apple, но никак не Яблоко. То же самое касается, например, Майкрософт. Мелкомягким его называют лишь в качестве шутки-юмора. Мне как верстальщику, куда более удобно читать «маргин» или «margin» чем поле. Поле, это там где скот пасут. У нас в вэбе это маргин/марджин.
Ничего не исправляйте, нормально читается без всякого напряга. Статья о верстке => целевая аудитория — верстальщики и иже с нами => менять «маргин» на «поле» глупо. Имхо.
да не надо ничего исправлять! В css пишется margin, а не «поле». Все правильно вы написали.
можно оставить как есть (но ни в коем случае не менять «маргин» на «поле»).
но с моей точки зрения лучше заменить «маргин» на «margin».
но с моей точки зрения лучше заменить «маргин» на «margin».
ИМХО, Вы неверно указываете ширину блока first.
На рисунке в статье ширина блока first (от которой считается 30% вложенного блока) указана голубоватой стрелкой как расстояние от левого края блока до правого.
Но это неверно. Ширина блока не включает отступы (говорим про обычный, не quirks, режим).
Ширина блока в модели W3C это ширина content (без padding).
На рисунке в статье ширина блока first (от которой считается 30% вложенного блока) указана голубоватой стрелкой как расстояние от левого края блока до правого.
Но это неверно. Ширина блока не включает отступы (говорим про обычный, не quirks, режим).
Ширина блока в модели W3C это ширина content (без padding).
хорошая статья, и явно не для филологов, я бы ничего не понял если бы слово маргин былобы переведено в «поле».
вот и я о том же
По-моему, читалось бы лучше:
Видя, когда новички верстая страницу за страницей, допускают кучу ошибок, делая поля (margin) и до конца не понимая, как эти самые поля на самом деле работают, я решил написать данную статью.
Есть устоявшиеся слова и выражения. Я подхожу к верстальщику и говорю — у тебя здесь маржин слишком большой. Если я скажу «поле», он будет искать форму на странице.
В разговоре (да даже в комментах) я скажу «лучше эту переменную спрятать на всякий пожарный», а в статье напишу «это свойство объекта должно быть инкапсулировано для избежания неотслеживаемых объектом модификаций».
По аналогии с комментарием:
«это свойство предмета (объекта) должно быть инкапсулировано для избежания неотслеживаемых предметом модификаций»
Я конечно не разбираюсь в ООП, но вот и я предложил называть объект предметом (от лат. objectum — предмет), так-же как поле вместо margin.
«это свойство предмета (объекта) должно быть инкапсулировано для избежания неотслеживаемых предметом модификаций»
Я конечно не разбираюсь в ООП, но вот и я предложил называть объект предметом (от лат. objectum — предмет), так-же как поле вместо margin.
Вы закруглили мне гештальт!
С одной стороны, как минимум половина этих особенностей была в свое время набита лбом, с другой — на некоторые даже не натыкался.
С одной стороны, как минимум половина этих особенностей была в свое время набита лбом, с другой — на некоторые даже не натыкался.
Не фига они не абсолютные. Поставляю одно разрешение — будет у них один физический размер, поставлю другое — будет другой.
Как у абсолютной величины может меняться физический размер? Как одному физическому размеру на одном и том же устройстве может соответствовать разное количество одних и тех же абсолютных единиц? Или вы хотите сказать, что сантиметр или дюйм являются относительными величинами?
Если менять пространство, то да. очевидно же.
Согласен, был неправ, действительно по CSS2.1 пиксель теперь абсолютная физическая величина. Но вот согласно спецификации он должен быть 1/96 дюйма, а не соответствовать физическому пикселю на мониторе. То, что сейчас пиксель в вёрстке всегда соответствует пикселю на мониторе, является нарушением спецификации. Причём браузеры прекрасно умеют работать с реальными разрешениями устройств вывода и не нарушают спецификацию например при печати, печатая страницу одним размером и при разрешении 300 dpi, и при 600, и при 1200, но почему-то игнорируя dpi монитора, нарушая спецификацию.
А какая разница, если на принтере он 1/72 дюйма, а на экране 1.3(3) физических пикселя? Браузеры не только для px не проверяют разрешение, но и для pt, in, mm на мониторе считают, что оно 96 dpi, даже если ОС знает, что 114, например.
Нет рабочего способа изобразить на экране шрифт высотой 12pt (1/6 дюйма) — он будет 16 физических пикселей. Последним сдался из популярных браузеров Firefox, насколько я знаю. В угоду совместимости с остальным браузерами его разработчики тоже решили нарушить спецификацию и считать, что для media=«screen» разрешение всегда 96 dpi, а не то, что сообщает ОС.
Нет рабочего способа изобразить на экране шрифт высотой 12pt (1/6 дюйма) — он будет 16 физических пикселей. Последним сдался из популярных браузеров Firefox, насколько я знаю. В угоду совместимости с остальным браузерами его разработчики тоже решили нарушить спецификацию и считать, что для media=«screen» разрешение всегда 96 dpi, а не то, что сообщает ОС.
Все что касается единиц измерения, я описал в новой статье
margin-top: 10px; в любом месте страницы будет ровно 10px (абсолютно). Em, ex и % в зависимости от того где лежит целевой элемент (относительно).
Это раньше так было, в CSS 2. А в CSS 2.1 браузерные пиксели отвязаны от экранных и привязаны к дюймам.
И сколько пикселей в дюйме?
Сам нашёл. Пиксель равен 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 точек на дюйм, дюйм считается в этих браузерах на четверть больше (и соответственно ещё сильнее отклоняется от реального значения).
Только на практике это не означало правильного отображения дюйма. На практике это означало тот же самый мнимый дюйм, но с поправкой на указанный в Windows экранный масштаб. То есть на моей домашней машине, где установлено значение 120 точек на дюйм, дюйм считается в этих браузерах на четверть больше (и соответственно ещё сильнее отклоняется от реального значения).
А у всех этих фактов есть какое-то логичное происхождение? Что высота считается в процентах от ширины, а атрибут А наследуется родителем (!), если у того не определен атрибут Б?
Это формализация. Интересно, какова разумная причина.
Специально для вас придумали тег
А в целом, отличная статья, уяснил для себя пару моментов, спасибо
Всё это выглядит полной дичью (сам механизм конечно, а не статья). Как такая простая вещь (это же отступ, обычный отступ!) может быть такой абсурдно сложной? И с div'ами такие сложности на каждом шагу. Иногда мне кажется, что верстальщики специально держатся за div'ы, чтобы быть незаменимыми, потому что это вероятно самый запутаный способ разметки в мире.
Конечно, именно для этого, сначала придумали таблицы, потом когда все научились верстать на таблицах прилюдно плюемся, и молимся на дивы. Представьте мы уже анимацию научились делать — все для того, чтобы быть незаменимыми.
Просто я не верю в то, что div'ы — это удобный способ разметки. Возможно он таковым задумывался, но в результате получилось чудовище с кучей всяких скрытых зависимостей, нюансов и обходных маневров, необходимых для самых простейших действий. Больше всего это напоминает кривую программу с миллионом багов, каждый из которых надо досконально изучить, прежде чем получится что-то сделать.
Как то меня попросили поправить верстку на сайте. Когда я открыл шаблон, увидел десяток вложенных друг в друга таблиц. Поиск по показал, что их в тексте до тысячи.
Сел и сверстал все на дивах, их получилось несколько десятков, и все понятно и просто.
На одной странице сайта использовались таблицы для вывода какой-то статистики. Их я оставил как было изначально. Там они использовались по назначению.
Сел и сверстал все на дивах, их получилось несколько десятков, и все понятно и просто.
На одной странице сайта использовались таблицы для вывода какой-то статистики. Их я оставил как было изначально. Там они использовались по назначению.
поиск по td показал… тег скушало
Возможно первый верстальщик просто плохо сверстал, а Вы хорошо. Потому что я, в свою очередь, тоже часто вижу верстку в которой миллионы дивов вложены друг в друга и ничего не понятно.
Я, вообще, то сам по себе не верстальщик, хотя и знаком с версткой не понаслышке. Сейчас я делаю Flex приложения и там для верстки используется язык MXML, который в миллион раз проще, понятнее и сверстать можно всё что угодно в любых вариантах. После этого на div'ы смотришь с недоумением.
Я, вообще, то сам по себе не верстальщик, хотя и знаком с версткой не понаслышке. Сейчас я делаю Flex приложения и там для верстки используется язык MXML, который в миллион раз проще, понятнее и сверстать можно всё что угодно в любых вариантах. После этого на div'ы смотришь с недоумением.
Ну мне сложно судить о MXML, я его не знаю. Чтобы я мог оценить миллионную простоту, покажите, например, как будет в нем выглядеть что-то подобное:
Лень открывать редактор. Примерно будет так:
Повторяющиеся стили можно вынести в CSS и использовать вместо них styleName = «someStyle»
Повторяющиеся стили можно вынести в 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, который в миллион раз проще».
Просто вы не разобрались в вопросе, и ваши утверждения голословны.
В общем я так и не увидел ваших доводов к тому, что дивы — «чудовище с кучей всяких скрытых зависимостей, нюансов и обходных маневров, необходимых для самых простейших действий».
И «MXML, который в миллион раз проще».
Просто вы не разобрались в вопросе, и ваши утверждения голословны.
Вы оба неправы (: Во флексе есть тот же самый CSS и можно сделать один в один такой же код, только у вас будет BorderContainer вместо div. Штука флекса не в этом.
Штука флекса в том, что он сделан для разработки UI и наследует все хорошие практики из мира UI дева. Все блоки связаны между собой (ну кроме выноса с помощью абсолюта, естественно) и если вы любому блоку даёте высоту в процентах, то результат ВСЕГДА будет одинаковый — высота будет просчитана от высоты родителя. И не важно указывали мы родителю высоту, флоатится он или ещё что. Те же марджины всегда означают однозначную границу вокруг элемента. Они не схлопываются «рандомом» (как в HTML+CSS, в каких-то случаях складываются, в каких-то нет) — у них всегда одно поведение (если силой не поменять).
Если нам надо сделать двух-колоночную вёрстку так, чтобы обе колонки занимали всю высоту родителя, то в HTML только таблица, во флексе — никаких бубнов.
Штука флекса в том, что он сделан для разработки UI и наследует все хорошие практики из мира UI дева. Все блоки связаны между собой (ну кроме выноса с помощью абсолюта, естественно) и если вы любому блоку даёте высоту в процентах, то результат ВСЕГДА будет одинаковый — высота будет просчитана от высоты родителя. И не важно указывали мы родителю высоту, флоатится он или ещё что. Те же марджины всегда означают однозначную границу вокруг элемента. Они не схлопываются «рандомом» (как в HTML+CSS, в каких-то случаях складываются, в каких-то нет) — у них всегда одно поведение (если силой не поменять).
Если нам надо сделать двух-колоночную вёрстку так, чтобы обе колонки занимали всю высоту родителя, то в HTML только таблица, во флексе — никаких бубнов.
> Если нам надо сделать двух-колоночную вёрстку так, чтобы обе колонки занимали всю высоту родителя, то в HTML только таблица, во флексе — никаких бубнов.
Да хоть четыреx-колоночную:
Да хоть четыре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 как нефиг делать.
Разные инструменты для разных задач.
Штука в том, что веб у нас контенто-ориентированный. Он наследует типографические традиции. Для UI он не предназначен в традиционном смысле. Вот верстать печать в Flex — это самоубийство (: А в HTML как нефиг делать.
Разные инструменты для разных задач.
Ну это пример, я на самом деле не представляю, где физически в вёрстке нужны колонки одинаковой высоты. Кроме как в таблицах, ну это, понятно, таблицами и решается.
Если же нужно визуально сделать одинаковыми, то ставим на бекграунд парента картинку-разделитель с repeat-y и пусть в реальности колонки будут разными — этого же никто не увидит.
Проблема, имхо, надумана.
Если же нужно визуально сделать одинаковыми, то ставим на бекграунд парента картинку-разделитель с 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/
Боже как все-таки как можно усложнить такие простые вещи, в верстке даже нельзя одной строчкой див по центру поставить и приходится городить огород, может появится когда-нибудь…
" в верстке даже нельзя ОДНОЙ строчкой див по центру поставить". Я особенно в верстку не углублялся, но если есть float: left (right) почему нет center. И кстати, я имел ввиду по ширине, вот к примеру статья на эту тему, многие вещи в css можно упростить. Не пойму, почему за выражение личного мнения нужно обязательно минусовать карму.
margin: 0 auto;
Я тоже всегда удивлялся. Если есть float: left (right) почему нет float: сверстать сайт как мне хочется;. Это было бы универсальным решением.
Не вижу картинок в статье.
Странно, что вам удалось опубликовать этот топик: ведь в заголовке вопиющая ошибка, которую, казалось бы, вы не должны были допустить, если прошли предварительный хабраquiz. ;-)
И таки-да, если уж калькировать слово margin на русский, правильнее будет «марджин». Я понимаю, что в русском языке есть слово «маргинал», но вот чтобы говорили «маргин» я, признаться, ни разу не слышал.
И таки-да, если уж калькировать слово margin на русский, правильнее будет «марджин». Я понимаю, что в русском языке есть слово «маргинал», но вот чтобы говорили «маргин» я, признаться, ни разу не слышал.
Разумеется, инсталлирую. Кроме того, «инсталляция» — это вполне себе легитимное слово русского языка (хоть и заимствованное), имеющее отношение не только к IT. Впрочем, думаю, это вам известно.
Вообще я не совсем верно выразился: вместо «кальки» в данном случае правильнее говорить о «транслитерации». Позволю себе короткую цитату из Википедии: «в технике перевода кальку следует отличать от морфологической передачи, когда иноязычное слово транслитерируется с последующим приспособлением его к морфологии родного языка», хотя сейчас мне кажется, что с этой точки зрения оба варианта одинаково неудачны.
В то же время я согласен, что вводить названия типа «НЖМД» или общие типа «поле» при наличии устоявшегося жаргона в предметной области вовсе не лучше, чем пытаться «выдумать» подходящий термин, который бы был сразу понятен и при этом «звучал».
В то же время я согласен, что вводить названия типа «НЖМД» или общие типа «поле» при наличии устоявшегося жаргона в предметной области вовсе не лучше, чем пытаться «выдумать» подходящий термин, который бы был сразу понятен и при этом «звучал».
[offtopic]Хаброкомьюнити как обычно больше интересуется правильным написанием слов, чем содержанием. Кажется это сайт лингвистов, а не айтишников.[/offtopic]
По сути: автор молодец, доходчиво всё описал. Не смотря на наличие стандартов, верстка сегодня остается «шаманством». Такие статьи немного облегчают жизнь. Спасибо!
По сути: автор молодец, доходчиво всё описал. Не смотря на наличие стандартов, верстка сегодня остается «шаманством». Такие статьи немного облегчают жизнь. Спасибо!
Всем спасибо за отзывы!
Я так понял, что продолжение писать стоит?
Я так понял, что продолжение писать стоит?
Не говоря уже об очень странном русском языке, Вы допустили две ошибки.
Во-первых, кто Вам сказал, что «Px, em, ex, % — относительные единицы»? 1 px = 1/96 in, это абсолютная единица.
Во-вторых, ex — это не em пополам, а x-высота шрифта, зависящая, соответственно, не от браузера, а от шрифта.
Во-первых, кто Вам сказал, что «Px, em, ex, % — относительные единицы»? 1 px = 1/96 in, это абсолютная единица.
Во-вторых, ex — это не em пополам, а x-высота шрифта, зависящая, соответственно, не от браузера, а от шрифта.
Вы только еще забыли упомянуть об одной «мелочи»: в ИЕ7, ИЕ6 (и ИЕ5.5. подозреваю тоже) сложение вертикальных маргинов у идущих друг за другом и вложенных элементов не подчиняется правилам CSS, а зависит от наличия layout. Более того, в некоторых ситуациях margin может складываться вопреки всем правилам даже с padding родительского элемента: www.brunildo.org/test/IEMarginCollapseLayout.html
Поэтому прежде чем радостно бежать применять эти трюки на своем сайте, стоит сначала проверить.а как это будет работать в самом веселом браузере. Это конечно не по стандартам, увы, но учитывать надо, так как эти баги никогда не будут исправлены.
Поэтому прежде чем радостно бежать применять эти трюки на своем сайте, стоит сначала проверить.а как это будет работать в самом веселом браузере. Это конечно не по стандартам, увы, но учитывать надо, так как эти баги никогда не будут исправлены.
У вас пробелы не с той стороны скобок.
Все что касается единиц измерения, я описал в новой статье
Если маргины одноименные( оба маргина или отрицательное или положительное число ), то в таком случае берется большое число по модулю, а меньшее не учитывается.
обновился у меня сегодня фаерфокс до пятерочки, а в нем… в нем это правило уже не действует %)
то есть он теперь не берет по модулю, а тупо складывает =(
кто-нибудь уже столкнулся с этим?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Поговорим о margin, он же маргин( часть 1-я )