]]> Vladimir ]]>

Понеслась…

>>> стандарты — в топку
Такое отношение мы уже видели, Microsoft так и поступила. Ругай IE или не ругай, всё равно часто приходится держать две версии CSS – одну для нормальных браузеров (которые не плюнули на стандарты), другую для IE (причем для каждой версии свою).

А теперь представьте, что было бы если бы Apple использовала бы свои стандарты вместо W3? А KHTML – свои? Было бы вообще всё здорово: одна версия сайта – для Выня, другая – для Линя, третья версия – для Мака (как когда-то было с русскими кодировками). Было бы это удобно? Сомневаюсь.

>>> Почему нет <nobr>
Это как с pre vs code: если нужен nobr, то используйте CSS. nobr расшифровывается как “no break”. Цитирую, “Здесь опять же идёт намёк на визуальную особенность элемента. Что идёт в противоречие с самой сутью XHTML”. Так что либо CSS, либо &nbsp;

>>> где грамматические, там и логические
Честно говоря, одно из другого не следует. Мы года четыре назад пытались исследовать этот вопрос, никакой статистической зависимости не нашли.

>>> зачем существуют выше перечисленные элементы?
Вы не учитываете естественную эволюцию стандартов. Вспомните времена HTML 2.0, 3.2, когда еще никто не знал про CSS. естественно, тогда не было тенденции разграничить “презентационное” и “смысловое”. А благодаря backward compatibility большинство deprecated элементов живо в (X)HTML Transitional и до сих пор. Ведь если убрать из второй группы все deprecated и forbidden элементы (в XHTML Strict), то останутся только те, которые несут смысловую нагрузку. Ладно, еще iframe, который приходится использовать время от времени (всякая там асинхронная загрузка файлов, реклама и прочее).

>>> Они часто используются?
Видимо, это зависит от того, что именно Вы верстаете (отбросим устаревшие элементы для ясности). Например, если Вам приходится иметь дело с “красивыми ссылками”, то тэг base незаменим. Сложные формы? Здесь fieldset + legend, optgroup. Иногда button (смотря что нарисует дизайнер). Для сложных таблиц часто используются caption и всякие там thead, tbody, tfoot (кстати, tbody вообще обязательный элемент). Приходится рисовать математический формулы? В идеале MathML, но из-за его хреновой поддержки – sub/sup. И так далее. Всем разрешенным тэгам можно найти нормальное применение.

Я ответил на вопрос?

>>> о блочном варианте code
Всё равно это pre. Либо code с &nbsp; и br. Но первое удобнее. Кстати, вот если бы был блочный вариант code, каким вы себе его представляете? Оставляя в стороне его семантическую нагрузку, как он должен представляться визуально?

>>> Я же буду использовать тот, что даёт конкретный браузер или операционная система
+1
Если бы дизайнеры думали точно так же… Хотя с другой стороны, я их немного понимаю: что стоит баг с z-index у select в IE. Да, исправляется путем использования дикого iframe, но там свои глюки вылазят, если у родительских элементов прописано относительное позиционирование.

]]> Никита ]]>

1. Я говорю об использовании разработчиками, а не о соблюдении производителями браузеров.

2. Это я к примеру. На самом деле, в том же XHTML 1.0 Strict полно ненужных тэгов, у которых сомнительная логика. &nbsp; не всегда можно применить. Ведь есть множество вариантов когда нельзя переносить и &nbsp; не уместен.

3. Смысловая нагрузка большинства строчных элементов надумана. Вместо iframe предлогается object.

4. base не имеет смысла, когда нормальные cms генерируют абсолютные ссылки.

5. Часто вы видели сложные формы? А удобны ли они? legend как заголовок fieldset-а, да и сам fieldset бесполезные штуки. Зачем для структурирования форм придумывать отдельный тег, но элементы внутри засовывать в p? Чем h1-h6 по смыслу отличаются от legend? Только тем, что legend думан для форм? Не вижу весской причины.

> Для сложных таблиц часто используются caption и всякие там thead, tbody, tfoot
Очень и очень не часто.

> кстати, tbody вообще обязательный элемент
Что-о-о? С каких пор?!

sub/sup тоже не имеют логического оправдания. Почему его не выкинули вместе с nobr?

6. блочный code мне тоже не нужен, я бы свой HTML писал вообще по другому. Будет время — напишу.

