-
Религиозные войны
Не ожидал, что статья про верстку двух колонок одинаковой высоты вызовет целый холивар на Хабре. В комментариях дискуссия велась по двум вопросам: зачем вообще нужно так извращаться и почему верстать таблицами — дурной тон. Если с первым вопросом более-менее разобрались (правдивые комментарии оставили errr, Jenek и ArtyV), со вторым вопросом все довольно грустно. Одни кричат, что таблицы для нетабличных данных — не семантично и не круто, вторые — что таблицами все делается проще и быстрее. И те, и другие в корне не правы.
Верстка сайта, как и дизайн, это решение поставленной задачи, а не очередной способ понтануться перед коллегами-гиками или схалявить. Я еще ни разу не получал задания «написать html-код», но постоянно получаю «сделать сайт», а это — не одно и то же. Сайт — это живой механизм со своим внутренним миром, своими проблемами и планами на будущее. От того, как вы его спроектируете, зависит то, рассыпется ли он при малейшем дуновении ветра или выдержит удар ядерной боеголовки (дружно вспоминаем сказку про трех поросят).
Проектирование модульной сетки сайта и его внутренних элементов — очень важная и ответственная задача. Выбор «верстать дивами или таблицами» должен быть обусловлен тщательным анализом — от внешнего вида макета до целевой аудитории сайта. Таблицы зачастую громоздки в реализации и поддержке, но это — пуленепробиваемый вариант для большого зоопарка браузеров. Блоки — легкий и гибкий инструмент, позволяющий творить невероятные вещи, но они могут превратиться в сущий кошмар для кроссбраузерности и реализации зачастую тривиальных вещей.
С семантикой тоже не все замечательно. Я не отрицаю, что это здорово и правильно, но вот скажите, если ли официальная спецификация семантичной верстки? Или же все это — частное мнение отдельных личностей, которое разнится от человека к человеку? Как, например, мне сверстать шахматную доску, чтобы любой user agent понял, что это именно шахматная доска, а не бессмысленное нагромождение элементов?
Семантичность того или иного решения в первую очередь должна определятся решаемой задачей, а не частным мнением людей со стороны. Вот типичный пример, на котором я ловлю большинство идеологов семантичной верстки. Как у любого ИТ-специалиста, у этих ребят в своих блогах есть листинги кода. И этот листинг обычно сопровождается нумерацией строк, что очень даже удобно при описании принципов работы кода. И как же эти листинги оформляются? Правильно, через
<ol>/<li>конструкции. Семантично? — вроде да. А я считаю, что нет. Нумерация — это декоративная составляющая листинга, которая никак не связана с самим кодом. А с помощью<ol>/<li>нумерация вдруг стала смысловой составляющей. Что выливается в то, что 95% пользователей при попытке скопировать этот код или его часть получат нумерацию строк впридачу. А ведь этот код вывешивается именно с целью дать посетителю скопировать и опробовать его. Нарушение семантики налицо. Некоторые, конечно, догадываются об этой проблеме, но решают они ее не отдельной колонкой с нумерацией, а кнопкой «view plain». То есть пользователю предлагается потанцевать с бубном только ради того, чтобы скопировать текст.Резюмируя все вышесказанное. При выборе «сверстать таблицами или блоками», равно как и в любой другой подобной задаче, нужно руководствоваться тщательным анализом той среды, в которой будет работать то или иное решение, а не идиотскими стереотипами или собственной ленью. Если 1% аудитории сайта — это десятки тысяч пользователей, приносящих реальный доход, то мой выбор — таблицы. Если нужно делать сложный презентационный макет с кучей уникальных по дизайну страниц, то я выбираю блоки. Как-то так.
45 комментариев
Я сначала поставил себе задачу «научиться круто семантично верстать, чтобы ну ваще без таблиц как у всех крутых перцев», потом от этого отошел, слава б-гу. 🙂 Теперь и так и так умею.
Если нужно просто сделать колонки одинаковой высоты — таблицы тут очень хорошо подходят. Да и использовать их понадобится 1, максимум два раза на всей странице. Так что страшные примеры с кучей вложенных таблиц тут неуместны.
Да и вообще, если времени в обрез и надо сделать трехколоночный макет — проще вставить одну таблицу, и всё тут.
А часто без них действительно можно обойтись. Например, если «одинаковость» ячеек заключается в наличии бордюра снизу у обоих блоков — делаем два блока с флоатом, а потом просто вставляем после них еще два плавающих блока с заливкой или тем же бордюром, у первого clear: left. «Визуально то же самое» — если думать в таком направлении, очень много получится.
Вообще, часто удивляюсь тому, как много внимания уделяется коду, а не результату.
Код просмотрит, возможно, 0,3-0,5% посетителей сайта, в то время как сам сайт увидят 100% посетителей. При этом часто возникает желание (у меня в том числе) решить дилемму в пользу красивого кода, с этим желанием я старательно борюсь.
Посетителю совершенно все равно, что написано в коде, он смотрит сайт. Конечно, есть люди, которые откроют исходник, увидят таблицу и усмехнутся с чувством собственного превосходства, однако они в любом случае не являются целевой аудиторией.
Кстати, по поводу нумерованных списков для публикации листингов — они всегда меня раздражали именно тем, что копировали номера вместе с текстом. Приходилось видеть решение, когда нумерация была вставлена фоновым изображением, и текст пригнан к ней с помощью line-height, но для себя лучшим решением в этом случае считаю две ячейки таблицы.
Аплодирую стоя!
>> но для себя лучшим решением в этом случае считаю две ячейки таблицы.
Пздц просто… И как же скопировать в этом случае код без номеров из соседних ячеек (Пусть у меня ИЕ или я не знаю про CTRL+Select в Мозилле)?
П. С. Сергей, а для коментов нету какого-нить тега типа [quote author=Автор]Цитата[/quote] или …
Ясно, понял 😉
by, так выделится только исходник. Ведь не построчно его разгонять в строки таблицы, а использовать всего две ячейки — одна для номеров, другая для кода.
Работает везде 😉
Как то был у меня заказчик, который просил сайты только таблицами верстать (и просил это потому, что раньше когда-то, когда ему на блоках делали, то на правку багов уходило много времени), и помнится я сделал изящный сайт на блоках, совсем позабыв, что он хотел на таблицах, а потом менеджер мне это напомнил. Собственно досадное чувство было. Тогда был не опытен и с позиции клиент всегда прав подходил. Но все же уговорил клиента позже, что или я так сделаю и если будет плохо, то я ботинки съем, или никак не делаю. Позже получил от него письмо, что сайт очень удобно сделал и легко интегрируется с его ЦМСкой. К чему все это написал..? Наверное чтобы кто-нибудь посмеялся 🙂 Так же как над этим убогим холиваром 🙂 П.с. Сергей, как хорошо что у вас нет никаких Карм, ЧикуенкоСилы и прочей фигни, а то быть мне в минусах 😉
не очень понял в конце про выбор.
а вообще, на хабре, по-моему, любой вопрос вызывается такое количество споров. было бы где потрепаться 🙂
Серёгин молодцом
Извините за жуткий оффтоп, но почему-то вспоминается старый анекдот…
«В Вилларибо и Виллабаджо опять дедлайн. Пока ребята из Вилларибо верстают сайт div’ами, ребята из Виллабаджо уже всё сверстали на таблицах и *бошат друг друга в квейк.»
К сожалению ещё во многих фирмах сайт наполняют «специально натасканные секретарши», которые не знают ничего кроме таблиц…
Хабр в большинстве своем — дилетанты, юнцы, и фрилансеры среднего уровня подготовки. Если человек большинство информации узнает из Хабра(а таких там 80%), то какое он право имеет устраивать холивар?
Не вижу смысла в этом посте и попытке кому-то добавить ума, ибо по ту сторону стоят люди, мнение которых редко потверждено опытом либо пониманием, и как следствие не имеет никакого авторитета, чтобы над ним хотя бы задуматься. Как правило аргументы за таблицы — никчемны, а спорить с ними — не вижу смысла, было время, когда сам не знал ничего кроме таблиц и не думал кроме как сеткой, теперь другое время и новые выводы, чтобы мнение поменялось должно что-то произойти с таблицами, а таких изменений нет и врядли будут.
ps: ветка превратится в точно такой же холивар и поток мнений, может стоить просто запретить комментирование? получили информации и несогласны — пошли думать, чего с ней спорить?
Мысль абсолютна верна: есть задача и набор инструментов, выбирай подходящий.
Но есть одно но, чтобы правильно выбирать нужный инструмент нужно одинаково _хорошо_ владеть всеми инструментами. Поэтому, мое мнение, такие холивары полезны, пускай начинающий верстальщик ради ложных и фанатичных целей поверстает год а лучше два дивами. К тому, что надо принимать решение об инструменте исходя из задачи он придет.
Я всё удивляют что такого в теге DIV семантичного? DIV — это какой-то сферический конь, тег, который на языке семантики означает «тут у нас всё, что угодно». Для семантики в HTML нехватает целой кучи тегов, которую, кстати, туда вполне можно принести. Ведь IE поддерживает custom tags, а все остальные браузеры умеют понимать любой валидный тег и навешивать туда стили. Конечно, тут лучше следовать какому-то стандарту, иначе будет вавилонская вёрстка, а не семантика. Можно, например, следовать HTML5.
Образец антисемантики — теги Hx. Подумайте — правда ли они семантичны? Все заголовки болтаются сами по себе, их приходится «семантически прикреплять» к тексту при помощи различных извращений, а каждый подзаголовок никак не связан с заголовком более высокого уровня, хотя и это иногда обходят, верстая все заголовки одним тегом и навешивая стили по степени вложенности.
Эх, как-то хотел написать большую статью по этому вопросу, да руки не дошли и желание пропало.
т. е. для длинных строк кода будет горизонтальный скрол? Или как тогда позиционировать нумерацию, если строки переносятся?
А вот в этом случае семантичный код как-раз таки и позволит избежать большинства ошибок.
DocBook вам в помощь 😉
А по теме семантики, вчера нашел очень мощную штуку: http://semantic-mediawiki.org/wiki/Semantic_MediaWiki
Более мощного инструмента по семантичной связке данных еще не встречал.
А когда при этом ещё ставится задача «фотки справа должны грузится первыми», тоауже никуда не денешься. Благо методика вёрстки на блоках достаточно разработана.
> т. е. для длинных строк кода будет горизонтальный скрол?
Да. Это почти не доставляет неудобств, в отличие от копирующихся номеров.
Я рассуждаю так, что пример исходного кода (особенно длиннее десятка строк) редко будут анализировать прямо на сайте, скорее всего его будут копировать и анализировать уже в работе. При этом скролл не мешает совершенно.
Но мы отвлеклись.
Помимо того, что список действительно «несемантичен» для этой задачи, наравне с таблицей, таблица подходит для этого лучше. И кому после этого настолько сильно нужна семантика?
Некоторое время назад я просто стал выбирать теги, которые предоставляют удобную структуру для поставленной задачи (списки, списки определений и т. д.)
Любое создание чего-либо не обходится без компромиссов. Конкретно тут могут быть два варианта: поменять макет, чтобы проще было сверстать дивами, либо убрать требование про порядок загрузки.
Программисты уже давно поняли, что не надо искать серебренную пулю, а надо работать. Об этом и в книгах часто пишут. Большинство же верстальщиков никак не угомонятся.
ЗЫ: Почти каждый день можно найти на Хабре очередные перлы от какого-нибудь «специалиста». Раньше смеялся и жалел что регистрации нет, чтобы показать человеку, что он бред несет. Сейчас уже пофиг, свое время дороже.
Ты немного не с той стороны смотришь на листинги кода при помощи OL. Главное в OL — это слово «ordered», означающее, что в данном списке принципиально важен порядок элементов. Собственно, это и есть единственная причина использования OL, а не UL.
В листинге кода как нигде важен порядок строк. А визуальное представление в виде нумерации строк даётся исключительно для красоты. Вот такая семантика.
И о семантике вообще: для семантической вёрстки не нужны спецификации и мануалы, это всего лишь набор идеологических установок. Я об этом писал, абзац озаглавленный «О „шмемантике“». И — да, этот набор будет разниться от человека к человеку, но он и не должен быть статическим.
Со всем полностью согласен, а код через ol придумали му-ки — каждый раз когда копирую такой матерюсь : D
В Сафари текст внутри нумерованного списка (OL) прекрасно копируется без номеров.
То есть самое ценное в конструкции <ol>/<li> — это название элемента? А то, ради чего вставляется листинг кода на сайт, уже не важно? 🙂
И что, например, случится, если <ol> заменить на <ul>, а нумерацию указать через CSS? Появится такой user agent, который выдаст строки в произвольном порядке? 🙂
>> Я об этом писал, абзац озаглавленный «О „шмемантике“»
и что? кто ты? Консорциум вэтрицэ, я не открыл ссылку, может там и умные вещи, но подкреплять свои же слова ссылкой на свой же блог — не убедительно.
Не надо переходить на личности. pepelsbey — уважаемый многими (и мной в том числе) специалист в области веб-разработки, и в приведенной им статье можно много чего полезного прочитать.
И что, например, случится, если заменить на , а нумерацию указать через CSS? Появится такой user agent, который выдаст строки в произвольном порядке?
А почему бы и нет? На то он и неупорядоченный 🙂 В спецификации про порядок элементов внутри <ul> ничего не сказано.
Но ведь есть микроформаты, RDFa, OWL и наверняка еще что-то.
Наверно, действительно всё упирается в цели. С одной стороны сайт — это то что нарисовал дизайнер (картинка адоптированная под Web). Но ведь с другой стороны — это информация, которую необходимо как-то структурировать, а пользователю эту информацию нужно как-то найти. В идеале семантика на это и направлена (на правах IMHO)
В целом — да. Так же, как самое ценное в элементе <p> — это то, что он p(aragraph), а не div(ision). А в элементе <h1> то, что он h(eading)1, а не t(able)d(ata).
Обвинять верстальщиков в том, что кто-то где-то что-то неправильно копирует — занятие сомнительное. Мне ни разу не приходилось копировать что-то вместе с номерами строк. К тому же, всё копируется в текстовые редакторы, которые работают в режиме plain text.
Кстати, твою претензию можно развернуть иначе:
Safari, Opera — всё отлично, просто текст.
Если думать что удобнее всего пользователю — то наверняка во многим будет удобнее всего читать информацию с листа или из PDF-файла. Но поскольку у разработчиков есть какой-то выбор, то мы выбираем HTML как инструмент, который удобен, прежде всего, нам. А если взялись за HTML, то стоит играть по его правилам. Каким правилам? По тем, что скупыми фразами обозначены в спецификации. В HTML 5 комментарии уже гораздо интереснее, чем в прежних спецификациях.
Вы хотите знать «с какова я раёна»? 😀
Из приведенного для создания сайтов на сегодняшний день можно использовать только микроформаты и RDFa, и то микроформаты это больше как инициатива нескольких человек, которая пока очень слабо поддерживается производителями браузеров. К тому же, они описывают только конкретные области, но не все. То есть мой вопрос про шахматную доску остается открытым.
Везет тебе, а вот намучился с репозиториями кода вроде этого. И я считаю, что подобные обвинения оправданы. Вот из-за таких «мелочей» складывается негативное впечатление о проекте. Мне, как пользователю, абсолютно наплевать на те высокие материи, которые преследует разработчик, если я не могу в полной мере воспользоваться предоставляемыми услугами.
Ну уж давай тогда развивать эту идею: «почему все браузеры такие тупые, что не делают то, что мне нужно?». То есть глючат в самых неприятных моментах. И я не согласен, что нумерация в списках — это декоративная часть, это как раз смысловая часть. Особенно если идет речь об официальных документах, где идут постоянные ссылки ко всяким «п.5» и «п.12». Получается, что при копировании такого текста не должна копироваться нумерация?
Если я ничего не путаю, то для кода есть отдельный тэг code. Взгляните как в той же wiki оформяются [
]:Наличие нумерации имеет смысл в том случае, если предполагается обсуждение того или иного куска кода. И в этом случае совершенно не важно, как он оформлен: хоть через ol/li, хоть через таблицей, кому интересно — почистят. Когда код уже обсужден и вылизан — нумерация не имеет смысла, но имеет смысл удобство копи-пастинга — code в помощь.
да таки с тэгами не срастуха…. попробуем так:
Если я ничего не путаю, то для кода есть отдельный тэг code. Взгляните как в той же wiki оформяются [code-nowiki-/nowiki-/code]: pre-code-/pre-/code
Комментарии Вадима видел, но изложу по-своему.
Вы зря всё-таки связываете ol и нумерацию — смысловой нумерация становится в головах людей, которым важно сделать то-то и то-то, а какой там смысл — да побоку. Да и w3c помог им в этом вопросе, связав нумерацию и ol стандартным стилем.
Нумерация в ol декоративна — т.к. по смыслу этот элемент являет собой лишь упорядоченный список. Вы ведь не будете говорить, что в упорядоченном списке обязательна нумерация? Или будете? Опять же, нумерация не соответствует порядку следования. Например — я записал пункты как попало, а затем отсортировал по некому критерию. При этом я сохраняю исходную нумерацию по каким-то причинам. Этот мой пример и ваш пример со ссылками в официальных документах — два частных случая упорядоченного списка, которые различаются по важности нумерации, но при этом одинаково важны в смысле порядка следования. Таким образом более важный смысл — в упорядоченности по некоторому критерию — в моём примере это «некий критерий», а в официальных документах — как правило ГОСТ, или некоторый вид стандарта оформления.
Про ul и css — всё очень просто. По смыслу ul не сортированный — потому ожидать порядка от него нельзя. Представьте себе, что некоторый полезный бот ходит по страницам и собирает списки. Пусть это будет сервис todo-листов, который может из вашего блога вытянуть todo в себя, чтобы потом всячески с ним извращаться — смс, веб, твиттер, бла-бла-бла. Теперь попробуйте написать список дел, отсортированный по приоритетам — и засуньте его в ul. А потом удивляйтесь, что он сортирован по алфавиту (например). Это если не извращаться с самодельными стандартами. Если извращаться — появляется новый смысловой уровень — который нынче пихают в атрибут класса.
Про шахматную доску — да очень просто — придумайте стандарт и заставьте всех его поддерживать 😉
Про код — смысловая часть обрамляется в code, остальное можете засунуть в один из типов списка, а можете и не засовывать — здесь уже важно другое — есть ли смысл в том, чтобы выделять строки (в семантическом плане).
Должна, но Rich-text виде.
В общем, как обычно пришёл jahson и сказал всё правильно 😉
Кстати, одна из вариаций разметки кода — это
<pre><code></code></pre>. Я, к примеру, этот вариант не понимаю. А вы что думаете?А репозитории вроде того, что приведён выше, используют вовсе не ol 🙂
Вадим, а здесь проблема видится в том, что code почему-то когда-то связали именно с моноширинным шрифтом, а не с тем, что там на самом деле важно — соблюдение отступов, без него код в большинстве случаев становится нечитаем. Отсюда и pre, что вполне разумно, по-моему, в нынешних условиях.
Хотя, если подумать, неоспоримо и существование фрагментов, в которых важна разметка. Но тогда w3c стоило бы делать примерно так — code сохраняет разметку и выводится моноширинным шрифтом (бонус), pre — просто сохраняет разметку, наследуя шрифт родителя.
А каким образом нумерация связана с приоритетами? То есть если я сделаю ol, бот однозначно будет знать, что список отсортирован по приоритету? Даже если я его отсортировал по дате добавления или по одному из тысячи других критериев? И как я могу отвечать за принципы работы неизвестного мне бота?
Вот смотрите, в данном примере с ботом вы продемонстрировали типичную модель поведения многих ярых адептов семантики: попытаться угадать, поймет ли их разметку какой-то неизвестный механизм, который еще даже не создан. Тут уже впору организовывать «Что? Где? Когда?» для веб-разработчиков: посадить 6 человек за стол и сказать: «Я придумал разметку для вывода списка задач; назовите мне, какие элементы и классы отвечают за название задачи, автора, исполнителя, приоритет, описание, дату добавления, дату завершения и список прикрепленных файлов. И сверстайте этот список, чтобы он выглядел в точности, как у меня. Время!».
Я уверен, что html-разметка без контекста задачи — ничто и не имеет абсолютно никакого смысла. Это как сказать «нужно сделать колесо», а для чего это колесо, для велосипеда или камаза, не уточнить. Если мне нужно сделать листинг кода с нумерацией, я не буду использовать ol/li до тех пор, пока не буду уверен, что любой современный браузер позволит скопировать его нормально. Если мне нужно подготовить листинг для специального агрегатора, то я буду использовать синтаксис, понятный именно ему.
А каким образом нумерация связана с семантикой? Т.е. если я сделаю ol бот будет знать, что список имеет определённый порядок — всё, что имелось в виду. Или, если есть оговоренный стандарт — тогда бот может понять и ul, как отсортированный. Отвечать за принципы работы вас никто не призывает — вы же не отвечаете за принципы работы браузера, который по-сути можно называть неизвестным вам ботом?
Вот смотрите, в данном примере с ботом я хотел вам помочь визуализировать ситуацию — вы же предпочли зацепиться за, возможно, не самый удачный пример, зачислив меня в адепты, что по смыслу недалеко от сектанта. «Что? Где? Когда?» у вас какое-то оторванное от реальности — я специально упомянул о «извращении со своими стандартами», что как раз убирает вашу угадайку, превращая её в следование описанному стандарту. Т.е. угадывать я не призываю.
html-разметка без контекста не имеет смысла — это почти правильно — т.к. элементы всё-таки имеют некоторый смысл. Я, собственно, нигде так и не говорил — везде описал контекст происходящего. Опять же, про оформление кода я написал выше и надеюсь, что моя позиция ясна — я не вижу смысла в списках до тех пор, пока нет смысла явно выделять строки.
Да, похоже, я не правильно понял ваш предыдущий коммент. Думаю, моя позиция в этом вопросе вам тоже ясна 🙂
Сергей, ну я не верю, что ты используешь P только потому, что он удобнее, чем DIV. У тебя тоже есть какое-то абстрактное понимание о предназначении элементов. Простейшая логика: «это было придумано для этого, то — для того». Речь только об этом. А уж насколько усложнять и ветвить систематику от базовой к многотомной — личное дело каждого. Главное, чтобы в базовых вещах было понимание.
И если ты выбираешь блочную, а не табличную вёрстку только потому, что это гибко и удобно, то я выбираю её потому, что это правильно с точки зрения языка, W3C и банальной логики. Но это не аксиоматика, это цель, к которой стремишься. Делаем шапки для десятков проектов Яндекса — таблицы, ибо мильён проблем. Верстаем сайт для гиковской конференции — да хоть HTML 5 + CSS 3 + SVG. Кстати, вот: Standards.next.
Хм, я такого не говорил. Лично мне пофигу, что писать, P или DIV, руки не отвалятся, но мне не пофигу, как это будет соотносится с результатом, который я хочу получить. Если мне нужно по-быстрому сварганить страничку, чтобы заткнуть на время дырку в пустующем сайте, то я вообще не буду париться насчет семантики, а если мне нужен сайт, который должен нормально индексироваться и находится поисковиками и быть удобным в использовании — буду играть совсем по другим правилам.
Так я не говорю, что семантика — это полный отстой. Это, бесспорно, важная и нужная вещь, хотя бы для обеспечения нормального отображения между user agent’ами. Я пытаюсь донести мысль, что нельзя подходить к разработке только со стороны «делаем все валидно и семантично» или «как проще», нужно встать где-то посередине и понять, что от тебя требуется не код, а работающий проект.
Кажется, именно такую мысль я и озвучил в последнем абзаце 🙂
Лондон… (*мечтательно)
А сверстать шахматную доску можно как двухмерный упорядоченный список OL->(LI->OL->LI*8)*8, на первом уровне значения A—H в которые вложен второй уровень (1—8). Тогда получится что шахматная доска — это упорядоченный двухмерный массив координат. Цвет клеток там ведь не имеет значения? 🙂 В крайнем случае можно еще добавить в каждую координату определение (…LI->DL) с цветом, состоянием (занята/свободна) и еще чем-нибудь. XDD
Другое дело это верстать замучаешься :))
Когда-то на каком-то западном блоге «пробегала» статья о том как сематически сверстать календарь. Сейчас он везде (где я видел) делается как таблица, но ведь по сути это тоже куча вложенных списков с определениями (год, месяц, день, день недели, …)
IMHO, семантика слишком молода для такой старой технологии как HTML 4 (5).
Vii, что касается календаря, то тут я склонен считать, что его структура ближе к табличной. Для меня это скорее таблица, в шапке которой — дни недели, а в столбцах — соответствующие им числа.
Я склоняюсь к тому, что шахматную доску нужно верстать таблицей. Причина кроется в обображении ее без стилей (не разрушится визуальная структура) и в более логичной, на мой взгляд, семантике, которой в сегодняшней беседе уделено немало времени.
Речь не о том, как сверстать доску, чтобы она выглядела как доска, а как ее сверстать, чтобы любой user agent понимал, что это именно шахматная доска, на не нагромождение списков или таблица. В этом и заключается суть семантики.
«Любому» юзер-агенту понимать семантику шахматных досок вовсе необязательно. Зато, например, шахматному поисковому движку, бродящему по интернету в поисках различных позиций, и любителю, открывающему в браузере сайт новостей из мира шахмат, чтобы проанализировать сложную позицию в своей любимой шахматной программе, такая возможность была бы нелишней.
К счастью, для записи шахматных позиций давно существует свой формат (PGN), который легко встроить в виде микроформата в любую верстку, хоть табличную, хоть дивную. И не нужно изобретать теги «position», «board», «cell», «piece», «castling», «en-passant» и «side-to-move». В PGN семантика любой шахматной позиции укладывается в пару десятков символов.
BTW, в XHTML 2 есть элемент
<blockcode>Секретарша левой ногой сделала документ в ворде, распечатала, на бумаге — все хорошо. И не имеет значения, что она выравнивание по правому краю делала добавлением на глазок пробелов слева и прочими прекрасными приемами. Это первый подход, назовем его «победа в битве».
Если же этот документ попадет другой секретарше на редактирование, у которой свой субъективный взгляд на методы форматирования, наверняка будут моменты сомнений и некоторое время будет потрачено на осознание и изучение подвигов предшественницы. А от недостатка знаний возможны и вовсе кардинальные решения. Тут сразу нервы, слезы и нецензурные выражения.
Совсем другое дело если обе они с твердым знанием инструментария. Этот подход я называю «победа в войне».
Принтер выдаст одинаковый результат, но время нынче дорого.
На мой взгляд, как раз инструментария, то есть семантики, как такого нету, есть только жалкие потуги иннициативной группы ))).
Семантика, на мой взгляд, это не более чем добрая воля здравомыслящих людей, любовь без обязательств, вещь абсолютно ненаправленная. Но нужная. И то что ее не пишут как стандарт — плохо. И к HTML верстке, как таковой, она отношение имеет «постольку-поскольку».
Параграф… в школе учил совсем другие параграфы, те что длинные, внутри с заголовками и абзацами и рядом §. Но коль нету тега _абзац_, с оглядкой использую _параграф_.
К сожалению в P вставить UL нельзя, нельзя TABLE, это что, вопреки здравому смыслу, что за бред??? И это вы называете семантикой? И почему в P нельзя вставить DIV, а SPAN можно? Вроде как они оба «несемантичные» и предназначение их от семантики совсем далеко.
Недосемантика с недоправилами вообще может быть предметом спора таких уважаемых людей?
В войне между «таблицами» и «флоутами» достигнут паритет. Навсегда, увы. Оба этих хакерских метода достигли своего предела в развитии, и оба должны исчезнуть. Но произойдет это только тогда, когда наконец появятся CSS-свойства, специально предназначенные для сложной верстки. Надо бы молиться, чтобы эти свойства были так хороши, что в старых методах отпадет нужда. От браузеров будет многое зависеть, конечно.