Несколько лет назад Joe Clark в известной статье написал следующее:

Если ваш сайт содержит валидный код или что-нибудь тривиально подобное валидному коду, Вы работаете в соответствии с веб стандартами

Если вы подаете суп только из одних тэгов или документ с огромным количеством ошибок, Вы однозначно используете CSS макет. Здесь нет сомнений, и вопрос решен однозначно.

Ровно год спустя, Doug Bowman дал другое определение (выделительный шрифт — мои слова):

Мы больше не выставляем напоказ ошибки валидации при редизайне. Мы знаем, что валидный сайт это всего лишь очень маленькая составляющая успеха. Валидация это только что, я делаю в своей работе сейчас.

Итак, мы имеем два хорошо всем известных стандартных подхода, для каждого из которых автор этой статьи сделал очень много продвигая их в жизнь. Теперь каждый из них по своему подходит к валидации и его роли в современном веб дизайне. Фактически они в полной мере представляют разделение, которое существует в рядах защитников стандартов. Возможно, и Вы займете одну из следующих сторон:

1. Бескомпромиссная позиция, справедливо утверждая, что если мы перестанем следовать правилам, мы создаем что-то совершенно другое и соответственно невалидное.
2. Прагматический взгляд, так же справедливо утверждая, что невалидный код, который будет сгенерирован поломанными тулзами и код написанный сторонними лицами не должен свести на нет общую приверженность веб стандартам.

И если оба эти подхода правильные, то куда мы придем?

Вот такая проблема

Все согласятся со мной, что создание сайтов, соответствующих стандартам задача достаточно сложная. Если CMS заказчика, старые визуальные WYSIWYG редакторы, сторонний рекламный код делают документы невалидными, различные элементы сайта начинают выглядеть убого, что наводит на размышления, о том что требование валидации больше характерно для коммерческого веб дизайна. Большинство подобных сайтов смотрится вполне нормально в разных браузерах, трата времени и денег на создание валидного кода будет не только противопоказана, но и бессмысленна.

Таким образом, валидная разметка становится приравнена к двум вещам, которых никто не хотел бы: непрактичность и невозможность.

Рассмотрим детальнее

Если бы на заре становления стандартов не появились сайты CSS Zen Garden, Wired News или Fast Company, мы бы не стали теми, кем мы сейчас являемся. Я бы так и занимался ненавистной версткой со вставками типа spacer.gif.

Каждый раз, когда я вел учебные курсы, я устраивал опросы, почему слушатели собираются использовать веб стандарты. Ответы обычно читались как принцип, на котором выросло мое поколение веб дизайнеров. Т.е. разработка в соответствии со стандартами может…

• сократить цикл разработки, отныне для создания шаблона нам не нужно писать по 6 уровней вложенных таблиц
• снизить стоимость поддержки и обслуживания, показательный пример это CSS Zen Garden
• уменьшить вес страницы, который уменьшает время загрузки страницы, а соответственно стоимость трафика (интервью Mike Davidson в ESPN.com ярко демонстрирует цифры)

Все эти плюсы являются основными преимуществами веб стандартов, главными отправными точками при продаже дизайнов созданных на CSS/XHTML будущим клиентам. И причины для этого действительно оправданы, все это именно так и работает.

В списке, приведенном выше четко отсутствует упоминание почему мы должны следовать стандартам или что весь этот процесс влечет за собой и что дает. Я имею ввиду перечисление преимуществ валидного кода:

• Проверенное расширение доступности (accessibility) сайта
• Независимости от устройств
• Уверенность, что сайт будет работать в браузерах, которые еще не изобретены.

Однако сумма этих пунктов не слишком ярко говорит «вытяни этот бизнес проект». Если вы разговариваете с руководителем среднего звена о стандартах, к чему бы вы вели, к экономии терабайтов трафика или к инвестированию в устройство-независимость.

Да, вот это именно то, что я и делал.

До тех пор, пока преимущества валидного кода будет не станут эффектными, мы можем и даже должны говорить о них. Валидация не является конечным результатом или готовым продуктом, она является процессом, который продолжается длительное время после запуска сайта. И если мы не создадим условия для валидации, не обеспечим документацией или руководством или не обучим валидации персонал, обслуживающий сайт, отполированные, идеально созданные страницы, попадут в программное обеспечение, которое сделает из него макароны с тэгами

Итак, давай те разберемся, как преподнести валидацию в выгодном свете для наших заказчиков

Скрытая стоимость

