@Dark_Knight read-only
Пользователь
14 июня 2011 в 17:48

Разработка → Поговорим о margin, он же маргин( часть 1-я ) из песочницы

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

Начинающим верстальщикам она точно будет полезна, а вот профессионалам — сомневаюсь, так как человек занимающийся не первый год версткой уже обязан «вызубрить» наизусть все особенности данного свойства.

В этой части статьи я напишу о вертикальном маргине. О горизонтальном поговорим в следующей части.

Для начала, разберем вкратце, какие есть единицы измерения, что они означают и какие использовать для отступов маргин.

Cm, mm, inch, pc, pt – абсолютные единицы измерения. Рекомендуется использовать при печати документов.

Px, em, ex, % — относительные единицы, используются для мониторов.

Для маргина, я использую px и %, а em – для указания размеров шрифта. Ex( в IE ex = em / 2 ) – использовать не рекомендую, т.к в каждом броузере интерпретируется по-разному.

И вообще, в какой единице вы бы не указали отступ или размер шрифта: броузер все преобразовывает в пиксели, не учитывая при этом область просмотра.

Область просмотра – то, на чем пользователь видит содержимое сайта, не прокручивая при этом экран. У каждого пользователя она разная.

Каждый верстальщик знает, что любой элемент можно представить в виде 4 областей( маргин, бордер, паддинг и контент ).
image
Маргин – внешний отступ. По вертикали и горизонтали построение маргин разные.

Как я уже писал выше, размеры для маргина могут проставляться в em, ex, px – жесткое задавание и в % — считаются относительно какой-то области.

Приведу пример одной из частых допускаемых ошибок начинающих верстальщиков.

Есть 2 дива: first и внем див second.
image
#first{
padding: 100px;
background: #b5bcbc;
}
#second{
height: 100px;
background: #b06b48;
margin: 30% 0 0;
}

Прошу обратить внимание что свойство width я не задал ни одному диву(об этом поговорим позже). Сейчас нас интересует только маргин, который равен margin: 30% 0 0;

Я надеюсь, что все знают, как считается маргин в данном случае, на всякий случай напомню, что считается по часовой стрелке, тоесть: сверху отступ будет 30%, справа — 0, снизу — 0 и слева, — так как я ничего не указал, то маргин принимает значение противоположной стороны, тоесть в данном случает, если маргин справа равен 0, то маргин слева, если не указан, тоже равен 0.

Но сейчас нас интересует маргин, который равен 30%, он же отступ сверху. Откуда же берутся эти 30%?

Многие считают и считают неверно, что 30% берутся от верхней части всей страницы.
image
Но это неверно!

Так как в данном случае, див second вложен в див first, то margin-top:30% будет считаться относительно ширины родительского дива second, тоесть относительно ширины дива first!
image
В данном случае ширина дива first по умолчанию авто, поэтому див принимает все свободное пространство по ширине, а из этой ширины будут высчитываться 30% маргин-топ для дива second.

При уменьшении родительского дива, будет и уменьшаться отступ сверху у дива second.

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

Например: два дива, лежащие один под другим.

image
если мы добавим первому диву margin-bottom: -100px, а второму margin-top: -50px
#first{
height: 200px;
background: #69c;
margin: 0 0 -100px;
}
#second{
height: 200px;
background: #f60;
margin: -50px 100px 0;
}

то произойдет следующее.
image
Но… тут и наступает большая ошибка новичков.

Многие думают, что так как верхний див имеет маргин-боттом -100px, а нижний див, маргин-топ -50px, то нижний див «заедет» на верхний на -150px.

Ошибка!

Если маргины одноименные( оба маргина или отрицательное или положительное число ), то в таком случае берется большое число по модулю, а меньшее не учитывается.

В данном случае нижний див «заедет» на верхний див на 100px, а 50px учитываться не будут.

Тоже самое верно и для положительных маргинов, нижний див «уедет» от верхнего на 100px, а 50px учитываться не будут.

Рассмотрим следующий пример.
Есть 2 дива, один под другим.
image
#first{
height: 200px;
background: #69c;
margin: 0 0 -100px;
}
#second{
height: 200px;
background: #f60;
margin: 50px 100px 0;
}

first
second

Как видите маргин-боттом первого — отрицательный, а маргин-топ второго — положительный, что произойдет в данной ситуации?

