Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 142
Замечательно!
Только микроволновая печь будущего знает не только XHTML, но и XHTML 2.0, где этот атрибут есть.
Понятно что с выходом чего нибудь подобного, если сайт поддерживаеться, атрибут поменяют, но просто ваш довод мне лично непонятный, микроволновки какие-то.
Вообще по поводу валидности. Я в своей жизни встречал наверно меньше 100 полностью валидных сайтов. Вот на этой странице tidy мне выдает больше 500 ошибок типа вместо . Все спорят, спорят, а валидные сайты не делают.
Понятно что с выходом чего нибудь подобного, если сайт поддерживаеться, атрибут поменяют, но просто ваш довод мне лично непонятный, микроволновки какие-то.
Вообще по поводу валидности. Я в своей жизни встречал наверно меньше 100 полностью валидных сайтов. Вот на этой странице tidy мне выдает больше 500 ошибок типа вместо . Все спорят, спорят, а валидные сайты не делают.
Простите, парсер. Вобщем элементарные ошибки, которые не на что не влияют в смысле отображения браузерами, и которые убрать 3 секундны.
А где я говорю что стоит? Ткните пожайлуста моей рожей в мое говно, если вас не затруднит.
а я говорю что стоит.
сайт должен быть чистым и красивым, и это показатель профессионализма.
сайт должен быть чистым и красивым, и это показатель профессионализма.
Что тебе это даст? Ну сделаешь ты сайт "чистым и красивым", что изменится? Внешне - ничего. Внутренне - а ты у нас по сайтам в блокноте лазишь? Теги проверяешь? :)
Вот ты дома убираешься хотя бы время от времени? А если к тебе в гости не ходят - в мусоре утонешь?
Есть ещё самоудовлетворение от своего труда. Это важная вещь, я считаю.
Есть ещё самоудовлетворение от своего труда. Это важная вещь, я считаю.
вы это зря самоудовлетворение пропагандируете! да ещё и валидированием кода :)
наш выбор - здоровый секс!
наш выбор - здоровый секс!
Сравнил, блин. Согласись, жить в грязи - явно неприятно, да?
В то же время в интернете с сайтами ты "общаешься" на уровне того, как тебе браузер сайт показывает. Зачем тебе лишний раз лезть в код - если все и так хорошо. Лучше от того, что ты там пару тегов закроешь - не будет никому.
В то же время в интернете с сайтами ты "общаешься" на уровне того, как тебе браузер сайт показывает. Зачем тебе лишний раз лезть в код - если все и так хорошо. Лучше от того, что ты там пару тегов закроешь - не будет никому.
вопрос глупца.
если я ковырну гвоздем дверь машины, хуже она от этого работать не станет, правда?
Вот и орите матом в следующий раз когда вам тачку поцарапают.
если я ковырну гвоздем дверь машины, хуже она от этого работать не станет, правда?
Вот и орите матом в следующий раз когда вам тачку поцарапают.
Зря вы вносите смуту в сознание горе-верстальщиков, автор ;) У них есть двоичное состояние: документ валиден/документ невалиден. Всё. Всякие аттрибуты их не интересуют, им верстать надо :)
Респект за статью
Респект за статью
Как насчет своих DTD, относительно которых валидироваться?
Лично мне все равно больше нравится вещи вроде
Лично мне все равно больше нравится вещи вроде
class="required email-validation"
Есть мнение, что, прежде чем давать советы по валидности HTML, неплохо было бы научиться понимать:
что тэги не бывают закрытыми или не закрытыми;
смысл элемента blockquote, его применение и почему его нельзя применять так, как его применил автор;
что элемент br можно употреблять только в исключительных случаях, а не так, как его употребляет автор;
разницу между элементами pre и code.
что тэги не бывают закрытыми или не закрытыми;
смысл элемента blockquote, его применение и почему его нельзя применять так, как его применил автор;
что элемент br можно употреблять только в исключительных случаях, а не так, как его употребляет автор;
разницу между элементами pre и code.
Отчего же вы не согласны с blockquote? Может автор себя цитировал. ;]
Лчино я тэг <br> не вставлял :) Неужели я должен отчитываться за код хабра? А по принципиальным отличиям логической и физической разметки в HTML я отвечу если нужно. В данном случае я писал статью, а не верстал сайт, и использовал только те тэги которые мне позволили использовать :)
Отчего же вы не согласны с blockquote? Может автор себя цитировал. ;]
Как сказал Тема Лебедев: "Лучший валидатор-браузер"
Я полностью с ним согласен, какой смысл писать валидный код, который будет некорретно отображатся в IE...
Я полностью с ним согласен, какой смысл писать валидный код, который будет некорретно отображатся в IE...
какой смысл писать валидный код, который будет некорретно отображатся в IE...
в таком случае смысла нет.... а вот писать валидный код, коррекно отображающийся в IE — это другое дело (даже за счет подпорок к костылям, но в рамках спецификации)
в таком случае смысла нет.... а вот писать валидный код, коррекно отображающийся в IE — это другое дело (даже за счет подпорок к костылям, но в рамках спецификации)
ACID, ACID2
а у меня FF 2.0.0.3 завалил ACID2
Какое отношение сиснтетический тест на сложные CSS-конструкции имеет к валидности (X)HTML-документа? Горе-эксперты...
а что, не валиден что ли? )))
Его валидность имеет отношение к тому, что не все браузеры могут его пройти? Так зачем ёрничать?
раз Тёма сказал - значит истина
своим умом, без Тёмы, нам до этого никак
своим умом, без Тёмы, нам до этого никак
полностью согласен. сайты мы делаем не для будущей совместимости, а для СЕГОДНЯШНЕГО дня и браузеров.
когда люди не знают, как извратиться, они извращаются подобным образом
да еще и пытаются других уму-разуму поучить
да еще и пытаются других уму-разуму поучить
Эээээ... не забирайте у верстальщиков хлеб)
не хотите напрягаться и писать валидный код — не пишите
зачем других то к этому склонять?
зачем других то к этому склонять?
Согласен. Сайты делаются для сейчас. Всё-равно потом всё снесешь и переделаешь ещё на 100 раз.
Лето на дворе. Забудьте вы о холиворах ради б-га.
Несомненно в избранное. В качестве отличного аргумента в спорах с твердолобиками.
Насчет добавления своих атрибутов, тегов и т.п. — пожалуйста, добавляйте xmlns, и используйте их. Более того, так уже делают те, кто хотят, допустим, вставить математические символы, — они используют MathML (xmlns="http://www.w3.org/1998/Math/MathML").
При этом получается валидный XHTML.
Насчет, элементарных ошибок, которые ни на что не влияют в смысле отображения браузером: совершенно верно; браузеры стали умные, однако есть еще такие вещи, как парсинг XHTML.
Если вы когда-нибудь пробовали парсить невалидный XHTML, а уж тем более HTML, то вы бы всегда после этого были адептом валидной верстки.
Есть ещё такое понятие как web-сервисы, в будущем сервисы должны работать как посредники между запросами и xhtml-страницами, для этого они должны уметь их парспить, для этого они должны быть валидны.
И на последок простейший пример (ну только не из XHTML, а из CSS).
Вот ИЕ просасывал раньше подобные вещи:
margin-left: 5;
Отлично ведь, да? :-) Он думал, что верстальщик ошибся, и добавлял px. В результате получалось:
margin-left: 5px;
Отлично, да вот только в CSS 3.0 появилась такая возможность действительно не указывать единицу измерения, т.е. margin-left: 5; — абсолютная CSS-валидная надпись; да вот только означает она в соответствии с новой спецификацией совсем не 5px.
И получается, что IE сделал медвежью услугу. (Эти несколько предложений ни в коем случае не надо воспринимать как хуление Майкрасофт, сам я с большим уважением отношусь к тому-же .NET ).
Конечно, в определенный период, такая позиция производителей браузеров себя оправдывала. Так же как когда-то существовала куча компиляторов Си. Но потом пришел стандарт ANSI. Это неизбежный процесс развития любого удачного языка/инструмента, каким и является XHTML.
Через несколько лет невалидный XHTML отображаться не будет.
И это всем пойдёт на пользу.
При этом получается валидный XHTML.
Насчет, элементарных ошибок, которые ни на что не влияют в смысле отображения браузером: совершенно верно; браузеры стали умные, однако есть еще такие вещи, как парсинг XHTML.
Если вы когда-нибудь пробовали парсить невалидный XHTML, а уж тем более HTML, то вы бы всегда после этого были адептом валидной верстки.
Есть ещё такое понятие как web-сервисы, в будущем сервисы должны работать как посредники между запросами и xhtml-страницами, для этого они должны уметь их парспить, для этого они должны быть валидны.
И на последок простейший пример (ну только не из XHTML, а из CSS).
Вот ИЕ просасывал раньше подобные вещи:
margin-left: 5;
Отлично ведь, да? :-) Он думал, что верстальщик ошибся, и добавлял px. В результате получалось:
margin-left: 5px;
Отлично, да вот только в CSS 3.0 появилась такая возможность действительно не указывать единицу измерения, т.е. margin-left: 5; — абсолютная CSS-валидная надпись; да вот только означает она в соответствии с новой спецификацией совсем не 5px.
И получается, что IE сделал медвежью услугу. (Эти несколько предложений ни в коем случае не надо воспринимать как хуление Майкрасофт, сам я с большим уважением отношусь к тому-же .NET ).
Конечно, в определенный период, такая позиция производителей браузеров себя оправдывала. Так же как когда-то существовала куча компиляторов Си. Но потом пришел стандарт ANSI. Это неизбежный процесс развития любого удачного языка/инструмента, каким и является XHTML.
Через несколько лет невалидный XHTML отображаться не будет.
И это всем пойдёт на пользу.
Как разработчик web-сервисов полностью с Вами согласен. Раньше я не подозревал как важно писать корректный (X)HTML код. Теперь же выдрачиваю все по спецификации, чтобы другие люди гемороем не страдали, если им придется тем или иным способом обрабатывать мои данные.
mihazimin и gorinich, чтобы парсить XHTML код достаточно чтобы он был well-formed, валидность же не влияет на алгоритм разбора XHTML.
Так то оно так. Но все же валидный код глаз больше радует :) Код должен быть и гибким и красивым одновременно. Такова моя философия. Я все равно буду писать максимально правильно, но при необходимости отойду от стандарта если это поможет сделать более красивое и гибкое решение.
Карме тоже достаточно быть просто положительной, но чем она выше, тем больше глаз радует :) И тем больше возможностей.
Карме тоже достаточно быть просто положительной, но чем она выше, тем больше глаз радует :) И тем больше возможностей.
Отличное мнение.
Вот только все мы подсознательно стремимся сделать все как можно ближе к стандартам. А все с той же целью, чтобы это все как можно лучше отобразилось в как можно большем количестве браузеров.
И потом это личное дело каждого. Я например и за гибкость и за чистоту кода. Если можно написать и так и так, я напишу как правильно. Если я знаю, что параметр height в стандарте не описан и его можно только внутри style (css) написать, то я так и сделаю, мне не сложно. Зато такой код будет понятнее разнообразному софту, т.к. софту проще работать со стандартными данными, а не думать что бы это могло значить.
HTML позволяет безобразничать, но этим не стоит злоупотреблять. XHTML это HTML на XML :) А это значит что он максимально гибок, но и ОЧЕНЬ ТРЕБОВАТЕЛЕН. Если в HTML можно было не закрывать тег, то XHTML этого не позволяет. Но все равно прощает.
Стандарт он для того и есть, чтобы можно было делать все только одним образом.
Просто подумайте о других.
Мне, например, приходится писать всяких роботов, которые смотрят в HTML. Но как объяснить роботу, что бывают дебилы, способные поставить на одной странице 3 тега TITLE и штук 5 вложенных HTML. Поисковики такой страницы побрезгуют :) Хотя такой HTML синтаксически корректен, но может свести с ума не мало софта.
Что-то я разошелся :)
Вот только все мы подсознательно стремимся сделать все как можно ближе к стандартам. А все с той же целью, чтобы это все как можно лучше отобразилось в как можно большем количестве браузеров.
И потом это личное дело каждого. Я например и за гибкость и за чистоту кода. Если можно написать и так и так, я напишу как правильно. Если я знаю, что параметр height в стандарте не описан и его можно только внутри style (css) написать, то я так и сделаю, мне не сложно. Зато такой код будет понятнее разнообразному софту, т.к. софту проще работать со стандартными данными, а не думать что бы это могло значить.
HTML позволяет безобразничать, но этим не стоит злоупотреблять. XHTML это HTML на XML :) А это значит что он максимально гибок, но и ОЧЕНЬ ТРЕБОВАТЕЛЕН. Если в HTML можно было не закрывать тег, то XHTML этого не позволяет. Но все равно прощает.
Стандарт он для того и есть, чтобы можно было делать все только одним образом.
Просто подумайте о других.
Мне, например, приходится писать всяких роботов, которые смотрят в HTML. Но как объяснить роботу, что бывают дебилы, способные поставить на одной странице 3 тега TITLE и штук 5 вложенных HTML. Поисковики такой страницы побрезгуют :) Хотя такой HTML синтаксически корректен, но может свести с ума не мало софта.
Что-то я разошелся :)
Я вот думаю что в момент выхода HTML было допущено большое попустительство. Он был слишком вольным в использовании его синтаксических конструкций. Если бы он разбирался как XML, то сейчас бы было меньше проблем и парсеры-рендереры HTML были бы проще. А сейчас мы имеем то, что имеем. Лично я за стандартизацию, так как это приводит в порядок образ мышления разработчика/верстальщика и делает код понятней для него-же самого. На собственном опыте убедился, что верстать правильно привыкаешь быстро, а когда привыкаешь, то по другому уже не можешь.
за стандартизацию можно бороться только если за тобой большинство, а иначе это будет выглядеть как борьба за мир во всем мире против всего мира.
По моему вполне логично, что для использования такого инструмента, который позволяет делать сложные вещи, требуются люди со специальными навыками. А "школьники" и сейчас верстают, пройдитесь по народ.ру и другим ему подобным :) HTML прост и сейчас, только на простом HTML можно делать исключительно простые вещи :)
Хотите что-либо запороть — сделайте его простым, для школьников.
С бэкендами это уже произошло, и называлось это PHP.
Для школьников есть графические среды, которые скрывают сложность, оставляя валидность.
С бэкендами это уже произошло, и называлось это PHP.
Для школьников есть графические среды, которые скрывают сложность, оставляя валидность.
Бред, валидация кода — это одна из составляющих профессионального подхода к созданию веб страницы. Рассматривать ее отдельно от семантически правильной структуры и корректных имен классов и айдишников и т.п. — в корне неверно.
Вооружитесь палкой и камнями и Вы сможете охотитца на животных!
Это 5!
Я вот тоже всегда считал, что главное, чтобы страница правильно отображалась.
Но все же проверял на валидность для верности.
Я вот тоже всегда считал, что главное, чтобы страница правильно отображалась.
Но все же проверял на валидность для верности.
Ага. А в соседнем топике чувак говорит - "а нафига нужно какое-то ооп? Тоже понапридумывали модных бесполезных фишек. Я вот без всяких оопов херачу и все работает."
Ну, нельзя такие вещи сравнивать.
Всегда есть какие-то задачи, возможно даже поставленные самому себе. Например, если я пишу маленький скриптик для загрузки файлов на сервер для себя, я знаю, что им буду пользоваться только, и никто другой, я напишу его так, чтобы он работал так, как мне нужно. И, скорее всего, я не буду использовать там ооп за ненадобностью. Нет смысла есть суп вилкой, даже признавая весь ее авторитет и гениальность ее изобретения.
А вот если я буду писать навороченную систему типа rapidshare, я буду использовать ооп, потому что это облегчит разработку в дальнейшем, даст более управляемое ядро системы, что позволит сократить издержки на поздних этапах разработки.
Равно и верстка. Если я стремлюсь к тому, чтобы сайт правильно отображался во всех нужных мне броузерах, нужных мне версий, мне плевать на валидность. В то же время, если задачей является написать именно валидный код, то безусловно, его нужно писать валидным.
Например, у нас в компании в стандартах верстки первым пунктом написано: «Код должен быть валиден с точки зрения w3c стандартов». Эта строчка говорит о том, что верстальщик не сдаст работу, пока валидатор не скажет: «ОК».
Что касается непосредственно статьи, то, как мне кажется, нужно четко осознавать, что ты пишешь и для чего ты пишешь. Можно сказать: «html — это всего лишь частный случай xml. Ограниченный, урезанный, нерасширяемый». И это чистая правда. А потом спросить себя, чем я сейчас занимаюсь? Если ответ: «Я занимаюсь html версткой», то другие доводы излишне.
Даже если сравнить текущие вакансии, то в большинстве случаев (возможно даже по незнанию) ищут html-верстальщика. И будут требовать валидной html верстки.
Хотя, с другой стороны, разрабатывая какую-то свою систему, грех не воспользоваться возможностями xhtml. Говоря по-простому, создавать свои теги. Это же мечта с давних лет. Но, к сожалению, пока нельзя использовать это повсеместно, потому что все-таки чаще всего есть заказчик, которому глубоко чихать на технологии, ему важен результат, и чтобы этот результат был корректен даже в его древнем Netscape Navigator'е.
Так что получаем палочку о двух концах. С одной стороны удобно и хорошо, с другой стороны просто нельзя. Не надо кидаться использовать знания, полученные после прочтения статьи. Надо просто спросить себя: «Чем я занимаюсь?», и ответ расставит все на свои места.
Всегда есть какие-то задачи, возможно даже поставленные самому себе. Например, если я пишу маленький скриптик для загрузки файлов на сервер для себя, я знаю, что им буду пользоваться только, и никто другой, я напишу его так, чтобы он работал так, как мне нужно. И, скорее всего, я не буду использовать там ооп за ненадобностью. Нет смысла есть суп вилкой, даже признавая весь ее авторитет и гениальность ее изобретения.
А вот если я буду писать навороченную систему типа rapidshare, я буду использовать ооп, потому что это облегчит разработку в дальнейшем, даст более управляемое ядро системы, что позволит сократить издержки на поздних этапах разработки.
Равно и верстка. Если я стремлюсь к тому, чтобы сайт правильно отображался во всех нужных мне броузерах, нужных мне версий, мне плевать на валидность. В то же время, если задачей является написать именно валидный код, то безусловно, его нужно писать валидным.
Например, у нас в компании в стандартах верстки первым пунктом написано: «Код должен быть валиден с точки зрения w3c стандартов». Эта строчка говорит о том, что верстальщик не сдаст работу, пока валидатор не скажет: «ОК».
Что касается непосредственно статьи, то, как мне кажется, нужно четко осознавать, что ты пишешь и для чего ты пишешь. Можно сказать: «html — это всего лишь частный случай xml. Ограниченный, урезанный, нерасширяемый». И это чистая правда. А потом спросить себя, чем я сейчас занимаюсь? Если ответ: «Я занимаюсь html версткой», то другие доводы излишне.
Даже если сравнить текущие вакансии, то в большинстве случаев (возможно даже по незнанию) ищут html-верстальщика. И будут требовать валидной html верстки.
Хотя, с другой стороны, разрабатывая какую-то свою систему, грех не воспользоваться возможностями xhtml. Говоря по-простому, создавать свои теги. Это же мечта с давних лет. Но, к сожалению, пока нельзя использовать это повсеместно, потому что все-таки чаще всего есть заказчик, которому глубоко чихать на технологии, ему важен результат, и чтобы этот результат был корректен даже в его древнем Netscape Navigator'е.
Так что получаем палочку о двух концах. С одной стороны удобно и хорошо, с другой стороны просто нельзя. Не надо кидаться использовать знания, полученные после прочтения статьи. Надо просто спросить себя: «Чем я занимаюсь?», и ответ расставит все на свои места.
кстати, не факт что ООП является оптимальным выбором. есть ещё как минимум 2 способа программирования кроме процедурного. не помню где, но я видел даже сайт, где разработчики приводили доводы и просили остановить это мировое безумство ООП :)
однако всё же, везде просто нужно чувство меры.
однако всё же, везде просто нужно чувство меры.
Дополнительные "свои" атрибуты - это то, к чему идет xhtml. Если мы немножечко побежим впереди поезда, подстраховавшись DTD, то к глобальному потеплению это не приведет
xhtml идёт совсем к другому. А dtd - это подарок от sgml.
К другому это к чему? Мы сейчас в ракурсе custom-атрибутов дискутируем. А это DTD, и на W3C написано что User DTD фактически поддерживается XTML, вот только браузеры еще об этом не знают.
К другому - это к модульности. Модульность будет позволять задавать для каждого документа свои элементы. Всё очень просто.
Да нет, пожалуй не очень просто...
Свои элементы для каждого документа - и есть DTD или его более поздние XML вариации.
Насколько я сейчас понимаю развитие XHTML, его собираются разбить на модули типа Ядро, Форма, Фрейм и далее.. Но все это опять-же тесно связяно с DTD
Как видно отсюда:
------
XHTML Modularization is a decomposition of XHTML 1.0, and by reference HTML 4, into a collection of abstract modules that provide specific types of functionality. These abstract modules are implemented in this specification using the XML Document Type Definition language, but an implementation using XML Schemas is expected. The rules for defining the abstract modules, and for implementing them using XML DTDs, are also defined in this document.
------
все опять крутится вокруг DTD-подобных схем. А модуляризация - это немного не то.
Свои элементы для каждого документа - и есть DTD или его более поздние XML вариации.
Насколько я сейчас понимаю развитие XHTML, его собираются разбить на модули типа Ядро, Форма, Фрейм и далее.. Но все это опять-же тесно связяно с DTD
Как видно отсюда:
------
XHTML Modularization is a decomposition of XHTML 1.0, and by reference HTML 4, into a collection of abstract modules that provide specific types of functionality. These abstract modules are implemented in this specification using the XML Document Type Definition language, but an implementation using XML Schemas is expected. The rules for defining the abstract modules, and for implementing them using XML DTDs, are also defined in this document.
------
все опять крутится вокруг DTD-подобных схем. А модуляризация - это немного не то.
Нет никакого смысла равняться на идеальный браузер, который понимает только Strict XHTML. Его еще не создали только потому что он никому не нужен и это не самоцель
Создали его давным-давно, http://www.w3.org/Amaya/.
Еще консольный есть, так и называется w3c
окей, пока вы не посылаете свою xhtml-страницу как application/xhtml+xml, браузерам действительно, видимо, все равно, как и что у вас написано. а, скажем, судьба несчастных портативных устройств, не в каждое из которых можно вставить robust html-парсер, вас совсем не волнует?
Зачастую люди пишут HTML даже понятия не имея, как он будет потом превращаться в страничку в браузере. Это проблема "прикладного программиста", который разрабатывает программу в VS.NET или Delphi, не имея представления о памяти, которую она занимает, процессорном времени. Эту работу на себя берет framework. А для веба на данный момент комплексных, доступных для понимания frameworkов как таковых нет. (ASP.NET не берем, он для IE сделан). "Прикладные программисты" были есть и будут, просто им нужен инструмент, такой чтобы не думать.
Валидатор - это не фетиш, а инструмент. И если вы этого не понимаете, то зачем он вам вообще сдался? Забудьте, он совершенно никому не нужен. У нас ведь есть graceful degradation. Мы ведь можем написать свой DTD, правда ведь?
А вообще, создаётся впечатление, что кто-то прочитал статьи Fault-tolerant system и Forward compatibility в Википедии и спешит сделать выводы.
Изящная деградация вовсе не означает, что можно писать что попало.
Этот принцип означает, что ваша, например, xhtml2 страница, будучи прочитана браузером прошлого поколения (или браузером устройства, которое ограничено в возможностях), будет отображаться вполне нормально - только без поддержки некоторых более новых возможностей.
Но, если вы пихнёте браузеру последнего поколения нечто, что должно представлять собой xhtml2 исходя из DTD, а оно вовсе не представляет собой xhtml2 (да и вообще никакой DTD не подходит) - это вовсе не изящная деградация, а невалидный документ.
И эту разницу необходимо для начала понимать.
А вообще, создаётся впечатление, что кто-то прочитал статьи Fault-tolerant system и Forward compatibility в Википедии и спешит сделать выводы.
Изящная деградация вовсе не означает, что можно писать что попало.
Этот принцип означает, что ваша, например, xhtml2 страница, будучи прочитана браузером прошлого поколения (или браузером устройства, которое ограничено в возможностях), будет отображаться вполне нормально - только без поддержки некоторых более новых возможностей.
Но, если вы пихнёте браузеру последнего поколения нечто, что должно представлять собой xhtml2 исходя из DTD, а оно вовсе не представляет собой xhtml2 (да и вообще никакой DTD не подходит) - это вовсе не изящная деградация, а невалидный документ.
И эту разницу необходимо для начала понимать.
Верстая валидно, вы упрощаете жизнь самому себе — легче искать ошибки.
На самом деле, мне кажется, правильный подход как всегда где-то посередине. То есть, правильно сверстанные документы — это хорошо, с ними легче работать машинам и, возможно, тем, кто будет разбирать ваш код потом. Но, по-моему, не стоит делать из этого священную корову. Если есть возможность сделать правильно, лучше сделать правильно, но при этом не стоит зацикливаться на валидном, но не практичном решении. Вот.
Валидность верстки - показатель культуры разработчиков.
Зачем гадать в стиле "что будет если", когда есть промышленные стандарты?
Профессионалы пользуются промышленными стандартами и спецификациями, соблюдает их. Все остальные могут писать "просто чтобы работало"
Зачем гадать в стиле "что будет если", когда есть промышленные стандарты?
Профессионалы пользуются промышленными стандартами и спецификациями, соблюдает их. Все остальные могут писать "просто чтобы работало"
не соображу.
Написал
Потом запускаю alert(document.forms.MF.Code.privet);
а он мне, гад, undefined показывает.
В чем прикол?
Написал
Потом запускаю alert(document.forms.MF.Code.privet);
а он мне, гад, undefined показывает.
В чем прикол?
приведу простой пример, почему я проверяю на валидность весь код. я делаю странички для wap'a а там если проверил на валидность - считай перестраховался, каждый телефон рендрит странички со своими глюками: nokia плохо понимает таблицы, кто-то еще не понимает частями css (речь идет о встроенных в мобильник браузерах)
и когда валидатор показал зеленый свет, можно на половину взхдохнуть спокойно… а потом уже смотрятся индивидуальные погрешности на телефонах
и когда валидатор показал зеленый свет, можно на половину взхдохнуть спокойно… а потом уже смотрятся индивидуальные погрешности на телефонах
Касательно валидации - см. http://www.habrahabr.ru/blog/webdev/1335…
Насчёт кастомных атрибутов - думаю, что в них нет совершенно никакой необходимости. HTML предназначен для описания структуры, семантики документа. А вот для того, что относится к его поведению, используется JavaScript.
Примешивание того, что касается сугубо JS-функциональности, к HTML-коду, в той же мере ошибочно, что и использование таблиц для разметки, spacer-картинок и font-тегов. Это нарушает разделение функций в front-end-технологиях, создаёт кашу и существенно вредит поддерживаемости и гибкости кода. Конечно, это классно работает как эдакий "quick hack", но не более.
Насчёт кастомных атрибутов - думаю, что в них нет совершенно никакой необходимости. HTML предназначен для описания структуры, семантики документа. А вот для того, что относится к его поведению, используется JavaScript.
Примешивание того, что касается сугубо JS-функциональности, к HTML-коду, в той же мере ошибочно, что и использование таблиц для разметки, spacer-картинок и font-тегов. Это нарушает разделение функций в front-end-технологиях, создаёт кашу и существенно вредит поддерживаемости и гибкости кода. Конечно, это классно работает как эдакий "quick hack", но не более.
По вашему аттрибут required вообще не описывает "структуру, семантику документа"? И о каких quick hack вы говорите? Все эти новые "кастомные" невалидные (в xHTML) аттрибуты которые привел я описаны в спецификации Web Forms 2.0, но дело даже не в этом, это я просто чтобы показать что вы даже в этом не правы. Если бы даже не было никакого required он бы должен был появиться (но не благодаря вам, к сожалению).
>По вашему аттрибут required вообще не описывает "структуру, семантику документа"?
Именно так. Это чисто серверная логика (в данном случае приукрашенная на стороне клиента с помощью JS). Она не имеет никакого отношения к семантике документа.
Хотите доказательство? Зайдите на страничку с отключённым JS. Или с мобильного устройства. Или даже скрин ридером. Какой смысл тогда будет иметь этот атрибут? Никакого. Это чисто вспомогательное средство для вашей JS-функциональности, она же в свою очередь поддерживает именно серверную логику (иначе приложение было бы инсекьюрным).
Спецификация Web Forms, видимо, берёт часть серверной логики на себя для упрощения разработки, но о ней сейчас речи не идёт. Мы говорим о (X)HTML. Так что неправы именно вы - признайте это.
Именно так. Это чисто серверная логика (в данном случае приукрашенная на стороне клиента с помощью JS). Она не имеет никакого отношения к семантике документа.
Хотите доказательство? Зайдите на страничку с отключённым JS. Или с мобильного устройства. Или даже скрин ридером. Какой смысл тогда будет иметь этот атрибут? Никакого. Это чисто вспомогательное средство для вашей JS-функциональности, она же в свою очередь поддерживает именно серверную логику (иначе приложение было бы инсекьюрным).
Спецификация Web Forms, видимо, берёт часть серверной логики на себя для упрощения разработки, но о ней сейчас речи не идёт. Мы говорим о (X)HTML. Так что неправы именно вы - признайте это.
Кстати, вы по всей видимости дублируете валидационную логику, описывая ее как на клиентской, и на серверной стороне. Это очень плохая практика в программировании, не говоря уже о стандартах. При малейшем изменении логики вам придётся ее менять в лучшем случае в двух местах (HTML, серверный код) и в худшем аж в трёх (HTML, сервер и JS в случае сложной валидации).
Хорошая практика программирования подразумевает, что изменения требуются лишь в одном. А что, если ваш код придётся поддерживать другому человеку? Он же обматюкает вас так, как вы себе и представить не можете.
Хорошая практика программирования подразумевает, что изменения требуются лишь в одном. А что, если ваш код придётся поддерживать другому человеку? Он же обматюкает вас так, как вы себе и представить не можете.
Холивор рулит. Валидация - примерно такая же священная тема как Linux vs Others.
В поддержку автора:
1. X в XHTML означает eXtensible ("расширяемый"). Глупо при таком наименовании наглухо закрывать перечень тэгов и атрибутов, которые позволительно использовать. Чего, по-моему, W3С и не делал.
2. JavaScript, именем которого уже намахались в ходе текущего холивора, практически никак не ограничивает программиста в расширении уже существующих объектов - любому из них (даже не вашему, например, document) - вы можете прикрутить любой метод или поле, какие вам только нужны. Можете поменять саму структуру документа через DOM (сделав исходно валидный документ невалидным в памяти браузера в runtime). Здесь почему-то такого фанатизма не наблюдается, никто не старается накатать самый валидный JS, в котором используются исключительно идентификаторы, одобренные W3C и внесенные в стандарты. Пишут как попало, а ведь это сложнее потом отлаживать и поддерживать, чем невалидный XHTML. И ошибок, как следствие, такой код порождает больше. Не о том воюете, граждане.
3. CSS содержит стандартный перечень свойств, расширяя который, вы ничего не добьетесь (многие начинающие выдумывают что-то типа "valign: top" или "font-color: red"). Но вот метод построения СЕЛЕКТОРОВ CSS позволяет выбирать ничем не ограниченный перечень тегов и их свойств, что еще раз говорит об идеи расширяемости, заложенной в стандарты. Еще раз задумайтесь: невалидный (в том смысле, который оговорен в этом хабрапосте) XHTML можно «подпереть» соответствующим CSS - и всё будет работать, потому что об этом думали, когда создавали стандарты.
В поддержку автора:
1. X в XHTML означает eXtensible ("расширяемый"). Глупо при таком наименовании наглухо закрывать перечень тэгов и атрибутов, которые позволительно использовать. Чего, по-моему, W3С и не делал.
2. JavaScript, именем которого уже намахались в ходе текущего холивора, практически никак не ограничивает программиста в расширении уже существующих объектов - любому из них (даже не вашему, например, document) - вы можете прикрутить любой метод или поле, какие вам только нужны. Можете поменять саму структуру документа через DOM (сделав исходно валидный документ невалидным в памяти браузера в runtime). Здесь почему-то такого фанатизма не наблюдается, никто не старается накатать самый валидный JS, в котором используются исключительно идентификаторы, одобренные W3C и внесенные в стандарты. Пишут как попало, а ведь это сложнее потом отлаживать и поддерживать, чем невалидный XHTML. И ошибок, как следствие, такой код порождает больше. Не о том воюете, граждане.
3. CSS содержит стандартный перечень свойств, расширяя который, вы ничего не добьетесь (многие начинающие выдумывают что-то типа "valign: top" или "font-color: red"). Но вот метод построения СЕЛЕКТОРОВ CSS позволяет выбирать ничем не ограниченный перечень тегов и их свойств, что еще раз говорит об идеи расширяемости, заложенной в стандарты. Еще раз задумайтесь: невалидный (в том смысле, который оговорен в этом хабрапосте) XHTML можно «подпереть» соответствующим CSS - и всё будет работать, потому что об этом думали, когда создавали стандарты.
путаете понятия, гражданин! =)
читайте комменты и статью. здесь вообще не идет речь об XHTML или HTML, она идет здесь ;) http://www.habrahabr.ru/blog/webdev/1254… , а в данной заметке речь идет о валидации. а про расширяемость без ущерба валидности уже ответили выше
кстати, font-color: red абсолютно правильная конструкция =)
а вот тут что-то непонятно, что вы хотели сказать? о какой расширяемости средствами CSS?? каскад не есть расширяемость, это просто способ применения что ли...
читайте комменты и статью. здесь вообще не идет речь об XHTML или HTML, она идет здесь ;) http://www.habrahabr.ru/blog/webdev/1254… , а в данной заметке речь идет о валидации. а про расширяемость без ущерба валидности уже ответили выше
Насчет добавления своих атрибутов, тегов и т.п. — пожалуйста, добавляйте xmlns, и используйте их. Более того, так уже делают те, кто хотят, допустим, вставить математические символы, — они используют MathML (xmlns="http://www.w3.org/1998/Math/MathML").
При этом получается валидный XHTML.
Насчет, элементарных ошибок, которые ни на что не влияют в смысле отображения браузером: совершенно верно; браузеры стали умные, однако есть еще такие вещи, как парсинг XHTML.
Если вы когда-нибудь пробовали парсить невалидный XHTML, а уж тем более HTML, то вы бы всегда после этого были адептом валидной верстки.
Есть ещё такое понятие как web-сервисы, в будущем сервисы должны работать как посредники между запросами и xhtml-страницами, для этого они должны уметь их парспить, для этого они должны быть валидны.
И на последок простейший пример (ну только не из XHTML, а из CSS).
Вот ИЕ просасывал раньше подобные вещи:
margin-left: 5;
Отлично ведь, да? :-) Он думал, что верстальщик ошибся, и добавлял px. В результате получалось:
margin-left: 5px;
Отлично, да вот только в CSS 3.0 появилась такая возможность действительно не указывать единицу измерения, т.е. margin-left: 5; — абсолютная CSS-валидная надпись; да вот только означает она в соответствии с новой спецификацией совсем не 5px.
И получается, что IE сделал медвежью услугу. (Эти несколько предложений ни в коем случае не надо воспринимать как хуление Майкрасофт, сам я с большим уважением отношусь к тому-же .NET ).
Конечно, в определенный период, такая позиция производителей браузеров себя оправдывала. Так же как когда-то существовала куча компиляторов Си. Но потом пришел стандарт ANSI. Это неизбежный процесс развития любого удачного языка/инструмента, каким и является XHTML.
Через несколько лет невалидный XHTML отображаться не будет.
И это всем пойдёт на пользу.
кстати, font-color: red абсолютно правильная конструкция =)
Но вот метод построения СЕЛЕКТОРОВ CSS позволяет выбирать ничем не ограниченный перечень тегов и их свойств, что еще раз говорит об идеи расширяемости, заложенной в стандарты. Еще раз задумайтесь: невалидный (в том смысле, который оговорен в этом хабрапосте) XHTML можно «подпереть» соответствующим CSS - и всё будет работать, потому что об этом думали, когда создавали стандарты.
а вот тут что-то непонятно, что вы хотели сказать? о какой расширяемости средствами CSS?? каскад не есть расширяемость, это просто способ применения что ли...
1. font-color: red не сработает. Поверьте профессиональному верстальщику или попробуйте сами. Сработает color: red;
2. Статью я прочел и комменты тоже. Потом написал свой. Речь в статье и моем комменте идет о том, что расширение XHTML собственными атрибутами в ущерб валидации - не такая фатальная вещь, и стандарты писали с оглядкой на такую возможность. Браузеры не станут отклонять невалидный код НИКОГДА, как они не делали этого до нынешнего момента (для их удобства, например, ввели DOCTYPE, чтобы они могли ЛУЧШЕ отображать новый код, соответсвующий стандартам, и сносно выводить УСТАРЕВШИЙ код, стандартам не подчинявшийся).
3. E[foo], E[foo="warning"], E[foo~="warning"]. Поищите этот код в спецификации CSS2, и вы поймете тот участок моего коммента, который еще не поняли.
2. Статью я прочел и комменты тоже. Потом написал свой. Речь в статье и моем комменте идет о том, что расширение XHTML собственными атрибутами в ущерб валидации - не такая фатальная вещь, и стандарты писали с оглядкой на такую возможность. Браузеры не станут отклонять невалидный код НИКОГДА, как они не делали этого до нынешнего момента (для их удобства, например, ввели DOCTYPE, чтобы они могли ЛУЧШЕ отображать новый код, соответсвующий стандартам, и сносно выводить УСТАРЕВШИЙ код, стандартам не подчинявшийся).
3. E[foo], E[foo="warning"], E[foo~="warning"]. Поищите этот код в спецификации CSS2, и вы поймете тот участок моего коммента, который еще не поняли.
1. упппс. сорри. вы правы, коллега, это я вчера в офисе перегрелся, я тоеже профессиональный верстальщик =)
2. не согласен, может мои надежды слишком утопичны? =)
3. это есть CSS3, если я не ошибаюсь. это выборка элемента по шаблону его атрибута, но я не считаю это расширением каким-то, это гибкость в рамках стандарта.
2. не согласен, может мои надежды слишком утопичны? =)
3. это есть CSS3, если я не ошибаюсь. это выборка элемента по шаблону его атрибута, но я не считаю это расширением каким-то, это гибкость в рамках стандарта.
кстати, интересный парадокс. по комментам и минусованию "неверных" =) видно, что большинство людей обсуждающих заметку за стандарты. однако статья, которая эти стандарты попирает получает 37 баллов.
совсем недавно я опубликовал статью об одном конкретном стандарте http://www.habrahabr.ru/blog/webdev/1254… собирает в комментах мало приверженцев стандартов и получает всего 17 баллов. статью писал я. ничего личного конечно. но непонятна логика.
совсем недавно я опубликовал статью об одном конкретном стандарте http://www.habrahabr.ru/blog/webdev/1254… собирает в комментах мало приверженцев стандартов и получает всего 17 баллов. статью писал я. ничего личного конечно. но непонятна логика.
На правильных микроволновках должны стоять правильные ОС и правильны браузеры...
Написано много, но не написано "почему". С какой стати мой аттрибут "required" вдруг все всем поломает? :)
Спасибо за ссылки, но проходили все это, и верстали валидно (ну вот только не тряслись над этим) и теперь видим ясно что смысл был вовсе не в том чтобы не придумывать свои аттрибуты.
Спасибо за ссылки, но проходили все это, и верстали валидно (ну вот только не тряслись над этим) и теперь видим ясно что смысл был вовсе не в том чтобы не придумывать свои аттрибуты.
1. Решить задачу написать валидатор форм в стиле Web Forms 2.0 не используя предлагаемые аттрибуты, а используя только class можно, но будет странно задавать всё всё всё (тип, разрешенные символы, проверочный шаблон, минимальная длина, многое другое) в поле, которое предназначено не для этого.
2. С моими (!) аттрибутами роботы работать не должны :) о браузерах (с JS) я сам позабочусь. Без JS работать все будет тоже, но без поддержки этих вкусных аттрибутов.
3. Вот единственная здравая мысль, но для этого можно следить за выходом новых спецификаций и не допускать конфликта.
"Нет ничего страшного" это введение, первый шаг, на самом деле это очень даже полезно, подумать к чему такая строгость, которая вовсе не к тому чтобы не изобретать новое. Плюсы по-моему видны в том маленьком кусочке XHTML что я привел. Если его описать валидно, то будет не так просто и очевидно.
2. С моими (!) аттрибутами роботы работать не должны :) о браузерах (с JS) я сам позабочусь. Без JS работать все будет тоже, но без поддержки этих вкусных аттрибутов.
3. Вот единственная здравая мысль, но для этого можно следить за выходом новых спецификаций и не допускать конфликта.
"Нет ничего страшного" это введение, первый шаг, на самом деле это очень даже полезно, подумать к чему такая строгость, которая вовсе не к тому чтобы не изобретать новое. Плюсы по-моему видны в том маленьком кусочке XHTML что я привел. Если его описать валидно, то будет не так просто и очевидно.
"Ваши" атрибуты могут вступить в конфликт с будущими версиями разметочного стандарта, что тогда? Правильно - на переделку.
Ну, даже просто HTML в новых версиях может измениться так, что ваш код будет невалиден. <b>? Но если у вас стоит DTD старой версии, то почему браузер должен натягивать новые аттрибуты?
1) Почему спустя рукава? Если в HTML 78.01 вдруг появляется атрибут "фигня", то почему браузеры будут его применять к моему коду с HTML DTD 4.01, где я использую свой атрибут "фигня"? Это HTML 4!
2) У меня возражения только по одному из пунктов :) Но если хотите:
3)
Это вообще никакой не аргумент. Мождо ещё и на Flash сделать всю страницу, но это ни о чём не говорит.
4)
Как сказал denver, не должны!
2) У меня возражения только по одному из пунктов :) Но если хотите:
3)
Поставленные задачи можно разрешить иначе.
Это вообще никакой не аргумент. Мождо ещё и на Flash сделать всю страницу, но это ни о чём не говорит.
4)
Каким образом с вашими атрибутами должны работать роботы, браузеры, вам в радость доставлять проблемы их разработчикам и тем тормозить развитие вэба?
Как сказал denver, не должны!
все равно все зависит от конкретной задачи, времени, бюджетности проекта наконец.
если пишется публичный веб-сервис, претендующий на широкую популярность - нужна валидность, чтобы его удобно было обрабатывать всякими парсерами, ридерами, была возможность безболезненного усовершенствования и так далее.
но опять же все зависит и от того, актуально ли это в данный момент. может проект пилотный, для обтачивания каких-то услуг, юзабилити и т.п. чтобы вслед за ним выпустить что-то уже более "релизное".
и если пишется какой-то небольшой сайтик, ориентированный на информирование достаточно узкой целевой группы, время на него и его оплата ограничены - то тратить это время на валидность в ущерб времени на дизайн или доп.функционал уже банально нерентабельно.
все неоднозначно.
если пишется публичный веб-сервис, претендующий на широкую популярность - нужна валидность, чтобы его удобно было обрабатывать всякими парсерами, ридерами, была возможность безболезненного усовершенствования и так далее.
но опять же все зависит и от того, актуально ли это в данный момент. может проект пилотный, для обтачивания каких-то услуг, юзабилити и т.п. чтобы вслед за ним выпустить что-то уже более "релизное".
и если пишется какой-то небольшой сайтик, ориентированный на информирование достаточно узкой целевой группы, время на него и его оплата ограничены - то тратить это время на валидность в ущерб времени на дизайн или доп.функционал уже банально нерентабельно.
все неоднозначно.
нужна валидность, чтобы его удобно было обрабатывать всякими парсерами, ридерамиА чем отсутствие валидности мешает парсерам?
я могу ошибаться в терминологии - но траблы бывают )
например при выводе каких-то партнерских блоков/лент на страницы других сайтов. мне приходится обрамлять этот блок дополнительными стилями (а не просто вставить код как предлагают ресурсы), потому что иначе периодически сайт разрывает то из-за длинных ссылок в этом блоке, или потому что в разных браузерах получаются разные отступы, ширина или еще по какой-то причине.
это не совсем подходящий пример для парсеров. но на вскидку сейчас не могу вспомнить :(
то есть проблема совместимости бывает, и в случае создания публичных сервисов все-таки IMHO нужно стремиться к каким-то общим стандартам.
например при выводе каких-то партнерских блоков/лент на страницы других сайтов. мне приходится обрамлять этот блок дополнительными стилями (а не просто вставить код как предлагают ресурсы), потому что иначе периодически сайт разрывает то из-за длинных ссылок в этом блоке, или потому что в разных браузерах получаются разные отступы, ширина или еще по какой-то причине.
это не совсем подходящий пример для парсеров. но на вскидку сейчас не могу вспомнить :(
то есть проблема совместимости бывает, и в случае создания публичных сервисов все-таки IMHO нужно стремиться к каким-то общим стандартам.
Все комменты не прочел, но все что у автора: - где то в школе чего-то недодали...
Попробую перевести на понятное:
Грамотно писать по Русски - глупо.
Нафиг писать по Русски правильно? Давайте везде писать в стиле медведа.
Зачем все пишут непонятно? Давайте перепишем конституцию и законы по понятиям(в натуре).
Зачем ставить запятые и знаки препинания? Давайте будем побльше лепить смайлы и рисовать картинки в текстах, придумаем свои буквы, никто не знает, зато круто.
Зачем вообще нужно писать правильно кто нибудь приведёт веские доводы?
Попробую перевести на понятное:
Грамотно писать по Русски - глупо.
Нафиг писать по Русски правильно? Давайте везде писать в стиле медведа.
Зачем все пишут непонятно? Давайте перепишем конституцию и законы по понятиям(в натуре).
Зачем ставить запятые и знаки препинания? Давайте будем побльше лепить смайлы и рисовать картинки в текстах, придумаем свои буквы, никто не знает, зато круто.
Зачем вообще нужно писать правильно кто нибудь приведёт веские доводы?
В своей статье кфшатиный автор призывает к укричутию пралмы. Некоторые вракувиты могли бы удивиться, — зачем хтамам лавтарсно иропиться? Но при более щегатом прочтении всем было бы садульно, что предложенная концепция является полной ухнёй.
(В этом тексте я использовал некоторые расширения русского языка, которые могут быть не поняты некоторыми читателями. Тем не менее, они понятны для меня, и в дальнейшем они могли бы быть понятны более широкому кругу читателей, если их включат в словари. Но вы не волнуйтесь, вы можете игнорировать непонятные слова.)
(В этом тексте я использовал некоторые расширения русского языка, которые могут быть не поняты некоторыми читателями. Тем не менее, они понятны для меня, и в дальнейшем они могли бы быть понятны более широкому кругу читателей, если их включат в словари. Но вы не волнуйтесь, вы можете игнорировать непонятные слова.)
Метод аналогий - худший из существующих)
Прошло почти два года с момента публикации статьи — а она даже более чем актуальна.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Валидация HTML — миф