TONIC XGM, за верстальщиков не скажу, а программисты ко мне с таким приходили. Были посланы в точности как написано выше.

Можно вопрос (с которого надо было начинать): а что плохого в соблюдение стандартов (или хотя бы попытки их соблюдения:)

И второй вопрос: а какой смысл, например, программировать без варнингов — прога компилиться, ну и ладно, и класть на то, что среда выдает десятки варнингов. Или еще лучше — PHP-скрипты: ну и х*й, что на странице "вылетает" 20 ошибок — написал в начале скрипта error_reporting(0) и всего-то делов.
Так почему так никто не делает?

Crazy, черт мне бы таких сознательных программистов:)))

типа их совесть замучала из-за оставленных косяков?:))

Кухан писал(а):

Можно вопрос (с которого надо было начинать): а что плохого в соблюдение стандартов (или хотя бы попытки их соблюдения:)

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

Кухан писал(а):

И второй вопрос: а какой смысл, например, программировать без варнингов — прога компилиться, ну и ладно, и класть на то, что среда выдает десятки варнингов. Или еще лучше — PHP-скрипты: ну и х*й, что на странице "вылетает" 20 ошибок — написал в начале скрипта error_reporting(0) и всего-то делов. Так почему так никто не делает?

Так делают. Часто. Это реальность, данная нам в ощущении.

Твоя проблема в том, что ты пытаешься спорить с каким-то воображаемым собеседником и опровергать воображаемые доводы.

Crazy писал(а):

Твоя проблема в том, что ты пытаешься спорить с каким-то воображаемым собеседником и опровергать воображаемые доводы.

Я и ни с кем не спорю, я просто пытаюсь подвести черту
На данный момент соблюдение стандартов никаких особых преимуществ не даёт, и пока их соблюдают только энтузиасты своего дела.
Наезжать на стандарты и на людей, которые их соблюдают, обосновывая, что это никому не нужно, что это только понты — тоже глупость. Единственная причина, по которой не соблюдают стандарты — это просто обычная человеческая лень, и не надо писать, что стандарты занимают больше времени, что верстать на дивах труднее — всё это бред.

Вывод: соблюдать стандарты или нет — личное дело каждого

P.S. это моё мнение, и не надо его комменитировать — всё равно не переубедить (многие уже пытались:)
P.P.S. "соблюдать стандарты" читать как "пытаться соблюдать", "делать вид, что соблюдаешь", "просто агитировать, при этом не соблюдая их самому "
P.P.P.S.

Оракл писал(а):

Вы превзошли себя, Кухан!

Кухан писал(а):

На данный момент соблюдение стандартов никаких особых преимуществ не даёт, и пока их соблюдают только энтузиасты своего дела.

Неверно. В ряде случаев соблюдение стандартов дает вполне ощутимые преимущества.

Цитата:

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

Наезжать -- всегда глупость. Правда, непонятно, какое отношение твоя фраза имеет к этому треду.

Цитата:

Единственная причина, по которой не соблюдают стандарты — это просто обычная человеческая лень

Таких причин в действительности три:

1. Глупость
2. Лень
3. Экономическая нецелесообразность

Встречаются произвольные сочетания этих причин.

Цитата:

и не надо писать, что стандарты занимают больше времени, что верстать на дивах труднее — всё это бред.

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

По поводу времени я уже писал выше и приводил конкретный пример, так что повторяться не буду.

Цитата:

Вывод: соблюдать стандарты или нет — личное дело каждого

...при условии отсутствия таковых требований в ТЗ или внутрифирменных правилах верстки.

Цитата:

P.S. это моё мнение, и не надо его комменитировать — всё равно не переубедить (многие уже пытались:)

О да, я вижу, ты все еще продолжаешь с НИМИ спорить. Только неясно, зачем делать сие в этом топике. ИХ здесь нет.

Цитата:

P.P.S. "соблюдать стандарты" читать как "пытаться соблюдать", "делать вид, что соблюдаешь", "просто агитировать, при этом не соблюдая их самому "

