HTML5 как победа научного материализма

    Стандарт HTML5 уже почти готов к использованию. Где-то все еще идут жаркие споры по конкретным секциям DOM, видеокодекам, анимации и прочим 3D, но основа HTML5 — его синтаксис, атрибуты и теги — уже устаканились. Эти разделы стандарта не меняются уже многие месяцы; окончательно и по факту их зафиксируют релизы IE9 и FF4, после чего какие-либо их изменения в рамках пятой версии станут невозможны.
    Так как костыли для старых версий 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, в разнообразном коммерческом и банковском софте и т.п., где совместимость между самым разным железом и софтом, а также надежность передачи данных действительно очень важны.
    Однако, подобное поведение — отказ от обработки всего документа при обнаружении любой ошибки — абсолютно неприемлемо для веба, где большую часть контента создают отнюдь не программы и даже не верстальщики, а сайт-менеджеры, писатели, блоггеры и, зачастую, рядовые посетители сайтов. Если условная «девочка» случайно забудет записать мантру &lt; вместо символа «меньше» (<), 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&gt я лично не вижу других мотивов, кроме мести за бредовость нового смысла <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. Этим все сказано.

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 194

      +26
      а бывают плохие и даже отвратительные, как спецификация ECMAScript

      О! Ещё один! Задолбали бросаться камнями в сторону JavaScript от непонимания.
        +11
        Javascript хороший язык, но с очень плохой спецификацией. Она насквозь мутная и при этом допускает множественные толкования там, где это недопустимо.
          +4
          JavaScript это всего лишь один из вариантов ECMAScript. Есть еще, например, ActionScript 3.
          | множественные толкования там, где это недопустимо.
          — ни разу не встречал. В общем не надо гнать на язык с которым не привыкли работать.

          А статья хорошая. Сам верстаю в XHTML — нравится порядок… Надо будет переучиваться :)
          • UFO just landed and posted this here
              +2
              Семантика, порядок, не особо помеха. Переучиваться — вряд ли, учиться — да! Я верстаю уже больше 7 лет… сейчас смотрю на html5 эксперементирую… жесть конечно :) учусь.

              строго имхо: По поводу JS, ребят, я дизайны рисую, и верстаю… с JS получается мегаинтересно. Как по мне JS просто обязан разваиватся, с ним веб будет лучше…
              0
              JavaSxript всего лишь — язык, а степень понимания зависит не только и не столько от спецификации
                0
                От спецификации зависит единообразие.
                Как ни крути, если что-либо может быть понятно неправильно — оно будет понято неправильно ©.
              –2
              Да уж, например, автоматическая расстановка точек с запятой — просто идеальный пример граблей, на которые вставал практически каждый. И эти грабли — не единственные.

              Можно на Javascript написать потенциально все что хочется, писать и в императивном, и функциональном стиле, но это требует больших усилий, чем в любом нормально спроектированном языке и выглядит монструозно и на грани читаемости в любом случае.
                +5
                Что? Какая «автоматическая расстановка точек с запятой»? Вы о стиле кодирования, где можно упускать знак ";"? Ну дык поменяйте стиль, ибо этот — вам не подходит)
                  +1
                  Я о том, что при переносе строк может полностью поменяться смысл кода.
                    +7
                    Это «от непонимания», о чём я и сказал в первом сообщении этой ветки
                      +3
                      Так им всем! Привыкли халявить и всякие а-это-же-не-обязательно символы пропускать, а потом «о боже, мой идеальный код не работает!»
                      0
                      Переносы строк вообще исчезают после сжатия.
                      Так что тут вопрос стиля кодирования. Если после точки с запятой всегда идет новая строка — проблем не будет.

                      P.S. Гуру JavaScript'а, поправьте меня, если я не прав.
                        0
                        Если после точки с запятой всегда идет новая строка — проблем не будет


                        И еще если новая строка ставится только после точки с запятой или египетских скобок.
                    +1
                    Курить Javascript: The Good Parts от Крокфорда
                      0
                      Это не мне надо курить, а TheShock. Насколько я помню, Крокфорд эту особенность в The Good Parts критикует. И вообще, где-то он говорил, что разочаровался в Javascript.
                        +1
                        Угу, как раз недавно обсуждали.
                        Крокфорд вообще поговорить любит. От этого Javascript хуже не становится.
                          +1
                          Только по ссылке не Крокфорд, а Eich, и не разочаровался, а сказал, что мог бы сделать и лучше :))

                          Но это я так, придираюсь
                            0
                            Ну вообще да)
                          0
                          Помимо критики, он так же говорит много чего про то, что в JS есть
                      0
                      Да уж придется потерпеть, коли так вышло.

                      Кстати, Douglas Crockford примерно такой же точки зрения придерживается.
                      Или он по-вашему тоже недопонимает JavaScript?
                        0
                        По-моему JavaScript плох даже после понимания…
                        +1
                        через несколько лет в каждой региональной газете появятся объявления типа «ремонт и настройка ПК, заправка принтеров, 1С, сайты на HTML5»
                        Сей отрывок вызвал у меня когнитивный диссонанс.
                          +7
                          У меня когнитивный диссонанс вызывает ник автора — хорошая статья, автор молодец!
                          +25
                          Имхо, статья длинная и достаточно тяжёлая. Впринципе, неплохая, но кое-где вы допустили ошибки.

                          Например, сравнение правильного именования элементов c «OOP» — некорректно.
                          Правильные имена должны быть в любой парадигме, в т.ч. процедурной.
                          Я приведу на примере класса, но точно так же можно взять в пример и процедурный код.
                          class Person {
                              public bool isOlderThan18 () {
                                  return this.age > 18;
                              }
                          };
                          // и так в приложении:
                          if (person.isOlderThan18()) {
                            print 'может покупать выпивку';
                          } else {
                            print 'не может покупать выпивку';
                          }
                          


                          Если изменится законы и совершенолетие будет наступать не в 18, а в 21, то придётся рефакторить весь код, потому корректно называть как-то так:
                          class Person {
                              public bool isAdult () {
                                  return this.age > 18;
                              }
                          };
                          


                          Грубо, конечно, но суть понятна.
                          Проблема в том, что в программировании это понимает большинство (хотя и не все именуют правильно), а вот за CSS в силу того, что язык разметки и многие относятся к нему «несерьёзно» сложилось мнение у многих, что можно именовать элементы по отображению.

                          И дело даже не в том, что содержимое может поменятся, а в том, что имя класса должно описывать сущность, что это за элемент и почему его необходимо выделить именно так, а не где он и какой он.
                            +1
                            У вас хороший пример, он отлично показывает оторванность семантистов от реальной жизни.
                            Понимаете, если вы пишете софт для крупной фирмы или государства, который будет крутится на серверных фермах ближайшие лет 30 — вы, безусловно, правы.
                            Но в мире верстки все совершенно не так. Там нет «законов», которые могут внезапно измениться. Есть макет дизайна, утвержденный заказчиком и дизайнером. Все, вот как оно есть в макете — так оно останется навсегда. Вся семантика, абстрактные классы и все прочие — это все предполагает, что будет версия 2.0, а за ней 3.0, и так далее. А в верстке этого не будет. Ну, то есть оно может и будет, но это будет совершенно другой дизайн, с совершенно другой, сделанной с нуля, версткой, как минимум на намного более новой версии CMS или вообще на другой CMS. Верстальщик решает конкретную задачу, у которой заведомо не будет продолжения. Любая абстракция в этой ситуации только вред.
                            Я, конечно, не рассматриваю ситуацию создания стандартного шаблона авторами CMS. Я говорю именно о студиях, выпускающих конечные сайты.
                              +29
                              Такие названия показывают наплевательское отношение разработчиков и/или непонимание сути вёрстки. Вся соль в том, что мне совершенно всё-равно, назвать этот метод "isAdult" или "isOlderThan18". Так само, как всё-равно, назвать класс "left" или "toolbar". Реализация не изменится, изменится только имя, которое для парсера совершенно не имеет смысла, пусть я его даже назву "sex" или "kak-ya-zdez-trahalsa-s-ie". Но если у вас проблема придумать осмысленное название классу элемента, то проблема в том, что вы просто не понимаете сути того, что вы делаете.

                              В современных ide отличная автозамена и при необходимости поменять все left на right не будет никакой проблемы. Но это просто хороший стиль программирования. Так само, как последовательные стандарты, разделение логики и представления, да и просто традиция писать все имена на английском, а не транслите.

                              Или вы не имеете ничего против названия класса «levaya-panel»? Это просто некрасиво и этому есть причины.
                                +21
                                если у вас проблема придумать осмысленное название классу элемента, то проблема в том, что вы просто не понимаете сути того, что вы делаете


                                Аплодирую. Если вдуматься, это наиболее точная формулировка принципу «осмысленности кода».

                              • UFO just landed and posted this here
                                  0
                                  Все, вот как оно есть в макете — так оно останется навсегда.
                                  Наверное это справедливо только для очень маленьких простых сайтов.
                                  В компании где я работаю, значительная часть тасков — правки уже существующих сайтов без кардинального изменения дизайна. И разумеется никто не перевёрстывает сайт заново, и уже тем более не переносит всё на другой движок. Зачем? Есть хорошо свёрстанный сайт, с отлаженным backend, зачем перевёрстывать всё заново если нужно внести правки?

                                  Чем легче поддерживать код — тем быстрее вносятся правки — меньше тратится времени — больше работы выполняется — больше денег — profit.
                                    0
                                    Поддержка — вообще отдельная тема.
                                    В данном случае, ИМХО, имеется в виду именно первичная разработка.
                                      +1
                                      Как таковая первичная разработка может быть только с зафиксированным ТЗ. Очень часто требования и ТЗ меняются до окончательной сдачи и первичная разработка плавно переходит в поддержку — сложно становится отделить разработку новых фич от изменения уже написанного для облегчения разработки нового. А если стоит вопрос выбрать имя для панели left или sidebar1, то, имхо, sidebar1 избавит от необходимости переименования в будущем, а в настоящем ничем разработку не задержит.
                                • UFO just landed and posted this here
                                    +2
                                    Если уж создали метод, то назовите его правильно — что он делает, а не повторите его исходный код. В этом идея моего сообщения. Согласны?
                                    • UFO just landed and posted this here
                                        +1
                                        Слишком не в тему. А зачем? Остановится надо тогда, когда надо остановится. Зависит от проекта, условий, денег, времени, желания, дурь на Солнце и ещё кучи факторов) Но ту часть, что вы _уже_ сделали — надо сделать качественно.
                                        • UFO just landed and posted this here
                                            +1
                                            Нет, вы занимаетесь подменой понятий.
                                            Вы всё-равно даёте этому диву название, вам не нужно проектировать, менять что-то или писать кучи кода, как в случае с дополнительными методами. Вам всего лишь нужно дать осмысленное название.
                                            Вы же не написали в комменте
                                            допустимо назвать ту штуку слева «left»

                                            вместо
                                            допустимо назвать сайдбар «left»

                                            И при общении с коллегами-программистами вы не будете говорить «добавь пару пунктов в левую штуку», а скажете что-то типа «добавь пару пунктов в тулбар».
                                            • UFO just landed and posted this here
                                                +2
                                                Подмена в том, что вы намеренно стараетесь убедить читателя в том, что дать осмысленное название настолько же тяжело, насколько тяжело написать несколько методов, хотя я утверждаю, что дать осмысленное название классу равносильно тому, чтобы дать осмысленное название методу.
                                                • UFO just landed and posted this here
                                                    +2
                                                    Не согласен. Если человек не потрудился более-менее нормально назвать блок, то он наплевательски относился к своей работе.
                                                    • UFO just landed and posted this here
                                                        +2
                                                        Где? Я всегда так говорил.
                                      0
                                      Мне кажется, что этот момент в условиях веб-разработки во многом зависит от бюджета и сроков. Можно навертеть кучу предусмотренных возможностей, но они не будут укладываться в бюджет, вы сорвете сроки разработки и провалите проект.


                                      Сорвать сроки могут как раз неосмысленные названия, которые будут замедлять ход последующей разработки.
                                      • UFO just landed and posted this here
                                          +2
                                          Смотрите, при создании ПО ничего не пишется с бухты-барахты. Каждый слой абстракции — это не только дополнительный слой абстракции, но и время на его написание, следовательно деньги на его написание.

                                          При создании ПО балансируют между двумя факторами — «деньги, затраченные на создание сейчас» против «деньги затраченные на поддержку потом». Так вот, осмысленные название значительно сокращают деньги, затраченные на поддержку потом, при этом увеличение стоимости создания стремится к нулю.
                                          –1
                                          Блин, ну что значит неосмысленные?
                                          Вы вообще понимаете, о чем речь?
                                          Есть CMS.
                                          В ней, к примеру, есть 4 потенциальных места для вставки блоков — слева, справа, сверху и снизу.
                                          Где-то в админке красивыми кнопочками указывается: логин слева, корзина справа, новости тоже справа под корзиной, баннер сверху.
                                          Потом придет условный сеошник и скажет: выкиньте баннер, зато сделайте мне блок сео-ссылок снизу.
                                          А ему — да пожалуйста, у нас все заложено в шаблоне. Здесь нажмите «выкл», а здесь «вкл».

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

                                          И вот как, по вашему, назвать общий контейнер для левых блоков, если не #left?
                                          • UFO just landed and posted this here
                                              0
                                              И что мешает ему это сделать из админки?
                                              0
                                              Ага. А в этой же CMS будет возможности менять шаблоны. Потому ни в какой нормальной цмске не делают блоков с названиями «left» и «right». В том же phpbb3 аватарки пользователей по-умолчанию справа, но можно легко поставить их слева.
                                                0
                                                Да вы что? Это вы сейчас phpbb3 назвали нормальной, да еще и CMS?
                                                О да, простите, в Wordpress колонки действительно называются не left и right, а col1 и col2. Точнее наоборот. Действительно, это семантический прорыв!
                                                  0
                                                  Я phpbb вообще оценки не давал, не надо мне приписывать того, что я вам не говорил.
                                                  Да, "{name}1" и "{name}2" — это куда лучше для абстрактных и равнозначных блоков, чем «left» и «right». Хотя, конечно, название получше можно было подобрать, чем «col»
                                                    0
                                                    Ну, подберите, если вы считаете, что можно лучше.
                                                    Давайте, давайте. Вот есть абстрактная колонка. Вы не знаете, что в ней будет, и где она собственно говоря будет. Это просто колонка. Есть вот в верстке такие объекты как колонки.
                                                    Придумайте ей название лучше чем col.
                                                      –1
                                                      container? =) все-равно надо смотреть по ситуации. всегда есть предназначение у колонки.
                                                        +4
                                                        box? block? panel? bar? square? place? plate? :)
                                                          0
                                                          Между прочим, можно взять название «aside» из html5
                                                            –1
                                                            aside у меня ассоциируется с чем-то посторонним. Не нравится мне это слово.
                                                0
                                                И таки я не понимаю вашего примера.
                                                «В ней, к примеру, есть 4 потенциальных места для вставки блоков — слева, справа, сверху и снизу.»
                                                Ага, сразу под блоком с ссылками, над панелью управления, два места в хедере и три — в футере. И что? А в другом шаблоке ссылки будут справа, а панель управления — слева?
                                                  –2
                                                  Вы админку джумлы там, или там вп, или амиры, или шоп-скрипта, или уме, или еще какой-нибудь user-friendly cms когда-нибудь видели?
                                                    0
                                                    Ага.
                                                      –4
                                                      image
                                                        0
                                                        И что? Таким же образом можно было написать «в шапке», «в меню», «в тулбаре», «в подвале».
                                                        И если верстальщик поменяет два блока местами, то секретарша не будет кричать: «почему я говорю поставить его справа, а оно стоит слева??!!»
                                                          –3
                                                          Вы вообще понимаете, что вы пишете?
                                                          Если верстальщик поменяет местами блоки left и right, чтобы довести до слез секретаршу, я его уволю.
                                                          Другими методами это не лечится.
                                                            +1
                                                            Вы вообще понимаете, что вы пишете? Верстальщик может поменять местами два блока, потому что ему так скажет ваш шеф.
                                                              –4
                                                              Азм есть шеф.
                                                              Я не стану отдавать приказ поменять местами блоки left и right, не меняя их названий.
                                                                +1
                                                                Сочувствую вашему верстальщику.
                                                                  0
                                                                  … на каждую мелкую правку переписывать тонны кода
                                                                    0
                                                                    В том-то и дело, что наименование блоков должно быть очевидно и понятно всем, кто с ними будет работать. А какое именно оно должно быть — это все болтология.
                                                                    Как я и написал в статье, это уже вопрос веры. Логикой тут ничего не докажешь, так что на этом предлагаю закончить.
                                                          +1
                                                          Ну, во-первых, там указана позиция, а не название блока, а во-вторых, в хорошей CMS должно быть все по-другому: шаблон определяет набор динамических блоков (позиций, условно говоря) со своими названиями, и при вставке блока-виджета надо выбирать «Хедер», «Левый сайдбар», «Текст внутри между третьим и четвертым постом», а не вот этот ужас, что на картинке. (Кстати, если сделать управление блоками sortable-списком будет круче)

                                                          Простите, конечно, за упоминание недостойного Вордпресс, но (это я к примеру, одним ВП все не заканчивается) управление меню и виджетами там как раз так и сделано.

                                                          В общем, для того, чтобы хорошо верстать и держать в поддержке код (а даже мелкие шаблончики на ВП приходится, нет-нет, и доделывать, переверстывать по чуть-чуть), надо, чтобы архитектура у движка была в поряде :)
                                                            –2
                                                            Скажите пожалуйста, чем названия «хедер» и «левый сайдбар» лучше для нормального русского человека, чем «сверху» и «слева»?
                                                            На картинке показано именно то, что вы описали.
                                                              0
                                                              На третий пункт взгляните. А потом подумайте еще раз, чем три блока «Подвал сайта», «Левая колонка» и «Реклама в тексте» лучше. И давайте заканчим тему идиотского именования файлов, идентификаторов и переменных, ведь это с опытом приходит, правда ведь?
                                                                +2
                                                                В том-то и дело, что молодежь начитается всякой модной фигни о том, что крутые пацаны обязательно придерживаются семантических правил и паттернов, прости Господи, проектирования, а потом приходит на работу и с умным видом начинает городить огород на 10 файлов, создавать себе проблемы и героически, но не до конца их решать там, где надо написать 1 простую строчку кода и пойти дальше.
                                                                С опытом как раз приходит понимание, что для каждого средства есть свой калибр целей, и что реально больших целей в этой жизни мало.
                                                                  +1
                                                                  Та да, все — лохи, а вы ;)
                                                                    +2
                                                                    Это не опыт, это усталость :)
                                                                      +1
                                                                      Я все же поясню, на мой взгляд, очевидную вещь (что правила и стандарты облегчают жизнь в дальнейшем). Паттерны и семантика, прежде всего служат для облегчения поддержки (особенно, при работе в команде, хотя клиент также не должен быть привязан к программисту, который им верстал небольшой шаблон), возможность масштабирования (планирование «на вырост») и реюзабельность (я в большинстве своих проектов верстки использую уже готовые шаблоны, в которых все уже поименовано, плюс не стоит забывать о том, что движок также может быть сменен, тогда хорошо сделанная верстка может быть легко адаптированна под новую архитектуру шаблона).

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

                                                        CMS, логика админки которой становится непредсказуемой от изменения CSS шаблона, сложно назвать юзабельной и универсальной, по-моему. А если мне нужно три сайдбара — два левых и один правый — как мне указать второй слева? Как-то завязывать серверную логику на классы html-элементов («left», «left1» => «слева», «left2» => «справа»)? А при натягивании стороннего шаблона переименовывать всё? Куда юзабельнее и универсальнее, по-моему, чтобы админка показывала визуально расположение панелей с их именами для данного шаблона, а пользователь задавал в какую панель поместить блок по её имени.
                                                          +1
                                                          Вы мыслите Jooml-ой
                                                    +5
                                                    Отличная статья, прочитал на одном дыхании. Спасибо. Был не в курсе про изменение поведения тэга a. *Пошёл проверять свои реализации*
                                                      +1
                                                      HTML не настолько хорош, как тут пытается рассказать автор ;)

                                                      В частности, frames deprecated, а что на замену?

                                                      И сейчас не вспомню, но там еще есть толпа других проблем
                                                        +4
                                                        А зачем вам фреймы? Тогда уж и обсудим замену.
                                                          +2
                                                          Сплиттеры. Единственный способ их сделать нативно, без толп яваскрипта. И хоть с какой-то поддержкой в том же mobile safari
                                                            –2
                                                            Что такое «сплитеры»?
                                                                +4
                                                                *Я научусь просматривать ссылки прежде, чем их постить*

                                                                methvin.com/splitter/
                                                                  0
                                                                  Ага, значит это штучка между двумя блоками, которой можно регулировать их размер?
                                                                  И именно для этого нужно оставить в стандарте фреймы, которые имеют кучу недостатков?
                                                                  Тем более, вам не надо писать кучу js-кода, ведь он уже написан в виде плагина для jQuery
                                                                    +3
                                                                    > И именно для этого нужно оставить в стандарте фреймы, которые имеют кучу недостатков?

                                                                    Недостатки надо устранять, а не убирать с глаз долой.

                                                                    > Тем более, вам не надо писать кучу js-кода, ведь он уже написан в виде плагина для jQuery

                                                                    И еще десятка других плагинов. Повторю:

                                                                    Убрать функциональность полностью и сказать «трахайтесь, реализуйте сами» — это не прогресс, а регрессия.

                                                                    Повторю:

                                                                    И хоть с какой-то поддержкой в том же mobile safari
                                                                      0
                                                                      Кстати, а можете перечислить недостатки фреймов?
                                                                0
                                                                Фрейм, в данном случае, является логикой поведения. То что ms не поддерживает скрипты, означает то что ему нужно подсовывать мобильную версию софта, без скриптов и html5, на каком нибудь chtml, а не то что нужно реализовывать логику поведения на html. А с dragenter-dragleave событиями html5 сплитер становится легок в реализации как никогда…
                                                                  0
                                                                  При чем тут MS????

                                                                  >А с dragenter-dragleave событиями html5 сплитер становится легок в реализации как никогда…

                                                                  Нихрена он легким не становится. Не говоря уже о мобильных браузерах
                                                                    0
                                                                    Mobile Safari ведь
                                                                      –2
                                                                      Что Mobile Safari?
                                                                      0
                                                                      Намного легче чем отлавливать и хранить событие mousedown, mousemove, mouseup… А про мобильные браузеры я уже сказал: Нефиг пользователю с экраном в 320x240 подсовывать сплиттеры, использовать надо тот инструмент, который для этого заточен.
                                                                      Убрать функциональность, которая скорее вредна, чем полезна — добро. Это как заменить карбюратор на инжектор в машине, вместо того чтобы прикручивать к карбюратору микроконтроллеры…
                                                                        +3
                                                                        > Намного легче чем отлавливать и хранить событие mousedown, mousemove, mouseup…

                                                                        Все равно нафига это реализовывать самому с нуля?

                                                                        > Нефиг пользователю с экраном в 320x240 подсовывать сплиттеры, использовать надо тот инструмент, который для этого заточен.

                                                                        Вы про iPad слышали? Нет? Просветитесь

                                                                        > Убрать функциональность, которая скорее вредна, чем полезна — добро.

                                                                        Фреймы внезапно стали вредными? Нуну. Как много нам открытий чудных…
                                                                      +2
                                                                      И, вдобавок. Убрать функциональность полностью и сказать «трахайтесь, реализуйте сами» — это не прогресс, а регрессия.
                                                                      0
                                                                      миллион лет их не видел :). ну, кроме одного на js :)
                                                                        +2
                                                                        Зато в сложных системах/cms/интранетах они используются на ура
                                                                      0
                                                                      Браузерка. Фрейм под чат, фрейм под список игроков онлайн, основной фрейм.
                                                                      Речь о текстовых браузерках, а-ля БК.
                                                                        0
                                                                        javascript'ом получится намного лучше.
                                                                          0
                                                                          Не хочу начинать холивар, но на JS придется делать тучу кода, чтобы работало хотя бы то же изменение размеров фрейма путем перетаскивания границы мышью.
                                                                            0
                                                                            Ага. Тоже в сплитерах проблема?
                                                                              0
                                                                              Ну в основном да, не считая работы по переделке кода.
                                                                                +1
                                                                                Старая добрая табличка иной раз спасает :)
                                                                              • UFO just landed and posted this here
                                                                                  0
                                                                                  И тащить за собой фреймворк?
                                                                                  • UFO just landed and posted this here
                                                                                      0
                                                                                      [irony]Браузеры не умеют отображать ассмеблер :([/irony]
                                                                                      • UFO just landed and posted this here
                                                                                          +2
                                                                                          Каюсь, применил неверный глагол.
                                                                                          Не умеют исполнять ассемблер.
                                                                                            0
                                                                                            реквестирую в топик какой-нибудь джаваскрипт-эмулятор асма…
                                                                                              +2
                                                                                              Я знал содержание коммента еще до открытия уведомления о нем :D

                                                                                              По-моему, таковых нет.
                                                                      +13
                                                                      основан не на SGML, а на XML, то есть представляет собой совершенно другой язык
                                                                      XML является подмножеством SGML.

                                                                      Вообще, стандарт XHTML потребовался для того, чтобы использовать HTML-подобную разметку внутри XML-документов.
                                                                      Не совсем так, хотя для этого он тоже пригоден. Вы можете и так использовать HTML-разметку (с незакрытыми тэгами и незакавыченными атрибутами) внутри XML — завернув ее в секцию CDATA.
                                                                      W3C создавала XHTML с расчетом, что разработчики будут создавать свои неймспейсы и использовать их. После чего они посмотрели бы на часто используемые неймспейсы и включили бы их в следующий стандарт.

                                                                      В XHTML существуют правила, например, запрет вложенности для тегов <a> и <p>, которые не могут быть выражены в терминах XML.
                                                                      А в терминах чистого XML такие вещи и не контролируются. XML должен быть well-formed. Всякие вещи типа вложенности тэгов, допустимости у их тех или иных атрибутов и т.д., т.е. все, что касается именно валидности, контролируются средствами проверки грамматики — типа DTD, XSD и RelaxNG.
                                                                        –1
                                                                        … и все они основаны на текстовых файлах. Спасибо, кэп.
                                                                        Попробуйте выразить в виде правил XSD тот факт, что запрещено делать вложенные абзацы.
                                                                          +2
                                                                          Ваще-то легко. XSD позволяет указать элементы, которые разрешается вкладывать. Соответственно, все неперечисленные — запрещено.
                                                                          Ну, а в RNG это еще проще.
                                                                          А в DTD, кажется, не получится — но я не говорю, что это равнозначные технологии.
                                                                        +7
                                                                        Не понимаю зачем ждать. Уже сейчас можно использовать HTML5, вообще не вижу причин не делать этого. Я на всех проектах по умолчанию верстаю в HTML5.
                                                                          +1
                                                                          >Я на всех проектах по умолчанию верстаю в HTML5.
                                                                          Под версткой в HTML5 вы понимаете верстку с doctype HTML5 или избыточную и инвалидную верстку с костылями для броузеров которые не поддерживают новшества HTML5, еще не принятого в качестве стандарта?
                                                                            –1
                                                                            В чём invalid'ную?
                                                                              0
                                                                              Инвалидная означает, что верстка ходит на JS-костылях, а без них она превращается в говно.
                                                                              Отдельные продвинутые индивидуумы типа TecHMeaT, считают это нормой. Впрочем у него много заблуждений. Например он уверен, что тупорылому Яндексу непофиг какой стандарт используется для верстки. Это, кстати, достаточно оригинальная и свежая ересь.
                                                                                +4
                                                                                Спасибо за комплимент :)
                                                                                Да, считаю нормой. Объясняю свою позицию. В нормальных браузерах всё хорошо, а у ослов всегда всё тормозило, и если сайт отрисуется на полсекунды медленнее, чем в нормальном браузере — да ну и что, пользователи ослов привыкли к тормозам, они не заметят разницы.
                                                                                Кроме «тупорылого» Яндекса есть еще несколько поисковиков. Всем им пофиг какой стандарт. Им важна семантика. Так уж сложилось, что HTML5 семантичнее старых версий. Логично?
                                                                                И вся эта моя «ересь» не единожды подтверждалась на деле в реальных проектах.
                                                                                Удачно вам оставаться на прямых ногах в прошлом, а я на костылях побежал в будущее!
                                                                                  0
                                                                                  >а я на костылях побежал в будущее!
                                                                                  С человеком бегущим на костылях в будущее особо спорить не хотелось бы. Но все же.
                                                                                  >у ослов всегда всё тормозило, и если сайт отрисуется на полсекунды медленнее,
                                                                                  Неприятность в костылях не столько в задержке, а в том что пока они не отработали сайт отображается криво, а потом скачками начинает выправляться. Причем если верстка сложная, а элементов требующих костылей много, полсекундой может и не обойтись — юзеры IE работают не на самых новых комп.
                                                                                  >И вся эта моя «ересь» не единожды подтверждалась на деле в реальных проектах.
                                                                                  Это и есть ересь. Говорить о влиянии чего-либо на алгоритмы поиска основываясь на 2-3 «реальных проетах», может толкьо человек не понимающий что такое SEO. Вы даже не удосужились погуглить эту тему. Я это сделал за вас:
                                                                                  Почитайте что по этому поводу думают в Google:
                                                                                  www.google.com/support/forum/p/Webmasters/thread?tid=1d3850aec4e3dd96&hl=en
                                                                                  — здесь специалисты Google говорят что им пох HTML5
                                                                                  www.google.com/support/forum/p/Webmasters/thread?tid=2d4592cbb613e42c&hl=en
                                                                                  — Здесь они говорят то же самое и рекомендуют особо торопливым бежать на костылях взад:
                                                                                  Personally, I would recommend using HTML5 where you think that it already makes sense, perhaps reverting to HTML4 if you can determine that the browser won't support the elements of HTML5 that you use properly. While this will not result in an advantage for your content in our search results, it generally wouldn't be disadvantageous either.
                                                                                    0
                                                                                    Чёрт, Вы меня не переубедили )
                                                                                    Через 2 года сегодня оставленные мною костыли будут уже просто лишней строчкой в коде.
                                                                                    А гуглил ли я… Я перечитал достаточно много литературы по этому поводу, в том числе документацию Google, где достаточно ясно написано, каким для него код является идеальным. Разработчики Google на конференциях повторяют тоже самое и приводят факты.
                                                                                    Действительно, не будем спорить. Пусть каждый решит для себя что есть идеал.
                                                                                      –1
                                                                                      >Я перечитал достаточно много литературы по этому поводу
                                                                                      Лучше признайтесь, что никогда не занимались SEO а про HTML5 в этой связи сболтнули неподумавши.
                                                                                      Впрочем можете и не признаваться. Оно и так ясно.
                                                                                        0
                                                                                        Вы наверное матерый продвигайзер, куда мне, грузчику с ликероводочного…
                                                                                        Это я так, наткнулся на пару текстов в гуглокоде, подумал, что полезная инфа, наверное они меня наивного обманули. Что-то где-то еще находил, но там по басурмански написано было, наверное я не так понял смысл :(
                                                                                        Всё-всё, больше не спорю. Теперь я постиг вселенскую истину!
                                                                                      0
                                                                                      Бывают случаи, когда целевой аудиторией является бот Яндекса.
                                                                                      Тогда можно хоть HTML 1 использовать, лишь бы он страницы кушал :)
                                                                                –1
                                                                                Под версткой в HTML5 я понимаю именно «верстку», а не доктайп :)
                                                                                Вы видимо плохо представляете, что такое HTML5, раз называете верстку в этом стандарте избыточной и инвалидной. А то что ослам нужны костыли — давно устоявшаяся практика, нет смысла холиварить по этому вопросу.
                                                                                В моей верстке всё работает и работает нормально. Сайты с моей версткой отлично видятся поисковиками, гораздо лучше, чем с классической версткой. Для меня эти 2 показателя являются решающими и… я хотел с высокой колокольни на всякие другие типа минусы.
                                                                                0
                                                                                Понимаете, пока не вышел IE9 — могут быть эээ… сюрпризы. Ну оно конечно здорово, что стандарт предельно понятный и точный, но вот с IE никогда нельзя знать заранее. А вдруг они какой-то пункт поняли не так? И из-за этого ваша верстка поплывет?
                                                                                  0
                                                                                  С CSS3 можно этого опасаться, с HTML5 всё устаканилось и сюрпризов не будет. Я имею ввиду только разметку HTML5 а не тренд в целом. Никто никуда не поплывет )
                                                                                  0
                                                                                  Во всех проектах используете header footer article и прочий nav?
                                                                                    0
                                                                                    По умолчанию, если нет обстоятельств против этого.
                                                                                  +8
                                                                                  Верстая левую колонку сайта, запрещается называть её #left, потому как на самом деле это не просто левая колонка, а тулбар

                                                                                  Потому, что когда мы захотим сделать поддержку арабского или иврита, колонка #left в комбинации direction: rtl; будет вызывать разрыв шаблона. Впрочем, так делать было неправильно и для HTML 4.01 То, что это зафиксировали в гайдлайнах — это правильно.

                                                                                  что в html-коде почти любой современной страницы можно наблюдать цепочки вида </div></div></div>. В количестве этих </div> очень даже легко ошибиться

                                                                                  Эммм, вы не пробовали редактировать код сайта не в нотепаде, а в редакторе с подсветкой парных тегов и переходами между ними? Если уж более «девелоперский» Scite это умеет, то всякие Notepad++ — тем более.

                                                                                  особенно если на странице есть контент, отправленный рядовыми пользователями. Лишний или просто расположенный не там </div> может привести к развалу всей верстки

                                                                                  А вот за возможность рядовым пользователям писать произвольный HTML, еще и без контроля за парностью тегов нужно отрывать кий. По самую бабушку.
                                                                                    0
                                                                                    Как отобразить браузеру или подсветить редактору невалидные конструкции? (Почему их нужно все равно отображать написанно в статье).

                                                                                    <div><div><div></div></div>
                                                                                    Не закрыт внешний тэг? (А внешние тэги отвечают я верстку макета)

                                                                                    Но судя такой записи
                                                                                    <div><article><div></article></div>
                                                                                    Можно утверждать что ошибка в нутри контейнера article и отобразить страницу более корректно

                                                                                    PS За незакрытые тэги нужно не только кий отрывать…
                                                                                    • UFO just landed and posted this here
                                                                                        0
                                                                                        > Как отобразить браузеру или подсветить редактору невалидные конструкции?


                                                                                        О да, автоматическое исправление таких тривиальных (если не сказать «тупых») ошибок — очень полезно. Чтобы Вася Пупкин мог не отвлекаться на всякие мелочи типа незакрытых тегов при разработке своего мега-портала.
                                                                                      +3
                                                                                      Не так хороша статья, как ее заголовок =). Спасибо, порадовали с утра =). Теперь работаться будет веселее =)
                                                                                        +2
                                                                                        В статье интересные моменты почерпнула. Особенно про тег .
                                                                                        А про то, что лучше атрибуты тегов не брать в кавычки, я бы ой как поспорила. И про создание валидного кода автоматическими редаторами тоже бы высказалась…

                                                                                        Но я рада, что доктайпов стало меньше. И за фреймы я рада. Давно им сказала R.I.P., рада и Transitional туда проводить…

                                                                                        В общем, статья приятная. Спасибо.
                                                                                          0
                                                                                          >А про то, что лучше атрибуты тегов не брать в кавычки, я бы ой как поспорила

                                                                                          Аналогично. Тем более, что заковыченные строки, как правило, даже в довольно простых редакторах выделяются цветом, и сразу визуально фильтруется — где имя атрибута, а где его значение.
                                                                                          +2
                                                                                          вот что меня больше всего напрягает в этих стандартах, так это их ну слишком долгое принятие.
                                                                                          блин, ребята, вы же рулите всем вебом. увеличьте штат за счет представителей от браузеров и утверждайте каждый год
                                                                                          • UFO just landed and posted this here
                                                                                              +11
                                                                                              Ошибка номер раз

                                                                                              «Девочка» может спокойно в документах писать < вместо &lt;, если это CDATA

                                                                                              Ошибка номер два

                                                                                              Между B и STRONG разница есть, и приличная. Корни уходят в книжную типографику, когда акценты в фразах выделялись именно strong-ом. Сегодня на них могут и должны реагировать аудио-читальщики текста, делая «ударение» на словах в этом теге.

                                                                                              Например «Это <strong>МОЙ</strong> хлеб и я его никому не отдам!» Тут strong уместен

                                                                                              А в фразе "<b>Начало производства</b>. Начинать производство нужно с разрешительных документов." выделение несет чисто визуальных характер, никакого акцента, никаких эмоций.

                                                                                              Личное недовольство

                                                                                              <header>, <footer>, <article> и прочие <nav> — капля в море, которая не закрывает и 10% потребности в тегах. Очень жаль, что никто из w3c не додумался до смешения всех плюсов XML и HTML, сделав XML для оформления и структуризации с вольным именованием тегов и микроформатами в придачу, и HTML для контента. Будем теперь мучаться с вечным дифицитом тегов. Или забъем и будем и дальше использовать собственные теги.
                                                                                                +1
                                                                                                С последним абзацом совершенно согласен. Ведь в чём проблема сделать «пользовательские теги» стандартными и с поведением по-умолчанию, как у div/span? Было бы просто отлично!
                                                                                                  +2
                                                                                                  Никто и не мешает это делать :) Уже три года использую в интерфейсных решениях. Доволен что слон.
                                                                                                    0
                                                                                                    Ага, тоже пробовал юзать, но невалидно) Пока таки не использую.
                                                                                                      0
                                                                                                      Валидность — субъективное понятие. Никто не мешает написать <!DOCTYPE HTMLX> :) С точки зрения вашего стандарта, все будет валидно.

                                                                                                    0
                                                                                                    Проблема в том, что в html6 введут тэг с таким же названием, но допустим с поведением таблицы. И ваша страничка сделает опаньки.
                                                                                                    Правильным решением было бы использовать неймспейсы, типа <my:superdiv>
                                                                                                      –1
                                                                                                      А в css — экранировать двоеточие? это ужасно. Как на счёт подчёркивания для неймспейса?
                                                                                                        +1
                                                                                                        Человек привыкает ко всему. Так что не так страшен черт, как его последователи :)
                                                                                                        0
                                                                                                        Так я так и использую. Свой неймспейс и вперед!
                                                                                                  • UFO just landed and posted this here
                                                                                                      0
                                                                                                      Если я не ошибаюсь, подчёркивание как элемент типографики это неуклюжее наследие печатных машинок. Они имели единственную гарнитуру, и, как следствие, были лишены курсивного начертания, необходимого для выделения текста. Взамен использовалось подчёркивание.

                                                                                                      Я считаю, всё правильно сделали. Подчёркиванием, чаще всего, злоупотребляют.
                                                                                                        +1
                                                                                                        Если бы хотели убить подчеркивание как стиль, убрали бы из CSS text-decoration:underline
                                                                                                        Тут именно что семантисты убрали тег.
                                                                                                        Нет, я все понимаю, ну объявите его deprecated, ну дайте ему определение «использовать только для целей совместимости», но убирать из стандарта-то зачем?
                                                                                                        Понимаете, 90% верстальщиков не перестанут пользоваться этим тегом, поэтому из браузеров его тоже не уберут.
                                                                                                        Получим в итоге, что в стандарте тега нет, а по факту есть и везде работает.
                                                                                                        Такая ситуация только подрывает авторитет стандарта и ничего не более.
                                                                                                          +1
                                                                                                          text-decoration:underline нужен для ссылок :)
                                                                                                      +2
                                                                                                      После прочтения статьи у меня сложилось мнение, что ничего хорошего с тегами в html5 не сделали. Одни убрали, ввели кучу новых, часть старых взяли и стали использовать для другого, у многих тегов теперь обтекаемое описание. Закрывающие теги оставили. Имхо, порядка больше не стало это точно.
                                                                                                        +2
                                                                                                        Порядок должен быть в голове.
                                                                                                        +3
                                                                                                        Вставлю свои 5 коп:
                                                                                                        1. Всё-таки не закрывать теги это кощунство. Хотя бы даже в нормальном редакторе, потому что последний сразу же теряется в догадках по поводу начала и конца блоков.
                                                                                                        2. По семантике у Вас какие-то крайности. То left, то toolbar. Да, лефт это неправильно, т.к. это имя нарицательное в семантике, а вот тулбар уже имя собственное. То есть в боковой колонке может быть не только тулбар. Тулбар это как компонент страницы, а боковая колонка (левая/правая) это скелет страницы. К тому же, как я понимаю, элемент остался жив в конечной (ну почти конечной) спеке и выполняет эту роль как нельзя лучше.

                                                                                                        В остальном полностью согласен с поправкой на то, что нужно внедрять html уже сейчас. Нет смысла ждать.
                                                                                                          0
                                                                                                          Ну какбы если html-редактор теряется в валидной html верстке, это плохой редактор.
                                                                                                            0
                                                                                                            Aptana/Eclipse если что. Я за ним уже два года и назвать плохим, Вы знаете, язык никак не поворачивается.
                                                                                                            0
                                                                                                            Там, в конце, про aside было. Парсер слопал его.
                                                                                                            0
                                                                                                            Сегодня утром начал новую вёрстку с, совершенно новые ощущения, будто трогаешь руками обнажённые нервы.
                                                                                                              –1
                                                                                                              cool story, bro
                                                                                                                0
                                                                                                                xxx: ничто так не оптимизирует код, как один пропущенный

                                                                                                                ibash.org.ru/quote.php?id=14006
                                                                                                                • UFO just landed and posted this here
                                                                                                                    0
                                                                                                                    i cannot into habra markup
                                                                                                                    • UFO just landed and posted this here
                                                                                                                +1
                                                                                                                Спасибо, статья порадовала! Вступление забавное :)
                                                                                                                  +2
                                                                                                                  Искренне благодарю за статью! Очень интересно
                                                                                                                    +6
                                                                                                                    Автор статьи совершенно не разбирается в предмете. Он не понимает, что такое SGML и XML, что такое их приложение, что такое правильно построенный (well-formed) и валидный XML-документ. Он даже XML-элементы называет тегами, хотя при описании семантики это неверно (даже стандарт HTML5 всячески пытается уйти от текстового представления документа с его тегами). Ну или вот прекрасное
                                                                                                                    В xhtml же технически возможен (и с точки зрения XML даже валиден!) вот такой код:
                                                                                                                    текст ячейки текст между ячейками, отображайте где хотите

                                                                                                                    хотя если почитать XHTML In XML Schema, то увидим такое
                                                                                                                      <xs:element name="tr">
                                                                                                                        <xs:complexType>
                                                                                                                          <xs:choice maxOccurs="unbounded">
                                                                                                                            <xs:element ref="th"/>
                                                                                                                            <xs:element ref="td"/>
                                                                                                                          </xs:choice>
                                                                                                                          <xs:attributeGroup ref="attrs"/>
                                                                                                                          <xs:attributeGroup ref="cellhalign"/>
                                                                                                                          <xs:attributeGroup ref="cellvalign"/>
                                                                                                                        </xs:complexType>
                                                                                                                      </xs:element>
                                                                                                                    

                                                                                                                    и где тут mixed=«true» у complexType?

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

                                                                                                                    программы этот контент нам презентуют во вменяемом виде. Конечно, кто-то до сих пор пишет HTML в блокнотике. Но вообще, обычно берут CMS, у которой есть либо WYSIWYG-редактор, либо язык вики-разметки. Так вот в любом случае, текст, введённый пользователем, нужно тщательно отпарсить во внутреннее представления и потом по внутреннему представлению генерить (X)HTML, подставляя, где нужно, теги (в том числе и закрывающие) и экранируя текст. Если всего этого CMS делать не умеет, то грош ей цена
                                                                                                                    Постоянные переключения синтаксиса в одном файле ни к чему хорошему не приводят, глаз программиста замыливается, и становятся возможными достаточно трудно вылавливаемые синтаксические ошибки.

                                                                                                                    Ну во-первых, не надо уж использовать упомянутый чуть выше PHP (впрочем, лучше вообще его не использовать) не по назначению. Может, не следует генерить (X)HTML из кода, а взять шаблонизатор? Тогда таких проблем не возникнет.
                                                                                                                      –4
                                                                                                                      Спасибо вам. Яркий представитель секты семантистов выше уже высказался, а вот фанатичного XML-поклонника как-то не было.
                                                                                                                      Нет, правда, здорово. Вы заявляете, что я называю XML-элементы тэгами (о ужас! как я мог использовать немодные синонимы?!), из чего делаете безусловный вывод, что я совершенно не разбираюсь в предмете!
                                                                                                                      Одновременно, мою статью вы просто не поняли. Ну, то есть, совсем. Все доводы про ошибки проектирования языка, про техническую возможность — вы слова прочитали, нашли знакомые буквы, но смысла в них не увидели.
                                                                                                                      Вы просто-таки классический пример XML-бюрократа. Не поняв сути даже близко, прицепиться к специально для этого придуманным формальностям и заявить, что раз даже формальности не выполнены — значит перед вами точно абсолютное пустое место. Именно это и составляет суть существования и бюрократов, и самого языка XML.

                                                                                                                      Моя статья не зря содержит слова «победа научного материализма». Она, эта победа, как раз и одержана над такими как вы и TheShock. Пока семантисты и XML-исты занимались семь лет ерундой, технари своими силами решили проблему.

                                                                                                                      Извините, если получилось резковато, я не хочу ни в коем случае задеть или обидеть вас лично. Я просто защищаю свой образ мыслей. Все люди во что-то верят, кто-то в Христа, кто-то в Большую *опу, кто-то в XML или семантику, кто-то в кумиров, а кто-то в непогрешимость своей левой пятки. Я вот с некоторых пор больше всего доверяю мат. логике, и я рад, что именно мои единомышленники победили в подковерных войнах за стандарт html5.

                                                                                                                      PS. Да-да, картинку с д'Артаньяном мне уже постили.
                                                                                                                        +4
                                                                                                                        Да при чём тут XML-фанатизм? Как раз я-то разбираюсь в чисто технических вещах и у меня есть строгие доводы в пользу XML. А вот Ваша статья как раз демонстрирует фанатичную любовь в SGML-синтаксису HTML, подкрепляемому неверными или сомнительными доводами. Вот этот Ваш ответ, извините, — пустая демагогия.

                                                                                                                        Почему XML-синтаксис не прижился? Потому т.н. «веб-программисты» не осилили. Потому что W3C занимались синтаксисом, а не пытались сделать что-то для улучшения семантики HTML. Кстати, HTML5 ничего не говорит о синтаксисе. Точнее, там он присутствует, но описание HTML-элементов даётся в нейтральной манере, чтобы можно было семантику завернуть в любой синтаксис. Кстати, если глянуть на XHTML 1.0, то можно увидеть, что по сути это такой же XML-синтаксис для HTML 4. Так что противопоставлять XHML и HTML5 попросту неверно, т.к. это всё равно, что противопоставлять HTML 4 и HTML5 — разумеется, второй лучше. А почему XHTML 2 так и не был готов? А не потому, что разработчики принадлежали к сектам семантистов и XML-истов, а потому, что были банальными бюрократами.
                                                                                                                          –1
                                                                                                                          Ну а какой ответ вы ожидали получить, если вы критикуете статью, которую то ли не удосужились прочесть, то ли не смогли понять? Почему я должен вам разжежывать мысли, которые и изложены в начале этой страницы? XML-синтаксис «не пошел» не потому, что «веб-программисты» все как на подбор тупые, а потому что он просто не применим к вебу, в 99% случаев не дает никаких плюшек, но при этом замусоривает код большим количеством цифрового шума и менее адекватен поставленной задаче, чем HTML. Почему я должен спорить с вами об XML схемах? К вебу они не имеют ну совсем никакого отношения, и поэтому в моей статье про них ничего нет.
                                                                                                                          PS. Хотя что я, в самом деле. Вы предлагаете «вообще не использовать PHP» и «взять шаблонизатор», хотя PHP и есть в чистом виде шаблонизатор, прокладка между базой данных и веб-браузером.
                                                                                                                          Ну, о как технических вещах тут еще говорить?
                                                                                                                            +1
                                                                                                                            XML-синтаксис «не пошел»… потому что он просто не применим к вебу, в 99% случаев не дает никаких плюшек, но при этом замусоривает код большим количеством цифрового шума и менее адекватен поставленной задаче, чем HTML.

                                                                                                                            Ага, этому и посвящена достаточна большая часть Вашей статьи. Вот только чтобы такие вещи утверждать, мало их написать на заборе. И ниже Вы начинаете пояснять, почему так. Так вот моё утверждение: все эти аргументы несостоятельны. Потому что банально неверны. Почему неверны, можно понять, разобравшись путём с XML. В принципе, я в первом комментарии кратко объяснил, что к чему. Но Вы-то ярый борец с «XML-сектой», потому, видимо, разбираться с XML — ниже Вашего достоинства.
                                                                                                                            Почему я должен спорить с вами об XML схемах? К вебу они не имеют ну совсем никакого отношения, и поэтому в моей статье про них ничего нет.

                                                                                                                            Ну какой-то мифический получается веб. В вебе что используется? HTML/XHTML. Формально их синтаксис описать надо? Надо. А это и делается с помощью DTD или более мощного средства, существующего в XML-мире — XML-схем. Ну вот я привёл кусок такого формального описания. Можно было бы и кусок DTD скопипастить. Или вообще кусок текста из стандарта. Однако, текст небезгрешен, его можно трактовать по-всякому, не в пример формальному описанию.
                                                                                                                            Вы предлагаете «вообще не использовать PHP» и «взять шаблонизатор», хотя PHP и есть в чистом виде шаблонизатор, прокладка между базой данных и веб-браузером.

                                                                                                                            PHP — не лучший шаблонизатор. Я бы предпочёл apache velicity, razor или самописный. Некоторые суровые парни высказались бы в пользу XSLT. Но это неважно. А важно то, что при прямом использовании проставлять кавычки и закрывающие теги в PHP не сильно страшно, вопреки Вашему ещё одному аргументу против XML-синтаксиса HTML (или XHTML, что верно для HTML 4).
                                                                                                                          +2
                                                                                                                          Она, эта победа, как раз и одержана над такими как вы и TheShock. Пока семантисты и XML-исты занимались семь лет ерундой, технари своими силами решили проблему.

                                                                                                                          Вот в этом и есть ваш фейл. html5 поддержал идеи семантики, а не опроверг их! Часто используете хедеры-навы-футеры? Вот вам соответсвующие теги. Нужны пользовательские атрибуты? Вот вам «data-»! Та даже те же новые виды инпутов. Всё-равно проверки делаются javascript-ом давно, они нужны только для пущей семантики!

                                                                                                                          Зато убрали теги center, font, strike. Переосмыслили теги <b> и <i>:
                                                                                                                          The b element now represents a span of text to be stylistically offset from the normal prose without conveying any extra importance, such as keywords in a document abstract, product names in a review, or other spans of text whose typical typographic presentation is emboldened.

                                                                                                                          The i element now represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, a ship name, or some other prose whose typical typographic presentation is italicized. Usage varies widely by language.


                                                                                                                          Ещё раз обратите внимание, убрали тег <center>, а не добавили теги <left> и <right> в стиле того маразма, который вы предлагали выше. Вместо классов col1 и col2 теперь желательно использовать использовать aside.

                                                                                                                          html5 принес больше семантики, чем xhtml и html4 вместе взятые. И это именно победа над такими как вы, которые не думают о будущем своего проекта, о тех, кто будет его поддерживать и развивать. Вы будете терпеть из-за этого убытки и это ваше наказание, и ваше решение принимать его в обмен на возможность не вникнать в суть проекта.
                                                                                                                            0
                                                                                                                            Если кто не понял, то теперь b и i — это не теги «жирный» и «курсив», а несут смысловую нагрузку.
                                                                                                                              –4
                                                                                                                              Какой же вы тугой. Никто не против семантики как таковой, в умеренной форме она несет здравые и разумные мысли. Все только приветствуют появление тэгов для типовых секций страницы: <header> («шапка»), <footer> («подвал»), <nav> (блок навигации) и прочие там <aside> («в стороне» или «сбоку»). Тег <center> убрали, потому что он означал «блок с выравниванием строк по центру» и мог сбить с толку потенциальных пользователей того же <aside>, ну и вообще данные с представлением нужно по возможности разделять. И этом, разумеется, HTML5 представляет собой шаг вперед.
                                                                                                                              Но чтобы понять, что списки лучше верстать тегами списков, заголовки — тегами заголовков, а для тела статей использовать тег <article>, достаточно простого здравого смысла, без всяких семантических теорий. К сожалению, идеи настоящего семантического веба, в том виде в каком их озвучивал тот же Тим Бернерс-Ли, до сих пор не реализованы и вряд-ли будут. Зато на модном слове вдоволь оттоптались людишечки, желающие повысить свое ЧСВ и поучить других, как им правильнее жить, например, что колонки left и right надо обязательно называть col1 и col2.
                                                                                                                                0
                                                                                                                                Тугой — это вы. Но вы этого не поймёте, потому что никогда не услышыте прот те лучи ненависти, которые будут вам направлять люди, поддерживающие вашу писанину.
                                                                                                                                  –1
                                                                                                                                  *услышите
                                                                                                                                    –2
                                                                                                                                    Вы знаете, если кто-то исходит на лучи от ненависти, увидев <div id=left> — ему срочно надо в больничку. Я серьезно.
                                                                                                                                      +2
                                                                                                                                      В больничку надо автору этого маразма. На крайняк — вон из профессии.

                                                                                                                                      Как и тому, кто использует <b> вместо <span class="vector"></span>. Потому что автор математических текстов всё-равно будет их вставлять специальной кнопкой. Зато если заказчик скажет: «анука сделай, чтобы все векторы были картинкой со стрелочкой» и если у вас нормальная верстка — написали кусок js-a и вуаля. А так — придётся перечитывать все тексты, где там <b> вставлено чтобы вектор выделить, а где чтобы слово акцентировать.
                                                                                                                                        –1
                                                                                                                                        Вероятность того, что заказчик скажет мне «анука», близка к нулю. Потому что после этого он перестанет быть заказчиком. Если он это попросит нормально (как доп. пункт к ТЗ, за отдельные деньги), то простейший js, превращающий все односимвольные <b> в буквы со стрелочками, пишется за 2 минуты. Нет ни одной причины тратить время (=деньги) сейчас на то, что потребуется с очень малой вероятностью в будущем, и что в этом будущем можно будет реализовать за 2 минуты.
                                                                                                                                        Выше в комментах кто-то, возможно вы, доказывал, что нельзя называть блок #left, потому что может быть, в будущем сайт придется переводить на арабский и там это вызовет проблемы. Во-первых, арабы хоть и пишут справа налево, но сами понятия права и лева у них совпадают с общемировыми. А во-вторых, в будущем, конечно, с сайтом небольшой российской фирмы (а на 99% я делаю именно их) много чего может случиться, но я даже не могу придумать более невероятное событие, чем его перевод на арабский, если фирма изначально никаких отношений с арабами не имела.

                                                                                                                                        В-общем, на этом дискуссию предлагаю прекратить. Аргументы у вас закончились, а доводить кого-то до истеричных оскорблений я не хочу. Спасибо, что изложили основные доводы своей религии, сейчас я внесу ссылки на самые яркие ваши комментарии в статью.
                                                                                                                                        Извините, если я где-то перегнул с троллингом.
                                                                                                                                          +2
                                                                                                                                          У меня аргументы закончились, а у вас их и не было)
                                                                                                                                          Не надо так категорично отзываться о семантистах. Вспомните, что было до прихода css и ужаснитесь, какой веб был бы сейчас, если бы не семантисты. А вы тут так нас покрываете.)
                                                                                                                              0
                                                                                                                              Первые два абзаца — лучшее, что написано в этом посте.
                                                                                                                              Любить XML или нет, но разработчик, тем более руководитель оных, должен владеть правильной терминологией или стремиться к этому.
                                                                                                                              +1
                                                                                                                              Я просто в восторге от стиля изложения автора! Отличная статья, во многих случаях мнения сходны.
                                                                                                                                0
                                                                                                                                Как и многие вышевысказавшиеся выражаю большое спасибо вашему слогу и вообще содержимому статьи, согласен во многом, особенно в части про семантический маразм
                                                                                                                                  0
                                                                                                                                  Так вы поддерживаете автора или против его позиции в вопросе семантики?
                                                                                                                                  –1
                                                                                                                                  А вы с какой целью интересуетесь? :)
                                                                                                                                    0
                                                                                                                                    Неясна ваша позиция.
                                                                                                                                      +1
                                                                                                                                      Я против семантического экстремизма, во всем должен быть здравый смысл. И блоки я буду именовать так, как захочу, хоть left-col хоть sidebar хоть aside.

                                                                                                                                      И естественно id/class нового блока буду писать исходя из соображений адекватности, в том числе, если блок переедет слева вправо он сразу же сменит IDшник или класс, если оно задано явно.

                                                                                                                                      Про 100% стилизацию при помощи одного только css не стоит поднимать полемику — тут я на 100500% согласен с автором статьи, обычно 1 макет, одна верстка. В следующем варианте будет другая. Я сделал такой вывод исходя из своего почти 8-летнего опыта. Для всего остального есть абсолютно независимая верстка, но это не тема данной статьи
                                                                                                                                        –1
                                                                                                                                        Понятно, спасибо.
                                                                                                                                    0
                                                                                                                                    Пепелсбей, приди!
                                                                                                                                      +1
                                                                                                                                      Больше всего удивляет, чем не угодил тег подчеркивания. Тем, что им «слишком часто» пользуются? Может, те, кто это утверждают, еще и сайты за меня делать будут? Чего уж там, давайте!
                                                                                                                                        0
                                                                                                                                        Однако, подобное поведение — отказ от обработки всего документа при обнаружении любой ошибки — абсолютно неприемлемо для веба, где большую часть контента создают отнюдь не программы и даже не верстальщики, а сайт-менеджеры, писатели, блоггеры и, зачастую, рядовые посетители сайтов.


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

                                                                                                                                        В XHTML существуют правила, например, запрет вложенности для тегов <a> и <p>, которые не могут быть выражены в терминах XML.


                                                                                                                                        Если какие-то правила нельзя выразить с помощью XSD или DTD, то почему их можно выразить с помощью только DTD?

                                                                                                                                        Бывают, например, произведения классиков, в которых они используют курсив и полужирное начертание исключительно в художественных целях (то есть так, как им лично захотелось), или, может, в соответствии с устаревшими на данный момент правилами языка, или еще как-то не по правилам.


                                                                                                                                        Классики могут любое оформление текста использовать в художественных текстах. И что, весь CSS в HTML обратно запихивать?
                                                                                                                                          0
                                                                                                                                          Ну, в-общем, да. Великий поэт и писатель Максим Горький (Пешков) очень точно сказал про этих всех Бернерсов-Ли: «рожденный ползать летать не может.» И он прав. Все, что они могут — это сохранить наследие Мастера. И права вносить свои семантические правки им никто не давал.
                                                                                                                                          0
                                                                                                                                          Перечитаю эту замечательную и полную оптимизма статью о победе HTML5 года через 2, нет 5…
                                                                                                                                          Напомните только о ней, pls :)

                                                                                                                                          Only users with full accounts can post comments. Log in, please.