Карта доступности мобильной связи в России: чем светлее, тем доступнее.

Судя по всему, на Байкале интернет бесплатный.

1. Я правильно понимаю, что вы:
— прочитали до конца;
— со всем согласны;
— и используете в своей ежедневной работе?

2. Уровень читателя обозначен в анонсе изначально.

Если ответить философски, то элемент / сущность со своими margin находится в контексте родителя, потока, интерфейса… где взаимодействует с другими элементами. Если по существу, то вопрос в системном управлении margin конкретного элемента / группы элементов в контексте родителя, потока, интерфейса…

Ohar, о чём речь?

Дополню, уточню.

1. Рекомендую явно указывать вертикальные margin для каждого элемента, который в них нуждается, полагаться на влияние margin от соседнего элемента опасно, особенно при работе с пользовательским контентом.

Я для этого использую миксин:

@mixin ritm($valueTop, $valueBottom:$valueTop) {

@if $valueTop != 0 {
@include not(':first-child') {
margin-top: $valueTop;
}
}

@if $valueBottom != 0 {
@include not(':last-child') {
margin-bottom: $valueBottom;
}
}
}

2. Не стоит обеспечивать отступ между соседними блоками за счёт отступов дочерних элементов.

3. А отступы это расстояние между границей блока и границей соседнего или родительского элемента.
Верно, но тут есть тонкий момент. Стоит сделать оговорку, что margin является неотъемлемой частью блока, хоть и воспринимается как нечто попутное. Вопрос в том, что размеры блока, а конкретно его ширина, не всегда одно и тоже, что значение свойства width. Width — это ширина части бокса от border до border, либо размер контентной области в зависимости от боксовой модели, но размеры блока остаются неизменные, это стоит понимать.

Each box has four edges: the margin edge, border edge, padding edge, and content edge.
developer.mozilla.org/en-US/docs/Web/CSS/CSS_Box_Model/Introduction_to_the_CSS_box_model

В ней у каждого бокса есть 4 области: margin (внешние отступы), border (рамка), padding (внутренние поля), и content (контент или содержимое).
developer.mozilla.org/ru/docs/Web/CSS/box_model

Each box has a content area (e.g., text, an image, etc.) and optional surrounding padding, border, and margin areas;
www.w3.org/TR/CSS2/box.html#box-dimensions

4. Таким образом, если граница и фон элемента не заданы, то нет разницы, использовать свойство padding или margin для задания отступов, но при условии, что ширина (width) и высота (height) элемента не заданы и не изменен алгоритм расчета размеров контента с помощью свойства box-sizing.
Для полноты картины, есть случаи, когда одинаковые значения margin и padding, даже при выше описанных условиях, производят различный результат, например margin: auto; ≠ padding: auto; codepen.io/matovas/pen/KzyLJZ

5. Отступы же всегда задаются снаружи элемента.
Перефразируем, «Отступы (margin) в обеих боксовых моделях (border-box и content-box), не влияют на значение width блока.»

6. Тонкости перевода, холивара ради,
— граница блока ≠ border блока, бордер — это border, а граница блока — это граница/край блока
— block area = область блока (читай размеры блока), но
— block area ≠ области ограниченной border'ом.
Тут стоит оговориться, наука наукой, а ежедневная работа вносит свои правки в лексикон разработчиков.

Так точно. И код на первый взгляд страшноватый, а если разобраться, то понятно, хоть и заморочно. Но при большом количестве сущностей с релевантным представлением, подход зачёт. Благодарю за возвращение)

В данном конкретном случае, действительно, «правильнее» отдать заказчику статику. Но при разработке HTML/CSS, лично мне, было бы удобнее и быстрее воспользоваться своими наработанными инструментами, например, Middleman и т.п.

не ClosureCompiler, конечно, а CSSO

Вот я и спрашивал товарища выше по ветке Eklykti, мол что он имеет в виду: дублирование селекторов в одном правиле, дублирование правил, дублирование содержимого правил. Товарищ поступил по-английски.

В случае с кнопкой код генерируется следующего содержания

.button__blue    { style for button__blue(bg ,color, border) }
.button__purple { style for button__purple(bg ,color, border) }
// дублирования нет

В случае с контентным блоком происходит дублирование правил, т.е.

@media screen and (min-width: 1240px) {
  pre.ui-code {
    padding-left: calc((100% - 640px)*(1/3));
    padding-right: calc((100% - 640px)*(2/3));
  }
}

// содержимое правила для сниппета «дублирует» содержимое правила для, скажем, изображения
@media screen and (min-width: 1240px) {
  .ui-img.ui-img_narrow {
    margin-left: calc((100% - 640px)*(1/3));
    margin-right: calc((100% - 640px)*(2/3));
  }
}

Не, ну можно, конечно заморочиться, написать пару функций на SassScript, которые бы объеденили группу правил в одно, но зачем, если это задача постпроцессоров. В моём случае пусть не идеально, но кое-где ClosureCompiler генерирует конструкции

@media screen and (min-width:1240px){.cs,.d1,.ce{margin-left:calc((100% - 640px)*(1/3));margin-right:calc((100% - 640px)*(2/3))}}
// код после обфускатора

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

Да, всё верно, это глобальная переменная проекта.

stardust_kid, добавил примеры генерируемого кода в статью. Благодарю за совет.

Будьте добры, поясните.

А ролик про выигранные билеты, похоже, постановочный.
В кадре актриса Татьяна Филатова

Артём,
— «сборщик html-вёрстки», может быть «сборщик html-разметки» или «сборщик вёрстки»;
— поправь свой БЭМ, плиз, menu, menu__item, menu__list, menu__link / menu__itemLink


А в целом, молодец (ы) :)

Ребята, попробуйте под виндой clink вместо cygwin

Марина Широчкина уже давно проповедует «глупые» принципы, посмотрите

Потому, что одно другому не помеха.

в DIR-320 один порт USB