http://ingvar1990.livejournal.com/3933.html

...ну разве что сделаем раздел "Методология разработки веб-приложений"

Цитата:

Неверно. В ряде случаев соблюдение стандартов дает вполне ощутимые преимущества.

И что я могу ответить на эту реплику? Послать если только. Если хочешь услышать нормальный ответ, приводи примеры, доводы. А так это бессмысленный базар на рынке, которой рано или поздно закончиться репликами "сам такой".

Цитата:

Наезжать -- всегда глупость. Правда, непонятно, какое отношение твоя фраза имеет к этому треду.

Не надо так узко мыслить. У человека должен быть широкий кругозор! Надо видеть не только сам вопрос, но и причины, которые к нему привели.

Цитата:

Таких причин в действительности три: 1. Глупость 2. Лень 3. Экономическая нецелесообразность

Любого человека можно научить, объяснить ему. Поэтому глупость — это просто лень учиться и разбираться.
Экономическая нецелесообразность, весьма спорная причина. Есть много людей(фирм), которые соблюдают стандарты, и при этом они не убыточны.

Цитата:

Как я уже говорил, ты споришь с каким-то воображаемым собеседником.

Прочти 5000 раз второе предложение моего предыдущего ответа.

Цитата:

Верстка на div'ах, к твоему сведению, вообще не имеет никакого отношения к соблюдению стандартов.

Датычо! А слабо было заглянуть в стандарт прежде чем это писать? Сам найдешь в стандарте, для чего используется тэг table и какие тэги отвечают за структуру страницы, или ткнуть пальцем?

Цитата:

...при условии отсутствия таковых требований в ТЗ или внутрифирменных правилах верстки

А ТЗ пишется на небесах в независимости от воли человека? Всё можно изменить, объяснить начальнику почему надо или наоборот не надо соблюдать стандарты, в крайнем случае, сменить работу.

Цитата:

О да, я вижу, ты все еще продолжаешь с НИМИ спорить.

Повторяю: прочти 5000 раз второе предложение моего предыдущего ответа.

Цитата:

http://ingvar1990.livejournal.com/3933.html

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

Да и какое вообще отношение оно имеет к моему ответу?

Andy_Bright писал(а):

TONIC XGM, Кира, Empiric, Покажате пожалуйста свои примеры, а то как-то голословно.

См. в личке

Crazy писал(а):