7. Это когда выпавший селект под флеш подлезает?

]]> Prestige ]]>

“Он мне нужен чаще, чем , , или .”
В этой статье, наверно, было ключевым.
Напримет при разработке сайта о недвижимости я очень часто использовал sup (квардатный метр), потому что его логичнее и легче использовать чем тот же span с необходимым классом.

]]> mihailt ]]>

По поводу стандартов почитай блог Сагалаева, там довольно интересные мысли обо всём этом. ))

]]> Артём Курапов ]]>

Как я понял основная идея статьи – противопоставление существующих стандартов целесообразность использования тех или иных тэгов в общем и введения новых. Я думаю с этим проблемы повсюду – в автомобилестроении скорей всего при изобретении кардинально нового модуля (двигателя/подвески) надо поновой смотреть на всю линию, переделывать кузов, вносить изменения во всю инфраструктуру производства. Это уйма работы и денег. Не думаю что W3C очень богатая организация что-бы запросто вводить в эксплуатацию video-тэг со всеми предложениями по кодекам, подгрузке, безопасности и тп. Поэтому и получается долгое развитие, которое в основном делают браузеры. FF увидел табы у Оперы – скопировали, IE в свою очередь скопировал у FF. Точно так же сейчас с закруглёнными уголками. Глядишь – и до формы загрузки файла дойдут с отображением %.

]]> Sam ]]>

Никита, ты молодец! Мыслишь глобально, хоть и выводов пока не сделал даже для себя Так и надо. Ещё бы слушали тебя производители браузеров… а они даже W3C слушать не хотят.

]]> Vladimir ]]>

2. Тогда остаётся CSS

3. Про iframe согласен. Но пока IE6 жив, боюсь, что вместо object придётся использовать iframe.
По пооду строчных элементов – не знаю, не знаю… Ведь мы договорились не рссматривать устаревшие и запрещенные элементы.

4. Ну не всё пишется на CMS. А если один шаблон разделяется между несколькими поддоменами? Можно, конечно, определить в коде константу BASE_URL и использовать ее везде в адресах/ссылках, но зачем, если то же самое можно сделать тэгом base? Тем более, что относительные пути короче абсолютных и продолжают работать, даже если страница сохранена локально.

5a. Сложные формы – да, видел. *На мой взгляд*, удобны. Ведь во многом всё зависит от дизайна. fieldset в web – аналог GroupBox на десктопе. Соответственно, для рядового пользователя это “привычный элемент” – если он видет его в диалоговых окнах, например, в Windows, то для него будет логичным видеть его и на сложных формах. Ибо он так привык. Не знаю, возможно, это дело личных предпочтений. h1-h6? А какой именно использовать? Я им придавал несколько иной смысл, возможно, это моя трактовка. По поводу p – действительно, зачем? И уместно ли его вообще там использовать?
Возможно, что вместо форм будем использовать XForms, но это будет, боюсь, нескоро.

5b. Опять же, смотря что Вам приходится верстать и для какого media. Если для paged, то использование thead/caption при длинных таблицах (всякие там статистические данные) весьма логично – заголовок будет отображаться на каждой странице (как, например, это требует наш ГОСТ/ДСТУ). tfoot идеально подходит для всяких summary. И т.п.

5c. Не совсем точно выразился. Я имел в виду, что браузер неявно подставит tbody, если верстальщик забыл указать его явно. А в JavaScript в IE6 tbody очень даже обязателен: попробуйте средствами DOM создать таблицу без tbody и прицепить к ней tr.

7. Нет. Есть select, есть div с бОльшим z-index. div можно перетаскивать. Когда div окажется поверх select, IE6 будет рисовать его так, как если бы у select был самый большой z-index. Если не хотите таскать div, просто спозиционируйте его над select.

]]> pepelsbey ]]>

Прочитал, матернулся. Захотелось спросить «ну и?».
Но вот пока сдержался, а завтра напишу развёрнутый ответ.

]]> pepelsbey ]]>

> если возникает вопрос «Почему?»

…то тут же возникает ответ «предложите альтернативу». DHTML? JScript? LAYER? NOINDEX? — мы в этом уже поиграли и вернулись к W3C потому, что хотим, чтобы интернет стал кроссбраузерным и кроссплаформенным, а не придатком какой-то корпорации.

