Заметки об HTML и CSS

notes-html-css.md

Классы в HTML: menu_main или main_menu?

Скорее, menu_main - сначала что, потом - какое. Поскольку внутри чего-то - какого-то блока или модуля - список дочерних сущностей обычно состоит из элементов разного назначения, а не из однотипных элементов разного вида.

Как назвать главный шаблон блока: блок/_all.tpl или блок/блок.tpl?

Плюсы _all.tpl:

• при переименовании блока/каталога не нужно переименовывать еще и шаблон
• основной шаблон называется всегда одинаково
• основной шаблон всегда идет первым в каталоге

Минусы:

• по названию файла не видно, что за шаблон
• название, начинающееся с подчеркивания, хуже воспринимается

Шаблоны и CSS - а не сделать ли вместо каталогов templates и css один общий каталог layout?

И складывать всё туда, и scss - тоже?

Всё упирается в расположение подключаемых картинок. Конечные пути к ним должны указываться относительно конечного css-файла, а не относительно текущего scss. То есть, при структуре типа

• layout/header/header.scss
• layout/header/icon.svg
• css/common.css

для иконки нужно указывать полный путь - /layout/header/header.svg, поскольку в конечном итоге подключается она из css/common.css.

Чтобы можно было пользоваться относительным путём в scss-файле, нужна какая-то конструкция, которая при импорте будет заменяться на путь импортируемого файла относительно импортирующего, причем каскадно - сохраняясь до самого последнего уровня импорта и заменяясь на статический путь только при конечной компиляции в CSS.

Похоже, Sass такое не умеет. Поэтому складывать шаблоны и стилевые файлы вместе неудобно - все равно придется где-то отдельно держать иконки (хотя их, возможно, и не обязательно раскладывать по модулям).

Так что такая схема сработает, только если для каждого блока делать отдельный css-файл - типа layout/header/header.css - и путь к нему использовать как корневой для иконок. Однако это приведет к образованию большого количества css-файлов, каждый из которых придется отдельно подключать на страницу и получать отдельным HTTP-запросом.

Кроме того, если есть некий подблок типа layout/header/someblock/someblock.scss, его иконки тоже должны будут подключаться относительно корневого header.scss.

См. также SO 56282653.

Анимации: CSS vs jQuery

Недостатки анимаций на основе transition и классов CSS

1. Анимация не работает, если одно из значений - auto.
   Например, height. Изменение размеров происходит мгновенно и эффект, аналогичный jQuery.slideDown(), не достигается.

2. При анимации прозрачности элемент в прозрачном, невидимом, состоянии закрывает находящееся за ним содержимое.
   Избежать этого можно лишь с помощью visibility:hidden, которое, в свою очередь, не анимируется, и элемент исчезает сразу (а display:none вообще прекращает любую анимацию).
   Другой обходной путь - назначение видимому элементу больших значений z-index, а невидимому - маленьких отрицательных, и анимация этого свойства. В результате элемент основную часть времени будет виден (основную - если отрицательное значение сильно меньше положительного). Однако это хак, который может создавать неудобства. В частности, положительные значения z-index должны быть достаточно большими (иначе элемент будет невидим в течение заметной доли анимации), и об этом нужно помнить, чтобы не переписать их в какой-нибудь другой группе стилей, с анимацией не связанной. При использовании jQuery.show() всех этих проблем не возникает.

   upd: разработано решение на основе z-index: конкретно для этого свойства указывается easing-функция типа step-start/step-end, причем для видимого состояния она переназначается! таким образом удаётся сохранить положительное значение z-index на всём протяжении анимации. Реализация - fade-animation.scss.
   Решение применимо только для абсолютно или фиксированно спозиционированных элементов.

В jQuery эти проблемы, похоже, решают созданием элемента-копии (см. http://code.jquery.com/jquery-3.4.0.js, propTween).

Недостатки анимаций на основе jQuery

1. Если элемент изначально скрыт (display:none), то в результате показа с помощью анимации ему будет назначен display:block. Это не позволяет управлять конечным display, в отличие от анимаций на основе CSS.

Иконка "бургера" для вызова меню без изображений

Иконка состоит из трех окрашенных линий и двух прозрачных полос между ними, все пять элементов равной высоты - по 20% от общей высоты иконки.

Идея состоит в том, чтобы сделать верхнюю и нижнюю линии при помощи border, прозрачные - при помощи padding, а среднюю - как псевдоэлемент ::before с фоновым цветом currentColor.

border-width нельзя указывать в процентах - только фиксированные величины в пикселях - поэтому нужно заранее знать размер стороны иконки. В таком случае можно использовать вот такой набор правил для SCSS:

$side: 40px;
$fr: 0.2*$side;
width: $side;
height: $side;
border-width: $fr 0;
border-style: solid;
border-color: currentColor;
box-sizing: border-box;
padding: $fr 0;
cursor: pointer;
&::before {
	content: "";
	display: block;
	height: $fr;
	background-color: currentColor;
}
/* также нужно указать цвет, в который будут окрашены три полоски */
color: red;
&:hover {
	color: pink;
}

Скролл с прилипшими header и footer

Идея в том, чтобы не нужно было точно знать высоту <header>, как это бывает при схеме position:absolute у <header> + margin у <body>.

В реальности #scrollable распирает содержимое по высоте так, что header и footer искажаются. Или вообще не реагирует на высоту родителя (как в jsfiddle). Почему так происходит - непонятно.

<header>This is a header</header>
<div id="scrollable">
    <div id="content">This is content</div>
    <footer>This is a footer</footer>
</div>

body {
    height: 100vh;
    display: flex;
    flex-direction: column;
    overflow-y: hidden;
}

#scrollable {
    overflow-y: scroll;
    display: flex;
    flex-direction: column;
    flex-grow: 1; // засчет этого занимает всю высоту при недостаточной высоте 
}

footer {
    margin-top: auto; // это + flex у родителя обеспечивает расположение внизу
}