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