CSS-live.ru

Проблема выбора структуры документа

Перевод статьи «The Document Outline Dilemma» с сайта css-tricks.com, опубликовано на css-live.ru с разрешения автора — Амелии Беллами-Ройдз

В последние несколько недель среди веб-стандартистов было много разговоров о HTML-заголовках. Возможно, вы видели какие-то записи в блогах, твиты и обсуждения разных ишью на Гитхабе. Заголовки — часть HTML начиная с самых первых сайтов в ЦЕРНе, так что может показаться странным, что спустя 25 лет в них нашлись какие-то противоречия. Я хочу сначала вкратце рассказать, почему это всё еще стоит обсуждения, а потом добавить собственные соображения по теме. Если вы сами следили за недавней дискуссией, можете перейти сразу к разделу «Более важная дилемма».

Предыстория

В HTML заголовки (<h1>, <h2>, <h3>, и т.д. вплоть до <h6>) служат для разметки названий последовательных разделов в тексте. Цифры (или уровни) в заголовочных элементах должны были логически соответствовать древовидной структуре вложенных разделов, вроде глав с разделами и подразделами в книгах.

Однако сначала в HTML-разметке не было способа выразить эту логическую структуру в виде вложенной структуры в DOM. В отличие от вложенных списков, вложенные заголовки на самом деле не были вложены в элементы, определяющие родительские разделы. Заголовочные элементы разного уровня в DOM были соседями друг для друга и для абзацев, которые они озаглавливали. «Разделы» были чисто логической структурой, а не DOM-структурой, и в них входила вся разметка начиная от заголовка и до тех пор, пока не встретится другой заголовок того же или еще более высокого уровня.

Как указывает Брайан Карделл, это было вполне логично в эпоху раннего HTML, когда разметка была плоской, как Земля в представлении древних, и теги фактически были командами форматирования, внедренными в поток текста (напр. тег <p> фактически был командой «Начать с красной строки», подобно символу ^p в Ворде, и был одиночным тегом, как <br> — прим. перев.). Представление об HTML-странице как о древовидной структуре появилось позднее, когда так называемому «динамическому HTML» понадобилась объектная модель документа (DOM) для описания этого потока текста с тегами как структуры данных, с которой могли работать скрипты.

Не хотелось раскрывать концовку, но сейчас в HTML есть элемент <section>, с помощью которого можно (хотя и необязательно) создавать вложенную DOM-структуру, соответствующую логической структуре заголовков. Элементы <main>, <header>, <footer>, <article>, <aside> и <nav> тоже помогают строить вложенную структуру документа, выраженную во вложенности DOM.

Но с изначальной моделью заголовков была еще одна проблема: их нельзя было запросто менять местами в системах шаблонов. Поскольку уровень заголовка определяется названием тега (<h1> или <h4>), а не контекстом, где он используется, не получится запросто использовать тот же контент в другом контексте, где уровень окажется другим. Например, в блоге один и тот же набор заголовков статей со вступительными абзацами может использоваться во многих местах: как самостоятельные страницы записей, как анонсы на главной странице, или как анонсы на странице архива с отдельными заголовками для каждого месяца или года.

В ранних предложениях для структурных элементов был также безуровневый элемент <h> или <heading>, уровень которому назначался бы по контексту (на самом деле эта идея восходит к самым первым обсуждениям HTML). Но когда структурные элементы наконец добавили в HTML, их «заточили» под работу с существующими заголовочными элементами. Зато спецификации определили «алгоритм структуры документа», который пересчитывал бы уровень заголовков для существующих «номерных» заголовочных тегов на основе вложенности секций.

С алгоритмом структуры документа можно было (в теории) использовать <h1> для всех заголовков, и браузер определял бы уровень каждого из них исходя из вложенности <article>, <section> и подобных элементов. Алгоритм структуры гарантировал бы, что у верхнего заголовка на странице будет уровень 1, а все остальные заголовки будут в логичном порядке вложенности, без пропуска уровней. WHATWG-версия структуры еще определяет правила для составных заголовков в элементе <hgroup>, чтобы подзаголовки не создавали подразделов (в W3C-версии вместо этого <hgroup> объявили устаревшим: составные заголовки надо размечать абзацами внутри <header>-а раздела или спанами внутри основного заголовочного элемента).

