Хотя технически ссылки не являются обязательным условием для функционирования интернета (вы можете обойтись только с помощью URL), они являются основной причиной, по которой Интернет так славно заработал. Ссылки являются неотъемлемой частью каждой веб-страницы, без ссылок мы будем постоянно копировать URL-адреса (или не будем, потому что кому нравится работать так). Но реализация ссылок (a-элемент html) была нарушена с самого начала Интернета, и с добавлением ссылок на уровне блоков ситуация только ухудшалась.
Фундаментальный вопрос
Первый аргумент довольно старый (кажется, я впервые прочитал его более 10 лет назад). Элемент ссылки не вписывается в философию веб-дизайна аксиоматического дизайна контента-функциональности. Ссылка не является семантической, она ничего не говорит о содержании внутри и не является структурной. Вместо этого он обеспечивает функциональность (он переносит вас с одной страницы на другую) и сообщает вам абсолютный адрес содержимого, которое он переносит. Теперь я понимаю, что отсутствие его встраивания в html привело бы к огромным проблемам (вы не хотите, чтобы поведение ссылок на страницы было частью javascript), но пару лет назад появилась серьезная возможность улучшить ссылку html. реализация.
В части давно устаревшего синтаксиса xhtml2 предложена другая реализация ссылок. Вместо использования отдельного тега (который является чуть более чем оправданием для установки атрибута href), синтаксис xhtml2 заявил, что вы можете просто установить атрибут href для любого элемента, который необходимо связать. Прекрасная идея, которая была отвергнута из-за проблем обратной совместимости (и, вероятно, справедливо), но, по крайней мере, теоретически эта реализация имела гораздо больший смысл, чем текущая.
Вложенность вопроса
Еще одна постоянная проблема заключается в том, что ссылки не могут быть вложенными. Когда браузер обнаруживает вложенные ссылки, они становятся совершенно бесполезными, извергая все разные виды дерьмового кода (я не могу гарантировать, что эти более ранние результаты все еще верны, но я попробовал различные варианты того, как сделать статью о вашем браузере рвотной несколько лет назад) ,
Концептуально я все еще верю, что нет ничего плохого во вложенных ссылках (более глубокие вложенные элементы появляются поверх более высоких элементов в любом случае, поэтому здесь нет реальной проблемы), но, очевидно, это создает пару технических трудностей, которые трудно обойти , Это настоящее перетаскивание, если вы хотите заблокировать ссылку на весь html-узел (например, предварительный просмотр поста), но при этом хотите получить немедленную ссылку на комментарии поста. Никакого хорошего обходного пути не существует, если только вы не извлекаете прямую ссылку из представления поста.
Проблема на уровне блоков
Больше всего меня раздражает практический характер. Несмотря на то, что связанные состояния компонентов имеют визуальные вариации, тот факт, что a-элемент изменяет структуру dom связанных элементов по сравнению с несвязанными элементами, означает, что нельзя использовать должным образом комбинатор (>) для стилизации. Есть 3 основных способа решения этой проблемы, но ни один из них не является надежным.
Чтобы проиллюстрировать проблему, представьте, что я хочу заблокировать ссылку на превью постов на моей домашней странице. Несвязанный HTML-код будет выглядеть так:
<article class="post"> <header> ... </header> <div class="main"> ... </div> <footer> ... </footer> </article>
Довольно простая html-структура (которую я использую для разметки типов контента постоянно).
Tag-замена
<a class="post" href="..."> <header> ... </header> <div class="main"> ... </div> <footer> ... </footer> </a>
Один из самых простых способов заблокировать компоновку компонента — просто заменить базовый тег на тег a (что несколько подражает идеологии xhtml2). Он сохраняет структуру dom нетронутой, что, по крайней мере, теоретически делает стилизацию компонента намного проще и более устойчивой к изменениям в дальнейшем.
Проблема в том, что вы теряете семантическое значение базового тега (статья в этом примере), и как только вы зависите от HTML-тегов в ваших селекторах CSS (у вас могут быть body.post, article.post и a.post) переключатель между статьей и тегом становится настоящей рутиной в css.
Внешняя упаковка
<a href="..."> <article class="post"> <header> ... </header> <div class="main"> ... </div> <footer> ... </footer> </article> </a>
Внешнее обертывание элемента помогает сохранить конструкции дочернего селектора (например, заголовок .post>), оборачивая a-тег вокруг компонента, но вводит свой собственный набор ограничений. Контекстно-зависимый стиль становится намного сложнее (вы не можете просто нацелиться на .context> .post, но также должны принять во внимание .context> a), а когда запрашиваете у dom информацию, вы пропускаете содержание ссылки при поиске сообщений (если вы запрашиваете article.post, который не будет включать a + href, довольно большую проблему для синдикации путем очистки.
Хотя эта настройка имеет больше смысла с традиционной точки зрения (это то, как мы всегда связываем вещи, оборачиваем a-тег вокруг объекта, который мы хотим связать), это далеко от идеала при работе с практиками CSS.
Внутренняя упаковка
<article class="post"> <a href="..."> <header> ... </header> <div class="main"> ... </div> <footer> ... </footer> </a> </article>
Последний вариант — заключить компонент в оболочку, поместив ссылку прямо под корневым тегом. Как я упоминал ранее, это полностью нарушает структуру дочерних селекторов в вашем css, что является довольно серьезным препятствием только для того, чтобы связать определенный компонент. Даже если меньше (или sass) может вам помочь, это далеко от идеала и приводит к перегрузке ненужных правил CSS.
С другой стороны, сама ссылка заключена в тег article, который выглядит правдоподобным с точки зрения структуры html (поскольку ссылка содержит URL-адрес для подробного представления связанного компонента). Только по этой причине я использовал эту опцию с тех пор, как было разрешено связывание блоков.
Вывод
Я не доволен HTML-ссылками. С концептуальной точки зрения их реализация вообще не имеет смысла. Даже при том, что у меня возникают проблемы с обратной совместимостью, я чувствую, что текущая настройка не является действительно устойчивой, так что было бы неплохо продвинуться вперед.
Кроме того, довольно грустно видеть, что один из наиболее важных элементов нашего языка настолько сильно поврежден и создает такой беспорядок в нашем коде. В целом я рад, что html5 сделал сокращение, но в некоторых редких случаях мне хотелось, чтобы сохранилось больше идей о синтаксисе xhtml2.