Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 95
Огорчает грядущее отсутствие тегов s, u, b, i.
Как-бы, легче на порядок написать <i><b>text</b></i> , и получить жирный текст курсивом, нежели мудрить со <span class="bold italic">, или, того хуже, <span style="...">... брррр.
Неправильную они там траву курят, ох неправильную. Я что-то совсем нифига не доволен.
Как-бы, легче на порядок написать <i><b>text</b></i> , и получить жирный текст курсивом, нежели мудрить со <span class="bold italic">, или, того хуже, <span style="...">... брррр.
Неправильную они там траву курят, ох неправильную. Я что-то совсем нифига не доволен.
Ну смысл их действий вроде бы верный - должен отмечать тегом, который отражает смысл, к примеру
<span class="notify"></span> или тем же <em>, иначе теряется семантика верстки. Об этом, кстати говорят не только дядьки из W3C, но и многие опытные верстальщики*опечатка: не em, а m
Как это парадоксально не звучит, но, в некоторых случаях:
для лучшей семантики следует использовать теги <b>, <i>, <u>, <strike> и т.д., а не <strong>, <em> или CSS.
Это происходит тогда, когда содержимое элемента имеет именно презентационный смысл: жирность, курсив, моноширинный шрифт, а не выделение, сильное выделение, цитата и т.д.
Вот пример текста:
В данном случае фразы:
И поэтому, для для верстки этого текста семантично использовать презентационные теги: <b>, <i>, <u>
Во всяком случае, это мое понимание семантики. Возможно, многие со мной не согласятся.
P.S. Кстати,
pepelsbey
для лучшей семантики следует использовать теги <b>, <i>, <u>, <strike> и т.д., а не <strong>, <em> или CSS.
Это происходит тогда, когда содержимое элемента имеет именно презентационный смысл: жирность, курсив, моноширинный шрифт, а не выделение, сильное выделение, цитата и т.д.
Вот пример текста:
В нашем текстовом редакторе можно:
- выделить текст жирным,
- сделать его курсивным,
- а также, использовать подчеркивание
В данном случае фразы:
- «выделить текст жирным» — имеет смыл именно «жирность», а не «сильное выделение»
- «сделать его курсивным» — имеет смыл именно «курсив», а не «обычное выделение»
- «использовать подчеркивание» — имеет смыл именно «подчеркивание» и т.д.
И поэтому, для для верстки этого текста семантично использовать презентационные теги: <b>, <i>, <u>
В нашем текстовом редакторе можно:
<ul>
<li>
выделить текст <b>жирным</b>,
</li>
<li>
сделать его <i>курсивным</i>,
</li>
<li>
а также, использовать <u>подчеркивание</u>
</li>
</u>
Во всяком случае, это мое понимание семантики. Возможно, многие со мной не согласятся.
P.S. Кстати,
pepelsbeyЯ высказал свое мнение и обосновал его.
Минусующим: пожалуйста, напишите, с чем вы не согласны.
Впрочем, я осознано пошел на публикацию предыдущего коммента и предполагал подобную реакцию...
Минусующим: пожалуйста, напишите, с чем вы не согласны.
Впрочем, я осознано пошел на публикацию предыдущего коммента и предполагал подобную реакцию...
Здесь минусуют без объяснения причин, потому что у вас наблюдается полное непонимание того, что такое семантика и и почему она полезна, а объяснить это в двух словах сложно.
Комментарием выше бал описан только один из случаев разметки. Как пример приведу другой случай: у меня есть интернет-магазин, и там в описании товара есть особенное свойство, которое надо выделить. Выделять тегами или писать в классе bold и italic - неправильно. Правильнее написать unique-property. Верстальщику писать придется больше, зато это семантично + при изменении дизайна не придется трогать верстку.
Я попытался описать случай, когда четко прослеживается отделение разметки документа от его отображения.
Комментарием выше бал описан только один из случаев разметки. Как пример приведу другой случай: у меня есть интернет-магазин, и там в описании товара есть особенное свойство, которое надо выделить. Выделять тегами или писать в классе bold и italic - неправильно. Правильнее написать unique-property. Верстальщику писать придется больше, зато это семантично + при изменении дизайна не придется трогать верстку.
Я попытался описать случай, когда четко прослеживается отделение разметки документа от его отображения.
Я писал, что «в некоторых случаях: для лучшей семантики следует использовать теги <b>, <i>, <u> ...»
Еще раз повторю, только — в некоторых случаях, т.е. тогда, элемент семантически имеет смысл «жирность» или «курсив» как техническую возможность.
Когда же элемент имеет другой смысл (как в Вашем случае), например, «выделение» или «цитата», то тогда, конечно, следует использовать соответствующие этим смыслам теги, например <strong> или <cite>.
Так что с пониманием семантики у меня все в порядке :-)
Еще раз повторю, только — в некоторых случаях, т.е. тогда, элемент семантически имеет смысл «жирность» или «курсив» как техническую возможность.
Когда же элемент имеет другой смысл (как в Вашем случае), например, «выделение» или «цитата», то тогда, конечно, следует использовать соответствующие этим смыслам теги, например <strong> или <cite>.
Так что с пониманием семантики у меня все в порядке :-)
Я промахнулся с ответом. К вашему комменту у меня нет претензий.
Согласен на все 100%.
Вот ещё пример со снипетами в гугле. Посмотрите сорец страницы и увидите каким тэгом подсвечиваются слова, и это верно, ведь никакогосмыслового выденления там нет, а само по себе выделение пристутствовать должно по-любому.
Вот ещё пример со снипетами в гугле. Посмотрите сорец страницы и увидите каким тэгом подсвечиваются слова, и это верно, ведь никакогосмыслового выденления там нет, а само по себе выделение пристутствовать должно по-любому.
Поправил ссылку :) снипеты
> + при изменении дизайна не придется трогать верстку
Мы все здесь знаем, что это утопия ;)
Мы все здесь знаем, что это утопия ;)
выделить текст <b><i><font size="2">увеличенным полужирным курсивом</font></i></b>
указать <span class="tag-h1">заголовок первого уровня</span>
h1, .tag-h1 { font-size: 2em; font-weight: bold; font-style: italic }
указать <span class="tag-h1">заголовок первого уровня</span>
h1, .tag-h1 { font-size: 2em; font-weight: bold; font-style: italic }
Я не минусовал, просто не согласен и пишу комментарий. :) Во-первых, приведённые вами случаи достаточно редки, и вполне можно пользоваться span’ами. Естественно, в данном случае использование strong и em не оправдано. Во-вторых, любое выделение (в том числе и в редакторе) де-факто имеет семантический смысл. И выделение полужирным в редакторе имеет смысл совершенно не полужирности, а именно что выделения, логического ударения. То есть, ещё раз, в приведённом вами тексте действительно это выделение не имеет семантической окраски, кроме «презентационности», в то время как подобное выделение в самом редакторе — имеет.
Все абсолютно правильно, только я не понял, с чем Вы не согласны... Ведь Вы говорите как раз о том, о чем и говорю :-)
Семантика подразумевает использование тегов в соответствием со смыслом элемента.
Если смысл элемента — «выделение», «сильное выделение» или «цитата» — используем теги <em>, <strong> или <cite> соответственно.
Если смысл элемента — «жирность», «курсив», или «подчеркивание» как техническая возможность — используем теги <b>, <i> или <u>.
Да, такие случае редки, но, всеже, они могут быть. Например, список технических возможностей текстового редактора, который я привел.
Использование <span> в таких случаев менее семантично, ведь <span> сам по себе не имеет никакой семантики, а <b> — имеет семантику «жирность как техническое явление».
Единственный случай, когда для обозначения «жирности как технической возможности» лучше использовать не <b>, а <span> со стилями, это тогда, когда следует соблюсти спецификацию xHTML Strict.
Семантика подразумевает использование тегов в соответствием со смыслом элемента.
Если смысл элемента — «выделение», «сильное выделение» или «цитата» — используем теги <em>, <strong> или <cite> соответственно.
Если смысл элемента — «жирность», «курсив», или «подчеркивание» как техническая возможность — используем теги <b>, <i> или <u>.
Да, такие случае редки, но, всеже, они могут быть. Например, список технических возможностей текстового редактора, который я привел.
Использование <span> в таких случаев менее семантично, ведь <span> сам по себе не имеет никакой семантики, а <b> — имеет семантику «жирность как техническое явление».
Единственный случай, когда для обозначения «жирности как технической возможности» лучше использовать не <b>, а <span> со стилями, это тогда, когда следует соблюсти спецификацию xHTML Strict.
Поскольку такие случаи редки, я за использование span, а не b, i и u, дабы не плодить сущностей без необходимости. :) Смысл не в технической возможности, а именно в выделении. Просто в HTML 4.0 позволялось не разделять представление от содержания, вот и были b, i и u. Если содержание и представление разделять, то их очевидно не должно быть.
Семантически выделение слов «жирным», «курсивом» и «подчёркивание» вообще не требуется — весь смысл фразы полностью содержится в ней самой, дополнительное выделение не требуется для полного её понимания.
Семантически выделение слов «жирным», «курсивом» и «подчёркивание» вообще не требуется — весь смысл фразы полностью содержится в ней самой, дополнительное выделение не требуется для полного её понимания.
Это, по-моему, единственный такой случай. Да и здесь уместнее использовать атрибут style.
Ну, в «парадоксах разметки» я уже отметился, повторюсь и здесь, заодно может чуть переформулирую и объединю с иными мнениями. Итак…
Мы сейчас очарованы идеями семантической верстки, правильной типографики и прочими замечательными идеями по развитию формы. Однако, в нашем стремлении к прогрессу мы упускаем развитие содержания. Приведенный Вами текст должен быть заменен на более современный, так же как табличная верстка должна быть заменена семантичной (я уже молчу о самом гипотетическом редакторе, который, судя по увиденному, сам по себе с семантикой дружить не будет). Например, каким-то таким образом:
В нашем текстовом редакторе можно:
И тому подобное. И уже в примерах использование семантических тегов вместо презентационных будет абсолютно оправдано.
Развивать и улучшать не только форму, но и содержание — это моё понимание семантики. Хотя, возможно, со мной не согласятся столь же многие, сколь и с Вами :)
Мы сейчас очарованы идеями семантической верстки, правильной типографики и прочими замечательными идеями по развитию формы. Однако, в нашем стремлении к прогрессу мы упускаем развитие содержания. Приведенный Вами текст должен быть заменен на более современный, так же как табличная верстка должна быть заменена семантичной (я уже молчу о самом гипотетическом редакторе, который, судя по увиденному, сам по себе с семантикой дружить не будет). Например, каким-то таким образом:
В нашем текстовом редакторе можно:
- наиболее важные элементы выделять полужирным начертанием (например: «Однако, в нашем стремлении к прогрессу мы упускаем развитие содержания»)
- цитаты выделять курсивом (например: «сомневаться полезно, это пробуждает мысль от сна слепой уверенности» — пишет
- Для устаревшей информации предыдущих изданий, приведенной для сравнения, использовать перечеркивание (например: Вы не получите качественной верстки за шесть
баксовевро)
И тому подобное. И уже в примерах использование семантических тегов вместо презентационных будет абсолютно оправдано.
Развивать и улучшать не только форму, но и содержание — это моё понимание семантики. Хотя, возможно, со мной не согласятся столь же многие, сколь и с Вами :)
Чем вас не устраивает:
А указанные вами теги и в текущей рекомендации html4.1 носят статус deprecated
<m>text</m>
m {
font-weight: bold;
font-variant: italic;
}
А указанные вами теги и в текущей рекомендации html4.1 носят статус deprecated
Да, но есть Strong :)
А M и правда рулит, через 10 лет будет кайфово верстальщикам :))))
А M и правда рулит, через 10 лет будет кайфово верстальщикам :))))
Не думаю, что strong'у при такой концепции долго жить осталось)
Почему нет? strong и em — теги, не привязанные к отображению. b означает bold
-полужирный, а strong означает выделенный. Как именно выделенный — дело автора
документа.
-полужирный, а strong означает выделенный. Как именно выделенный — дело автора
документа.
Вы не правы. Strong означает сильное логическое выделение. Ещё более сильное, чем em. Поэтому и использоваться strong должен значительно реже, чем em.
А в чём неправ?
В том, что «как именно выделенный — дело автора
документа». Это не как угодно выделенный, а именно означающий семантически сильное логическое выделение.
документа». Это не как угодно выделенный, а именно означающий семантически сильное логическое выделение.
да им и сейчас неплохо живется, если закрыть глаза на IE6- :)
Мнение полного профана: мне старый вариант кажется проще и понятнее. Слова span и class у меня никак не связываются со шрифтом. Ну и писать конечно меньше, если вручную редактировать.
Слова span и class у меня никак не связываются со шрифтом. Слова span и class у меня никак не связываются со шрифтом.Совершенно верно - так и должно быть. Содержимое текста вообще не должно быть связано со шрифтами. К сожалению во многих существующих продуктах (MS Office, HTML, etc) всё перемешано :-(
Признайте, что есть рациональное зерно в таком подходе.
Когда мы используем болд, то это однозначно болд, но если мы используем сильное выделение, то это не значит болд.. а может быть выделение цветом или бэкграундом.. и эти правила выделения мы можем менять.. на всем сайте буквально несколькими строчками в файле style.css.
Притом если мы пользуемся семантической разметкой документа, мы получаем более гибкую структуру при работе с различными нестандартными устройствами, распознавая которые можем отдавать другой css файл с другим представлением без правки кода.
Когда мы используем болд, то это однозначно болд, но если мы используем сильное выделение, то это не значит болд.. а может быть выделение цветом или бэкграундом.. и эти правила выделения мы можем менять.. на всем сайте буквально несколькими строчками в файле style.css.
Притом если мы пользуемся семантической разметкой документа, мы получаем более гибкую структуру при работе с различными нестандартными устройствами, распознавая которые можем отдавать другой css файл с другим представлением без правки кода.
Одни генерируют очередные костыли, а другие — идеалисты. А мучаться со всем этим опять нам и производителям браузеров.
Я боюсь, случится та же беда, что и с Си++, у которого очередной стандарт делают уже 10 лет. Пока делали, поезд уже ушёл — скоро строем будем переходить на Erlang, Haskel или F#.
У меня ноутбук, в прошлом году приобретённый, при размере экрана в 15 дюймов держит разрешение 1680*1050 (т.е. столько же, сколько 20-тидюймовый стационарный монитор). Чёткость изображения такая же, как у первых лазерных принеторов, 150dpi. Вот ещё года 2-3, ну 5, и у нас у каждого на рабочем столе будут стоять HD-мониторы по 24 дюйма. А это значит, что на экране будет помещаться газетный разворот, да такой, что от бумаги не отличишь.
И начнём мы массовый возврат к LaTeX, и будем PDF'ки рисовать. :)
У меня ноутбук, в прошлом году приобретённый, при размере экрана в 15 дюймов держит разрешение 1680*1050 (т.е. столько же, сколько 20-тидюймовый стационарный монитор). Чёткость изображения такая же, как у первых лазерных принеторов, 150dpi. Вот ещё года 2-3, ну 5, и у нас у каждого на рабочем столе будут стоять HD-мониторы по 24 дюйма. А это значит, что на экране будет помещаться газетный разворот, да такой, что от бумаги не отличишь.
И начнём мы массовый возврат к LaTeX, и будем PDF'ки рисовать. :)
Мне кажется вы зря пророчите гибель декларативных языков :)
Я грешным делом всегда считал, что декларативные языки, это SQL, XSLT, регулярные
выражения. Вы о каких языках говорите?
выражения. Вы о каких языках говорите?
Описка. Я имел ввиду императивные :)
Ужас какой. Разве я пророчил гибель? Я писал о бессмысленности нового стандарта
для Си++. А жить он будет очень долго, учитывая количество написанного кода.
для Си++. А жить он будет очень долго, учитывая количество написанного кода.
«скоро строем будем переходить на Erlang, Haskel или F#» — думаю это понимается однозначно как пророчество о гибели :)
Ну, я даже не знаю. MySQL и Apache на чистом Си писаны. Язык живой? Живой.
Но вот из новых программистов его мало кто изучает, и программисты на Си
нужны гораздо реже, чем программисты на Си++. А те, в свою очередь, на
Java. Это не гибель, это стагнация.
Но вот из новых программистов его мало кто изучает, и программисты на Си
нужны гораздо реже, чем программисты на Си++. А те, в свою очередь, на
Java. Это не гибель, это стагнация.
Но ведь есть и другие императивные языки. Зачем зацикливаться на С? Python, Ruby например. В последнее время они набрали популярность. И неспроста. Есть куда развиваться. А пока обычным делом не станут домашние дофига-процессорные системы — у С++ есть будущее. Вообще говоря функциональные языки это отдельный разговор. Не сомневаюсь, для определенных задач они хороши. Но определенно не там, где нужна быстрая разработка, доступная, например, в Python.
Мне даже как-то неловко, честное слово. И в Python, и в Ruby
функциональная парадигма прекрасно поддерживается.
функциональная парадигма прекрасно поддерживается.
Но вы же не назовете Python функциональным? Поглядите табличку в википедии :) Да, возможности есть. Но я сомневаюсь, чтобы они были реально востребованы.
Слово "мультипарадигменный" Вам знакомо? И, давайте,
прежде, чем ссылаться на википедию, Вы ознакомитесь
с предметом?
В той же мере, Вы не можете назвать Python императивным.
Иначе мне придётся дать Вам ссылку на такие его возможности,
как map, reduce или та же lambda.
Ну а то, что лично Вами они не востребованы, показыват
только уровень Ваших представлений. Разработчики Python и Ruby,
думаю, с Вами не согласятся.
прежде, чем ссылаться на википедию, Вы ознакомитесь
с предметом?
В той же мере, Вы не можете назвать Python императивным.
Иначе мне придётся дать Вам ссылку на такие его возможности,
как map, reduce или та же lambda.
Ну а то, что лично Вами они не востребованы, показыват
только уровень Ваших представлений. Разработчики Python и Ruby,
думаю, с Вами не согласятся.
Я знаком и с map(), и с reduce(), и с lambda-функциями, и даже, как ни странно, с list comprehension в Python. Это сильно упрощает жизнь в императивном коде. Покажите хоть один проект на Python, где бы целиком использовался функциональный подход? А вот ООП-проектов на Python великое множество. Дело не в возможностях, дело в том, как они используются.
Если Вы используете map, reduce и прочее, почему
Вы называете свой код императивным? Этих средств
в императивных языках никогда не было.
И откуда такая асимметричность в подходе? Похоже,
независимо от того, какой будет код, Вы всё равно
будете считать его импративным с функциональными
вставками?
Кстати, правильно ли я Вас понял, что вы
противопоставляете ООП и ФП?
Вы называете свой код императивным? Этих средств
в императивных языках никогда не было.
И откуда такая асимметричность в подходе? Похоже,
независимо от того, какой будет код, Вы всё равно
будете считать его импративным с функциональными
вставками?
Кстати, правильно ли я Вас понял, что вы
противопоставляете ООП и ФП?
Пока делали, поезд уже ушёл — скоро строем будем переходить на Erlang, Haskel или F#.Вы действительно в это верите? Я думаю что C++ будет жить ещё долго и счастливо. Как и Cobol (вы, я надеюсь, в курсе что в мире на Cobol пишут больше миллиона человек) и Fortran (ну тут и говорит не о чем). Так что да - переход случится, но займёт это на порядок больше времени чем идеалистам вроде вас кажется. Процесс перехода начался, но я не думаю что в ближайшие 10-15 лет на Erlang, Haskel и F# (вместе взятых!) будет создано больше ПО чем на C++...
Фортран — это прости Господи. Кошмарный язык.
Грешно Вам обзываться. Тем более, что мысли моей Вы не поняли. Ну, для программистов это
явление известное, и даже закономерное.
Попробую сказать по другому. Десятилетием Си++ были годы 1991-2000. Появились
доступные компиляторы, вышло много книг, народ массово стал переходить, работодатели
заинтересовались. Тогда и было время для разработки стандартов. А сейчас время Си++ ушло, и смысла в новом стандарте не так много, как, скажем, в начале 2000-х. Сейчас время Java (ну и более узкого C#). Активно идёт работа над языками, появляются новые возможности,
выходит литература, множество предложений от работодателей (больше, чем по Си++, и уж
тем более, чем по Коболу и Фортрану, кстати, а Вы на Коболе сами пишите?)
А следующее десятилетие будет посвящено функциональным языкам.
По поводу идеализма я всю свою жизнь сентенции слышу. Мне в 92-93 годах тоже говорили,
что зря я изучаю Си++, язык то не востребован. Однако, к 97-му году ситуация изменилась
кардинально. И тем, кто говорил про идеализм, пришлось догонять. И с Java было то же самое.
явление известное, и даже закономерное.
Попробую сказать по другому. Десятилетием Си++ были годы 1991-2000. Появились
доступные компиляторы, вышло много книг, народ массово стал переходить, работодатели
заинтересовались. Тогда и было время для разработки стандартов. А сейчас время Си++ ушло, и смысла в новом стандарте не так много, как, скажем, в начале 2000-х. Сейчас время Java (ну и более узкого C#). Активно идёт работа над языками, появляются новые возможности,
выходит литература, множество предложений от работодателей (больше, чем по Си++, и уж
тем более, чем по Коболу и Фортрану, кстати, а Вы на Коболе сами пишите?)
А следующее десятилетие будет посвящено функциональным языкам.
По поводу идеализма я всю свою жизнь сентенции слышу. Мне в 92-93 годах тоже говорили,
что зря я изучаю Си++, язык то не востребован. Однако, к 97-му году ситуация изменилась
кардинально. И тем, кто говорил про идеализм, пришлось догонять. И с Java было то же самое.
Теперь каждому верстальщику для работы будет положено пакет шмали. А как иначе? ;-)
конкуренция этих двух форматов неизбежна в любом случае.
если они не будут объединены в единый формат, задержка развития обмена информацией в сети, вызванная еб@ным IE6 покажется детско-индийской шалостью...
оба формата содержат такие вкусности, которые хочется видеть в ЕДИНОМ формате.
вред полиформатности уже давно виден даже ёжикам из тумана. очень жаль, чтомудазвоны очень умные дяди из W3C этого не понимают.
если они не будут объединены в единый формат, задержка развития обмена информацией в сети, вызванная еб@ным IE6 покажется детско-индийской шалостью...
оба формата содержат такие вкусности, которые хочется видеть в ЕДИНОМ формате.
вред полиформатности уже давно виден даже ёжикам из тумана. очень жаль, что
По моему мнению, лучше бы они взяли за основной стандарт XHTML 2.0, но добавили к нему API для web-приложений из HTML 5.0. То, что XHTML сложнее - это тоже не проблема, если у верстальщика мозги есть.
Единственная радость, что к выходу этих стандартов старые браузеры должны будут отмереть, а новые отображать страницы как положено, а не как на душу придется. Может, в кои-то веки, верстальщику не придется "костылями" придурь разработчиков браузера исправлять.
Единственная радость, что к выходу этих стандартов старые браузеры должны будут отмереть, а новые отображать страницы как положено, а не как на душу придется. Может, в кои-то веки, верстальщику не придется "костылями" придурь разработчиков браузера исправлять.
Про XHTML 5.0 — ни слова.
http://xhtml.com/en/future/x-html-5-versus-xhtml-2/
http://xhtml.com/en/future/x-html-5-versus-xhtml-2/
что такое XHTML 5.0? по той ссылки пишут X/HTML 5.0 и подрозумевают HTML 5, а вы о чём?
А нет XHTML 5.0. Когда whatwg'шники начали так называть XML-вариант своего стандарта, разработчики XHTML 2.0 возмутились: HTML 5 не только не является развитием XHTML 2.0, но даже лишён возможностей XHTML 1.1. И, помнится, приняли нотацию HTML5x.
Афтор пропустил букву: "...разработчиков XHTML 2.0 не контролирует эту тЕхнологию, а только..."
Рассчитывал на что-то действительно новое в разметке. Получилось только изменение названий некоторых тегов и убирание тех тегов, которые и так давно никто не использовал. Зато большое спасибо, что обратили внимание на убогую реализацию форм и инпутов.
Вот только еще лет пять не сможем юзать плоды эволюции.
Вот только еще лет пять не сможем юзать плоды эволюции.
Вам плюс. Разработчикам жирный минус. Теперь у нас будет и Лебедь и Рак. А щука IE6 незабвенный.
Зачотные обещания. Если еще и обойдется без «войн стандартов» — вообще порадуюсь.
Семантика и "отделение контента от представления" — это конечно хорошо, да вот только по-большому счету это никому не надо на данном этапе развития интернета в России. Заказчику (да и большенству пользователей) чаще всего пох, что там у верстальщика в коде: одни таблицы, одни дивы, сематическая верстка... Им нужно, чтобы сайт не разъезжался в браузере ("а что кроме ie еще что-то есть? а зачем??" >)) и сделано было в срок.
Сейчас HTML-верстальщик — это всего лишь какое-то звено между ДИЗАЙНЕРОМ и ПРОГРАММИСТОМ (человек из разряда подсобных рабочих) и пока народ не поймет, что это все не просто нарезка картинок, вещи а ля XHTML2 остануться очередной игрушкой тех, кому это надо.
Сейчас HTML-верстальщик — это всего лишь какое-то звено между ДИЗАЙНЕРОМ и ПРОГРАММИСТОМ (человек из разряда подсобных рабочих) и пока народ не поймет, что это все не просто нарезка картинок, вещи а ля XHTML2 остануться очередной игрушкой тех, кому это надо.
Ничего толком и не изменилось. Теги как были тегами так и остались...
Все эти нововведения ХТМЛ это попытка стандартизировать процесс верстки и ничего больше. <div class="menu"> всего лишь преопределится в <nav>
В коце концов все браузеры будут поддерживать и HTML 5 и XHTML 2.0. И как всегда будет воина между HTML 5 и XHTML 2.0, как это сеичас идет между дивами и таблицами.
Все эти нововведения ХТМЛ это попытка стандартизировать процесс верстки и ничего больше. <div class="menu"> всего лишь преопределится в <nav>
В коце концов все браузеры будут поддерживать и HTML 5 и XHTML 2.0. И как всегда будет воина между HTML 5 и XHTML 2.0, как это сеичас идет между дивами и таблицами.
Прошу автора не обижаться за этот совет, но прежде чем переводить статью стоит иногда погуглить, не сделал ли кто-то этого до вас.
XHTML2 против HTML5.
XHTML2 против HTML5.
Что-то чую я, что HTML5 будет внедрен раньше XHTML2. Так сказать, по просьбам трудящихся, не осиливших прочтение всех стандартов, на которые ссылается XHTML2.
Кажется, XHTML2 предназначается уже чисто для верстальных программ, ну или киборгов.
Кажется, XHTML2 предназначается уже чисто для верстальных программ, ну или киборгов.
Товарищи, о чем вы тут собачитесь? О том, что два стандарта в будущем - это плохо и будет еще хуже?
Отнюдь! По-моему, все развивается правильно.
HTML5 станет основой для веб-приложений, "личных кабинетов" и прочих бэкэндов: вместе с ним станет возможно проще построить более качественный интерфейс.
XMHTML2 станет основой для сайтов с документацией, техническими статьями: вместе с ним станет возможно более удобно обращаться с большими массивами сложно структурированных данных - работать с ними не только посредством кликов пользователей по ссылкам и формам. Скорее всего, будет проще построить мостик между различными форматами представления текста и графики.
Другими словами: HTML5 - по большей части для пользователей, XHTML2 - по большей части для машинной обработки.
И кстати, никто же не заставляет вас делать полностью весь сайт только на одном стандарте разметки: часть вы можете сделать в HTML5, часть в XHTML2.
Комбинируйте технологии! Иногда можно сотворить такой микс, от которого перехватывает дыхание! Так давай те же делать этот грандиозный веб!
Отнюдь! По-моему, все развивается правильно.
HTML5 станет основой для веб-приложений, "личных кабинетов" и прочих бэкэндов: вместе с ним станет возможно проще построить более качественный интерфейс.
XMHTML2 станет основой для сайтов с документацией, техническими статьями: вместе с ним станет возможно более удобно обращаться с большими массивами сложно структурированных данных - работать с ними не только посредством кликов пользователей по ссылкам и формам. Скорее всего, будет проще построить мостик между различными форматами представления текста и графики.
Другими словами: HTML5 - по большей части для пользователей, XHTML2 - по большей части для машинной обработки.
И кстати, никто же не заставляет вас делать полностью весь сайт только на одном стандарте разметки: часть вы можете сделать в HTML5, часть в XHTML2.
Комбинируйте технологии! Иногда можно сотворить такой микс, от которого перехватывает дыхание! Так давай те же делать этот грандиозный веб!
Мне кажется в будущем всё случится так, как случится и нефиг гадать. ЛУчше станет точно =)
А ещё порог на вхождение в эту сферу деятельности скорее всего повысится, так что радуйтесь. Конкуренция будет интереснее
А ещё порог на вхождение в эту сферу деятельности скорее всего повысится, так что радуйтесь. Конкуренция будет интереснее
Личное мнение: W3C пора вообще растрелять. Все, что она сделала - это обеспечила будущие холивары между стандартами XHTML 2 и HTML 5 и даже любителей старых XHTML/HTML 4.1. Вкусности разместили по обе стороны, прекрасно.
Вопрос: мы, наконец, сможем использовать СВОИ теги вместо предопределенных? Или все, что сделала W3C, это переименовала теги и добавила несколько новых, да плюс новые инпуты? Извините за эмоцианольность.
Вопрос: мы, наконец, сможем использовать СВОИ теги вместо предопределенных? Или все, что сделала W3C, это переименовала теги и добавила несколько новых, да плюс новые инпуты? Извините за эмоцианольность.
как же долго будем идти к этим стандартам :(
На мой взгляд, гораздо сильнее нужно ждать уже принятия CSS3, a HTML 4 и XHTML 1 будут в ходу ещё бесчисленное количество лет хотя бы потому, что лавинообразно растёт доля портативных устройств, которые будут использоваться ещё долго.
По поводу семантики — я сильно неуверен, что многие из отписавшихся «апологетов» хотя бы раз делали, например, сайты для людей с ограниченными физическими возможностями, а всем остальным абсолютно до лампочки, насколько строгое смысловое выделение использовалось, <b>, <span> или <strong> — потому что выглядит оно что на экране, что на печати одинаково жирно. Ну не поддерживает IE разные степени жирности в font-weight :) А какая тогда разница? Я за <b>, пока он из deprecated не превратится в restricted.
По поводу семантики — я сильно неуверен, что многие из отписавшихся «апологетов» хотя бы раз делали, например, сайты для людей с ограниченными физическими возможностями, а всем остальным абсолютно до лампочки, насколько строгое смысловое выделение использовалось, <b>, <span> или <strong> — потому что выглядит оно что на экране, что на печати одинаково жирно. Ну не поддерживает IE разные степени жирности в font-weight :) А какая тогда разница? Я за <b>, пока он из deprecated не превратится в restricted.
я не понял, тэгов и не будет ?????
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
XHTML 2 против HTML 5