[ Таких причин в действительности три: 1. Глупость 2. Лень 3. Экономическая нецелесообразность Встречаются произвольные сочетания этих причин.

+1, согласен.

Кухан писал(а):

И что я могу ответить на эту реплику? Послать если только. Если хочешь услышать нормальный ответ, приводи примеры, доводы.

Ты хочешь сказать, что фраза про "соблюдение стандартов никаких особых преимуществ не даёт" была сказана тобой совершенно всерьез? Типа совсем не шутка и под этой фразой имел в виду, что тебе действительно неизвестно ни одно преимущество, которое дает валидная верстка?

Это интересный поворот в дискуссии.

Ok. Если это так -- подтверди правильность моего понимания, please -- то я готов немедленно рассказать тебе, какие преимущества дает соблюдение стандартов. Для краткости изложения я намерен ограничиться конкретной областью: валидной версткой.

На остальные твои фразы (особенно про дивы и таблицы) у меня тоже есть комментарии, но их объем зависит от ответа на текущий вопрос.

Итак?

Я не говорил, что валидная верстка не дает преимуществ, я говорю, что все они несущественны.

Кухан писал(а):

Я не говорил, что валидная верстка не дает преимуществ, я говорю, что все они несущественны.

Исключительно чтобы я не повторял уже известные тебе вещи: о каких несущественных преимуществах валидной верстки ты знаешь?

IMHO профессионального веб-технолога\кодера на тему "валидная верстка":

Для начала нужно определиться, для кого она валидная? В процессе создания сайта есть две стороны -- заказчик и исполнитель (ну может быть еще третья, посредник -- не суть важно). Так вот... заказчику большей мерой важно, чтобы его сайт получился таким, каким он(заказчик) его хотел видеть. Все же требования вроде "Валидный XHTML, (и шоб не ниже стрЫкт!) + CSS" -- лишь указка очередного умника-консультанта, мужа\жены, брата\сестры или еще кого-нибудь. Валидатор же -- никак ни относиццо ни к первой, ни к второй стороне.

Почему провел такое сравнение? Меня честно очень улыбают выражения: "вся моя верстка валидна!, да чтоб я, да когда-нить!? да все теги закрыты!". Причина улыбки -- обычно когда заглядываешь непосредственно в сам код, там начинается полный ...вперед.

Еще очень улыбало(сейчас уже не так актуально, а вот года так полтора-два назад.…) валидацию возносили чуть ли ли выше самого сайта А зачем? Чтобы какой-нить очередной умник на каком-нить ботаническом форуме не дал ссылку на валидатор с параметром-именем вашего сайта?

Теперь все таки к нашим баранам:

Реальным же и действительно-важным, требование "валидная верстка" быть не может под одной простой причине:
НИ ОДИН из браузеров на сегодняшний момент, не поддерживает в полной мере, что пытается валидировать W3C.

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

дабы не получать мессагу, что видете-ли "недопустимый элемент в теге A"?

Другой вопрос в том, что валидация позволяет заставлять переделывать нелогичный код, как скажем:

Безусловно тег "FORM" тут совсем ни к месту, а ведь так удобно правда? Форма "волшебно теряет" "margin и padding", ничего никуда не вылезает -- банальщина, очень распрастраненный пример.

Посему валидным, в моем понимании, может быть такой код -- который:
1. Легко читаем
2. Не перегружен избыточностью
3. Все теги закрыты (очень важно)
4. Доступен логике нормального человека-кодера со средне-статистическим IQ

Так обясните же мне, господа -- о каких стандартах может идти речь, если эти стандарты не воплощены в жизнь сами разработчиками? Создали CSS3, не дождавшись даже 50% реализации CSS2? Вообще прикольно наверное там работать, чуваки приходят на работу в белых костюмчиках, мыслят о светлом, все разговоры видать о поезии и смысле тега <br />, создают новые приколы из серии "а как вам крулые рамки?" и при этом при этом нифига не смотрят на реальное положение дел.

Подытожу IMHO:
1. Валидная верстка -- логическая, правильная синтаксически и семантически, верстка, проходящая субъективную валидацию непосредственно разработчиком или же старшим кодером, веб-технологом, арт-директором (нужное подчеркнуть)
2. Нефик требовать валидации того, что не работает даже на 60%. Валидацию сделать возможно, но это будет верстка нелогичная, из серии "пробка в дырку, лишь бы ярлык блестел"

Crazy, если повторишь — ничего страшного не произойдет, заодно по каждому пункту я напишу, почему он несущественный.

Кухан писал(а):

Crazy, если повторишь — ничего страшного не произойдет.

Падонки непременно сказали бы, что "слив засчитан". Я же просто перейду ко вступлению.

Соблюдение стандартов не самоценно. Сайт (автомобиль, стиральная машина) не становится лучше просто оттого, что он соблюдает стандарты. Как я и обещал ранее, ограничимся вполне конкретной областью: стандартом HTML. Но сказанное ниже в значительной степени касается стандартов на юзабилити и др.

Прежде всего следует понимать, что стандарт HTML адресован не верстальщику, а разработчикам браузеров. Он дает формальное описание того, как следует интерпретировать HTML-код.

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

Разумеется, имеют место несоответствия стандарту, вызванные просто ошибками в коде браузеров, но эти несоответствия по возможности -- хоть и медленно -- исправляются.

Соответственно, при создании HTML-кода мы имеем дело с фичами следующих категорий:

1. Код, соответствующий стандарту и правильно интерпретируемый браузером.
2. Код, соответствующий стандарту и неправильно интерпретируемый браузером вследствие ошибки в браузере.
3. Код, вследствие ошибки нарушающий стандарт и интерпретируемый браузером исключительно согласно здравому смыслу его разработчиков.
4. Код, преднамеренно нарушающий стандарт и адресованный конкретному браузеру для использования его специфических особенностей.

Здесь и далее валидным кодом я называю код из пунктов 1 и 2. Невалидным -- из пунктов 3 и 4. Подчеркиваю: невалидный -- не значит "неработающий". Это лишь значит, что он формально нарушает стандарт.

Поскольку, как я уже сказал, соблюдение стандартов не самоценно, рассмотрим, какую пользу оно может нам принести в разработке сайтов. Поскольку соблюдение стандарта HTML очевидно не затрагивает подготовку договора, сбор требований и т.п., я буду рассматривать только две фазы: разработку и сопровождение. В обоих случаях создание кода или внесение в него запрошенных заказчиком изменений имеет итеративный характер: кодирование - тестирование - кодирование - … и т.д. При этом тестирование де-факто занимает от 30 до 70% общих трудозатрат на этой фазе. Разумеется, это не касается разработки трехстраничного сайта детсада "Ромашка", который верстальщик Петя не глядя кодит прямо на хостинге и оставляет на посмотр воспитателям детсада.

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

Если наш код написан "абы как", то мы вынуждены проводить исключительно ручное тестирование. Т.е. открываем сайт, лазаем по нему и на каждой странице внимательно смотрим глазами и ищем несоответствия. Фактически, мы уподобляемся воспитательнице детсада "Ромашка", вычитывающей Петин сайт.

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

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

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

Естественно, на практике все это не так хорошо и легко. В реальной жизни приходится столкнуться по крайней мере со следующими аспектами:

1. Необходимость интеграции со сторонними компонентами, которые формируют невалидный код.
2. Использование унаследованного кода, на переработку которого нет ресурсов.
3. Особенности квалификации и личного стиля работы верстальщиков.
4. Недостаточные выразительные возможности CSS2.
5. Высокая стоимость валидации.

Первые 4 пункта достаточно очевидны (если у кого есть вопросы по п.4 -- сравните CSS2 и CSS3). Обычно возникает вопрос с п.5. Действительно -- что сложного и дорого в том, чтобы провалидировать страничку? Кинуть на вход тестовому скрипту, всего и делов-то. Ничего сложного -- пока мы валидируем статический сайт детсада "Ромашка". И проблема здесь вовсе не в том, что в отличие от детсадовского сайта мы не можем захардкодить все три ссылки на страницы и вынуждены сделать выборочный обход сайта.

Если нам нужно провалидировать динамический сайт, то неизбежно встает стандартная проблема покрытия кода тестами. Предположим, у нас в коде есть условный оператор, который управляет форматом вывода новости в зависимости от ее возраста. Подавать исходник на вход валидатора -- бессмысленно. Он понимает только результирующий HTML-код. Стало быть, в общем случае мы должны дважды сформировать и провалидировать эту страничку, чтобы проверить обе ветви if'а.

Это требует как времени на разработку теста (тестовых данных), так и времени на исполнение теста.

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

Поскольку мы перешли от высокоидейного мира черного и белого к реальной жизни, то вывод становится очевиден: в реальной жизни есть такое понятие, как "компромис". Так, если приведение 90% формируемого HTML-кода к валидному виду занимает у нас 10 часов и ожидаемая экономия на времени тестирования составит 40 часов, то это уже разумное решение. Если доработка остальных 10% потребует еще 10 часов и даст экономию 2 часа, то мы оставим это занятие интеллектуальным онанистам, а сами продолжим гнусно зарабатывать деньги.

Как водится, у нас есть два пути к компромису: вдоль и поперек. Начнем с первого.

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

1. Возможность более адресных сообщений об ошибках. Т.е. вместо того, чтобы ругаться "ошибка на новостной странице" мы можем гораздо более внятно сказать: "ошибка в блоке вывода календаря". Или даже "Иван, в твоем блоке вывода календаря есть ошибка".
2. Возможность вывести из автоматического тестирования заведомо невалидный код. К примеру, если нам дали кривонаписанный фрагмент для установки баннера/счетчика/др, то мы просто сознательным решением выносим его из процесса автоматической валидации на соответствие HTML. Поскольку мы априори знаем, что валидацию он не пройдет и, что важнее, мы никак не намерены это исправлять.
3. Уменьшить общее количество автоматических тестов. Если у нас календарь может вывестись 3 способами, а новостная лента -- 4 способами, то формально нам требуется 12 тестов на страницу. Если мы выносим их в mock'и, то достаточно 7 тестов. Обычно разница более радикальная.
4. Mock-страницы зачастую требуют значительно меньше ресурсов (например, в случае использования порталов), поэтому даже при равном количестве тестов это ускоряет тестирование.

Второй компромис -- поперек -- состоит в том, чтобы изъять некоторые страницы из тестирования. К примеру, если одна из страниц представляет собой отчет, сформированный сторонней тулзой, которую мы не имеем намерения править, мы просто исключаем из тестирования всю страницу.

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

При создании сайта детсада "Ромашка" из трех статических страниц единственным достоинством валидной верстки является возможности рассказать на форуме о своей крутости.

P.S. Как указано в начале, все это относится не только к HTML-валидации. Кроме того, отдельный интересный аспект составляет не автоматическое, а автоматизированное тестирование. Например, тестовый скрипт не ограничивается бессмысленной проверкой "просто наличия" alt'ом в img, а составляет отчет, который затем вдумчиво вычитывает человек, отвечающий за SEO.

Кухан писал(а):

Цитата: Верстка на div'ах, к твоему сведению, вообще не имеет никакого отношения к соблюдению стандартов. Датычо! А слабо было заглянуть в стандарт прежде чем это писать? Сам найдешь в стандарте, для чего используется тэг table и какие тэги отвечают за структуру страницы, или ткнуть пальцем?

Определенно нужно ткнуть пальцем. Предвкушаю. Особенно интересно, как это валидатор проверяет.

А пока ты ищешь все это -- я восстановлю порезанную тобой цитату:

Цитата:

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

Курсивом -- та часть, которую я сейчас проиллюстрирую. Во всех случаях для краткости дается только содержимое <body>. Итак:

1. Пример валидного кода на дивах:



2. Пример невалидного кода на дивах:



3. Пример валидного кода без дивов (на таблицах -- раз уж ты их упоминаешь):



4. Пример невалидного кода без дивов (на таблицах):



Как я уже многкратно говорил (без толку, увы), ты постоянно споришь с каким-то вымышленным собеседником. Напомню еще раз свою фразу:

Цитата:

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

Твой ответ:

Цитата:

Сам найдешь в стандарте, для чего используется тэг table и какие тэги отвечают за структуру страницы, или ткнуть пальцем?

Ответь на простой вопрос: где ты видишь в моей фразе хоть слово о таблицах, упоминание тэга <table> и т.п.? Нет? Так на чью и какую реплику ты отвечал своим сообщением? Может быть, злые люди поставили перед тобой хитрый прокси и искажают текст сообщений?

Developer® писал(а):

1. Валидная верстка -- логическая, правильная синтаксически и семантически, верстка, проходящая субъективную валидацию непосредственно разработчиком или же старшим кодером, веб-технологом, арт-директором (нужное подчеркнуть)

Я бы все же порекомендовал воздержаться от использования существующих терминов -- валидная верстка, валидация -- в несвойственных им смыслам.

Валидация HTML -- проверка соответствия HTML-кода стандарту HTML. В процессе валидации, в частности, невозможно определить, семантическая это верстка или презентационная.
Валидная верстка -- верстка, успешно проходящая валидацию.

Все остальное -- от лукавого. Придумайте новый термин, please, и давайте ему любое угодное вам определение.

P.S. Ответ по п.2, в сущности, изложен двумя сообщениями выше.

Crazy, блин, потратить время, да ещё и выходные, и на ЭТО? Просто герой. А вобще, таким, вот, вопросам, дОлжно быть в теории, imo.

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

Из 40-60 сайтов, что я сделал, максимум 10 человек попросили отчитатся по поводу кода и валидатора.
Полностью солидарен с Crazy.

Цитата:

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

Вероятно вы не обнаружили в моем сообщении трактовку идеи "субъективности валидации".

Цитата:

Валидация HTML -- проверка соответствия HTML-кода стандарту HTML.

Это ваше субъективное мнение? "Is valid" -- пригодна. Верстка пригодна. Пригодна для чего? Для использования\понтов\просмотра\etc... Не важно для чего, важно для кого. В первую очередь для того, кому эта верстка была предназначена.

Для меня валидной версткой является такая верстка, которая:
1. Соответствует здравой логике
2. Написана в соответствии со стандартами кодирования на предприятии
3. Визуализация и организация которой соответствует требованиям

Зачем придумывать что-то, что уже давно придумано? Хотя конечно, велосипедные заводы процветают и по сей день

Developer® писал(а):

Это ваше субъективное мнение?

Цитирую текст стандарта (курсив -- мой):

Цитата:

3.2. XHTML 2 User Agent Conformance A conforming user agent must meet all of the following criteria, as well as other requirements found throughout this specification: 1. The user agent must parse and evaluate an XHTML 2 document for well-formedness. If the user agent claims to be a validating user agent, it must also validate documents against a referenced schema according to XML [p.248] ].