> «hello world» содержит грамматические ошибки

…как и заголовок публикации «Стандарты говорите», где запятая должна быть обязательно.

> Вот тэги, которые я бы использовал часто…

BR — это чтобы отступы не делать, или не использовать параграфы, или не писать элементам display:block для переноса на новую строку?

> Почему нет

Потому, что это элемент визуального форматирования. «Непереносить» — это по-вашему логика документа? У нас ведь кажется был CSS и white-space…

> legend как заголовок fieldset-а, да и сам fieldset бесполезные штуки.
> Зачем … придумывать отдельный тег, но элементы внутри засовывать в p?

Зачем, простите, внутри FIELDSET засовывать элементы форм в P (блок текста)? А… наверное это воспоминание о том, что в форму просто так нельзя положить INPUT, а требуется блочная обёртка. Так вот FIELDSET и является обёрткой, группируя поля формы. Удобнейшая вещь.

Проблема многих не слишком опытных верстальщиков (а потой и самых матёрых) состоит в том, что они не владеют в совершенстве тем языком, на котором они пишут. DIV, SPAN, TD и горы айдишников — всё, что нужно для счастья. Поэтому и кажется бесполезным FIELDSET, а NOBR мнится манной небесной.

> Чем h1-h6 по смыслу отличаются от legend?

Тем, что заголовки — это структурные элементы, которые держатся буквально вплотную к BODY, а LEGEND — это описание конкретного набора полей формы, заключённых в FIELDSET. Логично и просто.

В общем, содержание статьи сводится ко фразе «а почему меня не спросили, когда делали HTML?!» Я наверно не буду отвечать, только скажу, что технология развивается довольно давно и переживала множественные проблемы роста и то, что мы видим сейчас — это вполне себе удобный рабочий инструмент и не будь W3C, FONT’или бы мы сейчас и дальше. Ну или Flash’или бы…

Завершу свой чрезмерный коммент вашей же фразой — «Хватить канючить, пора работать». Не нравится та логика, что предложена W3C? Пожалуйста — не пишите DOCTYPE или создавайте свои DTD с логичными пространствами имён. А иначе все эти слова — выхлопы.

]]> Vladimir ]]>

>>> не пишите DOCTYPE
Вадим, простите, а что кардинально изменится, если не написать DOCTYPE (я не говорю о CSS)? Будет Quirks Mode, но от этого *смысл* элементов и их визуальное отображение не изменятся.

>>> создавайте свои DTD с логичными пространствами имён
в DTD пространства имён нет и не будет.

К тому же ни DTD, ни XSD, строго говоря, не дают элементам семантической нагрузки. Это мы знаем, что в XHTML p – это параграф, h1 – заголовок первого уровня, em – логическое ударение и т.п. Для XML-парсера названия тэгов ничего ровным счетом не значат. Всё, что DTD и XSD могут, это определить набор элементов и задать ограничения на их использование (например, что элементы, которые *мы* называем блочными, не могут появляться в элементах, которые *мы* называем строчными). Так что семантика – в общем случае, она только для верстальщика семантика.

]]> Yuri Baburov ]]>

Ага, бросай верстать. Самое верное решение.

]]> Andrew Tch ]]>

Скорее хватит рожать немного бесмыссленую статью просто для того чтобы что-то там родить и написать. ИМХО можно пиздеть на стандарты, но делай это кратко, а не пиши авторитетный маразм на 50 килобайт…

> Чем h1-h6 по смыслу отличаются от legend?

Ээээээ?? Вот от тебя не ожидал, перепутать текст с формой.

> а почему меня не спросили, когда делали HTML

…и когда делали стартапы, и когда пили пиво, и когда гейтс придумал кнопочку ок… Есть теоретики, есть практики.

]]> pepelsbey ]]>

> Вадим, простите, а что кардинально изменится, если не написать DOCTYPE

Документ без DOCTYPE — это не документ, поскольку не ясно к какой версии языка он принадлежит и по каким правилам мы вообще играем.

> К тому же ни DTD, ни XSD, строго говоря, не дают элементам семантической нагрузки

Согласен, однако, там описывается весь свод элементов конкретной версии языка и некоторые формальные правила их использования. А настоящая семантика начинается в спецификации. Не нравятся те версии языка, что рекомендует использовать W3C? Напишите свои, назовите ZHTML. Останется только мелочь — уговорить производителей браузеров понимать ваше расширение.

]]> Andrew Tch ]]>

