Шакид, всё же.

HTML-импорты считаются тупиковой веткой: они, например, уже есть за флагом в Firefox, но включать их не планируют. Не удивлюсь, если их выпилят и из Chrome. Альтернатива — ES-импорты.

Предвосхищая «ой, ну подумаешь» и оставляя в стороне то, что код не выделить и не скопировать, да и индексации ноль, я просто оставлю одну картинку. Зашёл почитать статью на мобилке:

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

Попробуйте может объяснить, я даже готов понять.

В тексте поста нет слова «Москва». Добавьте его, пожалуйста, в заголовок. «Ну а где ещё?» — это синдром дефолт-сити.

Спасибо за дайджест. Только у меня личная просьба: можно без & в заголовке? Это я магазину Шубы & Меха могу простить, они не ведают, что творят, но тут вроде дизайнеры, люди не чуждые здравому смыслу.

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

Такое ощущение, что я попал в 2003 год: комментаторы кивают головами «хорошая, хорошая статья, ну… разве что недостатки мелкие есть». Да вы с ума сошли все: <font color="#3AC1EF"> и сингл-пейдж на jQuery, серьёзно?

Опять вы переводите всякий мусор, не понимая, что делаете. Здесь очень много вредных советов для новичков. HTML, CSS, JS — весь код кричит «я с позавчерашнего дня во фронтенде, но вот вам статья».

Только не надо делать вид, что это рабочее решение. Оно недоступно с клавиатуры, для скринридеров и не выглядит проще. В чём, собственно, профит решений на чистом CSS? В том, что вам не нужно писать JS? На любом сайте уже куча JS.

Давайте сделаем правильный выбор между плохой сортировкой на CSS и хорошей на JS.

Ну давайте разбираться. То, что я приведу ниже — это не повод поспорить (оправдаться) по каждому пункту, это общепринятые практики в современной вёрстке. Я её практикую сам и учу в рамках HTML Academy — это мой ответ на вопрос «а где научиться?»

1. Опасные селекторы: #main может встречаться только один раз на странице, а значит никакой универсальности и сделать второй элемент с такими же стилями не получится. Плюс селектор по #id специфичнее, а значит его будет сложно перебить. Напротив, header может встречаться несколько раз на странице, а вы к нему обращаетесь глобально, мол, вообще все header на странице. Селектор .scroll-nav li a слишком зависит от структуры HTML, которая может и будет меняться.

#main { … }
header { … }
.scroll-nav li a { … }

Один из признаков того, что у вас проблемы с селекторами — это !important, который сам по себе является антипаттерном.

.lang-first-init {
    display: none !important;
}

Вывод: сегодня подавляющее большинство разработчики пишут селекторы вида .main и .header, это самое гибкое и удачное решение. Познакомьтесь с подходом БЭМ — это хорошая система именования классов и описания интерфейсов, которая сегодня мейнстрим в разработке интерфейсов.

2. Синтаксические ошибки: Это не CSS-комментарии (они выглядят так: /* … */) и такой код ломает следующий за ним селектор, то есть все стили для header не применятся.

<---------------header--------------->
header { … }

Да, это «всего лишь пример в статье», но это показывает небрежность. Скопированный отсюда код сломается.

3. Префиксы: В одном месте вы пишете очень подробную батарею префиксов для свойства transition, а в другом не пишете для animation и @keframes, притом, что кроссбраузерность у transition на поколение-два браузеров лучше, чем у animation.

.transition{
    -webkit-transition: all 500ms linear;
    -moz-transition: all 500ms linear;
    -o-transition: all 500ms linear;
    -ms-transition: all 500ms linear;
    transition: all 500ms linear;
}
@keyframes hideBlock {
    …
}

Уже года три верстальшики не пишут префиксы для браузерных свойств руками. Для этого используется Автопрефиксер, которому вы, при желании, можете скормить список браузеров, которые вы хотите поддерживать. Код с префиксами слишком раздувается, а их наличие — признак устаревшего кода и отсутствия шага сборки (оптимизации) этого кода.

4. Технологии вёрстки: Вы используете только флоаты float: left, которые хоть и продолжают работать во всех браузерах, но уже пару-тройку лет как уступили место флексам display: flex. Флексы гораздо удобнее: их не нужно клиарить, вертикальное выравнивание и колонки одинаковой высоты в них — ерундовое дело.

<div class="clearfix"></div>

Когда в коде есть .clearfix, то этот код с душком: либо устарел код, либо навыки автора.

5. Лишние атрибуты: У вас вроде есть и <nav>, и <header>, и даже пара заголовков <h3> — за что вам отдельное спасибо. Но есть места, где мусорные (ненужные) атрибуты показывают небрежность.

<link rel="stylesheet" type="text/css" href="css/style.css" media="all">
<link rel="stylesheet" href="css/style.css">
…
<script type="text/javascript" src="scripts/jquery.min.js"></script>
<script src="scripts/jquery.min.js"></script>

Есть большая беда с вашей статьёй: уровень знания вёрстки, судя по коду, у вас довольно начальный или устаревший. Это даже не уровень хорошего новичка, которого возьмут на работу верстальщиком.

И нет ничего плохого, в том, чтобы быть новичком. А если вы не новичок, то знайте: в коде много ошибок и устаревшие подходы.

Как бы то ни было, вы радостно демонстрируете этот код в рамках наверняка очень полезной статьи. Но код плохой, я бы никому не рекомендовал делать что-то подобное.

Может быть когда вы перейдёте к части про Vue.js, я буду ошеломлён и повержен. Но сейчас это урок плохой вёрстки.

1. display: none скрывает блок от всех, включая скринридеры
2. Разбавьте ваш суп из дивов ориентирами: header, footer, main, nav и заголовками секций
3. SVG-иконки лучше прятать, там может случайно оказаться <title> или какой-то текст

Посмотрите доклад «Людоедский интерфейс» и почитайте сайт «Веблайнд».

Больше недели назад перевели на Веб-стандартах, вы следите. В дайджесте на Хабре тоже упоминали перевод.

Картинка с текстом, где есть фотография, будет весить мегабайт и ваш глаз устанет раньше, чем дождётся её.

SVG-иконки пока плохо поддерживаются. Без парочки PNG и тач-иконки не обойтись.

Вы очень настойчиво пишете «ориентация письменности» вместо «направление письма» и об это всё время спотыкаешься. Это такой термин или вы неудачно перевели? Или ещё: «по стандартным скриптам глоссария Юникода» — в это месте я сломался. Вы про Unicode scripts? Так это письменности, а не скрипты.

Пост о том, что 2 из 10 верстальщиков знают об этом, а применяют — 0,5 из 10.

Это не «пользователь uve», это Уве Тульсиани (Uve Tulsiani) из команды Samsung Internet.

Не бойтесь слова вьюпорт. Представьте, что вы кричите коллеге в другом конце комнаты:

Какой размер шрифта ставить: полторы единицы изменения области просмотра или больше?

Нет конечно, скажете полтора вьюпорта и всё. Так зачем в статье усложнять?

Что это вообще значит в будущую спецификацию не войдет? Они уже в спецификациях и широко поддерживаются браузерами.