Так что смысл слова "валидация" описан в стандарте совершенно четко и недвусмысленно.

Замечательно Тобишь слово "валидация" по твоему может применяться только в случае "also validate documents against a referenced schema according to XML"? Еще раз подчеркну субъективность валидации -- она бывает разной, и то, что W3C использовала это слово в своих текстах не исключает это слово из английского словаря, правда? В моей компании например, как и во многих других: валидный(пригодный)код -- это код, который соответствует требованиям, которые я описал выше.

Однако ничего не мешает писать код по стандартам W3C, который правда в большинстве своих случаев уходит в небытие по причине изменения сайта непосредственно заказчиком(снятие с саппорта, привлечение дополнительных разработчиков-фриленсеров для "а вот мне тут цвет не поменяешь за 10 баксов", и очень распрастраненный случай "а чего это моя секретарша новости забивать не может? а пускай...").

Developer®, ты действительно хочешь меня убедить в том, что авторы объявлений, упомянутом в первом письме треда, имеют в виду не "валидацию в смысле w3c", а что-то близкое к твоей трактовке?

И зачем было столько писать?
Сразу напомню, что если какой-либо код проходит через валидатор, это еще не значит, что он полностью соответствует стандартам. Многие ошибки валидатор не может найти. Например, использование table в качестве разметки страницы.
Теперь о преимуществах, вернее об одном: автоматизация тестирования.
Валидный код еще не гарантирует правильность отображения, поэтому тестировщику все равно придется проверять страницу.
Идея о том, что невалидный код не показывать тестеру, а сразу возращать верстальщику тоже бредова. Это что из-за каждого <br> или из-за конструкций типа <a><div>….</div></a> код будет возвращаться верстальщику?
И самое главное, такие ошибки как незакрытые тэги, опечатки в названиях определяются еще редактором на стадии написания кода, и верстальщик прямо в редакторе может исправить, и не надо отсылать код на валидацию.

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