> Вадим, простите, а что кардинально изменится, если не написать DOCTYPE

например, скорость парсера. браузеру не нужно будет догадываться, а что хотел верстальщик, подгонять его верстку. без доктайпа код разбирается “со словарем”, а с ним – как родной язык.

> К тому же ни DTD, ни XSD, строго говоря, не дают элементам семантической нагрузки

охуеть. ты еще скажи что DTD не нужен при парсинге.
любой (X)HTML при обработке проходит СНАЧАЛА tokenizer, который благодаря DTD правилам разбирает код, выделят теги и аттрибуты – строит DOM дерево, и если не указан DTD, то включается Quirks mode и прочая хрень перегружающая ядро браузера. Семантика работает с конкретным деревом, разбирая его, и там уже скорее CSS аттрибутика (ширина, положение, выравнивание).

]]> Sam ]]>

DTD при парсинге нафиг не нужен. DTD только для валидации.

]]> Andrew Tch ]]>

*вырезан мат о дизайнерах-гуру, что лезут в программирование*

Валидации при парсинге НЕТ. Будь то HTML, CSS, C++, PHP. Есть набор ПРАВИЛ языка, по которым проводится его разбор. Почитайте о форме бекуса-науэра для языков программирования – так вот, DTD и есть своеобразный аналог. Разница в том, что если PHP парсер встречает непонятный или невозможный в данном месте токен, то он выкидывает E_PARSE_ERROR, а браузер пытается понять, что же хотел верстальщик – самоучка, либо пропускает данный тест вообще.

]]> Sam ]]>

Andrew Tch
Разбор и парсинг (SAX/DOM) — вещи разные… Так сразу и надо было говорить, что имеете ввиду семантику. Хотя, тут наверноя я просто не вник с самого начала.

Да, DTD, конечно (в идеале) при разборе выжен. Но не факт, что браузер реализован так, что правила берёт из DTD. Сомневаюсь, что trident вообще на DTD смотрит.

pepelsbey
Конечно с рекомедациями лучше, чем без них и ситуация сейчас намного лучше той, что была ранее. Но всё-таки, как раз из таких возмущённых статей и рождаются будущие спецификации. Взять западные блоги, там, если, вспомнить, весь конец предыдущего года шло обсуждение будущих рекомендаций. HTML5 и XHTML2.

]]> Andrew Tch ]]>

Синтаксис, Sam. DOM/SAX/SimpleXML – это _стнтаксические_ анализаторы. Gecko/IE Webform/WebKit – это семантика, рендеринг документа, собственно.

Никакой браузер не может разбирать HTML просто так. Если он не принимает во внимание актальный DTD – это не значит что в него не зашиты правила разбора. А это и есть DTD. Посмотрите файлы:

http://www.w3.org/TR/xhtml1/DT.....tional.dtd
http://www.w3.org/TR/xhtml1/DTD/xhtml-symbol.ent

Это и есть описание правил разбора/парсинга XHTML.

]]> Sam ]]>

Правила разбора — не то же, что и DTD. Как тогда разбираются невалидные документы? Почему не прерывается(Opera — особый случай) разбор в местах несоответствия DTD?

]]> Andrew Tch ]]>

> Как тогда разбираются невалидные документы?

Разница в том, что если PHP парсер встречает непонятный или невозможный в данном месте токен, то он выкидывает E_PARSE_ERROR, а браузер пытается понять, что же хотел верстальщик – самоучка, либо пропускает данный тест вообще.

Вы файлы смотрели? Это почти то же самое что и исходники для yacc/bison. Возможно, я вас удивлю, но правил разбора вообще не существует. Ни для одного языка. Просто существуют методики генерации парсеров на основе BNF/EBNF/DTD… Для этого и существует DTD, просто HTML движки много менее строги чем токенайзер C++.

]]> Sam ]]>

Andrew Tch
Ладно, теорию компиляторов я начал забывать, рассуждения на тему не потяну…

]]> Vladimir ]]>

>>> хватит рожать немного бесмыссленую статью просто для того чтобы что-то там родить

Статья совсем не бессмысленная, просто не везде до конца логичная. А так – весьма и весьма интересная.

