Web Standards Days в Киеве

andrewsumin — 20.09.2010 — Интернет Прочел первый не технический доклад. Вообще давно просто хотел высказаться.
Надеюсь, донес свои мысли правильно.




Скажу сразу, что под стандартами я понимаю не только валидность, но и попытки сделать код семантичным.

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

Приходит заказчик, смотрит на эту красоту. Не то что бы он верстальщик, но посмотреть исходник страницы может. И задает вам вопрос:

— Все это замечательно, но ты как думаешь: сайт http://ya.ru делали профессионалы?
— Конечно, — отвечаете Вы.
— А давай посмотрим, что там внутри.

И вы видите следующий код


...

http://help.yandex.ru/start/"onmousedown="c(this,17,1755);"> Сделать стартовой ... Доктайп HTML 4.01. Визуальные свойства таблицы задаются через атрибуты. Между атрибутами нет пробела. И, чтобы совсем Вас добить, он говорит: — А если все заменить на , то визуально ничего не измениться, а страница будет меньше весить. Зачем ты пишешь везде ? Вообще последний вопрос — один из моих любимых на собеседовании в группу верстки. А действительно — какая выгода соблюдать стандарты? Какая от них практическая польза? Все мы понимаем, что, размещая значок “валидно” на сайте, наше чувство собственного достоинства торжествует, мы знаем, что нужны этому миру и без нас он пропадет. Но вот появляется человек, который платит деньги, и нам ему нечего сказать в оправдание потраченного на валидность времени? Да он еще и может сказать, что она вредит? Код страницы раздувается, а пользы ноль. Очень мало людей могут парировать мои претензии к валидной и семантичной верстке. Соблюдение стандартов должно облегчать жизнь вам и экономить деньги заказчику, только это может оправдывать их существование. Чувство собственной нужности тренируйте на хомяках. Итак, для вас. Причина, по которой вам выгодно соблюдать стандарты, — развитие браузеров. Как сказал Виталий Харисов: — Если вы уверены, что в движке браузера глюк, то отправить багрепорт вы можете, только если ваш пример будет валиден. В противном случае баг вполне могут не принять. Мало ли что вы там сверстали, в стандарте это не объявлено — чинить смысла нет. Чем больше качественных багрепортов, тем быстрее браузеры от них избавляются и вы думаете о верстке, а не о хаках. Для заказчика. На самом деле мало сайтов живут по принципу “повисел неделю — убили”. Как только человек получает сайт, он сразу понимает, что ему его мало и его надо расширять, добавлять функционал и т.д. Если это небольшой заказ, то заказ на развитие может получить другой человек или студия. Если первый исполнитель соблюдал стандарты, то многие вещи второй поймет сразу и интуитивно. Например, увидев меню, он подсознательно ожидает увидеть там список, открывает код и действительно видит там список. Стоимость поддержки и развития сайта резко снижается, экономия на трафике на ее фоне выглядит просто смешно. Теперь вспоминаем главную Яндекса и плавно переходим ко второй части доклада про большие и нагруженные проекты. Думаю, теперь понятно, что такой код на главной Яндекса был взвешенным и продуманным решением. Люди правда экономят на трафике, и для них крайне важна скорость загрузки страницы. Сайт http://hh.ru еще не дорос до того, чтобы такое решение было экономически выгодным, но у нас есть большие отличия от общепринятого мнения про стандарты. Когда вы верстаете много небольших сайтов и заставляете себя соблюдать стандарты, вы делаете себе большую услугу. У вас входит в привычку думать системно. Вы начинаете выделять общие части у разных сайтов. И в результате начинаете писать “кроссайтовый” код. По моему мнению, это самая большая польза от стандартов для разработчика. Когда я только приехал в Москву устраиваться в Яндекс. Я тогда претендовал на должность JavaScript разработчика. Я был вдохновлен идеей полного следования стандартам и писал только “валидный код”. Да, да в JavaScript тоже есть стандарты. Метод innerHTML тогда был невалидным, а может таким остался до сих пор. Получив задание, я смело постарался его выпонить на честных DOM методах. Когда я показал результат, Саша Ермолаев (он тогда меня собеседовал) вместо огромного куска кода написал одну строку innerHTML=”...”, сказал что работает везде и наверно раз в 100 быстрее моего “валидного” кода. Итак, большой проект (например, http://hh.ru). Более 90 страниц только на http://hh.ru, три платформы, постоянный поиск новых инструментов, редизайн. Четкое соблюдение стандартов только вредит. Верстать на дивах — в топку. Вся раскладка только на таблицах. Когда на сайте есть контент, которым вы не управляете используйте только таблицы. Вы будете уверены что не будут “сваливаться” блоки, не будет “наползания” или контента просто не будет видно. В самом плохом случае появится горизонтальная прокрутка, думаю можно подождать утра и спокойно починить. Не использовать нестандартные атрибуты (например, autocomplete=”off”) и включать его через JS — в топку. И еще много чего такого, после чего значок с галочкой нам не светит. Но не создать или не следовать созданной системе и конвенции — самоубийство. Вся многоколоночная раскладка делается только давно оттестированным табличным кодом. Любой более-менее используемый компонент делается отдельно, инкапсулируется и используется строго заданным способом. Это тоже стандарты, только это уже ваши стандарты, и желательно им быть продуманными. В результате, мы получаем прогнозируемую по времени разработку, быструю обучаемость и спокойно спим по ночам. Ночной Киев очень понравился. Особенно коктейль "Хулиган" в баре "Паравоз", к сожалению фото нет.

Оставить комментарий

Популярные посты:

• Архив