Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 135
В 8 пункте в <table> «<>» замените на entities
Не очень понятна ваша позиция по пункту номер 10. Проясните пожалуйста.
""Если документ будет написан только на XHTML 1.0 (без использования других языков разметки), особых различий не будет. Однако по мере того, как инструменты XML становятся все более доступными - например, XSLT для преобразования документов - вы начнете замечать преимущества использования XHTML . Например, XForms позволяет редактировать XTML документы (или любые другие XML документы) простым и контролируемым способом. Семантические Интернет – приложения смогут воспользоваться преимуществами XHTML документов .
Если ваш документ включает не только XHTML 1.0, но например, и MathML, SMIL, или SVG, то преимущества очевидны: Вы не сможете сделать ничего подобного с HTML.
Помимо вышеперечисленного:
XHTML-документы соответствуют стандарту XML, и, следовательно, они могут просматриваться, редактироваться и проверяться на синтаксическую правильность стандартными средствами поддержки языка XML.
XHTML-документы могут отображаться как существующими обозревателями HTML-документов, так и новыми обозревателями, поддерживающими стандарт XHTML.
XHTML-документы могут обращаться к сценариям и аплетам, основанным на объектной модели документов (DOM).
С практической точки зрения преимущества XHTML таковы:
И разработчики документов, и разработчики обозревателей постоянно ищут новые способы выражения своих идей с помощью новых HTML-тегов. XML обеспечивает единый и простой способ создания новых элементов языка и их дополнительных атрибутов. XHTML призван унифицировать такие расширения языка HTML посредством XHTML-модулей, которые будут поддерживать комбинации существующих элементов HTML с новыми элементами при разработке и отображении документов.
Постоянно возникают все новые способы и средства доступа к Сети: карманные компьютеры и телевизионные приставки, сотовые телефоны и пейджеры. По некоторым оценкам, к 2002 г. 75% просмотра Веб-страниц будет осуществляться с помощью этих альтернативных средств. XHTML был разработан с ориентацией на обобщенный обозреватель, который в сочетании с механизмами словарей метаданных должен обеспечить оптимальное преобразование содержимого документа при его отображении, с тем, чтобы, в конце концов, перейти к разработке таких документов, которые будут адекватно отображаться любым обозревателем, поддерживающим стандарт XHTML.""
http://www.itstan.ru/content/view/2665/2…
Если ваш документ включает не только XHTML 1.0, но например, и MathML, SMIL, или SVG, то преимущества очевидны: Вы не сможете сделать ничего подобного с HTML.
Помимо вышеперечисленного:
XHTML-документы соответствуют стандарту XML, и, следовательно, они могут просматриваться, редактироваться и проверяться на синтаксическую правильность стандартными средствами поддержки языка XML.
XHTML-документы могут отображаться как существующими обозревателями HTML-документов, так и новыми обозревателями, поддерживающими стандарт XHTML.
XHTML-документы могут обращаться к сценариям и аплетам, основанным на объектной модели документов (DOM).
С практической точки зрения преимущества XHTML таковы:
И разработчики документов, и разработчики обозревателей постоянно ищут новые способы выражения своих идей с помощью новых HTML-тегов. XML обеспечивает единый и простой способ создания новых элементов языка и их дополнительных атрибутов. XHTML призван унифицировать такие расширения языка HTML посредством XHTML-модулей, которые будут поддерживать комбинации существующих элементов HTML с новыми элементами при разработке и отображении документов.
Постоянно возникают все новые способы и средства доступа к Сети: карманные компьютеры и телевизионные приставки, сотовые телефоны и пейджеры. По некоторым оценкам, к 2002 г. 75% просмотра Веб-страниц будет осуществляться с помощью этих альтернативных средств. XHTML был разработан с ориентацией на обобщенный обозреватель, который в сочетании с механизмами словарей метаданных должен обеспечить оптимальное преобразование содержимого документа при его отображении, с тем, чтобы, в конце концов, перейти к разработке таких документов, которые будут адекватно отображаться любым обозревателем, поддерживающим стандарт XHTML.""
http://www.itstan.ru/content/view/2665/2…
По поводу версий для сотовых, КПК и прочих. Я не считаю, что надо все скармливать единый шаблон, а потом его разными CSS-ами приводить к нужному виду. Ну не хочу я по GPRS качать здоровую версию страницы для большого экрана, чтобы потом браузер ее CSS-ил. Дайте мне адаптированную версию с минимумом веса и адаптированной навигацией.
вроде о css ни в статье, ни в топике речи вообще не идет, не так ли?
Тем более что часто сделать 2 версии шаблона быстрее, проще и выгоднее по затратам, чем делать одну универсальную.
Программеры часто стремятся решить задачу «наиболее общим» способом, в то время как надо решать «наиболее правильным».
Программеры часто стремятся решить задачу «наиболее общим» способом, в то время как надо решать «наиболее правильным».
простите, но это чушь, с каких пор делать два докмента с разной разметкой проще, чем один с двумя стилями?
Ну не хочу я по GPRS качать здоровую версию страницы для большого экрана
Согласен, GPRS траффик отнюдь не дешевый, да и скорость оставляет желать лучшего, поэтому для КПК должна быть отдельная версия.
По пункту 10: можно и без XHTML, а просто в HTML посредством CSS определять что пойдет на принтер, а что на экран. И даже при табличной верстке. Смотря как сверстать.
Понятно, спасибо
но вы не сможете, на 100% управлять форматированием документа, т.к. общая разметка уже задана самими таблицами
В том-то и прикол, что сам по себе XHTML ничем не лучше HTML, если не менять стиль и идеологию разметки. Грубо говоря "XHTML это стилистические правки к HTML чтобы это можно было называть XML-ем". Все остальные аспекты разницы между ними - ерунда. Лично я использую "DOCTYPE XHTML 1.1 Strict" лишь для укрощения глюков отображения CSS в IE6. Самый главный акцент ИМХО должен ставиться на том, как следует изменить мышление дизайнера, чтобы посредством CSS его продукт можно было эффективно и минимальным кодом доносить до любого устройства.
Как я понял, автора интересует, какие преимущества даст владельцу/разработчику css вёрстка сайта.
1. Для бизнеса, владельцев сайта
Можно предположить, что при удачно свёрстанном сайте, разработчик добьётся соблюдения синтаксиса и семантики. Тем самым владельцу сайта, можно будет рассчитывать на увеличение посещаемости сайта. В идеале – прибыли.
Владелец сайта может «козырнуть» перед партнерами/посетителями присутствием их сайта во всяческих «css-каталогах» по типу: http://www.cssmania.com
2. Для себя как разработчиков
1. Удобно править дизайн.
2. Читаемость кода(легко понять, что и где)
3. Поисковая оптимизация
4. Сделать и сказать, что: «Я смог» ;)
На практике, с css знаком на уровне одного, еще не запущенного сайта :)
1. Для бизнеса, владельцев сайта
Можно предположить, что при удачно свёрстанном сайте, разработчик добьётся соблюдения синтаксиса и семантики. Тем самым владельцу сайта, можно будет рассчитывать на увеличение посещаемости сайта. В идеале – прибыли.
Владелец сайта может «козырнуть» перед партнерами/посетителями присутствием их сайта во всяческих «css-каталогах» по типу: http://www.cssmania.com
2. Для себя как разработчиков
1. Удобно править дизайн.
2. Читаемость кода(легко понять, что и где)
3. Поисковая оптимизация
4. Сделать и сказать, что: «Я смог» ;)
На практике, с css знаком на уровне одного, еще не запущенного сайта :)
Немного не так поняли, вопрос был про "html vs xhtml"
Про преимущества CSS я знаю. Более того, наши сайты в 90% случаев сделаны по стандартам. У меня претензии к аргументам большинства фанатов валидности. Такие аргументы, скорее, препятствуют распространению стандартов.
Такие аргументы, скорее, препятствуют распространению стандартов.
А вот под этим подпишусь.
Валидность нужна для того, чтобы коды браузеров стали меньше, чтобы их можно было затолкнуть в ботинки и компасы. А сейчас для чтения большинства сайтов нужен чуть ли не искусственный интеллект (чтобы понимать что там понаписано) объемом в 60-70мег диска.
Владелец сайта может «козырнуть» перед партнерами/посетителями присутствием их сайта во всяческих «css-каталогах» по типу: http://www.cssmania.com
О да, так и вижу, как серьезный бизнесмен Дерипаска козыряет присутствием сайта «Русала» в cssmania :-) Это для бизнеса ничего не даст. Это как раз разработчики могут «козырять».
Согласен. Для коммерции ещё очень важным фактором является объём кода. Так уж получается, что мои XHTML/CSS сайты обходят в поисковиках очень серьёзных дядек только благодаря компактности кода. Второй важный коммерческий фактор - нагрузка. Сайты от 10к посетителей заметно нагружают сервера не только работой php но и трафиком (а он у лучших провайдеров не бесплатный). Косвенный фактор - загруженность каналов. Если только за счёт верстки я смог сэкономить 70-100 гигабайт трафика пользователям в месяц, то это значит, что они смогли сэкономить больше времени и закачать что-то ещё не переплачивая за свои каналы связи.
Забавную вы статью нашли.
Если уж читать про такие вещи, то у западных авторов.
Сразу скажу, что xhtml стоит воспринять скорее как концепцию, ведь xhtml-документ может отличаться от html-документа только DOCTYPE'ом (и некоторыми другими деталями, но, применительно к xhtml 1.0, это не так важно). В DOCTYPE задается ссылка на DTD, который определяет тип и правила написания документа.
Вся разница в использовании заключается в том, что xhtml предполагает разделение структуры и представления. Т.е. при определённых условиях можно из html4 смело переезжать в xhtml. А при максимальном отделении структуры от представления всё будет зависеть от того, работает ли браузер (не важно какой) со стилями. Если да - то он разметит соответственно стилям. Если нет - то соответственно своим представлениям. И не будет загружено ничего лишнего - только то, что представляет собой структуру документа.
Впрочем, никто не мешает сделать 33 версии одной страницы для разных пользовательских агентов.
Что и где использовать - личное дело каждого, но стоит признать, что переход к семантической вёрстке, сам по себе, подразумевает использование xhtml. А семантическая верстка - это уже высокий профессиональный уровень. Кто не хочет быть профессионалом? ;)
ps. Есть ещё понятие модульности xhtml, но про него читайте на w3c.org. Я ещё столько не курил.
pps. И вообще, рекомендую первоисточник.
Если уж читать про такие вещи, то у западных авторов.
Сразу скажу, что xhtml стоит воспринять скорее как концепцию, ведь xhtml-документ может отличаться от html-документа только DOCTYPE'ом (и некоторыми другими деталями, но, применительно к xhtml 1.0, это не так важно). В DOCTYPE задается ссылка на DTD, который определяет тип и правила написания документа.
Вся разница в использовании заключается в том, что xhtml предполагает разделение структуры и представления. Т.е. при определённых условиях можно из html4 смело переезжать в xhtml. А при максимальном отделении структуры от представления всё будет зависеть от того, работает ли браузер (не важно какой) со стилями. Если да - то он разметит соответственно стилям. Если нет - то соответственно своим представлениям. И не будет загружено ничего лишнего - только то, что представляет собой структуру документа.
Впрочем, никто не мешает сделать 33 версии одной страницы для разных пользовательских агентов.
Что и где использовать - личное дело каждого, но стоит признать, что переход к семантической вёрстке, сам по себе, подразумевает использование xhtml. А семантическая верстка - это уже высокий профессиональный уровень. Кто не хочет быть профессионалом? ;)
ps. Есть ещё понятие модульности xhtml, но про него читайте на w3c.org. Я ещё столько не курил.
pps. И вообще, рекомендую первоисточник.
Интересная статья на ту же тему от Ивана Сагалаева.
Что мешает верстать блоками, полностью безтабличной версткой в рамках HTML? Неужели, тот, кто верстает таблицами, не сможет продолжать делать это использую XHTML? Что мешает выносить все оформление в CSS из HTML документа?
По моему, на лицо подмена понятий.) Смена используемого DOCTYPE 'а не заставит никого верстать блочно и в соответствии со стандартами.
Последнее время все чаше появляются статьи молодых авторов, которые пытаются писать о том, в чем сами, до конца не разобрались. С одной стороны - нужно набираться опыта, с другой стороны, люди не достаточно подкованные в вопросе могут получить много лишней, а зачастую и ложной информации. Так что, уважаемые писатели, изучайте досконально предметную область!
По моему, на лицо подмена понятий.) Смена используемого DOCTYPE 'а не заставит никого верстать блочно и в соответствии со стандартами.
Последнее время все чаше появляются статьи молодых авторов, которые пытаются писать о том, в чем сами, до конца не разобрались. С одной стороны - нужно набираться опыта, с другой стороны, люди не достаточно подкованные в вопросе могут получить много лишней, а зачастую и ложной информации. Так что, уважаемые писатели, изучайте досконально предметную область!
Смена используемого DOCTYPE заставит документ проверяться по другим правилам.
Вы разницу между XML и HTML знаете ?
xhtml всё равно не xml
он, всё же, язык разметки =)
он, всё же, язык разметки =)
xhtml как раз xml. Внимательнее читайте :)
хм. да, а вы правы =)
не с той стороны посмотрел %)
xhtml "подмножество" xml, т.е. всё же им является.
не с той стороны посмотрел %)
xhtml "подмножество" xml, т.е. всё же им является.
а xml, по сути, упрощённый sgml ...как и html :)
Кто кому каким родственником приходится - не суть важно!
Кто кому каким родственником приходится - не суть важно!
важно не родство, а перспектива. у XML перспектива есть, а у HTML - нет. и тот факт, что спецификация HTML закрыта ясно говорит, что им более пользоваться не нужно.
Нуу... Торопитесь.
HTML 5
HTML 5
Это вилами по воде. На w3c такой спецификации нет. Кроме того назовите хоть одно преимущество HTML перед XML (XHTML) чтобы имелся хоть какой-то смысл оглядываться на него.
Отлов ошибок.
Да-да, я тоже некотрое время болел мыслью «XML парсер крут — чуть ошибка, сразу аборт, все будут делать лёгкие валидные сайты!»
Однако если у вас серьёзный живой сайт, вы не захотите, чтобы из-за незначительной ошибки пользователи виделю фигню на экране. А ошибка может завестись из-за: баннеров рекламы, комментариев (<strong>foo<em>bar</strong>quux</em>, не говоря уже о драконьих правилах «блочный-не блочный»), тагов, CMS, где директор захочет поменять текст, и.т.д.
Да-да, я тоже некотрое время болел мыслью «XML парсер крут — чуть ошибка, сразу аборт, все будут делать лёгкие валидные сайты!»
Однако если у вас серьёзный живой сайт, вы не захотите, чтобы из-за незначительной ошибки пользователи виделю фигню на экране. А ошибка может завестись из-за: баннеров рекламы, комментариев (<strong>foo<em>bar</strong>quux</em>, не говоря уже о драконьих правилах «блочный-не блочный»), тагов, CMS, где директор захочет поменять текст, и.т.д.
Вы просто опустили руки. Мало того, что ни один десктопный браузер не останавливает парсинг найдя ошибку валидации xhtml, так ещё и полно средств валидации кода внесённого пользователями. (у меня например пользователи давно не могут испортить валидацию). Баннерные системы это отдельная тема, но вцелом связываться с такими, которые не контролируют валидность кода обычно не оправдано.
Аргумент про драконьи правила "блочный-не блочный" не понял.
Аргумент про драконьи правила "блочный-не блочный" не понял.
Firefox. А ваш разве "падает"? =)
как раз по приведённым ссылкам фаерфокс «падает» [ff 2.0.0.4, win xp].
Разве это повод писать код невалидным и прикрываться спецификацией html? =)
разумеется нет.
но, имхо, это довольно весомый повод отдавать валидный код xhtml 1.0, как html (http://www.w3.org/TR/xhtml1/#guidelines)
но, имхо, это довольно весомый повод отдавать валидный код xhtml 1.0, как html (http://www.w3.org/TR/xhtml1/#guidelines)
Ваша позиция мне понятна, но я её не разделяю. И вот почему:
1. xhtml доступен бОльшему числу устройств чем html. И число это будет только увеличиваться.
2. Все языки программирования прекращают компиляцию/исполнение при обнаружении грубой ошибки, но это никого не останавливает от написания программ. Даже интерпретаторы языков разметки (PCL, Postscript, Grof, TeX) не допускают выполнения некорректной "программы". И только десктопные браузеры допускали интерпретацию ошибочного кода, а вы уже за это считаете html незаменимым. Очень странная у вас позиция — вы похоже считаете профессиональным написание невалидного кода только на том основании, что браузер это терпит.
1. xhtml доступен бОльшему числу устройств чем html. И число это будет только увеличиваться.
2. Все языки программирования прекращают компиляцию/исполнение при обнаружении грубой ошибки, но это никого не останавливает от написания программ. Даже интерпретаторы языков разметки (PCL, Postscript, Grof, TeX) не допускают выполнения некорректной "программы". И только десктопные браузеры допускали интерпретацию ошибочного кода, а вы уже за это считаете html незаменимым. Очень странная у вас позиция — вы похоже считаете профессиональным написание невалидного кода только на том основании, что браузер это терпит.
нет, код должен быть валидным. валидным xhtml'ем. тут спору нет. и обратного я не утверждал.
но…
на сегодняшний день браузеры работают так как они работают. в частности в документе отданном с application/xhtml+xml javascript-конструкция document.write(...) работать не будет. и это только один из примеров различия обработки бразуерами html- и xhtml- mime-типов.
поэтому, имхо, надо писать валидный xhtml и отдавать его в режиме совместимости с html.
но…
на сегодняшний день браузеры работают так как они работают. в частности в документе отданном с application/xhtml+xml javascript-конструкция document.write(...) работать не будет. и это только один из примеров различия обработки бразуерами html- и xhtml- mime-типов.
поэтому, имхо, надо писать валидный xhtml и отдавать его в режиме совместимости с html.
тут я с вами согласен. Хотя для себя выбрал необходимым ещё и отличать совместимых клиентов от несовместимых — чтобы на всяких наладонниках/телефонах проблем не было. А читать и разбирать "Accept:" весьма несложно.
А может вы мне объясните смысл обременения браузера дополнительной работой, заставляя его парсить непонятные слэши в тагах BR, HR? «XHTML», отданный как text/html, парсится как tag soup и не иначе. XML парсер и не включается.
Правда, если вы пытаетесь слать браузеру content-type, основываясь на Accept, тогда, может, идея совсем и не плоха.
Правда, если вы пытаетесь слать браузеру content-type, основываясь на Accept, тогда, может, идея совсем и не плоха.
Это повод пользоваться HTML в принципе.
1. не вижу
2. более жесткая структура — это всегда хорошо и удобно =) но я и на хтмл4 могу верстать с такой же жесткой структурой. для себя я тоже не вижу плюсов xhtml. движок придётся переписывать =/
2. более жесткая структура — это всегда хорошо и удобно =) но я и на хтмл4 могу верстать с такой же жесткой структурой. для себя я тоже не вижу плюсов xhtml. движок придётся переписывать =/
Работал верстальщиком начиная с 98-го года. Тогда никаких div+css никто не использовал, да и вообще w3c рекомендовал воздержаться от использования тега div.
В период бума css-верстки естественно тоже экспериментировал - получалось круто, но никак не лучше и не быстрее.
Сейчас занимаюсь версткой очень мало, а мнение мое таково:
Создавать документы по новым (но уже устоявшимся) стандартам (XHTML) - хорошо.
Самосовершенствоваться в подходах к разработке - хорошо.
Слепо следовать чьему-то мнению - плохо.
А вообще поставленный вопрос можно отнести к дебата на тему: что лучше java или с#?, perl или php? и т.д.
В период бума css-верстки естественно тоже экспериментировал - получалось круто, но никак не лучше и не быстрее.
Сейчас занимаюсь версткой очень мало, а мнение мое таково:
Создавать документы по новым (но уже устоявшимся) стандартам (XHTML) - хорошо.
Самосовершенствоваться в подходах к разработке - хорошо.
Слепо следовать чьему-то мнению - плохо.
А вообще поставленный вопрос можно отнести к дебата на тему: что лучше java или с#?, perl или php? и т.д.
Кстати, насчет кроссбраузерности валидного XHTML+CSS я совсем несогласен!
В моей практике очень часто встречалось, что полностью валидная и семантичная (ох, какие модные слова ныне) верстка выглядела в разных браузерах по-разному (в ие5 и прочих архаизмах я не тестировал).
Так что XHTML (а также валидность, семантичность и куча других ругательств) выжить на сегодня не всегда помогает - результат нужен здесь и сейчас, а не через н-цать лет, когда все браузеры будут корректно работать с версткой.
Я не противник w3c-стандартов, я наоборот буду праздновать тот день, когда производители браузеров и верстальщики дружно начнут поддерживать стандарты. Вторые уже активно идут к этому, а вот первые...
В моей практике очень часто встречалось, что полностью валидная и семантичная (ох, какие модные слова ныне) верстка выглядела в разных браузерах по-разному (в ие5 и прочих архаизмах я не тестировал).
Так что XHTML (а также валидность, семантичность и куча других ругательств) выжить на сегодня не всегда помогает - результат нужен здесь и сейчас, а не через н-цать лет, когда все браузеры будут корректно работать с версткой.
Я не противник w3c-стандартов, я наоборот буду праздновать тот день, когда производители браузеров и верстальщики дружно начнут поддерживать стандарты. Вторые уже активно идут к этому, а вот первые...
Валидный и семантически верный кто? Правильно — XHTML-код.
А за отображение в браузере отвечает кто? Правильно — CSS-код.
Думать нужно го-ло-вой.
Если вы умеете верстать, то делать это валидно вам не составит никакого труда.
Если нет — то дешевле отмазаться «мне это не нужно».
А за отображение в браузере отвечает кто? Правильно — CSS-код.
Думать нужно го-ло-вой.
Если вы умеете верстать, то делать это валидно вам не составит никакого труда.
Если нет — то дешевле отмазаться «мне это не нужно».
Уважаемый, не стоит рисоваться.
Курю эти чудесные документы уже несколько лет.
Я в курсе что такое валидность CSS.
Но речь шла о валидности и семантике. Пара этих свойств может принадлежать только (X)HTML-документу, потому как семантика построения CSS — это нонсенс.
В любом случае, ни одно их этих понятий — вместе или по одиночке — не влияют на отображение документа в браузере.
Курю эти чудесные документы уже несколько лет.
Я в курсе что такое валидность CSS.
Но речь шла о валидности и семантике. Пара этих свойств может принадлежать только (X)HTML-документу, потому как семантика построения CSS — это нонсенс.
В любом случае, ни одно их этих понятий — вместе или по одиночке — не влияют на отображение документа в браузере.
потому как семантика построения CSS — это нонсенс
Меня сначала тоже "резануло", но потом я кое-что вспомнил.
по-разному это на процентов 5, не больше. и есть множество css-хаков (даже валидных), дополнив которыми ваши стили, вы добьетесь одинакового отображения.
Я не писал про то, что я верстаю невалидно или не умею это делать. Мой сайт проходит валидацию. Я пишу о том, что сейчас настал такой момент, что юзеры поняли пользу стандартов, а изготовители браузеров - нет.
Я бы попросил разговаривать чуть более спокойным тоном - вы же уважаемый человек, вас итак хорошо слышно 8)
Я бы попросил разговаривать чуть более спокойным тоном - вы же уважаемый человек, вас итак хорошо слышно 8)
Прошу прощения за резкость.
Просто фраза «полностью валидная и семантичная ... верстка выглядела в разных браузерах по-разному» не выдерживает никакой критики.
Просто фраза «полностью валидная и семантичная ... верстка выглядела в разных браузерах по-разному» не выдерживает никакой критики.
Да ладно, так уж и не выдерживает? Интересно, зачем тогда приходится все эти «хаки» применять? Особенно когда дизайн более-менее сложный. В Опере одно отображение, в IE другое, например? Или такого не бывает?
Перечитайте, пожалуйста, внимательно первые две строки моего комментария.
Валидный и семантичный XHTML-код. Хаки пишутся в CSS.
Валидный и семантичный XHTML-код. Хаки пишутся в CSS.
Я что-то не могу понять: вы утверждаете, что если XHTML "валидный (что, кстати, сие значит?)" и "семантичный", то это автоматически делает код "кроссбраузерным"?
Уфф. Что-то меня перестали понимать.
Уважаемый Gugnin сказал выше, следующее:
«В моей практике очень часто встречалось, что полностью валидная и семантичная (ох, какие модные слова ныне) верстка выглядела в разных браузерах по-разному (в ие5 и прочих архаизмах я не тестировал)»
Т.е. он сказал, что валидный и семантичный XHTML-код сам по себе отображался криво.
Я посчитал эту фразу смешной и возразил:
«Валидный и семантически верный кто? Правильно — XHTML-код.
А за отображение в браузере отвечает кто? Правильно — CSS-код»
Валидность, т.е. соответствие кода правилам той версии языка, который указан в DOCTYPE, не имеет отношения к отображению сайта в браузере пользователя. За это отвечает CSS.
Надеюсь, что на этот раз я выразился ясно.
Уважаемый Gugnin сказал выше, следующее:
«В моей практике очень часто встречалось, что полностью валидная и семантичная (ох, какие модные слова ныне) верстка выглядела в разных браузерах по-разному (в ие5 и прочих архаизмах я не тестировал)»
Т.е. он сказал, что валидный и семантичный XHTML-код сам по себе отображался криво.
Я посчитал эту фразу смешной и возразил:
«Валидный и семантически верный кто? Правильно — XHTML-код.
А за отображение в браузере отвечает кто? Правильно — CSS-код»
Валидность, т.е. соответствие кода правилам той версии языка, который указан в DOCTYPE, не имеет отношения к отображению сайта в браузере пользователя. За это отвечает CSS.
Надеюсь, что на этот раз я выразился ясно.
Фразу надо воспринимать целиком, а не разбирая каждое слово отдельно.
Вёрстка - это работа с отоборажением информации т.е. совокупность CSS и (X)HTML
Валидная и семантически верная вёрстка означает её соответствие формальным стандартам и рекомендациям.
Вот что нам говорит Глоссарий.ру:
т.е. говоря простым русским языком: семантически верный значит "без трюкачеств", что вполне применимо и к CSS
Вёрстка - это работа с отоборажением информации т.е. совокупность CSS и (X)HTML
Валидная и семантически верная вёрстка означает её соответствие формальным стандартам и рекомендациям.
Вот что нам говорит Глоссарий.ру:
Семантика - От греч.Semantikos - обозначающий
Семантика - раздел языкознания и логики, исследующий проблемы, связанные со смыслом, значением и интерпретацией лексических единиц.
Семантика в программировании - система правил истолкования отдельных языковых конструкций. Семантика определяет смысловое значение предложений алгоритмического языка.
т.е. говоря простым русским языком: семантически верный значит "без трюкачеств", что вполне применимо и к CSS
Глоссарий — это чудесно, однако не стоит искать додумывать того, чего там нет:
«смысл, значение и интерпретация» — где фраза про трюкачества?
Хак, между прочим, это чёткая семантическая единица — это правило несущее информацию для конкретного браузера, точно так же, как элемент H1 несёт информацию о заголоке документа.
Содержимое, внутрення навигация, контакты, заголовки, ссылки, цитаты, пераграфы, etc... где вы нашли в CSS такое море семантических элементов, между которыми выстраиваются чёткие смысловые связи?
Я не спорю, что в построении CSS-файла должна присутствовать логика, но назвать это семантикой в широком смысле слова у меня не поворачивается язык.
Впервые с понятием семантика я познакомился ещё в курсе лекций по стилистике языка, поэтому я предпочитаю не произносить его почём зря только потому, что это стало модно.
«смысл, значение и интерпретация» — где фраза про трюкачества?
Хак, между прочим, это чёткая семантическая единица — это правило несущее информацию для конкретного браузера, точно так же, как элемент H1 несёт информацию о заголоке документа.
Содержимое, внутрення навигация, контакты, заголовки, ссылки, цитаты, пераграфы, etc... где вы нашли в CSS такое море семантических элементов, между которыми выстраиваются чёткие смысловые связи?
Я не спорю, что в построении CSS-файла должна присутствовать логика, но назвать это семантикой в широком смысле слова у меня не поворачивается язык.
Впервые с понятием семантика я познакомился ещё в курсе лекций по стилистике языка, поэтому я предпочитаю не произносить его почём зря только потому, что это стало модно.
Вот именно, что хак - это такое правило для броузера (интерпретация лексических единиц), смысл и значение которого не очевидны. Это как раз и есть нарушение семантики.
Если Каскадные Таблицы Стилей по вашему, не содержат элементов, между которыми выстраиваются смысловые связи, то говорить нам больше не о чем.
Если Каскадные Таблицы Стилей по вашему, не содержат элементов, между которыми выстраиваются смысловые связи, то говорить нам больше не о чем.
Каскадные таблицы стилей сами по себе не содержат никакой логической структуры, они основываются на том документе, к которому обращены.
#content .entry H3 — заголовок третьего уровня внутри элемента entry, являющегося дочерним по этношению к элементу content. Вы понимаете чья структура и логика описывается в данном правиле? Структура и логика документа, а не самой таблицы стилей.
> смысл и значение которого не очевидны
Если вы пишете хак, значит для вас его значение очевидно. Вот и смысл, вот и связи.
#content .entry H3 — заголовок третьего уровня внутри элемента entry, являющегося дочерним по этношению к элементу content. Вы понимаете чья структура и логика описывается в данном правиле? Структура и логика документа, а не самой таблицы стилей.
> смысл и значение которого не очевидны
Если вы пишете хак, значит для вас его значение очевидно. Вот и смысл, вот и связи.
уважаемый, обратите внимание на тему. CSS одинаков и для html и для xhtml а речь здесь лишь об этих двоих. Семантика и валидность одинаково возможны и для Х и без него, а вот парсинг по строгим правилам только для Х. Вся полемика вокруг того нужна ли такая особенность или нет. На мой взгляд нужна, поскольку сильно облегчит распространение и упорядочивание информации в сети, а автор поста считает, что вэб это лишь то, что видно через браузер.
изготовители готов, кроме Microsoft
Microsoft просто лень сесть и написать движок с нуля. Другого объяснения я не вижу просто. За 5 лет, которые прошли между выходом IE6 и IE7. Можно было сделать конфетку.
я думаю, дело не в лени, а в монополистских замашках мелкомягких.
пока у нас 80 процентов рынка, мы можем устанавливать свои правила игры. верстальщики буду писать код в основном для ie, а на поддержку остальных браузеров придется смотреть сквозь пальцы (даже такой монстр, как google, со своим gmail изначально имел всякие проблемы с оперой). следовательно пользователям невыгодно будет переходить на альтернативные браузеры, если на них многие сайты отображается по кривому.
пока у нас 80 процентов рынка, мы можем устанавливать свои правила игры. верстальщики буду писать код в основном для ie, а на поддержку остальных браузеров придется смотреть сквозь пальцы (даже такой монстр, как google, со своим gmail изначально имел всякие проблемы с оперой). следовательно пользователям невыгодно будет переходить на альтернативные браузеры, если на них многие сайты отображается по кривому.
По поводу пункта 8:
Как человек, который последние пару лет 90% времени занимается accessibility крупных сайтов, могу сказать что этот пункт абсолютно бессмысленнен — формат разметки и доступность сайта связаны между собой не больше чем цвет двери и удобство открывать ее. Если кто-то полагает, что скринридеры обязательно повалятся с криками, увидев в теле документа таблицу, используемую как "каркас" при верстке — этот человек просто слабо представляет себе, как рендерится страница и в каком порядке выдается информация.
"XHTML повышает доступность сайта для большего круга читателей, таких как люди с дефектами зрения или координации. Это означает, что на практике устройства чтения с экрана не будут сбиты с толку, увидев в теле документа тэг <table> и попытавшись выдать его содержимое, как какую-то табличную информацию. Также будет возможность полноценно и главное комфортно пользоваться сайтом даже при отсутствии мышки."
Как человек, который последние пару лет 90% времени занимается accessibility крупных сайтов, могу сказать что этот пункт абсолютно бессмысленнен — формат разметки и доступность сайта связаны между собой не больше чем цвет двери и удобство открывать ее. Если кто-то полагает, что скринридеры обязательно повалятся с криками, увидев в теле документа таблицу, используемую как "каркас" при верстке — этот человек просто слабо представляет себе, как рендерится страница и в каком порядке выдается информация.
Приветствую всех. Обсуждаемую статью написал я полгода назад, будучи еще не удрученным большим опытом вебкодером, но при этом ду кончиков пальцев проникшийся стандартами. =) Писалась она на основе моего поста в дискуссионный лист Татьяны Вукс, посвященный вебдизайну, как ответ одному из новичков на то, почему стоит применять вебстандарты на практике.
Более того, ссылку на статью я дал вот здесь http://likegroof.habrahabr.ru/blog/5387.… с пометкой:"вот я статейку писал как-то, правда пора ее более толково переписать, но руки не доходят http://www.i2r.ru/static/476/out_23437.s…"
Эх. Понеслась...
Да, согласен с тем, что правильнее было бы назвать статью "Вебстандарты. Преимущества очевидны", что собственно в следующей статье на эту тему и сделаю. С момента написания статьи, я не перестал собирать преимущества поддержки стандартов при разработке вебсайтов, как только разберусь сейчас со своим дипломом, обязательно напишу более развернутую и более продуманную статью о преимуществах стандартов. Пока же дам ответ, автору заметки.
1. XHTML является текущим опубликованным стандартом разметки гипертекста, заменившим HTML.
И что? Это преимущество? Это просто факт. В чем преимущество для компании-владельца сайта, скажем, в ближайший год после запуска?
Преимущество состоит в том, что разработка и развитие HTML фактически прекратилось, даже несмотря на то, что в недрах w3c не дремлет Тим Бернерс Ли с идеей HTML5. На ваш взгляд, что все таки сейчас выглядит более законченным и будет принято раньше XHTML2 или HTML5. На мой взгляд, XHTML2.
2. XHTML является более последовательным, чем HTML, что снижает вероятность возникновения ошибок.
Что значит «более последовательным»? Вероятность возникновения ошибок зависит не от языка, а от человека.
XHTML приучает к порядку в коде, посмотрите, как зачастую новички пишут HTML-разметку: атрибуты то берут, то не буркт в кавычки, то в верхнем регистре пишут тэги, то в нижнем, кроме того, валидатор явно укажет новичку на то, что вот сие есть архаизм и это правильно задавать через CSS (я имею в виду устаревшие стилистические тэги и атрибуты HTML, которые просто убраны из XHTML), новичок запомнит раз и навсегда про вложенность тэгов и т.д. и т.п.
3. Новые браузеры "любят" XHTML (в частности XHTML 1.0). Т.к. он предоставляет дополнительные функции, недоступные в HTML и имеет четкий синтаксис.
Это преимущество? Что значит «любят»? В какой форме это выражается? Какие преимущества и каким образом дает эта «любовь»? В чем именно HTML имеет «нечеткий» синтаксис?
Вы представляете каким образом происходит разбор HTML-кода, когда браузеру приходится пыхтеть проверяя различные ошибки разработчика, как незакрытые тэги, разного рода ошибки когда. Сейчас они просто по старинке закрывают глаза на все эти вещи. ЙКроме того, разработчикам браузеров приходится все это реализовывать в программном коде браузера, что повышает вероятность ошибок и уязвимостей уже в самом браузере. Про нечеткость таже беда, то разность регистра написания, то взятие, то невзятие в кавычки атрибутов и т.д.
4. XHTML является подмножеством языка XML, который позволяет уже сейчас значительно расширить возможности форматирования документов, а в будущем позволит полноценно использовать все новые, возможно, пока еще неизобретенные или неутвержденные технологии.
Окей, он является подмножеством. Наверное, это круто. В чем конкретно преимущество?
Я имел в виду такие вещи, как MathML, SVG, экспорт в RSS (HTML, к слову имеет такую возможность, но все это усложняется в случае нарушения стандарта XHTML) и т.п. И если вы следите за технологиями, то нетрудно заметить, что XML уже повсюду. Он вышел далеко за рамки веб, став межплатформенной средой что ли и применение ему продолжает находится непрерывно. Т.о. мы в каком-то смысле подходим к унификации обмена и хранению данных.
5. XHTML является частью семейства Web-стандартов (также включающего в себя CSS и W3C DOM), что позволяет контролировать внешний вид и поведение страницы на разных платформах, браузерах и устройствах.
Классно, что он является частью семейства. Про стандарты было в пункте 1, так что это уже ради красивой цифры притянуто. Интересно, до XHTML не могли контролировать? Как же тогда сайты делали? Или сейчас могут? Тогда почему столько мучений, чтобы оно выглядело одинаково в разных браузерах при более-менее сложном дизайне?
Про XSLT слыхали? Так вот эта вещь недоступна для HTML. Мучения в данный момент в 99% случаев только с IE. Все остальные браузеры достаточно полно и адекватно поддерживают CSS 2 и XHTML 1-1.1. Верстая, сейчас правильно, вы обеспечиваете долгую жизнь своему документу.
6. XHTML открывают путь в мир метаданных, что, можно утверждать с большой долей вероятности, позволит в будущем поисковым машинам более корректно и точно обрабатывать данные в XHTML документах (читай страницах сайта).
Как поэтично! Путь они открывают. А что это дает владельцам сайтов здесь и сейчас? А в HTML я метатеги не мог использовать? Мог. На них поисковики дружно забили.
Возможно, я сделаю для вас открытие, но META-тэгами не ограничивается понятие метаданных. Есть такая штука, как микроформаты еще, об этом вам лучше и популярнее сможет поведать Макс Россомахин. А в будущем именно через XML мы сможем описывать контент.
7. XHTML позволяет изменять порядок контента в документе, что также дает свои преимущества при поисковой оптимизации сайта.
Ну еще куда ни шло.
А вот здесь вы сами себе противоречите! %) HTML при блочной верстке тоже самое позволяет, но, как я указал в начале статьи, стоило статью несколько иначе позиционировать (этот пункт является больше преимуществом CSS и блочной верстки).
8. XHTML повышает доступность сайта для большего круга читателей, таких как люди с дефектами зрения или координации. Это означает, что на практике устройства чтения с экрана не будут сбиты с толку, увидев в теле документа тэг и попытавшись выдать его содержимое, как какую-то табличную информацию. Также будет возможность полноценно и главное комфортно пользоваться сайтом даже при отсутствии мышки.
Приму только из гуманистических соображений. В России, здесь и сейчас для большинства сайтов это значения не имеет. Аудитория не та. Тем, кто продает машины или компьютерные игры нет разницы, прочитает ли вдобавок к 500000 посетителей еще пара с брайлевского терминала.
А кто говорит, что разработчик должен ограничиваться только постсовковой клиентурой? Вы в курсе того, что в США, например, существует такой нормативный акт, как Section508, согласно которому авторы вебсайтов несут юридическую ответственность за недоступность контента сайта для людей с ограниченными физическими возможностями? И хотя эта статья применяется пока в большинстве случаев только к государственным сайтам, но она есть и дабы избежать возможного судебного разбирательства, лучше сразу его избежать на стадии разработки.
9. XHTML повышает доступность сайта также для большего круга user-agent'ов: КПК, мобильные телефоны, цифровые проекторы, и прочие устройства с выходом в веб. Это означает, что больше нет необходимости в создании нескольких версий сайта, т.к. берется один XHTML-шаблон, к которому по запросу применяются различные таблицы стилей.
Я не считаю это правильным. Если я выхожу с КПК через GPRS, я не хочу грузить всю страницу, чтобы потом посредством CSS было убрано лишнее из уже загруженного. Я хочу чтобы мне лишнее не грузилось и считаю правильным делать для КПК и мобильных отдельные версии с адаптированным контентом и навигацией, оптимизированные по трафику.
Во-первых речь идет о том, что многие новые мобильные юзерагенты просто не разбирают html-код, а только xhtml. Поговорим о целесообразности создания отдельных версий сайта. Затраты на разработку возрастаю в несколько раз, кроме того это просто плохой тон, определение агента посетителя. Применение вебстандартов во всех смыслах уменьшает объем передаваемого кода, так что несколько лишних килобайт кода, который потом будет скрыт, вам не сделают погоды, уж поверьте. А CSS-верстка позволит вам сделать полностью адаптированную версию для конкретного типа агента посетителя.
10. XHTML отменяет необходимость создания отдельной версии страницы для печати, т.к. при выводе документа в печать также есть возможность задать отдельный стиль. Этот преимущество, как и преимущество в пункте 6 недоступной табличной разметке, т.к. предварительное форматирование создано уже в самом теле документа.
Пардон муа, это как вы разметку сделаете.
Опять же делаю поправку на название статьи, это преимущество правильной верстки и применения стандартов. Здесь соглашусь частично с вами.
11. XHTML+CSS позволяет существенно снизить вес документа. Таким образом, вы существенно снижаете нагрузку на сервера, каналы связи и ускоряете выдачу готового документа пользователю. Это достигается за счет того, что XHTML-шаблон не содержит элементов разметки, т.к. они выносятся CSS-файл. Для более наглядного подтверждения этого довода обратимся к примеру. Обычно разница между XHTML+CSS и HTML+CSS (табличным) шаблонами составляет от 300 до 500 процентов в пользу XHTML+CSS, в некоторых случаях она может быть и больше. Представим воображаемый сайт с суммарной посещаемостью в сутки 10000 уникальных посетителей. Сверстаем его сначала классическим табличным способом. Получим - размер HTML-шаблона 20 Кб с файлом стилей размером 5 Кб. Итак, впервые выданный в браузер пользователя сайт закэширует все изображения, скрипты вынесенные во внешние файлы и файлы стилей, т.е. CSS-файлы. Также в расчетах примем за истину то, что дизайн сайта (CSS-файл) не будет подвергаться изменению в течение года и не потребует повторной загрузки. Скрипты и изображения можно не принимать в расчет, т.к. на конечный результат они не повлияют. (20 Кб * 10000 * 365 + 5*10000) /1024= 71337 Мб или 71,3 Гб трафика в течение календарного года. Сверстаем этот же сайт на XHTML+CSS методом CSS-верстки. На выходе XHTML, равный 5 Кб и CSS - 10 Кб (здесь необходимо отметить, что размер CSS файла обычно возрастает в связи с тем, что все данные о форматировании и визуальном представлении документа выносятся в CSS-файл). Проведем расчет. (5 Кб * 10000 * 365 + 10*10000) /1024= 17919,9 Мб или 18 Гб трафика. В данном примере экономия составляет 71,3 Гб - 18 Гб = 53,3 Гб! Комментарии излишни.
Хо-хо! Видел множество примеров, когда верстка на слоях без таблиц занимала больше места. Хотите примеров? Спросите у Яндекса.
Йо-хо-хо! А вот это уже из области неправильного применения стандартов, уж поверьте на слово, коллеги стандартисты безусловно поддержат.
12. XHTML, за счет выноса элементов и инструкций оформления документа во внешний файл, позволяет загрузить в браузер пользователя контент максимально быстро, а по мере того, как он приступит к его прочтению, продолжит загружаться оформление сайта. Это позволяет, не дожидаясь полной загрузки страницы, решить, существенна ли представленная информация, или стоит покинуть страницу и продолжить поиск информации на других сайтах.
Я и в HTML мог CSS применять. И с таблицами даже. Не засчитан пункт.
Согласен, опять же ссылаюсь на неграмотность названия статьи. С таблицами, без особого трюка отображение табличной разметки не начнется, пока браузер не увидит . Однако это не относится к Gecko-браузерам.
13. XHTML код более логичен и прост, поэтому в нем гораздо легче разобраться HTML-кодеру не писавшему код страницы.
Зависит от того, кто пишет код.
Согласен, но цель статьи, приучить людей к порядку, который без кнута в виде валидатора невозможен, а валидация HTML неактуальна в контексте разделения контента и оформления.
14. XHTML позволяет, имея один шаблон, подключать к нему бесконечное множество стилей, кардинально меняющих его оформление без единой правки самого шаблона. Это достигается за счет манипулирования свободной блочной разметкой содержимого в противовес жестко заданной табличной.
Есть конкретные примеры когда на реальном коммерческом сайте надо было это делать и не пришлось ни единой правки вносить именно в шаблон?
Ну вы меня просто убили... 8D О csszengarden.com хотя бы слышали?
15. XHTML корректно обрабатывается старыми браузерами, что уменьшает препятствия к его использованию. А в новых, за счет правильной поддержки CSS, можно добиться невероятных результатов.
Да? IE3 NN4? :-) Шучу. Вот насчет результатов. Бизнесу нужны не «невероятные результаты», а ощутимые финансовые. ;-)
Простите меня великодушно, но это ирония и ничего больше с вашей стороны. Поддержка браузеров ниже IE 5, NN6, Opera 8 просто неактуальна.
Собственно все. Вот практически и написал новую статью... =))
Более того, ссылку на статью я дал вот здесь http://likegroof.habrahabr.ru/blog/5387.… с пометкой:"вот я статейку писал как-то, правда пора ее более толково переписать, но руки не доходят http://www.i2r.ru/static/476/out_23437.s…"
Эх. Понеслась...
Да, согласен с тем, что правильнее было бы назвать статью "Вебстандарты. Преимущества очевидны", что собственно в следующей статье на эту тему и сделаю. С момента написания статьи, я не перестал собирать преимущества поддержки стандартов при разработке вебсайтов, как только разберусь сейчас со своим дипломом, обязательно напишу более развернутую и более продуманную статью о преимуществах стандартов. Пока же дам ответ, автору заметки.
1. XHTML является текущим опубликованным стандартом разметки гипертекста, заменившим HTML.
И что? Это преимущество? Это просто факт. В чем преимущество для компании-владельца сайта, скажем, в ближайший год после запуска?
Преимущество состоит в том, что разработка и развитие HTML фактически прекратилось, даже несмотря на то, что в недрах w3c не дремлет Тим Бернерс Ли с идеей HTML5. На ваш взгляд, что все таки сейчас выглядит более законченным и будет принято раньше XHTML2 или HTML5. На мой взгляд, XHTML2.
2. XHTML является более последовательным, чем HTML, что снижает вероятность возникновения ошибок.
Что значит «более последовательным»? Вероятность возникновения ошибок зависит не от языка, а от человека.
XHTML приучает к порядку в коде, посмотрите, как зачастую новички пишут HTML-разметку: атрибуты то берут, то не буркт в кавычки, то в верхнем регистре пишут тэги, то в нижнем, кроме того, валидатор явно укажет новичку на то, что вот сие есть архаизм и это правильно задавать через CSS (я имею в виду устаревшие стилистические тэги и атрибуты HTML, которые просто убраны из XHTML), новичок запомнит раз и навсегда про вложенность тэгов и т.д. и т.п.
3. Новые браузеры "любят" XHTML (в частности XHTML 1.0). Т.к. он предоставляет дополнительные функции, недоступные в HTML и имеет четкий синтаксис.
Это преимущество? Что значит «любят»? В какой форме это выражается? Какие преимущества и каким образом дает эта «любовь»? В чем именно HTML имеет «нечеткий» синтаксис?
Вы представляете каким образом происходит разбор HTML-кода, когда браузеру приходится пыхтеть проверяя различные ошибки разработчика, как незакрытые тэги, разного рода ошибки когда. Сейчас они просто по старинке закрывают глаза на все эти вещи. ЙКроме того, разработчикам браузеров приходится все это реализовывать в программном коде браузера, что повышает вероятность ошибок и уязвимостей уже в самом браузере. Про нечеткость таже беда, то разность регистра написания, то взятие, то невзятие в кавычки атрибутов и т.д.
4. XHTML является подмножеством языка XML, который позволяет уже сейчас значительно расширить возможности форматирования документов, а в будущем позволит полноценно использовать все новые, возможно, пока еще неизобретенные или неутвержденные технологии.
Окей, он является подмножеством. Наверное, это круто. В чем конкретно преимущество?
Я имел в виду такие вещи, как MathML, SVG, экспорт в RSS (HTML, к слову имеет такую возможность, но все это усложняется в случае нарушения стандарта XHTML) и т.п. И если вы следите за технологиями, то нетрудно заметить, что XML уже повсюду. Он вышел далеко за рамки веб, став межплатформенной средой что ли и применение ему продолжает находится непрерывно. Т.о. мы в каком-то смысле подходим к унификации обмена и хранению данных.
5. XHTML является частью семейства Web-стандартов (также включающего в себя CSS и W3C DOM), что позволяет контролировать внешний вид и поведение страницы на разных платформах, браузерах и устройствах.
Классно, что он является частью семейства. Про стандарты было в пункте 1, так что это уже ради красивой цифры притянуто. Интересно, до XHTML не могли контролировать? Как же тогда сайты делали? Или сейчас могут? Тогда почему столько мучений, чтобы оно выглядело одинаково в разных браузерах при более-менее сложном дизайне?
Про XSLT слыхали? Так вот эта вещь недоступна для HTML. Мучения в данный момент в 99% случаев только с IE. Все остальные браузеры достаточно полно и адекватно поддерживают CSS 2 и XHTML 1-1.1. Верстая, сейчас правильно, вы обеспечиваете долгую жизнь своему документу.
6. XHTML открывают путь в мир метаданных, что, можно утверждать с большой долей вероятности, позволит в будущем поисковым машинам более корректно и точно обрабатывать данные в XHTML документах (читай страницах сайта).
Как поэтично! Путь они открывают. А что это дает владельцам сайтов здесь и сейчас? А в HTML я метатеги не мог использовать? Мог. На них поисковики дружно забили.
Возможно, я сделаю для вас открытие, но META-тэгами не ограничивается понятие метаданных. Есть такая штука, как микроформаты еще, об этом вам лучше и популярнее сможет поведать Макс Россомахин. А в будущем именно через XML мы сможем описывать контент.
7. XHTML позволяет изменять порядок контента в документе, что также дает свои преимущества при поисковой оптимизации сайта.
Ну еще куда ни шло.
А вот здесь вы сами себе противоречите! %) HTML при блочной верстке тоже самое позволяет, но, как я указал в начале статьи, стоило статью несколько иначе позиционировать (этот пункт является больше преимуществом CSS и блочной верстки).
8. XHTML повышает доступность сайта для большего круга читателей, таких как люди с дефектами зрения или координации. Это означает, что на практике устройства чтения с экрана не будут сбиты с толку, увидев в теле документа тэг и попытавшись выдать его содержимое, как какую-то табличную информацию. Также будет возможность полноценно и главное комфортно пользоваться сайтом даже при отсутствии мышки.
Приму только из гуманистических соображений. В России, здесь и сейчас для большинства сайтов это значения не имеет. Аудитория не та. Тем, кто продает машины или компьютерные игры нет разницы, прочитает ли вдобавок к 500000 посетителей еще пара с брайлевского терминала.
А кто говорит, что разработчик должен ограничиваться только постсовковой клиентурой? Вы в курсе того, что в США, например, существует такой нормативный акт, как Section508, согласно которому авторы вебсайтов несут юридическую ответственность за недоступность контента сайта для людей с ограниченными физическими возможностями? И хотя эта статья применяется пока в большинстве случаев только к государственным сайтам, но она есть и дабы избежать возможного судебного разбирательства, лучше сразу его избежать на стадии разработки.
9. XHTML повышает доступность сайта также для большего круга user-agent'ов: КПК, мобильные телефоны, цифровые проекторы, и прочие устройства с выходом в веб. Это означает, что больше нет необходимости в создании нескольких версий сайта, т.к. берется один XHTML-шаблон, к которому по запросу применяются различные таблицы стилей.
Я не считаю это правильным. Если я выхожу с КПК через GPRS, я не хочу грузить всю страницу, чтобы потом посредством CSS было убрано лишнее из уже загруженного. Я хочу чтобы мне лишнее не грузилось и считаю правильным делать для КПК и мобильных отдельные версии с адаптированным контентом и навигацией, оптимизированные по трафику.
Во-первых речь идет о том, что многие новые мобильные юзерагенты просто не разбирают html-код, а только xhtml. Поговорим о целесообразности создания отдельных версий сайта. Затраты на разработку возрастаю в несколько раз, кроме того это просто плохой тон, определение агента посетителя. Применение вебстандартов во всех смыслах уменьшает объем передаваемого кода, так что несколько лишних килобайт кода, который потом будет скрыт, вам не сделают погоды, уж поверьте. А CSS-верстка позволит вам сделать полностью адаптированную версию для конкретного типа агента посетителя.
10. XHTML отменяет необходимость создания отдельной версии страницы для печати, т.к. при выводе документа в печать также есть возможность задать отдельный стиль. Этот преимущество, как и преимущество в пункте 6 недоступной табличной разметке, т.к. предварительное форматирование создано уже в самом теле документа.
Пардон муа, это как вы разметку сделаете.
Опять же делаю поправку на название статьи, это преимущество правильной верстки и применения стандартов. Здесь соглашусь частично с вами.
11. XHTML+CSS позволяет существенно снизить вес документа. Таким образом, вы существенно снижаете нагрузку на сервера, каналы связи и ускоряете выдачу готового документа пользователю. Это достигается за счет того, что XHTML-шаблон не содержит элементов разметки, т.к. они выносятся CSS-файл. Для более наглядного подтверждения этого довода обратимся к примеру. Обычно разница между XHTML+CSS и HTML+CSS (табличным) шаблонами составляет от 300 до 500 процентов в пользу XHTML+CSS, в некоторых случаях она может быть и больше. Представим воображаемый сайт с суммарной посещаемостью в сутки 10000 уникальных посетителей. Сверстаем его сначала классическим табличным способом. Получим - размер HTML-шаблона 20 Кб с файлом стилей размером 5 Кб. Итак, впервые выданный в браузер пользователя сайт закэширует все изображения, скрипты вынесенные во внешние файлы и файлы стилей, т.е. CSS-файлы. Также в расчетах примем за истину то, что дизайн сайта (CSS-файл) не будет подвергаться изменению в течение года и не потребует повторной загрузки. Скрипты и изображения можно не принимать в расчет, т.к. на конечный результат они не повлияют. (20 Кб * 10000 * 365 + 5*10000) /1024= 71337 Мб или 71,3 Гб трафика в течение календарного года. Сверстаем этот же сайт на XHTML+CSS методом CSS-верстки. На выходе XHTML, равный 5 Кб и CSS - 10 Кб (здесь необходимо отметить, что размер CSS файла обычно возрастает в связи с тем, что все данные о форматировании и визуальном представлении документа выносятся в CSS-файл). Проведем расчет. (5 Кб * 10000 * 365 + 10*10000) /1024= 17919,9 Мб или 18 Гб трафика. В данном примере экономия составляет 71,3 Гб - 18 Гб = 53,3 Гб! Комментарии излишни.
Хо-хо! Видел множество примеров, когда верстка на слоях без таблиц занимала больше места. Хотите примеров? Спросите у Яндекса.
Йо-хо-хо! А вот это уже из области неправильного применения стандартов, уж поверьте на слово, коллеги стандартисты безусловно поддержат.
12. XHTML, за счет выноса элементов и инструкций оформления документа во внешний файл, позволяет загрузить в браузер пользователя контент максимально быстро, а по мере того, как он приступит к его прочтению, продолжит загружаться оформление сайта. Это позволяет, не дожидаясь полной загрузки страницы, решить, существенна ли представленная информация, или стоит покинуть страницу и продолжить поиск информации на других сайтах.
Я и в HTML мог CSS применять. И с таблицами даже. Не засчитан пункт.
Согласен, опять же ссылаюсь на неграмотность названия статьи. С таблицами, без особого трюка отображение табличной разметки не начнется, пока браузер не увидит . Однако это не относится к Gecko-браузерам.
13. XHTML код более логичен и прост, поэтому в нем гораздо легче разобраться HTML-кодеру не писавшему код страницы.
Зависит от того, кто пишет код.
Согласен, но цель статьи, приучить людей к порядку, который без кнута в виде валидатора невозможен, а валидация HTML неактуальна в контексте разделения контента и оформления.
14. XHTML позволяет, имея один шаблон, подключать к нему бесконечное множество стилей, кардинально меняющих его оформление без единой правки самого шаблона. Это достигается за счет манипулирования свободной блочной разметкой содержимого в противовес жестко заданной табличной.
Есть конкретные примеры когда на реальном коммерческом сайте надо было это делать и не пришлось ни единой правки вносить именно в шаблон?
Ну вы меня просто убили... 8D О csszengarden.com хотя бы слышали?
15. XHTML корректно обрабатывается старыми браузерами, что уменьшает препятствия к его использованию. А в новых, за счет правильной поддержки CSS, можно добиться невероятных результатов.
Да? IE3 NN4? :-) Шучу. Вот насчет результатов. Бизнесу нужны не «невероятные результаты», а ощутимые финансовые. ;-)
Простите меня великодушно, но это ирония и ничего больше с вашей стороны. Поддержка браузеров ниже IE 5, NN6, Opera 8 просто неактуальна.
Собственно все. Вот практически и написал новую статью... =))
блин, не закрыл тэг =))))
И всё же налицо подмена понятий:
1. HTML не развивается
То, что появляются новые версии XHTML ничуть не говорит в пользу страрых его версий. Эта преемственность на практике ничего не означает - никто не будет лопатить код, чтобы исправить XHTML1 в XHTML2.
2. XHTML является более последовательным, чем HTML
Вот этот аргумент меня всегда удивлял. Возьмём типичный нумерованный список: в html элементы списка отделены друг от друга тэгом <li> - всё, последовательней некуда! В XHTML это выглядит набором блоков, между которыми вполне логично навтыкать других блоков, например, подзаголовков... но нельзя. Так что о последовательности XHTML говорить не надо.
3. Разбор XHTML для броузера проще
На самом деле броузер начинает выводить документ ещё не получив его полностью. Т.е. алгоритм парсинга практически идентичен - броузер сам "закрывает тэги".
4. XHTML является подмножеством языка XML
Когда всякие вкусности XML станут доступны броузерам, сайт, скорее всего переделают полностью, учитывая новые возможности.
5. XHTML является частью семейства Web-стандартов
Про HTML можно сказать то же самое. Упоминание XSLT совершенно не в кассу. XSLT позволяет действительно логическую разметку текста в XML преобразовывать в другой XML, XHTML, HTML, обычный текст и т.п., преобразовывать XHTML им, конечно можно, но простите, практически не во что.
6. XHTML открывают путь в мир метаданных
Опять упёрлись в радужные перспективы XML
7. тут не интересно
8. XHTML повышает доступность сайта
Как и в предыдущем пункте перепутаны XHTML и блочная вёрстка
9. XHTML повышает доступность сайта также для большего круга user-agent'ов: КПК, мобильные телефоны, цифровые проекторы, и прочие устройства с выходом в веб.
Для мобильных устройств, действительно нужно создавать специальные версии сайтов. Т.к. гипотетическая доступность для юзер-агента вовсе не гарантирует автоматическую доступность для человека. IMHO всё же дял мобильников существует wap. А на КПК и HTML отображается корректно.
10. XHTML отменяет необходимость создания отдельной версии страницы для печати
Это возможности CSS, а не XHTML
11. XHTML+CSS позволяет существенно снизить вес документа.
Опять путаем технологии
12. XHTML, за счет выноса элементов и инструкций оформления документа во внешний файл, позволяет загрузить в браузер пользователя контент максимально быстро, а по мере того, как он приступит к его прочтению, продолжит загружаться оформление сайта.
И снова мы про CSS
Кстати, предпосылка вообще неверна - файл со стилем обычно заметно легче содержательной части т.е. загрузится раньше, чем мы вникнем в суть содержимого.
13. XHTML код более логичен и прост, поэтому в нем гораздо легче разобраться HTML-кодеру не писавшему код страницы.
Это про блочную вёрстку
14. XHTML позволяет, имея один шаблон, подключать к нему бесконечное множество стилей
Опять про CSS
15. и снова CSS
Ужас!
Проблема тут не только в ложном названии, а в том что под словом XHTML подразумевают множество технологий прекрасно работающих и без этого самого XHTML
Что бы мы не говорили, но XHTML - язык визуальной разметки, т.к. для логической он слишком беден. В нём приходится множество разных смысловых сущностей оторажать идентичными элементами, либо строить громозкие поясняющие конструкции из атрибутов.
Очень часто его пропагандируют, как промежуточных шаг между HTML и XML - этакое "ни рыба, ни мясо". Полагаю, что у нет будущего - т.к. это искусственная ступенька, через которую многие могут и готовы просто перешагнуть.
1. HTML не развивается
То, что появляются новые версии XHTML ничуть не говорит в пользу страрых его версий. Эта преемственность на практике ничего не означает - никто не будет лопатить код, чтобы исправить XHTML1 в XHTML2.
2. XHTML является более последовательным, чем HTML
Вот этот аргумент меня всегда удивлял. Возьмём типичный нумерованный список: в html элементы списка отделены друг от друга тэгом <li> - всё, последовательней некуда! В XHTML это выглядит набором блоков, между которыми вполне логично навтыкать других блоков, например, подзаголовков... но нельзя. Так что о последовательности XHTML говорить не надо.
3. Разбор XHTML для броузера проще
На самом деле броузер начинает выводить документ ещё не получив его полностью. Т.е. алгоритм парсинга практически идентичен - броузер сам "закрывает тэги".
4. XHTML является подмножеством языка XML
Когда всякие вкусности XML станут доступны броузерам, сайт, скорее всего переделают полностью, учитывая новые возможности.
5. XHTML является частью семейства Web-стандартов
Про HTML можно сказать то же самое. Упоминание XSLT совершенно не в кассу. XSLT позволяет действительно логическую разметку текста в XML преобразовывать в другой XML, XHTML, HTML, обычный текст и т.п., преобразовывать XHTML им, конечно можно, но простите, практически не во что.
6. XHTML открывают путь в мир метаданных
Опять упёрлись в радужные перспективы XML
7. тут не интересно
8. XHTML повышает доступность сайта
Как и в предыдущем пункте перепутаны XHTML и блочная вёрстка
9. XHTML повышает доступность сайта также для большего круга user-agent'ов: КПК, мобильные телефоны, цифровые проекторы, и прочие устройства с выходом в веб.
Для мобильных устройств, действительно нужно создавать специальные версии сайтов. Т.к. гипотетическая доступность для юзер-агента вовсе не гарантирует автоматическую доступность для человека. IMHO всё же дял мобильников существует wap. А на КПК и HTML отображается корректно.
10. XHTML отменяет необходимость создания отдельной версии страницы для печати
Это возможности CSS, а не XHTML
11. XHTML+CSS позволяет существенно снизить вес документа.
Опять путаем технологии
12. XHTML, за счет выноса элементов и инструкций оформления документа во внешний файл, позволяет загрузить в браузер пользователя контент максимально быстро, а по мере того, как он приступит к его прочтению, продолжит загружаться оформление сайта.
И снова мы про CSS
Кстати, предпосылка вообще неверна - файл со стилем обычно заметно легче содержательной части т.е. загрузится раньше, чем мы вникнем в суть содержимого.
13. XHTML код более логичен и прост, поэтому в нем гораздо легче разобраться HTML-кодеру не писавшему код страницы.
Это про блочную вёрстку
14. XHTML позволяет, имея один шаблон, подключать к нему бесконечное множество стилей
Опять про CSS
15. и снова CSS
Ужас!
Проблема тут не только в ложном названии, а в том что под словом XHTML подразумевают множество технологий прекрасно работающих и без этого самого XHTML
Что бы мы не говорили, но XHTML - язык визуальной разметки, т.к. для логической он слишком беден. В нём приходится множество разных смысловых сущностей оторажать идентичными элементами, либо строить громозкие поясняющие конструкции из атрибутов.
Очень часто его пропагандируют, как промежуточных шаг между HTML и XML - этакое "ни рыба, ни мясо". Полагаю, что у нет будущего - т.к. это искусственная ступенька, через которую многие могут и готовы просто перешагнуть.
То, что появляются новые версии XHTML ничуть не говорит в пользу страрых его версий. Эта преемственность на практике ничего не означает - никто не будет лопатить код, чтобы исправить XHTML1 в XHTML2.
Что-то совсем непонятно, о чем вы говорите? Что вы хотели сказать первым предложением? А вот по поводу обратной совместимости XHTML2 сейчас и стоит серьезная проблема. Ее решают.
Вот этот аргумент меня всегда удивлял. Возьмём типичный нумерованный список: в html элементы списка отделены друг от друга тэгом - всё, последовательней некуда! В XHTML это выглядит набором блоков, между которыми вполне логично навтыкать других блоков, например, подзаголовков... но нельзя. Так что о последовательности XHTML говорить не надо.
Речь идет о дереве элементов: о вложенности, об обязательном закрытии, у атрибутов обязательно должно быть значение...
В XHTML это выглядит набором блоков, между которыми вполне логично навтыкать других блоков, например, подзаголовков... но нельзя.
Не вижу логики...
На самом деле броузер начинает выводить документ ещё не получив его полностью. Т.е. алгоритм парсинга практически идентичен - броузер сам "закрывает тэги".
Парсить - да, но не выводить. Выводить в процессе парсинга HTML под Win может только любой Gecko-браузер, также FF3.0 aplha 3 уже выводит во время парсинга и XHTML (XML). В том и дело, что браузеру приходится вот такие вещи вытворять и неправильно вложеные элементы разбирать и т.п., что существенно усложняет парсинг. А парсинг XHTML проще и быстрее, чем HTML. Поскольку синтаксис XML строже, чем SGML и обработка XHTML возможна даже на мобильных телефонах с малыми ресурсами.
Когда всякие вкусности XML станут доступны броузерам, сайт, скорее всего переделают полностью, учитывая новые возможности.
А зачем, если XHTML это уже XML, все остальное будет встраиваться, как XML-модули!
Про HTML можно сказать то же самое. Упоминание XSLT совершенно не в кассу. XSLT позволяет действительно логическую разметку текста в XML преобразовывать в другой XML, XHTML, HTML, обычный текст и т.п., преобразовывать XHTML им, конечно можно, но простите, практически не во что.
XSLT говорите? А вызнаете, как его можно во благо использовать? Позволю себе процитировать слова одного участника все того же дискуссионного листа Татьяны Вукс:
> К сожалению, по данному вопросу не могу ничего
>> конкретного сказать - мы давно ушли от редактирования контента как
>> редактирования HTML-кода.
Z> А вот здесь подробнее можно про редактирование контента?
Контент как текст с абзацами представляет собой блочную модель -
линейный набор блоков. Рассматривая каждый блок как отдельный объект,
можно прилинковать к нему изображения, тэги (в понятии семантики),
прочие поля вроде "комментариев на полях" и т.д. Далее, оперируя
такими блоками, можно легко строить контент хоть в HTML, хоть в XHTML,
хоть в RSS, хоть в версии для печати, хоть с картинками, хоть без них,
хоть кратким текстом, хоть полным, хоть полным с комментариями, хоть
облаком...
Опять упёрлись в радужные перспективы XML
А почему, собственно, нет??
Как и в предыдущем пункте перепутаны XHTML и блочная вёрстка
Читаем, что я писал, сам про свою статью.
Для мобильных устройств, действительно нужно создавать специальные версии сайтов. Т.к. гипотетическая доступность для юзер-агента вовсе не гарантирует автоматическую доступность для человека. IMHO всё же дял мобильников существует wap. А на КПК и HTML отображается корректно.
Ну тут только имхо, мое говорит о том, что только CSS-верстка позволит в 90% случаев обойтись без отдельной версии сайта.
Это возможности CSS, а не XHTML
Все та же бадяга... не читаем комменты автора.
Опять путаем технологии
И снова...
Кстати, предпосылка вообще неверна - файл со стилем обычно заметно легче содержательной части т.е. загрузится раньше, чем мы вникнем в суть содержимого.
Речь идет о пустом документе. Чистый структурированный документ без контента. Но и при это CSS файл может быть
Опять про CSS
эх...
и снова CSS
и снова вам лень читать комментарий автора
Ужас!
Проблема тут не только в ложном названии, а в том что под словом XHTML подразумевают множество технологий прекрасно работающих и без этого самого XHTML
Хотя и намешано много в статье. Но речь идет об XHTML+CSS!
Что бы мы не говорили, но XHTML - язык визуальной разметки, т.к. для логической он слишком беден. В нём приходится множество разных смысловых сущностей оторажать идентичными элементами, либо строить громозкие поясняющие конструкции из атрибутов.
все. я под столом. лучше бы вы этого не писали!
Очень часто его пропагандируют, как промежуточных шаг между HTML и XML - этакое "ни рыба, ни мясо". Полагаю, что у нет будущего - т.к. это искусственная ступенька, через которую многие могут и готовы просто перешагнуть.
Без промежуточного шага не будет шага следующего. Что будет, если сейчас сразу ввести XHTML2, например, в том виде, в котором он сейчас есть? А ничего. мы просто не сможем применить его на практике.
Что-то совсем непонятно, о чем вы говорите? Что вы хотели сказать первым предложением? А вот по поводу обратной совместимости XHTML2 сейчас и стоит серьезная проблема. Ее решают.
Вот этот аргумент меня всегда удивлял. Возьмём типичный нумерованный список: в html элементы списка отделены друг от друга тэгом
Речь идет о дереве элементов: о вложенности, об обязательном закрытии, у атрибутов обязательно должно быть значение...
В XHTML это выглядит набором блоков, между которыми вполне логично навтыкать других блоков, например, подзаголовков... но нельзя.
Не вижу логики...
На самом деле броузер начинает выводить документ ещё не получив его полностью. Т.е. алгоритм парсинга практически идентичен - броузер сам "закрывает тэги".
Парсить - да, но не выводить. Выводить в процессе парсинга HTML под Win может только любой Gecko-браузер, также FF3.0 aplha 3 уже выводит во время парсинга и XHTML (XML). В том и дело, что браузеру приходится вот такие вещи вытворять и неправильно вложеные элементы разбирать и т.п., что существенно усложняет парсинг. А парсинг XHTML проще и быстрее, чем HTML. Поскольку синтаксис XML строже, чем SGML и обработка XHTML возможна даже на мобильных телефонах с малыми ресурсами.
Когда всякие вкусности XML станут доступны броузерам, сайт, скорее всего переделают полностью, учитывая новые возможности.
А зачем, если XHTML это уже XML, все остальное будет встраиваться, как XML-модули!
Про HTML можно сказать то же самое. Упоминание XSLT совершенно не в кассу. XSLT позволяет действительно логическую разметку текста в XML преобразовывать в другой XML, XHTML, HTML, обычный текст и т.п., преобразовывать XHTML им, конечно можно, но простите, практически не во что.
XSLT говорите? А вызнаете, как его можно во благо использовать? Позволю себе процитировать слова одного участника все того же дискуссионного листа Татьяны Вукс:
> К сожалению, по данному вопросу не могу ничего
>> конкретного сказать - мы давно ушли от редактирования контента как
>> редактирования HTML-кода.
Z> А вот здесь подробнее можно про редактирование контента?
Контент как текст с абзацами представляет собой блочную модель -
линейный набор блоков. Рассматривая каждый блок как отдельный объект,
можно прилинковать к нему изображения, тэги (в понятии семантики),
прочие поля вроде "комментариев на полях" и т.д. Далее, оперируя
такими блоками, можно легко строить контент хоть в HTML, хоть в XHTML,
хоть в RSS, хоть в версии для печати, хоть с картинками, хоть без них,
хоть кратким текстом, хоть полным, хоть полным с комментариями, хоть
облаком...
Опять упёрлись в радужные перспективы XML
А почему, собственно, нет??
Как и в предыдущем пункте перепутаны XHTML и блочная вёрстка
Читаем, что я писал, сам про свою статью.
Для мобильных устройств, действительно нужно создавать специальные версии сайтов. Т.к. гипотетическая доступность для юзер-агента вовсе не гарантирует автоматическую доступность для человека. IMHO всё же дял мобильников существует wap. А на КПК и HTML отображается корректно.
Ну тут только имхо, мое говорит о том, что только CSS-верстка позволит в 90% случаев обойтись без отдельной версии сайта.
Это возможности CSS, а не XHTML
Все та же бадяга... не читаем комменты автора.
Опять путаем технологии
И снова...
Кстати, предпосылка вообще неверна - файл со стилем обычно заметно легче содержательной части т.е. загрузится раньше, чем мы вникнем в суть содержимого.
Речь идет о пустом документе. Чистый структурированный документ без контента. Но и при это CSS файл может быть
Опять про CSS
эх...
и снова CSS
и снова вам лень читать комментарий автора
Ужас!
Проблема тут не только в ложном названии, а в том что под словом XHTML подразумевают множество технологий прекрасно работающих и без этого самого XHTML
Хотя и намешано много в статье. Но речь идет об XHTML+CSS!
Что бы мы не говорили, но XHTML - язык визуальной разметки, т.к. для логической он слишком беден. В нём приходится множество разных смысловых сущностей оторажать идентичными элементами, либо строить громозкие поясняющие конструкции из атрибутов.
все. я под столом. лучше бы вы этого не писали!
Очень часто его пропагандируют, как промежуточных шаг между HTML и XML - этакое "ни рыба, ни мясо". Полагаю, что у нет будущего - т.к. это искусственная ступенька, через которую многие могут и готовы просто перешагнуть.
Без промежуточного шага не будет шага следующего. Что будет, если сейчас сразу ввести XHTML2, например, в том виде, в котором он сейчас есть? А ничего. мы просто не сможем применить его на практике.
Что вы писали про свою статью я вижу.
Ратуя за стандарты вы противопоставляете XHTML+CSS возможностям и практике использования древнего HTML 3.1
Подобные трюкачества говорят о вас не лучшим образом.
Если вы не поняли, о чём говорит Татьяна Вукс в приведённой вами же цитате, я поясню:
Материалы сайта хранятся на сервере в XML со всей мыслимой логической разметкой. Пользователю же они отдаются в HTML, XHTML, RSS и т.п. посредством XSLT-преобразования на сервере.
Ратуя за стандарты вы противопоставляете XHTML+CSS возможностям и практике использования древнего HTML 3.1
Подобные трюкачества говорят о вас не лучшим образом.
Если вы не поняли, о чём говорит Татьяна Вукс в приведённой вами же цитате, я поясню:
Материалы сайта хранятся на сервере в XML со всей мыслимой логической разметкой. Пользователю же они отдаются в HTML, XHTML, RSS и т.п. посредством XSLT-преобразования на сервере.
вы не правы. любой валидный xhtml превосходно отобразится в браузере с HTML 3.1. именно такая обратная совместимость и отличает xhtml от xml
Второй раз вы не правы когда утверждаете, что XSL-преобразования - прерогатива сервера. В том и дело, что строгий синтаксис XML/XSL давно позволил встроить возможность выполнять XSL-преобразователи в браузеры без особого утягощения (это умеет даже IE).
Второй раз вы не правы когда утверждаете, что XSL-преобразования - прерогатива сервера. В том и дело, что строгий синтаксис XML/XSL давно позволил встроить возможность выполнять XSL-преобразователи в браузеры без особого утягощения (это умеет даже IE).
Что значит "не прав"?!
1. Я вообще ничего не говорил про (обратную) совместимость.
2. Я не утверждал этого, я пояснил практику использования XSLT во вполне конкретном случае.
Если же говорить о XSLT в броузере, то не "даже IE", а "только IE", причём весьма ограниченно.
P.S. Вот теперь можете считать, что я это говорил :-P
1. Я вообще ничего не говорил про (обратную) совместимость.
2. Я не утверждал этого, я пояснил практику использования XSLT во вполне конкретном случае.
Если же говорить о XSLT в броузере, то не "даже IE", а "только IE", причём весьма ограниченно.
P.S. Вот теперь можете считать, что я это говорил :-P
"XHTML повышает доступность сайта для большего круга читателей, таких как люди с дефектами зрения или координации." - вы обоснуйте сие утверждение, все-таки.
по заметке:
пункт 4:
Хотелось бы пояснить: приемущество действительно есть. Xhtml cтраничку проще генерировать: сейчас существует куча фреймворков для любого языка для обработки xml (я могу назвать много слов с буквой х, типа xsl, xslt, xpath, xsl fo, но просто поверьте как девелоперу, действительно легче генерить xml, чем html). А если проще генерировать, значит легче разрабатывать/поддерживать - следовательно дешевле/быстрее в производстве. Приемущество?
по теме:
Опять же отвечу как девелопер, т.е. сфокусирую внимание на технических аспектах. Всегда приятно работать, когда ты не изобретаешь велосипед по сотому разу, а грамотно используешь всю мощь доступных тебе инструментов. Это и удобнее, и быстрее, и понятнее для остальных членов команды. В общем ты делаешь Right Thing. В случае веб-программирования такой Правильной Вещью является xhtml. Чем он лучше? Отличий не особо много и они не особо существенны. В основном они сводятся к более строгому синтаксису и изменению кодировки на utf8. Более строгий синтаксис - это хорошо, потому что
Кодировка utf8 в общем-то тоже рулит, и если когда-нибудь во всем мире будет использоваться одна и таже кодировка, то это будет одна из версий utf.
ps
а вообще, спасибо за заметку
+1 к карме
пункт 4:
4. XHTML является подмножеством языка XML, который позволяет уже сейчас значительно расширить возможности форматирования документов, а в будущем позволит полноценно использовать все новые, возможно, пока еще неизобретенные или неутвержденные технологии.
Окей, он является подмножеством. Наверное, это круто. В чем конкретно преимущество?
Хотелось бы пояснить: приемущество действительно есть. Xhtml cтраничку проще генерировать: сейчас существует куча фреймворков для любого языка для обработки xml (я могу назвать много слов с буквой х, типа xsl, xslt, xpath, xsl fo, но просто поверьте как девелоперу, действительно легче генерить xml, чем html). А если проще генерировать, значит легче разрабатывать/поддерживать - следовательно дешевле/быстрее в производстве. Приемущество?
по теме:
Опять же отвечу как девелопер, т.е. сфокусирую внимание на технических аспектах. Всегда приятно работать, когда ты не изобретаешь велосипед по сотому разу, а грамотно используешь всю мощь доступных тебе инструментов. Это и удобнее, и быстрее, и понятнее для остальных членов команды. В общем ты делаешь Right Thing. В случае веб-программирования такой Правильной Вещью является xhtml. Чем он лучше? Отличий не особо много и они не особо существенны. В основном они сводятся к более строгому синтаксису и изменению кодировки на utf8. Более строгий синтаксис - это хорошо, потому что
- его нетрудно придерживаться
- код более "читаем"
- надеюсь, о преимуществе придерживание определенного кодестайлa не надо рассказывать?
- тенденция такова, что браузеры
наконец-тоначинают отображаться все ближе и ближе к стандарту. Чем больше народа будет придерживаться стандартов в верстке, тем быстрее мы получим браузеры, которые отображают все одинаково.И наступит общее счастье
Кодировка utf8 в общем-то тоже рулит, и если когда-нибудь во всем мире будет использоваться одна и таже кодировка, то это будет одна из версий utf.
ps
а вообще, спасибо за заметку
+1 к карме
Для бизнеса, владельцев сайта
Если Вы понимаете, зачем в принципе нужны стандарты, то в чём заключается вопрос?
Во многих случаях, особенно когда встаёт вопрос о доработке и развитии, техническая составляющая может иметь непосредственное влияние на стоимость реализации новой функциональности вплоть до ситуации, когда «выкинуть и сделать всё заново» оказывается и проще, и быстрее, и дешевле.
Для себя как разработчиков
По сути те же причины, только немного под другим углом.
Требование к документам быть корректно сформированными во множестве случаев действительно позволяет избегать формальных ошибок. А указание спецификации приводит к значительно более предсказуемому поведению браузеров. XHTML Strict исключает устаревшие теги и атрибуты, в результате разделение контента и представления приближается к уровню обязательного требования. На практике всё это существенно облегчает процесс разработки, особенно если проект дорабатывается, а люди меняются.
В комментариях активно обсуждается применение CSS и даже XSLT, и хотя это имеет непосредственное отношение к «преимуществам» XHTML, но обсуждать их стоит отдельно, поскольку иначе потребуется сначала провести длительную дискуссию о неболее однозначных для большинства преимуществах семантической вёрстки с множеством оговорок о бездумном применении «блочной» вёрстки, а также всех смежных технологиях.
потребуется сначала провести длительную дискуссию о неболее однозначных для большинства преимуществах семантической вёрстки с множеством оговорок о бездумном применении «блочной» вёрстки, а также всех смежных технологиях.
Как показали недавние дискуссии на страницах «Хабра», прежде следует провести ликбез в части искоренения путаницы в понятиях.
Holy war
На мой взгляд весь сыр-бор по большей части происходит из-за того, что все свалено в одну кучу...
Блочная верстка – это совсем не обязательно XHTML.
Сравнивать, наверное, нужно было по отдельности следующее:
1. Табличная верстка vs Блочная верстка (не важно – HTML или XHTML).
2. HTML vs XHTML (не важно – табличная верстка или блочная верстка).
У XHTML определенно есть некоторые преимущества. Но рассматривать эти преимущества необходимо вне контекста CSS-верстки. Потому как блоками можно совершенно спокойно верстать и с "чистым" HTML...
Блочная верстка – это совсем не обязательно XHTML.
Сравнивать, наверное, нужно было по отдельности следующее:
1. Табличная верстка vs Блочная верстка (не важно – HTML или XHTML).
2. HTML vs XHTML (не важно – табличная верстка или блочная верстка).
У XHTML определенно есть некоторые преимущества. Но рассматривать эти преимущества необходимо вне контекста CSS-верстки. Потому как блоками можно совершенно спокойно верстать и с "чистым" HTML...
блоками можно сверстать и без xhtml, а вот подключить кучу css на разные устройства - увы нельзя.
можно
http://www.w3.org/TR/html4/present/style…
http://www.w3.org/TR/html4/present/style…
media = media-descriptors [CI]
This attribute specifies the intended destination medium for style information. It may be a single media descriptor or a comma-separated list. The default value for this attribute is "screen".
Простите, это на основании чего Вы такое предположение сделали?
Впрочем, Ваше утверждение уже опровергли соответствующим образом...
Впрочем, Ваше утверждение уже опровергли соответствующим образом...
Сколько слов написали. Зачем только автор смешивал понятия, приплёл CSS зачем-то. Поделюсь точкой зрения программиста.
Дискуссия эта стара и принимает различные формы. Например, кто круче, пёрл или питон.
На перле просто писать код быстро. (Расслабленный синтаксис, интуитивная интерпретация => HTML).
На питоне просто писать код правильно. (Неправильный просто не будет работать => XHTML).
Аргументы же по поводу ненужной многословности XHTML имеют силу, если предполагать, что код пишут руками. Строго говоря, ни один из *TML для этого особо не предназначен. Для этого есть средства создания метакода, текстовые (MarkDown, HAML), визуальные (редакторы, экспорт из текстовых процессоров, и даже, прости господи, FrontPage), и апишные (прикладные библиотеки, генерящие код на ходу). Ни в одном из этих случаев особо знать разницу не приходится. Максимум, обозначить параметр типа "OutputFormat = XHTML".
XML (читай XHTML), конечно, не идеальное изобретение, но полный SGML (читай HTML) являет собой нечто трудно совместимое с жизнью в принципе. Создание парсеров и генераторов для обобщённого SGML есть задача для особо крепких духом, а их сейчас маловато. При том, что SGML значительно старше, посчитайте, сколько есть инструментальных средств для XML и сколько для полного SGML, сколько есть подъязыков для XML (сотни) и сколько, отличных от XML, для SGML (два?). Отсюда и аргумент по лучшей поддержке браузерами XHTML. Браузерам проще сойтись во мнении, как надлежит интерпретировать нечто простое, чем нечто сложное.
Мне кажется, что сообщество уже де факто проголосовало, своей деятельностью по имплементации стандартов. Ответ очевиден.
Дискуссия эта стара и принимает различные формы. Например, кто круче, пёрл или питон.
На перле просто писать код быстро. (Расслабленный синтаксис, интуитивная интерпретация => HTML).
На питоне просто писать код правильно. (Неправильный просто не будет работать => XHTML).
Аргументы же по поводу ненужной многословности XHTML имеют силу, если предполагать, что код пишут руками. Строго говоря, ни один из *TML для этого особо не предназначен. Для этого есть средства создания метакода, текстовые (MarkDown, HAML), визуальные (редакторы, экспорт из текстовых процессоров, и даже, прости господи, FrontPage), и апишные (прикладные библиотеки, генерящие код на ходу). Ни в одном из этих случаев особо знать разницу не приходится. Максимум, обозначить параметр типа "OutputFormat = XHTML".
XML (читай XHTML), конечно, не идеальное изобретение, но полный SGML (читай HTML) являет собой нечто трудно совместимое с жизнью в принципе. Создание парсеров и генераторов для обобщённого SGML есть задача для особо крепких духом, а их сейчас маловато. При том, что SGML значительно старше, посчитайте, сколько есть инструментальных средств для XML и сколько для полного SGML, сколько есть подъязыков для XML (сотни) и сколько, отличных от XML, для SGML (два?). Отсюда и аргумент по лучшей поддержке браузерами XHTML. Браузерам проще сойтись во мнении, как надлежит интерпретировать нечто простое, чем нечто сложное.
Мне кажется, что сообщество уже де факто проголосовало, своей деятельностью по имплементации стандартов. Ответ очевиден.
Боюсь, для вас это будет потрясением, но первые же строки спецификации xml (http://www.w3.org/XML/) говорят, что он основан на SGML:
Исходя из ваших слов:
следует, что XML это такой подвид HTML :-))
Extensible Markup Language (XML) is a simple, very flexible text format derived from SGML (ISO 8879).
Исходя из ваших слов:
полный SGML (читай HTML)
следует, что XML это такой подвид HTML :-))
Ещё рекомендую предположить, что я алфавит плохо знаю, потому что не все буквы употребил.
Я не ожидал, что будут придираться к словам, и поэтому не разжёвывал.
А вообще... «Я спецификации не читаю, я их пишу» ©
SGML —> HTML
SGML —> DocBook
SGML —> XML —> XHTML, XSL, XSLT, XSL-FO, XML Schema, XPAth, XLink, XQuery и прочая, и прочая. В создании одного из стандартов я участвую сейчас и сам.
«SGML, читай HTML» означало лишь, что HTML унаследовал сложность и бесструктурность родительского стандарта, в то время как XML попытался внести некоторую упорядоченность и упрощение.
Я не ожидал, что будут придираться к словам, и поэтому не разжёвывал.
А вообще... «Я спецификации не читаю, я их пишу» ©
SGML —> HTML
SGML —> DocBook
SGML —> XML —> XHTML, XSL, XSLT, XSL-FO, XML Schema, XPAth, XLink, XQuery и прочая, и прочая. В создании одного из стандартов я участвую сейчас и сам.
«SGML, читай HTML» означало лишь, что HTML унаследовал сложность и бесструктурность родительского стандарта, в то время как XML попытался внести некоторую упорядоченность и упрощение.
В России, здесь и сейчас для большинства сайтов это значения не имеет. Аудитория не та. Тем, кто продает машины или компьютерные игры нет разницы, прочитает ли вдобавок к 500000 посетителей еще пара с брайлевского терминала.
Простите, не понял: Вы считаете, что "большинство сайтов" в России продает автомобили или компьютерные игры и имеет аудиторию в 500000 посетителей за некий конечный период времени?
Или Вы полагаете, что "большинство сайтов" содержит нечто, совершенно ненужное тем, кто пользуется брайлевским терминалом?
Или Вы просто-напросто думаете, что количество тех, кто пользуется брайлевским терминалом, столь ничтожно, что и хрен бы с ними?
(Это всего лишь вопрос, я не собираюсь никому читать мораль.)
Холивор в ночь на субботу? Это уже что-то новое.
Бросьте это бесполезное занятие. На улице отлично.
Бросьте это бесполезное занятие. На улице отлично.
Юношеский максимализм в каком возрасте бывает? Вот такой же максимализм и у разработчиков после 2-3х лет занятия этим ремеслом. Сродни крикам "нет! будет у нас XSLT в одном месте и PHP в другом!! Чтобы отделить логику от представления!!!". Хотя вроде бы надо логику от представления отделить - но никак не HTML от PHP :). То же самое с блочной версткой vs. табличной - делать такой (X)HTML чтобы одним CSS стилем можно его было с ног на голову поменять - глупо. Это всё - представление. Тут нету модели данных даже (если скажете что xhtml выступает в её роли - мои тапочки со смеху подохнут). (X)HTML+CSS это целиком логика представления, так что если для изменения дизайна надо менять и то и другое - это абсолютно нормально и естественно.
Я вот кстати не понял - каким образом XHTML связан с блочной вёрсткой ^_^. Оба понятия настолько тесно переплетены в цитируемом документе - как будто одно целое :).
Сам я пишу на XHTML в основном из-за более аккуратного внешнего вида кода :) ("внешний вид кода".. хм.. надо же). Ну и возможность без определённых проблем работать с документом как с обычным XML - тоже чего-то стоит. А вот дебаты табличная верстка vs. блочная мне в целом совсем непонятны :). Если заглянуть в мир глянцевых журналов и книжек - то станет понятно что блочная верстка действительно крута при очень четких понятиях размера шрифта, гегля, размеров блоков, размеров VIEW (т.е. страницы). В браузерах же - всё бесконечно тянется во всех направлениях (т.е. view не лимитирован). Ладно, фиг с ним - можно сайт резиновым по ширине не делать. А вот уж по вертикали - извините, но постранично сайты листать это совсем что то новое :). Помимо всего прочего табличная верстка как правило куда быстрее реализовывается и куда более одинаково отображается :). Ещё пинок - есть варианты которые решительно невозможно реализовать методами "всплытия поплавков". Ещё есть вариант создания заточенного под один сайт VIEW путём разрисовки всего UI блоками на яваскрипте. Тем более что после внесения в блок всех составляющих - т.е. текста картинок и тп - становится ясным и четким его физических размер ещё _до_ отображения на экране. Тогда проблема смены медиа-устройства (normal,print,tv) будет совсем порстенькой - JS отвечающий за позиционирование и раскраску поменять и всё :). Но это огромная куча лишней работы, которую совсем не нужно делать компаниям.
p.s. в первом абзаце я обращался не к автору поста на хабре, а к автору 15-ти пунтков отсюда http://www.i2r.ru/static/476/out_23437.s…, с автором поста на хабре (Novikov) я согласен почти целиком (что странно ;)) и столь же скептически отношусь к таким взываниям "мир, труд, май, XHTML!"
Я вот кстати не понял - каким образом XHTML связан с блочной вёрсткой ^_^. Оба понятия настолько тесно переплетены в цитируемом документе - как будто одно целое :).
Сам я пишу на XHTML в основном из-за более аккуратного внешнего вида кода :) ("внешний вид кода".. хм.. надо же). Ну и возможность без определённых проблем работать с документом как с обычным XML - тоже чего-то стоит. А вот дебаты табличная верстка vs. блочная мне в целом совсем непонятны :). Если заглянуть в мир глянцевых журналов и книжек - то станет понятно что блочная верстка действительно крута при очень четких понятиях размера шрифта, гегля, размеров блоков, размеров VIEW (т.е. страницы). В браузерах же - всё бесконечно тянется во всех направлениях (т.е. view не лимитирован). Ладно, фиг с ним - можно сайт резиновым по ширине не делать. А вот уж по вертикали - извините, но постранично сайты листать это совсем что то новое :). Помимо всего прочего табличная верстка как правило куда быстрее реализовывается и куда более одинаково отображается :). Ещё пинок - есть варианты которые решительно невозможно реализовать методами "всплытия поплавков". Ещё есть вариант создания заточенного под один сайт VIEW путём разрисовки всего UI блоками на яваскрипте. Тем более что после внесения в блок всех составляющих - т.е. текста картинок и тп - становится ясным и четким его физических размер ещё _до_ отображения на экране. Тогда проблема смены медиа-устройства (normal,print,tv) будет совсем порстенькой - JS отвечающий за позиционирование и раскраску поменять и всё :). Но это огромная куча лишней работы, которую совсем не нужно делать компаниям.
p.s. в первом абзаце я обращался не к автору поста на хабре, а к автору 15-ти пунтков отсюда http://www.i2r.ru/static/476/out_23437.s…, с автором поста на хабре (Novikov) я согласен почти целиком (что странно ;)) и столь же скептически отношусь к таким взываниям "мир, труд, май, XHTML!"
Заинтересовал пункт:
За счет чего XHTML-код:
будет занимать меньше, чем HTML-код
А?
11. XHTML+CSS позволяет существенно снизить вес документа.
За счет чего XHTML-код:
<p class="caption">Список:</p>
<ol>
<li>Пункт первый</li>
<li>Пункт второй</li>
</ol>
<p>Ну как-то так...</p>
будет занимать меньше, чем HTML-код
<p class=caption>Список:
<ol>
<li>Пункт первый
<li>Пункт второй
</ol>
<p>Ну как-то так...
А?
Это хорошее рассуждение ввело меня в курс дела сразу нескольких технологий.
Благодарю!
Благодарю!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ответ на «15 преимуществ» XHTML и 2 вопроса к читателям