>>> Останется только мелочь — уговорить производителей браузеров понимать ваше расширение.

На самом деле, нет. XML+XSLT поддерживают почти все современные браузеры (не в курсе, как там с Оперой).

>>> ты еще скажи что DTD не нужен при парсинге.

DTD нужен только для валидации

>>> tokenizer, который благодаря DTD правилам разбирает код, выделят теги и аттрибуты – строит DOM дерево

Да ну? Лексический анализатор меньше всего зависит от DTD. DTD, если говорить с точки зрения теории компиляции, больше задаёт семантику, так как по сути, если верстальщик нарисовал что-то невалидное, при синтаксическом разборе Parse Error не выскакивает (то есть используются более мягкие правила разбора, нежели заданные в DTD). А DTD может использоваться для неявного закрытия тэгов и т.п. Хотя, если по большому счёту, во всех браузерах лексический, синтаксический и семантический анализ тесно связаны.

>>> Семантика работает с конкретным деревом, разбирая его, и там уже скорее CSS

Семантический анализатор HTML ну никак не связан с CSS. Вы понимаете, что такое семантика в теории компиляции?

>>> DTD и есть своеобразный аналог

Аналог-то аналог, но, как я говорил, браузер использует другую (более мягкую) грамматику, нежели та, которую предлагает DTD.

>>> Разбор и парсинг – вещи разные

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

>>> SAX/DOM

SAX – это разбор XML, который по определению well-formed, и если что с XML не так, то parse error. HTML же – это не XML, и при помощи SAX в общем случае его не разобрать. А DOM – это объектная модель документа, фактически, то, что является результатом работы всех анализаторовю

>>> Сомневаюсь, что trident вообще на DTD смотрит

ИМХО, на DTD смотрит только Konqueror и только если документ отдается как application/xhtml+xml (если говорить об (X)HTML и не лезть в XML). Gecko просто проверяет валидность XML-дерева.

>>> не зашиты правила разбора. А это и есть DTD

DTD – это (в идеале) грамматика. А правила разбора – это правила разбора. Это *восприятие* грамматики. Грамматика, зашитая в анализатор для разбора HTML, может в корне отличаться от грамматики, которую задает DTD.

>>> но правил разбора вообще не существует

Я это даже комментировать не буду. Грамматика задает правила разбора. Точка.

>>> менее строги чем токенайзер C++

Всякие Бизоны и т.п. генерируют парсеры для LALR-грамматик. Грамматика С++ – не LALR.
А токенайзер – это лексический анализатор.

>>> на самом деле, никакого AI – просто неявное закрытие/открытие тэгов, и не более того. И причем вне зависимости от того, задан DTD или нет.

]]> pepelsbey ]]>

> Но всё-таки, как раз из таких возмущённых статей и рождаются будущие спецификации

Что-то я не услышал в этой статье внятных и конкретных предложений. Сплошные вопросы «Почему так?!» и странные предположения про NOBR и элементы форм.

]]> Sam ]]>

pepelsbey
По этому я и написал про то, что «выводов пока не сделал даже для себя». Но, как известно, в диалоге рождается истина…

]]> Никита ]]>

mihailt, знаем, читали.

Артём Курапов, начнём с того, что в W3C входят столько богатых компаний, что вопрос о деньгах не стоит.
> Глядишь – и до формы загрузки файла дойдут с отображением %.
очень надеюсь.

Vladimir,
> 3. Про iframe согласен. Но пока IE6 жив, боюсь, что вместо object придётся использовать iframe.
а разве есть проблемы? Читайте — http://xhtml.ru/2007/09/06/no-iframe-use-object/

> По пооду строчных элементов – не знаю, не знаю… Ведь мы договорились не рссматривать устаревшие и запрещенные элементы.
Если запрещённые — это depricated, то что вы назваете устаревшими?

> 4. Ну не всё пишется на CMS…
Ну чаще всего. Ладно, это просто я не использую base, против него не выступаю. ))

> fieldset в web – аналог GroupBox на десктопе. Соответственно, для рядового пользователя это “привычный элемент”
Если элемент оформлен похоже, то это «привычный элемент». Не вижу кардинальных отличий логики fieldset и, например, div.

> h1-h6? А какой именно использовать?
А какой вы используете для заголовоков? По уровню вложения естественно.

