Зашел тут один спор по поводу стандартов. А в частности web стандартов и горячо мной любимого w3c.
Кто вдруг не знает (как я с ужасом выясняю, довольно многие этого не знают), этот консорциум ответственен за стандарты HTML и около него, XML и около него. И не только.
Суть проблемы вот в чем. Не все браузеры корректно отображают сайты и прочие веб радости или не отображают их вовсе.И надо с этим что то делать. Причин тому может быть несколько.
Одна из них (наиболее популярная в сети, но не фатальная, по причинам, изложенным ниже) – код написан левой ногой, и не валиден. Не фатальна она в случае с HTML (коего пока что большинство), в стандарте не слишком в свое время озаботились вопросом, а что же делать если оно… ну не то чтобы совсем плохо, а так, слегка неправильно. Поэтому браузеры отрабатывают этот момент по разному: игнорируют или пытаются исправить ( иногда успешно, к примеру, код <i><b>текст</i></b> в IE таки покажет вам жирный курсив, хотя вместо вложенности теги перемешаны). Но в любом случае не информирует об этом пользователя (того же разработчика на этапе написания кода). Поэтому сейчас мы имеем огромное множество сайтов, написанных некорректно. Это раз.
Если в этом ключе обратиться к XML, то можно увидеть что ребята (w3c) таки учатся на своих ошибках. Нормальные (соответствующие спецификации) парсеры XML никогда вам не покажут невалидный код, зато точно скажут, какой именно символ им не понравился (а некоторые… нет, не попытаются исправить, просто порекомендуют решение). А все потому, что спецификация все это учитывает. В итоге – ни одного невалидного сайта на XML XSLT я не видел (я, правда, их вообще не очень-то много видел). И в том числе и по этому сейчас w3c рекомендует XHTML где эти грабли устранены.
Но это все про серверную часть. На клиентской тоже есть проблемы. Далеко не все браузеры поддерживают спецификации того же HTML + CSS в полном объеме (особенно 3й CSS). Видимо, они просто не успевают угнаться за новыми версиями, производящимися w3c. А в связи с появляющимся стойким желанием угнаться, видимо (а то, ведь если фирма заявит, что только их продукт поддерживает вот эти вот «синие бантики в горошек», то к ним пойдут люди и понесут им деньги), забывают закрыть старые недоработки и очень мелкие недоделки (особенность мелких недоделок – они всегда проявляются в самый неподходящий момент). Также еще (сейчас я беру камень и несу его в сторону огорода Мелкоsoft) некоторые фирмы считают просто не столь важным это исправлять, мол, задачки и поважнее есть. Я думаю не стоит упоминать, что веб разработчики пытаются пользоваться новшествами по мере выхода спецификаций, а не обновления браузеров. Посему в части HTML тут разброд и шатание (стоит только зайти на хороший сайт по верстке и вы там увидите кучу таких сносочек – что это, мол, хорошо, но вот тут не работает, на плохом не увидите, но работать оно от этого не станет). В XML опять же все стойко – стандарт так хитро закручен, что все или ничего (ну по крайней мере по сравнению с HTML).
Это все было лирическое вступление (которое, по моему мнению, должно таки помочь понять идею). Суть спора:
То есть было предложено сделать такое подмножество стандарта, которое бы закрывало глаза на ошибки в коде, которые не повлияют на отображение (возможно, они будут исправлены), и говорило, что где не будет работать (в том числе из верного кода). Это даже не подмножество, а какое-то междумножество – частично «под», частично «над».
В этом есть здравая идея в том моменте, что этот валидатор должен в силу своего определения находить новые реализации в коде спецификаций не реализованных в браузере. То есть ограждать продвижение технологии вверх. Тогда разработчик (у которого к примеру IE7) будет точно знать, что его творение будет так же смотреться на IE5. На текущий момент это реализуется установкой на машине разработчика нескольких браузеров и тестирования во всех сразу.
С другой стороны такой валидатор будет отсекать возможно нужные или не ненужные(в классической спецификации) куски кода, так как конкретный браузер их не поймет и заругается на них. То есть классически верный код будет неверен в специфическом валидаторе. Вот это в корне неверно.
Далее. Несколько абстрактных измышлений по этому поводу.
Во-первых, кто будет этим всем заниматься. Этих браузеров более десятка, отслеживать их (если этим заняться w3c) это издевательство. Сами фирмы этим заниматься не будут – им еще дырки в реализации спецификации латать и латать.
Во-вторых, это приведет к размыванию стандартов. Уже сейчас, при едином стандарте есть сайты написанные, к примеру, под IE. Когда такие валидаторы появятся – это только усугубит ситуацию, так как узаконит такое деление. И следом в разных направлениях расползутся стандарты этих валидаторов, так как будут сделаны какие-то допущения то там, то тут. И на благо развитию общей идеи это не пойдет.
В-третьих, пример из жизни. Появилась идея сделать HTML динамичным, и придумали JavaScript (это не Java). После чего он развивался. Но развивался как амеба – на разных браузерах в свои стороны. И в итоге – простой скрипт вы напишете легко, а вот чуть копнуть поглубже – и одни и те же свойства лежат в разных объектах. И приходится по наличию тех или иных объектов выяснять на месте какой это браузер – и для него уже запускать специально написанный код. То есть один и тот же алгоритм приходится писать 2 (а то и 3) раза для разных браузеров, чтоб не ограничивать пользователей. Собственно что и ожидалось при такой идеологии.
Невыполнение стандартов ведет к гибели стандарта.
Кто вдруг не знает (как я с ужасом выясняю, довольно многие этого не знают), этот консорциум ответственен за стандарты HTML и около него, XML и около него. И не только.
Суть проблемы вот в чем. Не все браузеры корректно отображают сайты и прочие веб радости или не отображают их вовсе.И надо с этим что то делать. Причин тому может быть несколько.
Одна из них (наиболее популярная в сети, но не фатальная, по причинам, изложенным ниже) – код написан левой ногой, и не валиден. Не фатальна она в случае с HTML (коего пока что большинство), в стандарте не слишком в свое время озаботились вопросом, а что же делать если оно… ну не то чтобы совсем плохо, а так, слегка неправильно. Поэтому браузеры отрабатывают этот момент по разному: игнорируют или пытаются исправить ( иногда успешно, к примеру, код <i><b>текст</i></b> в IE таки покажет вам жирный курсив, хотя вместо вложенности теги перемешаны). Но в любом случае не информирует об этом пользователя (того же разработчика на этапе написания кода). Поэтому сейчас мы имеем огромное множество сайтов, написанных некорректно. Это раз.
Если в этом ключе обратиться к XML, то можно увидеть что ребята (w3c) таки учатся на своих ошибках. Нормальные (соответствующие спецификации) парсеры XML никогда вам не покажут невалидный код, зато точно скажут, какой именно символ им не понравился (а некоторые… нет, не попытаются исправить, просто порекомендуют решение). А все потому, что спецификация все это учитывает. В итоге – ни одного невалидного сайта на XML XSLT я не видел (я, правда, их вообще не очень-то много видел). И в том числе и по этому сейчас w3c рекомендует XHTML где эти грабли устранены.
Но это все про серверную часть. На клиентской тоже есть проблемы. Далеко не все браузеры поддерживают спецификации того же HTML + CSS в полном объеме (особенно 3й CSS). Видимо, они просто не успевают угнаться за новыми версиями, производящимися w3c. А в связи с появляющимся стойким желанием угнаться, видимо (а то, ведь если фирма заявит, что только их продукт поддерживает вот эти вот «синие бантики в горошек», то к ним пойдут люди и понесут им деньги), забывают закрыть старые недоработки и очень мелкие недоделки (особенность мелких недоделок – они всегда проявляются в самый неподходящий момент). Также еще (сейчас я беру камень и несу его в сторону огорода Мелкоsoft) некоторые фирмы считают просто не столь важным это исправлять, мол, задачки и поважнее есть. Я думаю не стоит упоминать, что веб разработчики пытаются пользоваться новшествами по мере выхода спецификаций, а не обновления браузеров. Посему в части HTML тут разброд и шатание (стоит только зайти на хороший сайт по верстке и вы там увидите кучу таких сносочек – что это, мол, хорошо, но вот тут не работает, на плохом не увидите, но работать оно от этого не станет). В XML опять же все стойко – стандарт так хитро закручен, что все или ничего (ну по крайней мере по сравнению с HTML).
Это все было лирическое вступление (которое, по моему мнению, должно таки помочь понять идею). Суть спора:
| стандарты — это хорошо, но если бы валидатор проверял совместимость с конкретными браузерами, было бы лучше и полезнее | vs | только стандарты, и никаких исключений (позиция автора) |
То есть было предложено сделать такое подмножество стандарта, которое бы закрывало глаза на ошибки в коде, которые не повлияют на отображение (возможно, они будут исправлены), и говорило, что где не будет работать (в том числе из верного кода). Это даже не подмножество, а какое-то междумножество – частично «под», частично «над».
В этом есть здравая идея в том моменте, что этот валидатор должен в силу своего определения находить новые реализации в коде спецификаций не реализованных в браузере. То есть ограждать продвижение технологии вверх. Тогда разработчик (у которого к примеру IE7) будет точно знать, что его творение будет так же смотреться на IE5. На текущий момент это реализуется установкой на машине разработчика нескольких браузеров и тестирования во всех сразу.
С другой стороны такой валидатор будет отсекать возможно нужные или не ненужные(в классической спецификации) куски кода, так как конкретный браузер их не поймет и заругается на них. То есть классически верный код будет неверен в специфическом валидаторе. Вот это в корне неверно.
Далее. Несколько абстрактных измышлений по этому поводу.
Во-первых, кто будет этим всем заниматься. Этих браузеров более десятка, отслеживать их (если этим заняться w3c) это издевательство. Сами фирмы этим заниматься не будут – им еще дырки в реализации спецификации латать и латать.
Во-вторых, это приведет к размыванию стандартов. Уже сейчас, при едином стандарте есть сайты написанные, к примеру, под IE. Когда такие валидаторы появятся – это только усугубит ситуацию, так как узаконит такое деление. И следом в разных направлениях расползутся стандарты этих валидаторов, так как будут сделаны какие-то допущения то там, то тут. И на благо развитию общей идеи это не пойдет.
В-третьих, пример из жизни. Появилась идея сделать HTML динамичным, и придумали JavaScript (это не Java). После чего он развивался. Но развивался как амеба – на разных браузерах в свои стороны. И в итоге – простой скрипт вы напишете легко, а вот чуть копнуть поглубже – и одни и те же свойства лежат в разных объектах. И приходится по наличию тех или иных объектов выяснять на месте какой это браузер – и для него уже запускать специально написанный код. То есть один и тот же алгоритм приходится писать 2 (а то и 3) раза для разных браузеров, чтоб не ограничивать пользователей. Собственно что и ожидалось при такой идеологии.
Невыполнение стандартов ведет к гибели стандарта.