Браузеры изменили свои стили по умолчанию, чтобы заголовки во вложенных разделах отображались всё меньшим и меньшим шрифтом (подобно тому, как у <h3> по умолчанию шрифт мельче, чем у <h2>, а у того — мельче, чем у <h1>). Но не изменили то, как уровень заголовков «виден» API доступности, которым пользуются скринридеры. А пользователи скринридеров — единственные, для кого заголовки оказываются важной частью пользовательского интерфейса.

Зачитывая заголовки, скринридеры объявляют уровень их номера, и позволяют пользователям быстро «пробежаться» по заголовкам данного уровня. Согласно исследованию WebAIM для двух третей пользователей скринридеров такое «сканирование» заголовков — первый шаг в поиске нужной информации на большой странице. Для этих пользователей единственным эффектом от алгоритма структуры документа было то, что некоторые новые страницы (поспешно сделанные по новой спецификации) представлялись как плоский список заголовков первого уровня, вообще без какой-либо структуры.

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

Адриан Розелли хорошо систематизировал обсуждения проблем, связанных с нереализованной спецификацией для структуры, в статье «Структуры документа нет». В новейшей спецификации W3C HTML алгоритм структуры документа служит лишь напоминанием, как разработчикам следует синхронизировать номерные заголовочные теги со вложенными структурными элементами. В спецификации WHATWG HTML весь алгоритм структуры по-прежнему описан как требование, но есть открытое ишью, где многие советуют убрать его совсем. Как выразился редактор спецификации WHATWG Доменик Деникола:

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

Нынешние дебаты

Нынешний всплеск дебатов начался, когда Джонатан Нил открыл ишью по спецификации W3C HTML, в очередной раз предложив неуловимый элемент <h>. Ключевой пункт этого предложения — для заголовка <h> можно было бы определять уровень вложенности по структурным элементам, а обычным номерным заголовкам по-прежнему определять уровень по имени тега. Путем использования этого нового тега верстальщики могли бы включать алгоритм структуры, когда нужно. Пока браузеры не начнут поддерживать <h>, можно было бы рассчитывать уровни заголовков полифилом на JavaScript (или на стороне сервера) и добавлять их в DOM с помощью ARIA-атрибутов: role="heading" и aria-level="3" укажут браузеру, что для целей доступности элемент надо воспринимать как заголовок 3 уровня, вне зависимости от имени тега или вложенности, так что за любую путаницу с заголовками будет всецело отвечать автор страницы.

Много хороших аргументов высказано в обсуждении того ишью и в больших статьях в блогах по этому поводу. Главный аргумент за добавление нового элемента в том, что он не поменяет поведения имеющегося контента. Вдобавок к аргументам Нила на Гитхабе, с этим же взглядом на проблему выступает предложение Брайана Карделла насчет пользовательского элемента и полифилла. С другой стороны, Джейк Арчибальд призывает исправить те элементы, что у нас уже есть:

Работа по исправлению имеющегося веба — лишь часть работы по созданию нового элемента, делающего то же самое, но не исправляющего имеющийся веб.

Другими словами, если алгоритм структуры так хорош, что ради него стоит вводить новый элемент, то почему бы не взять и реализовать его для уже имеющихся элементов?

Если вам до сих пор неясно, почему все никак не могут договориться о такой с виду простой вещи, как HTML-заголовки, то специально для вас Брайан Карделл написал второй пост, убрав все лишние технические подробности.

Более важная дилемма

Все обсуждения, как строить схему-оглавление (outline) для веб-страницы, таят в себе одно неявное допущение. Разговоры о том, как строить оглавление документа, подразумевают, что структуру страницы можно определить в виде оглавления — дерева, где уровень вложенности заголовков определяет их важность.

Лично я не думаю, что простое вложенное оглавление может учесть все уровни смысла, передаваемые HTML-заголовками, как они используются в вебе. Чуть позже я покажу, почему. Но у того, что все обсуждают именно этот тип оглавления, есть причина: именно такого типа оглавления ждут пользователи скринридеров.

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