Для разноименных маргинов произойдет сложение, тоесть: -100 + 50 = -50. Соответственно нижний див поднимиться на 50px вверх.

Едем далее.

Два дива, один вложен в другой.
image
#first{
background: #b5bcbc;
}
#second{
height: 200px;
background: #b06b48;
}

Если в цсс добавить внутреннему диву маргин-топ 200px,
#second{
height: 200px;
background: #b06b48;
margin-top: 200px;
}


То, вот тут то и очередная ошибка! Некоторые считают, что внутренний маргин, должен «отодвинуться» от своего родителя на 200px вниз а его родитель останется на месте, и тем самым растянется.
image
Но, как бы не так!

Если у родительского эл-та нет ограничивающих факторов ( об этих факторах напишу чуть ниже ), то маргин переходит от внутреннего элемента к внешнему. Потом по старой схеме выбирается маргин: если они одноименные, то выбирается больший, если разноименные, то происходит сложение.
И результат
image
Но, как быть, если нам это не нужно и мы хотим, чтобы див-родитель остался на своем месте, а див-ребенок отодвинулся на 200px вниз?

Можно отменить это действие по отношению к родителю, есть несколько способов.
1. задавание padding родительскому блоку
2. задавание border родительскому блоку
3. задавание overflow родительскому блоку, любое значение кроме visible( работает везде, кроме старых ИЕ )
И вуаля
image
Спасибо за внимание, надеюсь мне удалось прояснить новичкам, что такое маргин и как правильно и откуда его считать.
Если статья оказалась полезна и есть желание читать продолжение, то в следующей части я опишу о горизонтальных маргинах. Там дела обстоят не так просто, как кажется на первый взгляд ;)
@Dark_Knight
карма
27,0
рейтинг 0,0

Похожие публикации

Самое читаемое Разработка

