Стандарт HTML5 уже почти готов к использованию. Где-то все еще идут жаркие споры по конкретным секциям DOM, видеокодекам, анимации и прочим 3D, но основа HTML5 — его синтаксис, атрибуты и теги — уже устаканились. Эти разделы стандарта не меняются уже многие месяцы; окончательно и по факту их зафиксируют релизы IE9 и FF4, после чего какие-либо их изменения в рамках пятой версии станут невозможны.
Так как костыли для старых версий IE уже созданы и обкатаны, то уже совсем-совсем скоро, начиная новый проект, можно будет открыть свой любимый редактор и, не скрывая наслаждения, написать
Сначала, конечно, html5 появится скорее в бложиках энтузиастов, чем на серьезных сайтах, но — вот увидите — через несколько лет в каждой региональной газете появятся объявления типа «ремонт и настройка ПК, заправка принтеров, 1С, сайты на HTML5».
В IT, как и в других областях техники, спецификации бывают хорошие, как у Страуструпа, а бывают плохие и даже отвратительные, как спецификация ECMAScript. По моему скромному мнению, спецификация HTML5 обещает стать воистину великой, просто-таки образцовой вершиной этого бюрократического жанра.
Пролистывая на выходных свежую версию черновика стандарта (от 5-ого марта), я в очередной раз не мог не восхититься изящностью принятых решений и филигранной точностью формулировок родившейся в тяжелых муках спецификации.
Эта статья о том, почему стандарт html5 получился именно такой, и что на самом деле скрывается за его внешне обтекаемыми формулировками.
Разработка HTML5 началась с революции — откола рабочей группы WHATWG в лице Mozilla, Opera и Apple от основного консорциума. Я не хочу пересказывать всю историю, но главной причиной раскола стало то, что в www-консорциуме («w3c») практически не осталось ни людей, связанных с реальным использованием html, ни даже разработчиков браузеров. Консорциум превратился в сборище корпоративных бюрократов, решавших свои собственные конкурентные и маркетинговые задачи.
В конечном итоге, конечно, бунтарям пришлось «покаяться» и получить необходимое благословение официальной бюрократии, поэтому многие места содержат формулировки, которые выглядят компромиссом, если не сказать прогибом. Но в техническом плане стандарт был создан не «демократически», а группой под авторитарным управлением Яна Хиксона, бывшего на тот момент разработчиком Оперы, и большинство компромиссов на самом деле имеют двойное дно.
Стоит отметить, что даже в режиме авторитарного управления разработка стандарта потребовала семи лет жарких споров, которые продолжаются на периферии и до сих пор. Я отлично понимаю, что «не всех война убила», и что публично поддерживая то или иное решение WhatWG, я отчаянно рискую своей кармой. Плевать; если хоть кого-то статья заставит задуматься, я буду рад. Как говорят на одном популярном Л-ресурсе, перед вами статья-детектор, в (комментах к) которой пока не хватает ненависти.
Простите за длинное вступление, я, кажется, увлекся. Итак.
Как вы, наверное, уже поняли, в HTML остался всего один тип документа, а именно
На данный момент действует одновременно 6 допустимых доктайпов — это по три диалекта (Frameset, Transitional и Strict) для двух языков — HTML и XHTML. Разумеется, не существует браузеров, отображающих, скажем, только XHTML Frameset; все [современные] реальные браузеры поддерживают все типы документов. Точнее, конечно же, они поддерживают некий супер-доктайп, обобщающий все шесть, который у каждого браузера — свой. В идеале, именно этот один универсальный доктайп и должен был остаться. Он и остался. Теперь это просто html.
Первым пал диалект Frameset; хотя кое-где в веб-интерфейсах китайских коммутаторов еще можно встретить фреймы, официально тег <frame> сотоварищи больше не существует. Туда ему и дорога. (Речь о совсем старых фреймах, <iframe> никто не трогал).
Вторым ожидаемо пал Transitional, который в дополнение ко всем тегам диалекта Strict содержал атрибуты, дублирующие CSS-свойства, такие как width и bgcolor. На заре внедрения HTML4 это было необходимо для обеспечения совместимыми со старыми сайтами и старыми браузерами, но сейчас это уже неактуально. Тэги font, center и им подобные, равно как и атрибуты align, valign, width, height, cellspacing и cellpadding остались в прошлом, и слава Богу. Разумеется, все сделано с умом: у тега img атрибуты width и height выполняют другую функцию, поэтому они никуда не делись.
Таким образом, остался диалект Strict, но для двух языков: HTML и XHTML. Вот здесь уже кипели нешуточные войны, языки собирались окончательно разойтись, но… ставший смертельным выстрел сделала Apple, выйдя из рабочей группы по XHTML 2.0. Победители, впрочем, вполне обоснованно не стали добивать этот формат и позволили ему продолжить существование в качестве подмножества HTML5. Объявляется «новый xhtml» так:
После такого объявления верстальщик добровольно обязуется соблюдать все требования XML, в том числе, строго нижний регистр, закрытие всех тегов и кавычки в атрибутах.
Сейчас я попробую объяснить, почему утвержденный вариант решения проблемы объединения нельзя назвать иначе как мудрым.
Творец всемирной паутины Тим Бернерс-Ли создал HTML не на пустом месте. HTML это приложение (подмножество) метаязыка SGML, работы над которым начались в IBM еще в 1969 году. Он мощен, гибок и имеет строгое математическое обоснование алгоримтов своего разбора, но его синтаксис позволяет достаточно вольные выкрутасы вполне в духе созданного тогда же языка Си, а написать корректный парсер HTML с учетом DTD достаточно сложно.
XHTML, хотя и очень похож на HTML с клевой буквой Х впереди (от столь приятной сердцу любого bullshit-маркетолога eXtensibility, «расширяемости»), основан не на SGML, а на XML, то есть представляет собой совершенно другой язык. XML — это созданный, кстати, w3c метаязык, синтаксис которого настолько прост и формален, что написать для него парсер способен любой знающий рекурсию школьник. В отличие от верстаемого преимущественно вручную HTML, XML ориентирован на программную генерацию кода, поэтому любое отклонение от формальной структуры в XML-файле cчитается исключительной ошибкой, свидетельствующей о сбое в программе-генераторе. По стандарту, невалидные XML документы должны объявляться непригодными к использованию, и в большинстве систем именно так все и происходит.
XML нашел широкое применение в различных распределенных системах, таких как ERP, CRM, в разнообразном коммерческом и банковском софте и т.п., где совместимость между самым разным железом и софтом, а также надежность передачи данных действительно очень важны.
Однако, подобное поведение — отказ от обработки всего документа при обнаружении любой ошибки — абсолютно неприемлемо для веба, где большую часть контента создают отнюдь не программы и даже не верстальщики, а сайт-менеджеры, писатели, блоггеры и, зачастую, рядовые посетители сайтов. Если условная «девочка» случайно забудет записать мантру < вместо символа «меньше» (<), XML — страница станет невалидной, и, по требованиям XML, вообще не должна отображаться браузером. Уже этого достаточно для понимания того факта, что XHTML был изначально мертворожденным.
Вообще, стандарт XHTML потребовался для того, чтобы использовать HTML-подобную разметку внутри XML-документов. Например, в XML-прайслисте может существовать поле «описание товара», в котором это самое описание может быть отформатировано при помощи XHTML-тегов (все тех же курсива <i>, ссылок <a>, разбивки на абзацы <p> и т.п.). До тех пор, пока это описание создается при помощи RichText поля ввода, которое само создает тэги и гарантирует валидность получаемого кода (пусть даже там каша из тегов, но валидная каша) — все нормально. Но как только возникает необходимость вставить текст, взятый «из дикого интернета», — в этот момент любые преимущества XHTML заканчиваются. Как бы глубоко не был xhtml совместим с xml, все равно необходимо писать отдельный парсер, который выкинет из внешнего html весь лишний css и javascript, причешет код и оставит только нужные тэги. Это не перетягивание одеяла и не желание усложнить кому-то жизнь, это, в первую очередь, очевидные требования безопасности и надежности.
В свое время стандарты XML и XHTML рекламировались производителями коммерческого софта как серебряная пуля, после которой наступит неизбежное совместимое счастье. XML действительно во многих случаях помог объединить разрозненные и плохо совместимые системы. В качестве примера можно привести ONIX XML, на котором в России работает полностью автоматический электронный обмен всеми коммерческими данными (прайсами, анонсами, заявками, накладными и т.п.) между всеми издательствами и подавляющим большинством книжных магазинов.
А вот с XHTML не сложилось. Очень многие разработчики клюнули на рекламу и стали использовать XHTML как некий «строгий» формат, он стал даже моден, но по факту 99.9% созданных на XHTML сайтов в условиях реальной эксплуатации все равно содержат ошибки, и, таким образом, не выполняют требования XML. Из-за этого ни один реальный браузер или серьезный парсер также никогда не полагается на XML-валидность и даже не ожидает ее. То есть, собственно во всемирной паутине, о которой и должен в первую очередь заботиться WWW Consortium, XHTML нормально не используется.
На практике, HTML никогда не применяется сам по себе. Обычно используется гремучая смесь html, css, javascript и какого-нибудь php или на чем там написана система управления сайтом. В последних трех языках, как и подавляющем большинстве других, синтаксис таков, что всё, заключенное в кавычки, считается строковой константой и код внутри кавычек дальше не интерпретируется; а вот все остальное заключать в кавычки нельзя или нежелательно. В XHTML же в кавычки должны быть заключены любые значения атрибутов, включая числа, идентификаторы, перечисления и так далее. Постоянные переключения синтаксиса в одном файле ни к чему хорошему не приводят, глаз программиста замыливается, и становятся возможными достаточно трудно вылавливаемые синтаксические ошибки.
Читаемость в xhtml также сильно отстает от читаемости html. Например, html-тег
превращается в монструозный
Когда код генерируется программно — это почти не проблема, если не считать лишние затраты памяти; но при ручной верстке весь этот цифровой мусор заметно снижает производительность труда.
Но главная беда XHTML, конечно же, это обязательность закрывающих тегов, за которыми не стоит никаких сущностей реального мира. Речь здесь о </td>, </p> и прочих </li>, использование которых в xhtml приводит к очень неприятным ошибкам, которые в обычных языках программирования принято называть ошибками проектирования.
Вот например тег </td>, который обозначает «конец ячейки таблицы». Этот самый конец ячейки не может существовать в чистом виде. В настоящих, а не абстрактных таблицах этот конец всегда совпадает либо с началом следующей ячейки, либо с концом всей таблицы. В xhtml же технически возможен (и с точки зрения XML даже валиден!) вот такой код:
Если скормить нечто такое браузеру, он взгрустнет, но текст между ячейками все-таки вынужденно отобразит. Где-то. Это «где-то» будет точно не внутри той таблицы, где встретилось это безобразие, а где-то еще. И непонятно с какими стилями. Если бы тега </td> не было, этот текст бы «прилип» к предыдущей ячейке и был бы сразу «вычислен» при отладке; ну в крайнем случае он был бы хотя бы показан прямо рядом с нужным местом, и читатель смог бы догадаться, что к чему. В XHTML же типичная «success story» представляет собой страницу с каким-нибудь сложным отчетом, который внезапно некорректно отображаться у пользователя IE для древней MacOS, и все что у вас есть — это скриншот, на котором часть ячеек уехало за пределы таблицы. Вот и ищите.
Я уж молчу о том, что будет с почти любой страницей, если ей влепить в случайное место лишний (непарный) </td>.
Это, конечно, не значит, что закрывающие теги вообще нельзя использовать. Можно и часто нужно. Но не всегда. В мире вообще мало вещей, которые должны соблюдаться всегда.
Чтобы все-таки обеспечить совместимость с XML, в html5 оставили не только закрывающие тэги для элементов-контейнеров, но и впервые для html допустили самозакрытые теги (в том числе тег <br/> вызывающий Warning в валидаторе HTML 4.01 Strict).
Из других нововведений в доктайп стоит отметить наконец-то добавленную расширяемость пользователем атрибутов тегов; теперь верстальщики могут записывать любую нужную им информацию в атрибуты data-*. Передавая параметры в какой-нибудь скрипт, который обработает ваши теги после загрузки, наконец-то можно забыть о rel, rev и прочих экзотических атрибутах как о потенциальных «осликах».
Резюмируя раздел о доктайпе:
1. WhatWG угодила всем бюрократам, нашедшим в спецификации понятные для себя слова, но не разбирающимся в технических деталях;
2. На самом же деле, они оставили из 6 виртуальных доктайпов один реальный, соблюдения которого действительно можно требовать и добиваться;
3. XHTML, как вещь, фактически не работающая на практике, официально прекратил существование;
4. В html5 стала возможной прямая выгрузка форматированного текста из XML в HTML;
5. Появилась возможность форматировать html валидно с точки зрения XML там, где это действительно нужно;
6. Язык html остался грамотно спроектированным и удобным для ручной верстки;
7. Наконец, стало официально невозможным создать прямой шлюз из «дикого» интернета в закрытые корпоративные XML-системы без установки промежуточного парсера, что хорошо с точки зрения безопасности.
Таким образом, двумя элегантными штрихами и одним метким выстрелом WhatWG сделал для реальной совместимости XML и HTML намного больше, чем весь язык XHTML за всю свою десятилетнюю историю и со всеми потраченными на его рекламу миллионами. Браво, иначе не скажешь!
Принцип семантической верстки в сайтостроении очень похож на антропный принцип в физике. В слабой своей форме они оба очевидны до степени аксиомы; в сильной же оба принципа являются исключительно вопросом веры, не имеющим отношения к данной нам Господом в ощущениях объективной реальности.
Итак, слабый принцип семантической верстки предписывает верстать, допустим, список, представляющий, скажем, меню сайта, с использованием (барабанная дробь) не таблиц, не блоков <div> и не простой последовательности ссылок с текстовыми разделителями — а, вы не поверите, с использованием списочных тегов <ol> или <ul>.
В сильном варианте все намного хуже. Верстая левую колонку сайта, запрещается называть её #left, потому как на самом деле это не просто левая колонка, а тулбар; и вообще, она может ВНЕЗАПНО стать правой, а названия в стилях и скриптах так и останутся #left и в будущем будут сбивать с толку. Ну, с доводами уровня «если бы у бабушки был кий» как-то даже не хочется спорить, а тема ООПухолей мозга на хабре полностью раскрыта. Блин, неважно, как называется тот или иной блок, если это название однозначно понятно всем, кто будет с ним работать; что касается переноса блока #left вправо без его переименования, то за такой «рефакторинг» нужно карать в любом случае.
К сожалению, ипсиссимусы секты семантистов пробрались в w3c и попытались отменить теги, существование которых противоречит их религии. Так, например, под вопросом оказалось существование тега <b>, обозначающего полужирное начертание текста (bold). Вместо него предлагалось использовать тег <strong>, который ранее применялся для выделения сильных (в смысле важных) утверждений.
В конце концов тег <b> партии здравого смысла удалось отстоять, но если раньше им обозначался просто полужирный текст, то теперь им следует выделять, цитирую, «spans of text whose typical typographic presentation is emboldened», то есть подстроки, которые обычно выделяются полужирным при печати. О как!
На первый взгляд, это решение из серии «и вашим и нашим» и вообще болтология, но, если разобраться, автор этой фразы достоин настоящих оваций и чемпионского звания в номинации бюрократического словоблудия. Это не сарказм, я сейчас объясню, что к чему.
Всё дело в тонкой логической ошибке в рассуждениях семантистов. Классы «полужирных» и «важных» подстрок совпадают не на 100%, а всего на 99%. Другими словами, существуют слова и фразы, обозначаемые полужирным шрифтом, но не выделяющиеся из текста семантически.
Примером могут служить векторные величины в математических формулах. Их принято обозначать стрелкой сверху, а когда это технически невозможно (как в случае HTML), — печатать полужирным шрифтом. Совсем не выделять их никак нельзя, так как могут существовать скалярные величины с таким же обозначением. Никакой «важности» сам факт векторности величины также не несет. Когда я рассказываю про вектор напряженности электрического поля E, тег <b> нужен мне в своем первозданном виде, чтобы отличать эту величину от энергии системы Е. И да, <span class=vector> с заведомо единственным стилем font-weight:bold на каждое упоминание Е просьба не предлагать. Мне работать надо, а не спотыкаться глазами о бесконечные спаны и классы.
Кроме того, далеко не всегда верстальщик имеет право вносить хоть какие-то изменения в текст. Бывают, например, произведения классиков, в которых они используют курсив и полужирное начертание исключительно в художественных целях (то есть так, как им лично захотелось), или, может, в соответствии с устаревшими на данный момент правилами языка, или еще как-то не по правилам. Тэги <strong> и <em>, вообще говоря, не должны быть обязательно полужирным и курсивом, они вполне могут выделять текст, допустим, другим цветом. От верстальщика классики же требуется строго сохранить авторское написание. Точка. Про span см. выше.
В-общем, <b> и <i> отстояли. Более того, в html5 переопределили смысл тега <strong>, теперь вместо «сильных» утверждений им следует выделять именно «важные» (англ. «important»).
Вот честно, в переопределении смысла тега <strong> я лично не вижу других мотивов, кроме мести за бредовость нового смысла <b>. Хотя, возможно, речь идет об обычном буквоедстве самих семантистов.
А вот тег <u>, обозначающий подчеркивание, отстоять не удалось. Официально — по той причине, что подчеркиванием в вебе принято выделять ссылки. Проблема в том, что выделение ссылок подчеркиванием это всего лишь культурный обычай определенной социальной группы. Всемирный стандартный формат текстовых (простите, гипертекстовых) документов должен быть универсальным и подходить в том числе для нужд представителей «оффлайновой» культуры. А в их книгах и документах подчеркивание встречается и активно используется и безотносительно ссылок. Из-за этого html5 теряет однозначную совместимость с распространенными текстовыми форматами, в которых подчеркивание есть. Его, разумеется, можно реализовать через стили, но здесь отсутствует именно однозначность такой конверсии.
Из позитивных изменений можно отметить тот факт, что в языке появились теги <header>, <footer>, <article> и прочие <nav>, которые в html4 почти всегда реализовывались при помощи тега <div> с «говорящими» идентификаторами или классами.
Сейчас нехватка в языке блочных тегов приводит к тому, что в html-коде почти любой современной страницы можно наблюдать цепочки вида </div></div></div>. В количестве этих </div> очень даже легко ошибиться, особенно если на странице есть контент, отправленный рядовыми пользователями. Лишний или просто расположенный не там </div> может привести к развалу всей верстки, причем в разных браузерах эффект будет разным. В случае же специализированных тегов, во-первых, статья будет всегда заканчиваться уникальным тегом </article>, и развал всей верстки странице грозить не будет, а во-вторых, запись <article> просто понятнее, удобнее и короче, чем <div class=article>.
Последним в рамках этой статьи изменением, достойном всяческих похвал, стало полное переосмысление тега <a>. Проблем с этим тегом столько, что в проекте XHTML 2.0 его предлагалось вообще удалить из языка, разрешив всем остальным тегам иметь атрибут href и куда-то ссылаться. (С тегом img и атрибутом src предлагалось поступить аналогично. Спасибо, Apple, мы не забудем!).
Изначально <a> предназначался для создания якорей на странице, и получил свое имя от слова anchor — «якорь». По задумке, выглядело это примерно так:
и, где-то в другом месте,
Но кривая развития веба сложилась так, что сначала использовать ссылки внутри страницы стало «немодно» и про якоря подзабыли, а затем редко используемый формат подхватили AJAX-приложения, которым было нужно как-то отображать своё состояние на адресную строку. но в которых уже не было никаких якорей.
Еще одной проблемой стала путаница между атрибутами id и name, которые могут не совпадать. Если первый должен обязательно быть уникальным, то атрибут name может быть общим для нескольких элементов, например, у образующих одну группу радиокнопок. При этом обозначение части ссылки в url через решетку указывает на атрибут name, но в CSS та же конструкция относится уже к id!
В-общем, теперь ссылка с #решеткой указывает на элемент не по name, а по его id, причем не на элемент <a> в режиме якоря, а вообще на любой элемент с объявленным id.
Сам же тег <a> якорем быть перестал. Теперь, если у <a> не указан атрибут href, считается, что это временно неработающая ссылка, которая возможно будет инициализирована скриптом. Что касается атрибута name, то у тега <a> он должен или совсем отсутствовать, или — для совместимости — совпадать со значением атрибута id.
Еще одно изменение связано с тем, что теперь тег <a> перестал считаться строчным элементом. То есть, в html4 внутрь тега <a> нельзя было включить пару абзацев или, скажем, таблицу. В html5 можно объявлять ссылкой и строчные, и блочные элементы.
Да, конечно, я тоже ненавижу, когда кто-нибудь в ЖЖ забудет закрыть ссылку, и вся его писанина на много абзацев выделяется цветом и подчеркиванием. Но иногда это все-таки нужно. Например, для создания HTML-баннеров с какой-нибудь анимацией, или (типичный вариант) чтобы сделать ссылкой красиво оформленный блок «название товара как h5 + картинка + цена + описание». Объявлять ссылку на один и тот же урл внутри каждого блочного элемента — не очень хорошая идея.
Читая новый стандарт, трудно избежать эпитетов типа «здорово!», «молодцы» и «надо же, и об этом не забыли!». Люди действительно работали эти семь лет, выявляя недостатки html4 и вырабатывая продуманные и взвешенные решения. Это невиданный доселе прогресс. Версии html 3.2 и ниже вообще фактически никем не разрабатывались. Версия 4 просто закрепляла в своей transitional-части фактическое состояние дел после браузерной войны. Так что пятая версия станет первой действительно спроектированной в том смысле, в каком принято что-либо проектировать в мире IT, и, черт побери, она станет хорошо спроектированной.
Да, конечно, как-то мы жили и раньше. Вопрос в том, как. Просто вспомните, что уходящая эпоха — это эпоха IE6. Этим все сказано.
Так как костыли для старых версий IE уже созданы и обкатаны, то уже совсем-совсем скоро, начиная новый проект, можно будет открыть свой любимый редактор и, не скрывая наслаждения, написать
<!doctype html>Сначала, конечно, html5 появится скорее в бложиках энтузиастов, чем на серьезных сайтах, но — вот увидите — через несколько лет в каждой региональной газете появятся объявления типа «ремонт и настройка ПК, заправка принтеров, 1С, сайты на HTML5».
В IT, как и в других областях техники, спецификации бывают хорошие, как у Страуструпа, а бывают плохие и даже отвратительные, как спецификация ECMAScript. По моему скромному мнению, спецификация HTML5 обещает стать воистину великой, просто-таки образцовой вершиной этого бюрократического жанра.
Пролистывая на выходных свежую версию черновика стандарта (от 5-ого марта), я в очередной раз не мог не восхититься изящностью принятых решений и филигранной точностью формулировок родившейся в тяжелых муках спецификации.
Эта статья о том, почему стандарт html5 получился именно такой, и что на самом деле скрывается за его внешне обтекаемыми формулировками.
Разработка HTML5 началась с революции — откола рабочей группы WHATWG в лице Mozilla, Opera и Apple от основного консорциума. Я не хочу пересказывать всю историю, но главной причиной раскола стало то, что в www-консорциуме («w3c») практически не осталось ни людей, связанных с реальным использованием html, ни даже разработчиков браузеров. Консорциум превратился в сборище корпоративных бюрократов, решавших свои собственные конкурентные и маркетинговые задачи.
В конечном итоге, конечно, бунтарям пришлось «покаяться» и получить необходимое благословение официальной бюрократии, поэтому многие места содержат формулировки, которые выглядят компромиссом, если не сказать прогибом. Но в техническом плане стандарт был создан не «демократически», а группой под авторитарным управлением Яна Хиксона, бывшего на тот момент разработчиком Оперы, и большинство компромиссов на самом деле имеют двойное дно.
Стоит отметить, что даже в режиме авторитарного управления разработка стандарта потребовала семи лет жарких споров, которые продолжаются на периферии и до сих пор. Я отлично понимаю, что «не всех война убила», и что публично поддерживая то или иное решение WhatWG, я отчаянно рискую своей кармой. Плевать; если хоть кого-то статья заставит задуматься, я буду рад. Как говорят на одном популярном Л-ресурсе, перед вами статья-детектор, в (комментах к) которой пока не хватает ненависти.
Простите за длинное вступление, я, кажется, увлекся. Итак.
1. Доктайп
Как вы, наверное, уже поняли, в HTML остался всего один тип документа, а именно
<!doctype html>Краткое пояснения для людей, не владеющих техническими тонкостями верстки. Тип документа — doctype — объявляет используемый данной страницей диалект языка, то есть допустимый набор тегов и атрибутов. Документы без указанного doctype считаются сверстанными по совсем старым правилам (до html4) и отображаются в режиме совместимости (quirks mode). Чтобы страница выглядела попиксельно одинаково в разных браузерах необходимо (но далеко не достаточно) правильно указывать доктайп и затем его придерживаться.
Проверка на соответствие реальной страницы заявленному доктайпу называется валидацией, а страница, прошедшая такую проверку — валидной. «Главный валидатор» находится на сайте W3C; также существуют валидаторы в виде плагинов к браузерам и IDE. Если в студии верстка ведется валидно, то такой валидатор-плагин позволяет сразу обнаруживать ошибки в коде на самой ранней стадии, зажигая лампочку «Хьюстон, у нас проблемы», даже если в браузере разработчика страница отображается полностью корректно. Кроме того, валидность оставляетслабуюнадежду на совместимость результата с будущими версиями браузеровMicrosoft.
На данный момент действует одновременно 6 допустимых доктайпов — это по три диалекта (Frameset, Transitional и Strict) для двух языков — HTML и XHTML. Разумеется, не существует браузеров, отображающих, скажем, только XHTML Frameset; все [современные] реальные браузеры поддерживают все типы документов. Точнее, конечно же, они поддерживают некий супер-доктайп, обобщающий все шесть, который у каждого браузера — свой. В идеале, именно этот один универсальный доктайп и должен был остаться. Он и остался. Теперь это просто html.
Первым пал диалект Frameset; хотя кое-где в веб-интерфейсах китайских коммутаторов еще можно встретить фреймы, официально тег <frame> сотоварищи больше не существует. Туда ему и дорога. (Речь о совсем старых фреймах, <iframe> никто не трогал).
Вторым ожидаемо пал Transitional, который в дополнение ко всем тегам диалекта Strict содержал атрибуты, дублирующие CSS-свойства, такие как width и bgcolor. На заре внедрения HTML4 это было необходимо для обеспечения совместимыми со старыми сайтами и старыми браузерами, но сейчас это уже неактуально. Тэги font, center и им подобные, равно как и атрибуты align, valign, width, height, cellspacing и cellpadding остались в прошлом, и слава Богу. Разумеется, все сделано с умом: у тега img атрибуты width и height выполняют другую функцию, поэтому они никуда не делись.
Таким образом, остался диалект Strict, но для двух языков: HTML и XHTML. Вот здесь уже кипели нешуточные войны, языки собирались окончательно разойтись, но… ставший смертельным выстрел сделала Apple, выйдя из рабочей группы по XHTML 2.0. Победители, впрочем, вполне обоснованно не стали добивать этот формат и позволили ему продолжить существование в качестве подмножества HTML5. Объявляется «новый xhtml» так:
<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml">
После такого объявления верстальщик добровольно обязуется соблюдать все требования XML, в том числе, строго нижний регистр, закрытие всех тегов и кавычки в атрибутах.
Сейчас я попробую объяснить, почему утвержденный вариант решения проблемы объединения нельзя назвать иначе как мудрым.
Творец всемирной паутины Тим Бернерс-Ли создал HTML не на пустом месте. HTML это приложение (подмножество) метаязыка SGML, работы над которым начались в IBM еще в 1969 году. Он мощен, гибок и имеет строгое математическое обоснование алгоримтов своего разбора, но его синтаксис позволяет достаточно вольные выкрутасы вполне в духе созданного тогда же языка Си, а написать корректный парсер HTML с учетом DTD достаточно сложно.
XHTML, хотя и очень похож на HTML с клевой буквой Х впереди (от столь приятной сердцу любого bullshit-маркетолога eXtensibility, «расширяемости»), основан не на SGML, а на XML, то есть представляет собой совершенно другой язык. XML — это созданный, кстати, w3c метаязык, синтаксис которого настолько прост и формален, что написать для него парсер способен любой знающий рекурсию школьник. В отличие от верстаемого преимущественно вручную HTML, XML ориентирован на программную генерацию кода, поэтому любое отклонение от формальной структуры в XML-файле cчитается исключительной ошибкой, свидетельствующей о сбое в программе-генераторе. По стандарту, невалидные XML документы должны объявляться непригодными к использованию, и в большинстве систем именно так все и происходит.
XML нашел широкое применение в различных распределенных системах, таких как ERP, CRM, в разнообразном коммерческом и банковском софте и т.п., где совместимость между самым разным железом и софтом, а также надежность передачи данных действительно очень важны.
Однако, подобное поведение — отказ от обработки всего документа при обнаружении любой ошибки — абсолютно неприемлемо для веба, где большую часть контента создают отнюдь не программы и даже не верстальщики, а сайт-менеджеры, писатели, блоггеры и, зачастую, рядовые посетители сайтов. Если условная «девочка» случайно забудет записать мантру < вместо символа «меньше» (<), XML — страница станет невалидной, и, по требованиям XML, вообще не должна отображаться браузером. Уже этого достаточно для понимания того факта, что XHTML был изначально мертворожденным.
Вообще, стандарт XHTML потребовался для того, чтобы использовать HTML-подобную разметку внутри XML-документов. Например, в XML-прайслисте может существовать поле «описание товара», в котором это самое описание может быть отформатировано при помощи XHTML-тегов (все тех же курсива <i>, ссылок <a>, разбивки на абзацы <p> и т.п.). До тех пор, пока это описание создается при помощи RichText поля ввода, которое само создает тэги и гарантирует валидность получаемого кода (пусть даже там каша из тегов, но валидная каша) — все нормально. Но как только возникает необходимость вставить текст, взятый «из дикого интернета», — в этот момент любые преимущества XHTML заканчиваются. Как бы глубоко не был xhtml совместим с xml, все равно необходимо писать отдельный парсер, который выкинет из внешнего html весь лишний css и javascript, причешет код и оставит только нужные тэги. Это не перетягивание одеяла и не желание усложнить кому-то жизнь, это, в первую очередь, очевидные требования безопасности и надежности.
В свое время стандарты XML и XHTML рекламировались производителями коммерческого софта как серебряная пуля, после которой наступит неизбежное совместимое счастье. XML действительно во многих случаях помог объединить разрозненные и плохо совместимые системы. В качестве примера можно привести ONIX XML, на котором в России работает полностью автоматический электронный обмен всеми коммерческими данными (прайсами, анонсами, заявками, накладными и т.п.) между всеми издательствами и подавляющим большинством книжных магазинов.
А вот с XHTML не сложилось. Очень многие разработчики клюнули на рекламу и стали использовать XHTML как некий «строгий» формат, он стал даже моден, но по факту 99.9% созданных на XHTML сайтов в условиях реальной эксплуатации все равно содержат ошибки, и, таким образом, не выполняют требования XML. Из-за этого ни один реальный браузер или серьезный парсер также никогда не полагается на XML-валидность и даже не ожидает ее. То есть, собственно во всемирной паутине, о которой и должен в первую очередь заботиться WWW Consortium, XHTML нормально не используется.
XHTML вообще странный язык. Продвигаемый как приложение (грубо говоря, подмножество) XML, он таковым не является. В XHTML существуют правила, например, запрет вложенности для тегов <a> и <p>, которые не могут быть выражены в терминах XML. То есть возможен код, валидный с точки зрения XML, но невалидный в XHTML. При этом, ради обеспечения XML-валидности были принесены в жертву гибкость и человекочитаемость html-разметки.
На практике, HTML никогда не применяется сам по себе. Обычно используется гремучая смесь html, css, javascript и какого-нибудь php или на чем там написана система управления сайтом. В последних трех языках, как и подавляющем большинстве других, синтаксис таков, что всё, заключенное в кавычки, считается строковой константой и код внутри кавычек дальше не интерпретируется; а вот все остальное заключать в кавычки нельзя или нежелательно. В XHTML же в кавычки должны быть заключены любые значения атрибутов, включая числа, идентификаторы, перечисления и так далее. Постоянные переключения синтаксиса в одном файле ни к чему хорошему не приводят, глаз программиста замыливается, и становятся возможными достаточно трудно вылавливаемые синтаксические ошибки.
Читаемость в xhtml также сильно отстает от читаемости html. Например, html-тег
<input id=doYouAgree type=checkbox selected disabled>превращается в монструозный
<input id="doyouagree" type="checkbox" selected="selected" disabled="disabled" />Когда код генерируется программно — это почти не проблема, если не считать лишние затраты памяти; но при ручной верстке весь этот цифровой мусор заметно снижает производительность труда.
Но главная беда XHTML, конечно же, это обязательность закрывающих тегов, за которыми не стоит никаких сущностей реального мира. Речь здесь о </td>, </p> и прочих </li>, использование которых в xhtml приводит к очень неприятным ошибкам, которые в обычных языках программирования принято называть ошибками проектирования.
Вот например тег </td>, который обозначает «конец ячейки таблицы». Этот самый конец ячейки не может существовать в чистом виде. В настоящих, а не абстрактных таблицах этот конец всегда совпадает либо с началом следующей ячейки, либо с концом всей таблицы. В xhtml же технически возможен (и с точки зрения XML даже валиден!) вот такой код:
<td> текст ячейки </td> текст между ячейками, отображайте где хотите <td></td>Если скормить нечто такое браузеру, он взгрустнет, но текст между ячейками все-таки вынужденно отобразит. Где-то. Это «где-то» будет точно не внутри той таблицы, где встретилось это безобразие, а где-то еще. И непонятно с какими стилями. Если бы тега </td> не было, этот текст бы «прилип» к предыдущей ячейке и был бы сразу «вычислен» при отладке; ну в крайнем случае он был бы хотя бы показан прямо рядом с нужным местом, и читатель смог бы догадаться, что к чему. В XHTML же типичная «success story» представляет собой страницу с каким-нибудь сложным отчетом, который внезапно некорректно отображаться у пользователя IE для древней MacOS, и все что у вас есть — это скриншот, на котором часть ячеек уехало за пределы таблицы. Вот и ищите.
Я уж молчу о том, что будет с почти любой страницей, если ей влепить в случайное место лишний (непарный) </td>.
Это, конечно, не значит, что закрывающие теги вообще нельзя использовать. Можно и часто нужно. Но не всегда. В мире вообще мало вещей, которые должны соблюдаться всегда.
Чтобы все-таки обеспечить совместимость с XML, в html5 оставили не только закрывающие тэги для элементов-контейнеров, но и впервые для html допустили самозакрытые теги (в том числе тег <br/> вызывающий Warning в валидаторе HTML 4.01 Strict).
Из других нововведений в доктайп стоит отметить наконец-то добавленную расширяемость пользователем атрибутов тегов; теперь верстальщики могут записывать любую нужную им информацию в атрибуты data-*. Передавая параметры в какой-нибудь скрипт, который обработает ваши теги после загрузки, наконец-то можно забыть о rel, rev и прочих экзотических атрибутах как о потенциальных «осликах».
Резюмируя раздел о доктайпе:
1. WhatWG угодила всем бюрократам, нашедшим в спецификации понятные для себя слова, но не разбирающимся в технических деталях;
2. На самом же деле, они оставили из 6 виртуальных доктайпов один реальный, соблюдения которого действительно можно требовать и добиваться;
3. XHTML, как вещь, фактически не работающая на практике, официально прекратил существование;
4. В html5 стала возможной прямая выгрузка форматированного текста из XML в HTML;
5. Появилась возможность форматировать html валидно с точки зрения XML там, где это действительно нужно;
6. Язык html остался грамотно спроектированным и удобным для ручной верстки;
7. Наконец, стало официально невозможным создать прямой шлюз из «дикого» интернета в закрытые корпоративные XML-системы без установки промежуточного парсера, что хорошо с точки зрения безопасности.
Таким образом, двумя элегантными штрихами и одним метким выстрелом WhatWG сделал для реальной совместимости XML и HTML намного больше, чем весь язык XHTML за всю свою десятилетнюю историю и со всеми потраченными на его рекламу миллионами. Браво, иначе не скажешь!
Новые теги и семантическая верстка
Принцип семантической верстки в сайтостроении очень похож на антропный принцип в физике. В слабой своей форме они оба очевидны до степени аксиомы; в сильной же оба принципа являются исключительно вопросом веры, не имеющим отношения к данной нам Господом в ощущениях объективной реальности.
Итак, слабый принцип семантической верстки предписывает верстать, допустим, список, представляющий, скажем, меню сайта, с использованием (барабанная дробь) не таблиц, не блоков <div> и не простой последовательности ссылок с текстовыми разделителями — а, вы не поверите, с использованием списочных тегов <ol> или <ul>.
А еще Кэп намекает, что шурупы хоть и можно забивать молотком, но отвертка все-таки удобнее.
В сильном варианте все намного хуже. Верстая левую колонку сайта, запрещается называть её #left, потому как на самом деле это не просто левая колонка, а тулбар; и вообще, она может ВНЕЗАПНО стать правой, а названия в стилях и скриптах так и останутся #left и в будущем будут сбивать с толку. Ну, с доводами уровня «если бы у бабушки был кий» как-то даже не хочется спорить, а тема ООПухолей мозга на хабре полностью раскрыта. Блин, неважно, как называется тот или иной блок, если это название однозначно понятно всем, кто будет с ним работать; что касается переноса блока #left вправо без его переименования, то за такой «рефакторинг» нужно карать в любом случае.
К сожалению, ипсиссимусы секты семантистов пробрались в w3c и попытались отменить теги, существование которых противоречит их религии. Так, например, под вопросом оказалось существование тега <b>, обозначающего полужирное начертание текста (bold). Вместо него предлагалось использовать тег <strong>, который ранее применялся для выделения сильных (в смысле важных) утверждений.
В конце концов тег <b> партии здравого смысла удалось отстоять, но если раньше им обозначался просто полужирный текст, то теперь им следует выделять, цитирую, «spans of text whose typical typographic presentation is emboldened», то есть подстроки, которые обычно выделяются полужирным при печати. О как!
На первый взгляд, это решение из серии «и вашим и нашим» и вообще болтология, но, если разобраться, автор этой фразы достоин настоящих оваций и чемпионского звания в номинации бюрократического словоблудия. Это не сарказм, я сейчас объясню, что к чему.
Всё дело в тонкой логической ошибке в рассуждениях семантистов. Классы «полужирных» и «важных» подстрок совпадают не на 100%, а всего на 99%. Другими словами, существуют слова и фразы, обозначаемые полужирным шрифтом, но не выделяющиеся из текста семантически.
Примером могут служить векторные величины в математических формулах. Их принято обозначать стрелкой сверху, а когда это технически невозможно (как в случае HTML), — печатать полужирным шрифтом. Совсем не выделять их никак нельзя, так как могут существовать скалярные величины с таким же обозначением. Никакой «важности» сам факт векторности величины также не несет. Когда я рассказываю про вектор напряженности электрического поля E, тег <b> нужен мне в своем первозданном виде, чтобы отличать эту величину от энергии системы Е. И да, <span class=vector> с заведомо единственным стилем font-weight:bold на каждое упоминание Е просьба не предлагать. Мне работать надо, а не спотыкаться глазами о бесконечные спаны и классы.
Кроме того, далеко не всегда верстальщик имеет право вносить хоть какие-то изменения в текст. Бывают, например, произведения классиков, в которых они используют курсив и полужирное начертание исключительно в художественных целях (то есть так, как им лично захотелось), или, может, в соответствии с устаревшими на данный момент правилами языка, или еще как-то не по правилам. Тэги <strong> и <em>, вообще говоря, не должны быть обязательно полужирным и курсивом, они вполне могут выделять текст, допустим, другим цветом. От верстальщика классики же требуется строго сохранить авторское написание. Точка. Про span см. выше.
В-общем, <b> и <i> отстояли. Более того, в html5 переопределили смысл тега <strong>, теперь вместо «сильных» утверждений им следует выделять именно «важные» (англ. «important»).
Вот честно, в переопределении смысла тега <strong> я лично не вижу других мотивов, кроме мести за бредовость нового смысла <b>. Хотя, возможно, речь идет об обычном буквоедстве самих семантистов.
А вот тег <u>, обозначающий подчеркивание, отстоять не удалось. Официально — по той причине, что подчеркиванием в вебе принято выделять ссылки. Проблема в том, что выделение ссылок подчеркиванием это всего лишь культурный обычай определенной социальной группы. Всемирный стандартный формат текстовых (простите, гипертекстовых) документов должен быть универсальным и подходить в том числе для нужд представителей «оффлайновой» культуры. А в их книгах и документах подчеркивание встречается и активно используется и безотносительно ссылок. Из-за этого html5 теряет однозначную совместимость с распространенными текстовыми форматами, в которых подчеркивание есть. Его, разумеется, можно реализовать через стили, но здесь отсутствует именно однозначность такой конверсии.
Из позитивных изменений можно отметить тот факт, что в языке появились теги <header>, <footer>, <article> и прочие <nav>, которые в html4 почти всегда реализовывались при помощи тега <div> с «говорящими» идентификаторами или классами.
Сейчас нехватка в языке блочных тегов приводит к тому, что в html-коде почти любой современной страницы можно наблюдать цепочки вида </div></div></div>. В количестве этих </div> очень даже легко ошибиться, особенно если на странице есть контент, отправленный рядовыми пользователями. Лишний или просто расположенный не там </div> может привести к развалу всей верстки, причем в разных браузерах эффект будет разным. В случае же специализированных тегов, во-первых, статья будет всегда заканчиваться уникальным тегом </article>, и развал всей верстки странице грозить не будет, а во-вторых, запись <article> просто понятнее, удобнее и короче, чем <div class=article>.
Новая жизнь тега <a>
Последним в рамках этой статьи изменением, достойном всяческих похвал, стало полное переосмысление тега <a>. Проблем с этим тегом столько, что в проекте XHTML 2.0 его предлагалось вообще удалить из языка, разрешив всем остальным тегам иметь атрибут href и куда-то ссылаться. (С тегом img и атрибутом src предлагалось поступить аналогично. Спасибо, Apple, мы не забудем!).
Изначально <a> предназначался для создания якорей на странице, и получил свое имя от слова anchor — «якорь». По задумке, выглядело это примерно так:
<h3><a name=chapter3>Часть 3</a></h3>и, где-то в другом месте,
... в <a href=#chapter3>третьей части</a>...Но кривая развития веба сложилась так, что сначала использовать ссылки внутри страницы стало «немодно» и про якоря подзабыли, а затем редко используемый формат подхватили AJAX-приложения, которым было нужно как-то отображать своё состояние на адресную строку. но в которых уже не было никаких якорей.
Еще одной проблемой стала путаница между атрибутами id и name, которые могут не совпадать. Если первый должен обязательно быть уникальным, то атрибут name может быть общим для нескольких элементов, например, у образующих одну группу радиокнопок. При этом обозначение части ссылки в url через решетку указывает на атрибут name, но в CSS та же конструкция относится уже к id!
В-общем, теперь ссылка с #решеткой указывает на элемент не по name, а по его id, причем не на элемент <a> в режиме якоря, а вообще на любой элемент с объявленным id.
Сам же тег <a> якорем быть перестал. Теперь, если у <a> не указан атрибут href, считается, что это временно неработающая ссылка, которая возможно будет инициализирована скриптом. Что касается атрибута name, то у тега <a> он должен или совсем отсутствовать, или — для совместимости — совпадать со значением атрибута id.
Еще одно изменение связано с тем, что теперь тег <a> перестал считаться строчным элементом. То есть, в html4 внутрь тега <a> нельзя было включить пару абзацев или, скажем, таблицу. В html5 можно объявлять ссылкой и строчные, и блочные элементы.
Да, конечно, я тоже ненавижу, когда кто-нибудь в ЖЖ забудет закрыть ссылку, и вся его писанина на много абзацев выделяется цветом и подчеркиванием. Но иногда это все-таки нужно. Например, для создания HTML-баннеров с какой-нибудь анимацией, или (типичный вариант) чтобы сделать ссылкой красиво оформленный блок «название товара как h5 + картинка + цена + описание». Объявлять ссылку на один и тот же урл внутри каждого блочного элемента — не очень хорошая идея.
Вместо заключения
Читая новый стандарт, трудно избежать эпитетов типа «здорово!», «молодцы» и «надо же, и об этом не забыли!». Люди действительно работали эти семь лет, выявляя недостатки html4 и вырабатывая продуманные и взвешенные решения. Это невиданный доселе прогресс. Версии html 3.2 и ниже вообще фактически никем не разрабатывались. Версия 4 просто закрепляла в своей transitional-части фактическое состояние дел после браузерной войны. Так что пятая версия станет первой действительно спроектированной в том смысле, в каком принято что-либо проектировать в мире IT, и, черт побери, она станет хорошо спроектированной.
Да, конечно, как-то мы жили и раньше. Вопрос в том, как. Просто вспомните, что уходящая эпоха — это эпоха IE6. Этим все сказано.