Так что нам следует обсуждать не вопрос «Как нам назначать уровни в оглавлении для заголовков?», а вопрос «Как кратко передать осмысленную структуру страницы таким образом, чтобы пользователи вспомогательной технологии могли легко находить контент?»

Лично я была бы счастлива, если бы браузеры добавили возможность для всех пользователей отображать структуру в виде оглавления, и позволили быстро переходить к заголовкам с клавиатуры. Может быть, если бы было так, больше веб-разработчиков обратили бы внимание на то, как у них выглядит структура. Но браузеры этого не делают, так что и большинство разработчиков — тоже.

Если хотите взглянуть, на что похожа структура заголовков вашего сайта — и как она теоретически могла бы выглядеть благодаря алгоритму структуры документа — можете воспользоваться новым сервисом проверки HTML от W3C, с отмеченной галочкой «Show outline» («Показать структуру»).

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

Язык определяется теми, кто говорит на нём

HTML уникален среди компьютерных языков тем, что определяет множество конструкций, не привязывая к ним никакого конкретного поведения. Значение в компьютерном коде известно как семантическая сторона языка, в противовес синтаксическим структурам его грамматики. Но в большинстве языков программирования семантический аспект встроенных объектов жестко связан с инструкциями для компьютера. Например, в JavaScript у new Date() и new Promise() один и тот же синтаксис — вызов функции-конструктора — но интерпретатор JS понимает семантическое различие между именами обоих объектов и ведет себя с ними по-разному.

В HTML, напротив, ни у <article>, ни у <section> нет каких-либо инструкций, что браузер должен с ними делать (помимо так и не реализованного алгоритма структуры). Всё различие между двумя этими элементами сводится к значению содержимого, к возможности машиночитаемым образом пометить информацию, передаваемую от одного человека — автора сайта — другому: его читателю.

Значению в общении между людьми трудно дать определение, и оно не бывает статичным. Но прежде всего его определяют сами люди, пользующиеся языком. Словари собирают и систематизируют фактически используемые значения, но не ограничивают их. Если люди начинают употреблять слова по-другому и по-разному, любой сколь-либо приличный словарь обновит свои определения.

Когда я была младшеклассницей, библиотекарь показывала нам многотомный Оксфордский словарь английского языка, знакомя нас с отдельными редкими и необычными словечками. Слово «гугл*» обозначало число, записываемое единицей со 100 нулями (10100, если записать по-научному). Дико, правда? Кому и зачем нужно знать такое слово? Но времена меняются. В 2006-м Оксфордский словарь добавил новое определение, глагол «гуглить» (что означает искать в поисковике «Гугл»), которое в современной английской речи используется, наверное, в гугл раз чаще, чем название числа.

*Уточнение: как заметил в комментариях Марк, то слово, что мне тогда давным-давно показали, правильно пишется «гугол». И я не знаю уже, чему и верить.

В том, что касается значения HTML-тегов, роль словарей играют две конкурирующие HTML-спецификации (WHATWG и W3C). И совсем как словари, обе они начались с попыток описать язык так, как он реально используется.

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

Но не всё так просто, конечно. Языком HTML пользуются не только люди, но и компьютеры. И компьютеры не очень-то сильны в обработке расплывчатого и изменчивого значения.

Всякий раз, когда вы требуете от компьютера что-то сделать со своим контентом — например, сообщить скринридеру, что за заголовки на этом сайте и как они организованы — ему нужны четкие и явные правила, как это делается. Если одни веб-разработчики используют заголовки одним способом, а другие используют те же теги в другом значении, браузеру нужны дополнительные правила, чтобы разобраться, где какой случай — иначе он поймет их неправильно, как минимум в некоторых случаях.

Движение веб-стандартов вдохновлялось надеждой, что все брузеры будут реагировать на код страниц (примерно) одинаковым образом. И это означает определение новых функций в стандартных документах до того, как использовать их в вебе. Вместо того, чтобы описывать, как словарь (определяя, как что есть) они предписывают, как юридический документ (определяя, как что должно быть).

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

И это лишь про описание того, что должны делать браузеры. Как насчет всех HTML-элементов, определяющих семантику контента? Надо ли им тоже «улучшить соответствие реальности»?