Комментарии (163)

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

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

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

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

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

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

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

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

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

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

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

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

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

    image

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

        padding: 100px;

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

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

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

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

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

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

      margin:10%
      От высоты его в принципе посчитать нельзя, но зато можно сделать одинаковым со всех сторон если считать от ширины — более чем здравое решение.

      Вертикальные отступы — надо понимать их смысл, это отступы до содержимого, промежутки между абзацами и заголовками. Текст в данном случае первичен. Это не отступ потомка передаётся родителю, этот отступ определяет место, где может начаться родитель.
      Многое тут от типографии, это может казаться страшным вуду, но это так.
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Специально для вас придумали тег
    
    А в целом, отличная статья, уяснил для себя пару моментов, спасибо
    • 0
      скушалось. тег <source>
  • +2
    Всё это выглядит полной дичью (сам механизм конечно, а не статья). Как такая простая вещь (это же отступ, обычный отступ!) может быть такой абсурдно сложной? И с div'ами такие сложности на каждом шагу. Иногда мне кажется, что верстальщики специально держатся за div'ы, чтобы быть незаменимыми, потому что это вероятно самый запутаный способ разметки в мире.
    • +4
      Конечно, именно для этого, сначала придумали таблицы, потом когда все научились верстать на таблицах прилюдно плюемся, и молимся на дивы. Представьте мы уже анимацию научились делать — все для того, чтобы быть незаменимыми.
      • –4
        Просто я не верю в то, что div'ы — это удобный способ разметки. Возможно он таковым задумывался, но в результате получилось чудовище с кучей всяких скрытых зависимостей, нюансов и обходных маневров, необходимых для самых простейших действий. Больше всего это напоминает кривую программу с миллионом багов, каждый из которых надо досконально изучить, прежде чем получится что-то сделать.
        • НЛО прилетело и опубликовало эту надпись здесь
          • 0
            Это не мессия, это предвестник апокалипсиса…
            Поймете через пол года после реализации данного куска будущей спецификации.

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

        • +1
          Осильте уже книгу во CSS, главу про компоновку таблиц, много вас открытий чудных ждёт про действительно скрытые зависимости и нюансы.

          А по вопросам веры в церковь.
        • 0
          Как то меня попросили поправить верстку на сайте. Когда я открыл шаблон, увидел десяток вложенных друг в друга таблиц. Поиск по показал, что их в тексте до тысячи.

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

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

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

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

                  Повторяющиеся стили можно вынести в CSS и использовать вместо них styleName = «someStyle»
                  • –1
                    Вероятно мне не хватает кармы чтобы использовать теги. Тогда вот ссылка: pastebin.com/7nDLEDpJ
                    • +3
                      Не вижу особой простоты, возьмем те же дивы и 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>
                      
                      • 0
                        Заранее извиняюсь за код, я не верстальщик, немного знаю css, так-как приходится с верстальщиком взаимодействовать.
                        • –2
                          Вероятно это простой пример. Но суть в том, что у меня никогда не возникает вопроса, как что-то сверстать в MXML, при том, что на обучение достаточно пары дней.
                          • +1
                            Когда мне нужно было срочно сверстать страницу, я выучил все, что мне требовалось за три часа. Хотя css не мой профиль, я занимаюсь серверными скриптами.

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

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

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

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

                        Если нам надо сделать двух-колоночную вёрстку так, чтобы обе колонки занимали всю высоту родителя, то в HTML только таблица, во флексе — никаких бубнов.
                        • +1
                          > Если нам надо сделать двух-колоночную вёрстку так, чтобы обе колонки занимали всю высоту родителя, то в 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>
                          
                          • 0
                            Забыл добавить в parent:

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

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

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

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

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

                              Проблема, имхо, надумана.
                              • 0
                                Почему надумана? Я же говорю — сверстайте любое десктопное приложение для разминки.
                                • 0
                                  Я представляю, что это такое. Просто для разных вещей разные инструменты. Если в десктопной вёрстке высота чаще всего ограничена высотой окна, то для веб это не нужно.
                        • 0
                          Ну зачем таблицы, задача уже давно решена, при том кроссбраузерно.
                    • 0
                      Не убедительно. На 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>
                      ...
                      
        • 0
          Просто вы не умеете их готовить ©
  • +2
    А разве не логично использовать текстовых блоков отступы в виде em?
  • +5
    Я все же не понимаю, почему вертикальный margin зависит от ширины родителя, а не от его высоты. Даже подумать о таком не мог, пока не прочитал в статье. Проверил — так и есть. Тут почитал, но все равно не понимаю.
    • +3
      потому что по задумке в3ц у правильных блоков нет жёсткой высоты — она вычисляется на основе ширины и содержимого. а раз нет высоты, то и вычислять относительно неё никак. поэтому margin-top:30% можно интерпретировать как угодно. решили интерпретировать так, чтобы одинаковые отступы (30%, 1em, 10px) для вертикальных полей и горизонтальных давали одинаковые результаты. так получается опрятней при резиновом вертикальном размере. я бы сделал по аналогии с height:30% — если у родителя вертикальный размер определён, то считается относительно него, если нет — включаем нашу магию.
  • +2
    а я в своё время изучение css начал со спецификаций 2.1 и с тех пор мне странно смотреть всякие «уроки для чайников». Официальные спецификации и понятнее же и обо всём же сразу. www.w3.org/TR/CSS21/
    • 0
      Вот-вот, и я о томже. В конце-то концов, CSS — язык разметки, а не программирования, и ничего сложного в нем нет. Давайте еще статьи про HTML писать. Например:«Для чего нужны теги Head и Body».
    • 0
      А где на русском?
      • 0
        CSS — каскадные таблицы стилей. Подробное руководство. 3-е издание Мейер Э. 2008

        Можно я не буду гуглить за вас?

        На выходных дочитал именно её. Отменно, если сделать скидку на то, что 3 года прошло и некоторые вещи изменились.
        • +1
          Я просил спецификацию, а не руководство.
  • +2
    «Внешний отступ» — почему-то нормально переводят в книгах тех же. Или я не прав?
  • +1
    Боже как все-таки как можно усложнить такие простые вещи, в верстке даже нельзя одной строчкой див по центру поставить и приходится городить огород, может появится когда-нибудь…
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        " в верстке даже нельзя ОДНОЙ строчкой див по центру поставить". Я особенно в верстку не углублялся, но если есть float: left (right) почему нет center. И кстати, я имел ввиду по ширине, вот к примеру статья на эту тему, многие вещи в css можно упростить. Не пойму, почему за выражение личного мнения нужно обязательно минусовать карму.
        • 0
          margin: 0 auto;
          • 0
            В данном случае даже 0 не надо указывать. Просто margin: auto;
            • 0
              Я так понял, что нужно центрировать по горизонтали
              • 0
                Он и будет центрировать по горизонтали, если не указан position, где margin-top/bottom считает как top/bottom. Но тогда в данном случае 0 и есть то, что по дефолту, т.е. auto.
          • 0
            для этого надо указать ширину. а если она зависит от конента, то опаньки.
        • +1
          Я тоже всегда удивлялся. Если есть float: left (right) почему нет float: сверстать сайт как мне хочется;. Это было бы универсальным решением.
          • 0
            Спасибо за margin: auto раньше как-то пропускал этот момент, попадались методы выравнивания типа
            #CenterBlock{
                    width:400px;
                    height:400px;
                    position:absolute;
                    top:50%;
                    left:50%;
                    margin:-200px 0 0 -200px;
                }
            
            • 0
              обычно этот метод используется для выравнивание по центру не только по горизонтали, но и по вертикали. И наверное самый простой
          • +1
            float: зафигачить;
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Только не надо этот страшный ужас показывать людям :)
      • 0
        Это же еще не стандарт.
    • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      jsfiddle.net/punk_undead/YZuhm/light/
      Типа такого?

      Отлично можно.

      Надо понимать, что потомок влияет на высоту родителя, поэтому перестроения высоты некоторым образом ограничены для того, чтобы ускорить компоновку и избежать ошибок и неоднозначностей.
  • 0
    Не вижу картинок в статье.
  • +1
    Странно, что вам удалось опубликовать этот топик: ведь в заголовке вопиющая ошибка, которую, казалось бы, вы не должны были допустить, если прошли предварительный хабраquiz. ;-)

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

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

    По сути: автор молодец, доходчиво всё описал. Не смотря на наличие стандартов, верстка сегодня остается «шаманством». Такие статьи немного облегчают жизнь. Спасибо!
    • НЛО прилетело и опубликовало эту надпись здесь
      • +1
        Если бы ещё разработчики браузеров её читали…
        • НЛО прилетело и опубликовало эту надпись здесь
        • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Вы конечно разбираетесь в вопросе, поэтому я не верю в искренность ваших слов. Держу пари, на вашем рабочем месте приклеено 120 бумажек с «популярными исключениями из правил».
        • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    Всем спасибо за отзывы!
    Я так понял, что продолжение писать стоит?
    • НЛО прилетело и опубликовало эту надпись здесь
  • +2
    Не говоря уже об очень странном русском языке, Вы допустили две ошибки.

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

    Во-вторых, ex — это не em пополам, а x-высота шрифта, зависящая, соответственно, не от браузера, а от шрифта.
    • 0
      Я сейчас пишу статью на эту тему. Через час можно будет обсудить этот вопрос в отдельном топике
    • +1
      Подключите телевизор и вытащите на него браузер, пиксели внезапно станут втрое больше.

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

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

    • 0
      особенности ИЕ будут описанны в следующей части
    • 0
      В ИЕ7 указывайте, а остальные уже умерли.

      • 0
        Ай!
        DOCTYPE указывайте само собой, без него не тот режим включен по умолчанию.
        • +1
          да доктайп буду указывать
          и ИЕ6 тоже описывать
  • +2
    У вас пробелы не с той стороны скобок.
    • +1
      Я вот тоже не пойму, как можно, рассуждая о грамотной верстке, за целый день не найти несколько секунд и не исправить этот вырвиглазный заголовок.
      • +1
        Не только заголовок, везде в тексте так же.
        • 0
          Ой, и правда. Как же, интересно, автор прошел хабратест на правильное оформление топика? Там же, кажется, специальный пункт есть насчет скобок и пробелов.
          • +1
            брутил?
    • +2
      Он использовал паддинг вместо уместного марджина. И этот человек нам лекции читает? :)
  • 0
    Все что касается единиц измерения, я описал в новой статье
  • 0
    Если маргины одноименные( оба маргина или отрицательное или положительное число ), то в таком случае берется большое число по модулю, а меньшее не учитывается.

    обновился у меня сегодня фаерфокс до пятерочки, а в нем… в нем это правило уже не действует %)
    то есть он теперь не берет по модулю, а тупо складывает =(
    кто-нибудь уже столкнулся с этим?

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.