Нет, просто считаю, что W3C валидация -- отнюдь не первостепенная задача интернет-проекта, и даже не вторичная. Миф о том, что сайт правильный("хороший"), если проходит W3C валидацию, является мифом. В этом же топике, мнение о W3C валидации скачет по синусоиде. Потому и отписал тут IMHO, быть может это кому-нибудь интересно

Кухан писал(а):

И зачем было столько писать? Сразу напомню, что если какой-либо код проходит через валидатор, это еще не значит, что он полностью соответствует стандартам. Многие ошибки валидатор не может найти. Например, использование table в качестве разметки страницы.

Что в w3c называют валидацией -- я процитировал. Так что не надо, please, разговоров в пользу бедных.

Кстати, я почему-то не вижу в твоем сообщении цитаты, о которой я спрашивал. Все еще ищешь ее?

Цитата:

Идея о том, что невалидный код не показывать тестеру, а сразу возращать верстальщику тоже бредова. Это что из-за каждого <br> или из-за конструкций типа <a><div>….</div></a> код будет возвращаться верстальщику?

Именно. Чтобы сократить цикл разработка-тестирование и не тратить время тестировщика.

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

Теперь цитаты из W3C:
http://www.w3.org/TR/html4/struct/tables.html

Цитата:

Tables should not be used purely as a means to layout document content.