Несколько месяцев назад Сара Суайдан предложила рабочей группе HTML в W3C, не сделать ли элемент <address> валидным для любых адресов (а не только контактных адресов владельца страницы). И до нее многие просили об этом же. Но в этот раз случилось что-то необычное. После небольшого анализа наскоро собранных данных, показавшего, что реальное использование в вебе не ограничивается исходным определением, определение в спецификации W3C обновили.

Это что-то изменило? Может, и нет. Браузеры ничего не делают с <address>, разве что оформляют курсивом. И в спецификации WHATWG HTML определение по-прежнему старое. Но это значит, что спецификация чуть приблизилась к описанию того, как код действительно используется в вебе, а не чьих-то давнишних представлений о том, как это будет.

Что опять возвращает нас к нашим заголовкам: как они используются в вебе на самом деле? И можно ли вообще определить предписывающий набор инструкций, для авторов страниц и для браузеров, который гарантировал бы, что значение заголовков будет правильно передаваться скринридерам (а в теории и другим программам)?

Такие многозначные заголовки

Что такое заголовок? Это краткое название раздела документа. У этого раздела заголовок «Такие многозначные заголовки». Пока всё хорошо.

Но не все заголовки созданы равными.

Есть большие заголовки:

Большой заголовок

а есть намного меньшие заголовки:

Такой малюсенький заголовочек, что почти и не заголовок вовсе

Если посмотреть код, видно, что первый — это <h1>, а второй — <h6>. Оба обернуты в теги <figure>, что — по алгоритму структуры документа — должно их инкапсулировать, чтобы они не вмешивались в основную структуру документа. Но, как мы уже знаем, на самом деле браузеры не пользуются этим алгоритмом, так что прошу прощения у всех пользователей скринридеров, кто по ошибке вдруг оказался посреди страницы.

Для каждого, кто читает эту страницу глазами, различие между этими заголовками видно из размера шрифта, и, возможно, из его стиля. Конкретные подробности зависят от того, смотрите ли вы на стили сайта или стили режима чтения у вас в браузере, а также от того, когда в последний раз Крис поменял стили CSS-Tricks. Но если Крис совсем уж не напортачил, при чтении глазами будет ясно, что <h1> крупнее и важнее, чем <h6>. Можно поменять CSS, чтобы они выглядели одинаково, но уже сейчас непонятно, зачем такое может понадобиться. Если они должны выглядеть одинаково, почему бы не использовать один и тот же тег?

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

See the Pen Heading outlines example #1 by Ilya Streltsyn (@SelenIT) on CodePen.

Вот другой способ выстроить те же заголовки и абзацы:

See the Pen Heading outlines example #2 by Ilya Streltsyn (@SelenIT) on CodePen.

А вот третий:

See the Pen Heading outlines example #3 by Ilya Streltsyn (@SelenIT) on CodePen.

Если невооруженным глазом смотреть только на вкладку «Результат» в этих примерах, легко можно подумать, что второй и третий примеры идентичны и очень отличаются от первого. Визуально и примере №2, и в примере №3 есть главный раздел с большим заголовком и боковая панель с маленьким заголовком. Разница лишь в том, что в одном структура строится с помощью элементов <div>, а в другом с помощью структурных элементов HTML.

Раз вы дочитали досюда, вас вряд ли слишком удивит, что эти два примера дают разные структуры при обработке алгоритмом структуры HTML-документа. В этом алгоритме дивы игнорируются, так что пример №2 будет воспринят точно так же, как пример №1: главный заголовок, абзац обычного текста, затем подзаголовок и еще один абзац. Оглавление никак не показывает, что боковая панель — отдельная структура, параллельная основной статье:

  1. Большой заголовок
    1. Такой малюсенький заголовочек, что почти и не заголовок вовсе

Напротив, если запустить алгоритм структуры для примера №3, он покажет нам, что здесь безымянный основной документ (заголовка верхнего уровня нет) с двумя равнозначными дочерними элементами (оба заголовка трактуются как второй уровень). Так что он четко передает параллельность структуры, но не передает различия в важности заголовков:

  1. [элемент body без заголовка]
    1. Большой заголовок
    2. Такой малюсенький заголовочек, что почти и не заголовок вовсе