> По поводу p – действительно, зачем? И уместно ли его вообще там использовать?
Почему нет? Это просто структурирование. fieldset отделяет элементы форм друг от друга, div и p отделяют текст, по сути это одно и то же. Это визуальная информация.

> thead/caption при длинных таблицах (всякие там статистические данные) весьма логично … tfoot идеально подходит для всяких summary. И т.п.
Если у меня будет summary не внизу а справа рядом с каждой строкой, что мне делать? Как я туда tfoot воткну?

> А в JavaScript в IE6 tbody очень даже обязателен: попробуйте средствами DOM создать таблицу без tbody и прицепить к ней tr.
У меня ученики занимались этим. Без проблем, динамически добавляли и удаляли строки и работало это во всех браузерах.

> Нет. Есть select, есть div с бОльшим z-index. div можно перетаскивать. Когда div окажется поверх select, IE6 будет рисовать его так, как если бы у select был самый большой z-index.
Я такие вещи обхожу. Считаю что для форм не должно быть каких-либо отвлекащих вещей. Тем более что при вёрстке очень часто обхожусь вообще без z-index и position: relative.

Кстати, почитайте историю, первые кто нарушил логику SGML — это Netscape.

pepelsbey,
альтернативы нет. Я её пока не вижу. Вернее вижу, но у каждой есть минусы.

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

> BR — это чтобы отступы не делать, или не использовать параграфы, или не писать элементам display:block для переноса на новую строку?
Это вы к чему?

> Потому, что это элемент визуального форматирования. «Непереносить» — это по-вашему логика документа? У нас ведь кажется был CSS и white-space…
Это к примеру, в противовес другим визуальным тэгам. Читайте между строк.

> Так вот FIELDSET и является обёрткой, группируя поля формы. Удобнейшая вещь.
А если в один fieldset нужно разместить несколько элементов на разных строках, но с одной темой? br-ами их будете разделять? Не вижу серьёзных причин для использования fieldset вообще. div тоже группирует элементы.

> Проблема многих не слишком опытных верстальщиков
Спасибо за комплимент ))

> LEGEND — это описание конкретного набора полей формы, заключённых в FIELDSET. Логично и просто.
Это не «описание», а заголовок.

> а почему меня не спросили, когда делали HTML?!
Не ну а действительно, почему меня не спросили? ))

> или создавайте свои DTD с логичными пространствами имён.
один из альтернативных вариантов, но не слишком удобный из-за того что все придуманные элементы будут строчными в бразуерах не поддерживающих CSS.
> А иначе все эти слова — выхлопы.
Зачем же вы комментируете, если для вас это выхлоп?

Andrew Tch,
> Ээээээ?? Вот от тебя не ожидал, перепутать текст с формой.
Я не путаю, я не вижу логики. Она надумана.

Херню какую-то ты понаписал про разбор по DTD. Разбор зависит только от Content-Type. Если это text/xml — разбирает, как xml, если text/html — как html, если application/xhtml+xml —как xhtml.

Дальше Andrew Tch, Sam и Vladimir общаются на тему парсеров. Не лезу. Я в этом ничего не понимаю.

> На самом деле, нет. XML+XSLT поддерживают почти все современные браузеры (не в курсе, как там с Оперой).
Только весьма топорно всё это создавать. Лучшее решение было бы xml + специфические элементы html + css. А такого нет.

> DTD нужен только для валидации
Ну как же это? Нужен хоть какой-то DTD чтобы выключить Quirks Mode.

]]> Sam ]]>

Никита
«Почему нет? Это просто структурирование. fieldset отделяет элементы форм друг от друга, div и p отделяют текст, по сути это одно и то же. Это визуальная информация.»
Это семантическая информация А так конечно похожи.

«У меня ученики занимались этим. Без проблем, динамически добавляли и удаляли строки и работало это во всех браузерах.»
Странно… советую перепроверить

«Разбор зависит только от Content-Type.»
А DOCTYPE?

«Нужен хоть какой-то DTD чтобы выключить Quirks Mode.»
Имелся ввиду DOCTYPE?

]]> Никита ]]>

Sam, вообще само использование семантики в разработке очень спорно. Зачем браузеру «понимать» значение того или иного элемента? Нужно объяснить функциональную нагрузку и всё. Остальная семантика предназначена только для самих разработчиков и сервисов использующих чужие данные.