Валидация может не быть самым «сексуальным» пунктом продажи стандартов, но она имеет очень реальные денежные выгоды. За последние пару лет моей практики у меня появились ненавязчивые идеи следить на своим временем, особенно время на отслеживание ошибок. Когда я начинал иметь с ними дело, я замечал ошибку, делал отчет и засекал время. Как только я ее исправлял, я замечал причину, останавливал таймер и так далее.

К концу первого года в бизнесе, я заметил что все больше и больше моих сайтов содержит в коде ошибки. Ошибки в шаблонах правились легко, но довести темплейт до валидного отнимал достаточно много времени, особенно если в нем было несколько сотен ошибок на страницу. Необходимо также было выяснить, какие части страницы не содержали ошибки, таким образом, я мог сосредоточиться на проблемных частях кода. Но когда ошибок на странице было 3-4 сотни, процесс правки меня просто топил. Это был, конечно же, необходимый процесс, но реальная клоака.

И к концу года, я обнаружил, что примерно 15% моего времени ушло на приведение кода в порядок. Как независимый дизайнер/разработчик/да кто угодно я благодарен своим клиентам за данную мне работу. А если бы я был наемным работником с фиксированной оплатой? Если бы IT отделы провели подобный аудит, я уверен, цифры были бы похожими. И похоже подобный аудит необходим. Невалидные сайты конечно же могут выглядеть одинаково, так же как и валидные, но я уверен, в обслуживании они обходятся значительно дороже. Это и есть скрытый вес невалидного кода, скрытая стоимость, о которой не сильно много говорят.

Веб, следующий второй пункт

Если быть до конца честным, прагматики правы: для большинства случаев валидация и коммерческий веб дизайн являются популярно-диаметрально противоположными. Но инструменты развиваются в направлении далекой от валидации и CMS'ы подобные WordPress и Slashcode направлены на создание соответствующего стандартам кода, визуальные редакторы, типа Dreamweaver и (самого последнего) Microsoft Expression Web упрямо отказываются создавать невалидный код. Итак, куда мы пришли?

Напряженный процесс, но не код

Последние месяцы я заново переучился продавать стандарты. Я все еще продолжаю делать волнующие биды (чем легче страницы, тем ниже стоимость поддержки, и т.д.), но я не воздерживаюсь от продажи роли валидации, как реальной экономии, которую дают веб стандарты. И это самая легкая продажа, которую я когда либо знал: как только вы показал заказчику, каким образом стандарты могут улучшить доступность сайта, рассказал об устройство-независимости и возможности работы сайта в будущем, и каким образом можно снизить стоимость обслуживания, такое обычно готовы все выслушать

И это именно тот момент, когда начинается разговор. Учитывая все обстоятельства построения рабочего процесса вашего клиента и используемого программного обеспечения для этого, вы вместе сможете лучше определить, как все можно увязать со стандартами и как результат, он сможет решить эти задачи даже лучше самостоятельно.

Умный магазин: стандартный магазин

Компании, подобные Adobe и Microsoft признали растущий рынок соответствия стандартам и в рекламных материалах показывают свои продукты как W3C-friendliness.

Здесь как раз отдельный потребитель и может сдвинуть горы. Встречаясь с будущим продавцом, наши клиенты хотят получить ответ, соответствуют ли их продукты стандартам, бывает даже больше, могут спросить, работает ли таргетирование в системе управления рекламой или является ли CMS J2EE compliant. Стандарты должны быть равновесными частями любого процесса, связанного с принятием решения и если мы напомним заказчику о финансовой выгоде валидации, тогда так и будет.

Та же песочница, та же борьба

Совершенно откровенно, реальная работа начинается с нами. Невзирая, будет ли валидация бесполезной или обязательной, борьба общественности за стандарты будет серьезной помехой в реальном процессе. Вместо того, чтобы пытаться понять какой фактор больше всего волнует обе стороны мы поносили людей, находящимися по другую сторону агрумента. Нам нужно понять, что делает 100%-ю валидацию такой дорогой и сложной и работать в направлении удаления данного фактора.

Как наш взнос в этом направлении, мы будем обсуждать противников валидации и все что сними связано в будущих статьях A List Apart. Вы тоже можете посодействовать, распространив статью на форумах

В совершенном мире плохое ПО и плохая технология не испортят наш код и валидация в этом имеет не последнее место. До тех пор, пока у меня будет эта волшебная летающая пони, которую я просил, у нас будет работа. И наконец, действительное соответствие стандартам только тогда станет бесполезной и невозможной, когда мы так решим. Если посмотреть, насколько далеко мы ушли вперед за последние годы, этот вызов покажется просто тривиальным.

Давайте работать.

Источник alistapart.com

Перевод — Дмитрий Папуца

Оригинал статьи

Translated with the permission of A List Apart Magazine and the author[s].