http://www.w3.org/TR/html4/struct/global.html#h-7.5.3

Цитата:

The DIV and SPAN elements, in conjunction with the id and class attributes, offer a generic mechanism for adding structure to documents.

Crazy, как раз мой пример показывает не про сокращение времени тестировщика, а про увелечение времени верстальщика, потому что валидатор будет "ругаться" на работающие конструкции: такие как <br> вместо <br />, та же неправильная вложенность блочных элементов в строчные, отсутствие блочных элементов внутри <form> и т.п. Если таких ошибок много, то легче просто посмотреть в браузерах, чем всё это исправлять.

Цитата:

Так что не надо, please, разговоров в пользу бедных.

Ты о чем?
Я имел ввиду, что валидатор не считает ошибкой разметку страницы на таблицах, использования тэга img для вставки прозрачных картинок-заглушек, или еще хуже для рисования линий.

Кухан писал(а):

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

Прекрасно. А с кем ты об этом говорил? Если со мной -- то с чего вдруг? Но раз уж начали, то продолжим. Итак, вот как ты обосновываешь свою точку зрения:

Цитата:

Теперь цитаты из W3C: http://www.w3.org/TR/html4/struct/tables.html Цитата: Tables should not be used purely as a means to layout document content. http://www.w3.org/TR/html4/struct/global.html#h-7.5.3 Цитата: The DIV and SPAN elements, in conjunction with the id and class attributes, offer a generic mechanism for adding structure to documents.