> Имелся ввиду DOCTYPE?
да, именно

]]> Sam ]]>

Никита
А как же альтернативные браузеры? Читалки с экрана там, плагины для микроформатов, PDA, которые частенько применяют свои стили?

]]> Никита ]]>

Sam, они могут применять свои стили без проблем, но зачем же для этого городить огород из var, samp, kbd и т. п?

]]> Sam ]]>

Те же читалки стили не применяют. Они сменяют тональность в зависимости от семантики.

]]> Vladimir ]]>

>>> fieldset отделяет элементы форм друг от друга, div и p отделяют текст, по сути это одно и то же

Sam меня опередил…

>>> Без проблем, динамически добавляли и удаляли строки и работало это во всех браузерах

Оно-то без проблем, только для IE tbody всё равно нужен. Если tbody есть, тогда работает везде.

>>> Ну как же это? Нужен хоть какой-то DTD чтобы выключить Quirks Mode.

DTD можно оставить пустым – поставить две кавычки. И будет не Quirks Mode.

>>> вообще само использование семантики в разработке очень спорно.

Семантика не столько для браузера, сколько для удобства машинной обработки текста.

>>> А если в один fieldset нужно разместить несколько элементов на разных строках, но с одной темой?

А если элементы зафлоатить и, например, метке, поставить clear: both?

>>> Если у меня будет summary не внизу а справа рядом с каждой строкой, что мне делать? Как я туда tfoot воткну?

<th scope=”row”>, я полагаю… Хотя неудачно. Вспомните историю tfoot – раньше соединения были медленными, всё было на таблицах, и пока вся таблица не загрузится, она не отобразится. tfoot располагается перед tbody, поэтому summary можно увидеть до окончания загрузки.

А если серьезно, то всё зависит от таблицы… Понятно, что решение не универсальное, к сожалению.

>>> все придуманные элементы будут строчными в бразуерах не поддерживающих CSS

Уберите у FireFox его дефолтные стили (валяются в папке resource), и он тоже всё будет отображать строчными элементами.

>>> Если запрещённые — это depricated, то что вы назваете устаревшими?

Запрещенные – это forbidden (исключенные из спецификации). Устаревшие – deprecated – в спецификации остались, к использованию не рекомендуются.

>>> зачем же для этого городить огород из var, samp, kbd и т. п?

var – переменная, kbd – ввод пользователя. kbd пользоваться не пришлось, а var в математических формулах использую и ничего плохого в этом не вижу.

Кстати, будет желание – почитайте семантическую часть MathML, вот там действительно огород И, выражаясь “современным” языком, “многа букф”.

>>> Они сменяют тональность в зависимости от семантики.

… а тональность, в свою очередь, можно контролировать через CSS (всякие там azimuth, voice-family, cue).

]]> Никита ]]>

Vladimir,
Ошибся, я имел в виду DOCTYPE. достаточно написать <!DOCTYPE html>, чтобы включился стандартный режим.

> А если элементы зафлоатить и, например, метке, поставить clear: both?
Ага, и при малейшей ошибке, элементы потекут. Это никому не нужное извращение. Как будет отображаться в браузерах неподдерживающих CSS? В одну строчку выстроятся. Как вы сделаете две колонки? А вы знаете, что высота textarea в разных браузерах разная, хотя мы точно можем поставить кол-во строк.

> tfoot располагается перед tbody, поэтому summary можно увидеть до окончания загрузки.
при совершенно нелогичной последовательности.

> Уберите у FireFox его дефолтные стили (валяются в папке resource), и он тоже всё будет отображать строчными элементами
Пользователей тоже так делают? На мобилках удаляют стили? Что-то я не слышал о такой практике.

> Запрещенные – это forbidden (исключенные из спецификации). Устаревшие – deprecated – в спецификации остались, к использованию не рекомендуются.
Ну так о них вообще речи не идёт. Разве я их упомянул?

> var – переменная, kbd – ввод пользователя. kbd пользоваться не пришлось, а var в математических формулах использую и ничего плохого в этом не вижу.
Я в этом не вижу ничего полезного.

> … а тональность, в свою очередь, можно контролировать через CSS (всякие там azimuth, voice-family, cue).
тем более. Это ответ на твой вопрос, Sam.

]]> Артём Курапов ]]>