Не думаю, что какое-либо из этих оглавлений точно описывает визуальную структуру блоков страницы. Не описывает ее и оглавление по названиям тегов, которое не только считает боковую панель вложенной в основную статью, но еще сбивается с толку наличием на моей страничке <h6> при отсутствии элементов <h2/3/4/5>.

Если бы меня попросили описать кому-нибудь эту структуру, я бы отметила два момента:

  • тут два раздела друг рядом с другом;
  • один из этих разделов более важен, чем другой.

В этом простом примере важность компонентов друг относительно друга — отдельная порция информации помимо структуры вложенности (или ее отсутствия). В более сложных примерах у одних частей контента будет осмысленные вложенные заголовки (как у этой статьи), а у других (как у боковых панелей или раздела с комментариями внизу) будет параллельная, отдельная структура, в которой заголовки внутренних уровней никак не связаны с заголовками первой части. Если воспринимать все параллельные части как равнозначные, потеряется их относительная важность, заданная в разметке. Но лепить эти дополнительные заголовки в конец основной статьи, просто потому, что между ними нет заголовка более высокого уровня, выглядит еще хуже.

Даже когда компоненты вложены, их уровень важности не всегда зависит от количества окружающих их разделов. Я пишу книги по SVG для издательства O’Reilly. Разметка, с помощью которой мы делаем книги, преобразуется в HTML. У книги (заголовок 1 уровня) есть главы (заголовки 2 уровня) с разделами (заголовки 3 уровня), в которых бывают подразделы и даже подподразделы (уровни 4 и 5). Но в ней есть также примеры, предупреждения и примечания на полях, и у них всех есть свои заголовки, с одинаковым оформлением независимо от того, находится ли этот компонент в обычном разделе или в подподразделе. Если бы мы использовали «правильные» HTML-заголовки, у них были бы разные имена тегов, в зависимости от глубины раздела, но их стили были бы идентичны.

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

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

А затем сосредоточиться на действительно важном вопросе:

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

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

  • Нужны лучшие правила для исключения безымянных разделов, может быть, стоит рассматривать их не как дополнительные уровни вложенности в оглавлении, а как ARIA-группы.
  • Могут понадобиться лучшие правила для работы с составными заголовками, объединенными с помощью элементов <hgroup> или <header>.
  • И, пожалуй, понадобятся лучшие правила насчет того, какие элементы инкапсулируют заголовки своих потомков и полностью изолируют их от основного оглавления (и будут ли такие элементы вообще).

Покажите мне данные

Но это лишь мое мнение.

Чтобы браузеры и скринридеры изменили свое поведение — не говоря уж о том, чтобы убедить сотни тысяч веб-разработчиков, использующих в своем контенте заголовки — одних мнений и догадок недостаточно. Как я еще давно утверждала, нам нужны данные. И Джейк, и Брайан дружно повторили этот призыв.

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

Структурным элементам HTML уже много лет. Они больше не что-то теоретическое. Они часть языка, с помощью которого вы, веб-разработчики, передаете информацию. Если вы пользуетесь структурными элементами, наверное, вы руководствуетесь какой-то логикой. Когда вы выбираете тег для заголовка, наверное, вы тоже руководствуетесь какой-то логикой. Самое время пересмотреть стандарты HTML и убедиться, что они отражают логику и смысл, вкладываемые в разметку большинством разработчиков.

Так что я прошу вас: «прогоните» свои любимые сайты (которые вы делали или которые вы посещаете) через оба генератора оглавлений в HTML-валидаторе.

  • Есть ли смысл хоть у одного из оглавлений?
  • Можно ли сделать их осмысленными с помощью не слишком сложных доработок разметки, которые можно внедрить в вашу систему сборки или компонентный фреймворк?
  • Какое оглавление лучше?
  • Какие аспекты структуры документа вызывают больше всего проблем?

И пока мы не забыли, еще один вопрос:

Как вам самим, как пользователю веба, хотелось бы открывать документы и переходить по ним при помощи заголовков или оглавлений?

P.S. Это тоже может быть интересно:

12 комментариев

  1. от того, когда в последний раз Крис поменял стили CSS-Tricks

    Хорошо проехалась

    1. Меня особенно впечатлила мысль о том, что иерархичность заголовков и их важность — не одно и то же и не связаны однозначно. Задним числом кажется такой простой вещью, почти что очевидной — но до сих пор во всех обсуждениях многострадальной «outline», по крайней мере на моей памяти, никто ее не высказывал!

      1. И не просто важность, а относительная важность. От этого вообще минут на 5 (или больше) ушёл в ступор и глубокие размышления.

  2. Спасибо за статью, было интересно читать.
    Насчет гугла: как раз сейчас прочла статью про «ошибки в крупных компаниях»:

    В частности, основатели Google Сергей Брин и Ларри Пейдж также дали своей компании ошибочное название: «google» вместо «googol». Гугол — математический термин, обозначающий число из единицы и ста нулей. Пейдж и Брин таким образом хотели показать, как много информации умеет обрабатывать их система. Термин «гугл» ввел в обиход американский математик Эдвард Казнер, чтобы показать разницу между большим числом и бесконечностью.

    https://ain.ua/2017/03/11/fioletovyj-stal-firmennym-cvetom-po-oshibke
    Так что с гуглом всё сошлось :)

  3. Здравствуйте, автор!
    Хороший у Вас блог, видно углублённое понимание и профессионализм… Хочу Вам тонкий вопрос задать, если можно…

    По ссылке картинка с кодом: https://hkar.ru/RtWT

    Вопрос о тонкостях… На картинке первый вариант — это 3 блока («a», обёрнутый анонимным боксом (или сам в данном случае бокс?); «nav» и ещё один «a») или 4 блока (первый «а» структурно не группирует два «p» внутри и чтобы было 4 нужен ещё «div» — второй вариант на картинке)?

    1. Опечатался в вопросе: имел в виду, нужно ли «div» добавлять, чтобы было 3 блока или это излишне и «a» и так логически группирует (или внонимный бокс, который оборачивает «а»)?

      1. Боксы — CSSное понятие, так что для правильной структуры боксов достаточно в первом варианте задать display:block самой ссылке. А если header — флекс-контейнер, то и этого не нужно (прямые потомки флекс-контейнера становятся флекс-элементами независимо от своего изначального display). Добавлять div необязательно (хотя и вреда от него не будет).

        Вообще нужно следить, чтобы в HTML была логичная структура вложенности (текстовые элементы в структурных, а не наоборот, чтобы не было вложенных друг в друга интерактивных элементов, и т.д.), а в CSS — логичная структура боксов (внутри display:block — либо другие боксы блочного уровня, т.е. block, flex, grid, table или flow-root, либо боксы инлайнового уровня, т.е. inline/inline-что-то, но не те и другие вперемешку). Второе менее критично, т.к. здесь на как раз на помощь приходят анонимные боксы (CSS-боксы, не связанные ни с каким элементом), но обычно лучше не доводить до их появления. И нужна внимательность, поскольку с современным CSS эти две структуры (DOM-дерево и дерево отрисовки) практически независимы.

        1. Ага, то есть вы говорите, что анонимные боксы — это только на уровне css, который для стилистики, а не для структурной логики и семантики. Ясно…

          Вот о правильной структурной вложенности у меня вопрос прежде всего… Спецификация же «a» называет прозрачным элементом, в который можно вкладывать потоковое структурное содержимое, если «a» является потомком такого содержимого. В этом случае «a» наследует свойство размещения в себе потокового содержимого у родителя (в примере «a» наследует это свойство у секции «header»).

          Но, наследует ли «a» в этом случае свойство быть структурным элементом? По идее, чтобы не писать лишние «div» в вёрстке, было бы логично, если бы наследовал, но не понятно… Группирует ли в приведённом примере «a» эти 2 параграфа или всё-таки там нужен ещё «div» внутри «a»?

          1. Структурные роли элементов не наследуются, а компонуются, каждый отвечает за свою часть общей задачи. Элемент <a> никак не влияет на семантику содержимого <header> за исключением того, что делает его заодно еще и кликабельной ссылкой. А <div> не влияет на нее вообще никак и нужен чисто для оформительских или скриптовых задач, для чисто визуальной группировки никак иначе не связанных между собой элементов. В примере в обоих случаях группировка двух абзацев чисто визуальная, поэтому, если <a> с нужными стилями и так справляется с ней без посторонней помощи, добавлять <div> не нужно.

Оставить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

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