Теперь я понимаю источник твоих заблуждений. Английский язык -- штука тонкая. Особенно в части употребления модальных глаголов. И чтобы не возникало неувязок, в стандарте есть раздел 4, "Conformance: requirements and recommendations" (курсив в цитате -- мой):

Цитата:

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. However, for readability, these words do not appear in all uppercase letters in this specification.

Открыв RFC2119, к которому нас отсылают, мы видим, что там совершенно недвусмысленно сказано:

Цитата:

4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

Так что в стандарте вовсе не сказано, что употребление таблиц для создания layout'а запрещено стандартом и делает страницу невалидной. Там сказано, что это не более чем нерекомендованная практика и прежде чем так поступать -- нужно хорошо обдумать свои действия и оценить последствия. Более того, явно и недвусмысленно сказано, что так поступать можно.

Итак, книжки -- читать, траву -- курить. Не наоборот.

P.S. Кстати, обрати внимание: во второй твоей цитате из стандарта даже нет рекомендации так -- верстать DIV'ами -- поступать. Просто сказано, что эти тэги предосталяют возможности, удобные для семантической верстки. Если ты хотел донести до меня свежую и оригинальную информацию о семантике тэгов DIV и SPAN, то, право, не стоило так себя утруждать.

Кухан писал(а):

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

И правильно делает. Поскольку ничто из этого не противоречит стандарту.

Ты опять путаешься. В данном случае -- между валидацией согласно стандарту и следование рекомендациям по правильной семантической верстке.