>> 3. Про iframe согласен. Но пока IE6 жив, боюсь, что вместо object придётся использовать iframe.
> а разве есть проблемы? Читайте — http://xhtml.ru/2007/09/06/no-iframe-use-object/

Насколько я знаю, использовать вместо iframe тэг object не лучшее решение, потому что могут возникнуть препятствия с вызыванием межоконных функций (всякие parent, top, window..). Сам я столкнулся с этим пытаясь создать из codepress ( http://kurapov.name/technology.....e_editors/ ) валидный XHTML редактор, и в FF были с этим проблемы. Направление помоему было – вызов функции (контейнер -> object). В то же время я удачно встраивал svg как объект и обратный вызов (object->контейнер) работал удачно.

]]> Никита ]]>

> А в JavaScript в IE6 tbody очень даже обязателен: попробуйте средствами DOM создать таблицу без tbody и прицепить к ней tr.
Убедился, но не совсем так. IE6 всё добавляет, и даже tbody, но только tr он вставляет после закрывающего tbody. Хотя если так написать статично, то всё отображается. Вообще в IE элементы создаются с HTML синтаксисом, как то, тэги прописными буквами, а значения атрибутов без кавычек. В Опере тэги в капсе, но атрибуты в кавычках. Остальные браузеры такой фигнёй не страдают.

]]> Никита ]]>

Собственно, вот о чём я говорил, когда упомянул о нехватке блочного code:
http://www.w3.org/TR/xhtml2/mo....._blockcode

]]> Sam ]]>

Если посмотреть в черновые варианты HTML5 и XHTML2 — найдёшь там многое из того, что ты говорил…

]]> Никита ]]>

Я об этом уже пишу новый пост.

]]> Vladimir ]]>

>>> а разве есть проблемы? Читайте

Проблемы есть и много… Во-первых, скроллинг и рамка у object, которые CSS убрать не в состоянии (скроллинг убирается только в Quirks Mode). Во-вторых, object – это ActiveX control, и для загрузки документа с другого сайта нужно извращаться (из-за censored модели безопасности).

>>> HTML5 и XHTML2

HTML5 и XHTML2, конечно, хорошо, но если смотреть объективно, то через сколько лет мы их сможем использовать?

]]> Zigzag ]]>

Никита, во многом не согласен с тобой. Не понимаю причин, по которым стоит убирать, fieldset, sup, sub и прочее. Я вот как-раз против введения новых элементов header, footer и прочих, которые есть в HTML5.

Лично мне больше нравятся идеи XHTML2.

]]> Никита ]]>

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

]]> Zigzag ]]>

Я против расширения языка за счет внедрения новых элементов, я не вижу практической пользы от них. Имхо, лучше микроформаты двигать в этом направлении.

]]> Никита ]]>

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

]]> Zigzag ]]>

Мне проще работать с микроформатами, чем супом тэгов.

]]> Денис ]]>

Да, иногда приходится отходить от стандартов.
А почему вместо <nobr> вы не используете   ?

]]> Денис ]]>

*nbsp

]]> Никита ]]>

Денис, потому что не нужные переносы слов могут быть не только по пробелу, но и по дефису, слешу и другим символам.

]]> Vladimir ]]>

<span style="white-space: nowrap">...</span>?

]]> Vladimir ]]>

PS – а почему нельзя переносить по дефису или слэшу?

]]> Никита ]]>

Vladimir, так можно, это понятно, но много писанины. Ещё раз повторяю, я не за то, чтобы вернуть nobr. Я просто привёл его в качестве примера.

По дефису не переносятся телефонные номера и слова «во-первых» и т. п. А по слешу нельзя переносить например номера договоров (у Евросоюза есть такие).

]]> Vladimir ]]>

За дефисы спасибо, не знал.

>>> это понятно, но много писанины

А что делать, если нужен полужирный текст, при этом выделение является декоративным, а не семантическим (то есть тэг b вместо strong)? По-моему, этот вопрос поднимался у Вас на блоге (возможно, я ошибаюсь). Пока что единственным “семантическим” решением, не идущим вразрез с XHTML Strict, является span style=”font-weight: bold”.

]]> Никита ]]>

Я вижу для себя решение создания namespace, например:
<decor:b>полужирный декоративный элемент</decor:b>

Кстати, есть неразрывный дефис. Его код: &#8209;