Jump to content

Валидация кода


still swamp
 Share

Recommended Posts

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

Код должен быть валидным с точки зрения валидатора.

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

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

Исходя из всего сказанного, фраза: "фи - да у тебя код невалидный" звучит приблизительно так же как "фи - да у тебя перья не гламурные".

Корректные возражения можно?

Link to comment
Share on other sites

Валидный код должен браться за основу.

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

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

Link to comment
Share on other sites

Можно не закрыть тег, а потом пожалеть об этом. Не веришь?

Верю. Валидатор как инструмент - вполне себе. Но это не имеет никакого отношения к замечаниям "у тебя код не валидизируется". Это то же самое что говорить... "ааа у тебя HTML в блокноте набран, а кошерно в xxx". Вот я о чем. Валидатор - это инструмент а не догма.

Edited by still swamp
Link to comment
Share on other sites

Валидный код должен браться за основу.

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

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

Полностью согласен.

насколько я знаю, консорциум w3c не устанавливает свои правила для написания кода кроссбраузерного как догму, а только лишь как рекомендацию.

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

Link to comment
Share on other sites

Не устанавливает, потому что нет технической возможности.

Нет, не поэтому. Потому что они никогда не смогут договориться с разработчиками браузеров с их вечными багами (в частности самизнаетекакой).

Link to comment
Share on other sites

Нет, не поэтому. Потому что они никогда не смогут договориться с разработчиками браузеров с их вечными багами (в частности самизнаетекакой).

Именно так. Это и есть отсутствие возможности. :)

Link to comment
Share on other sites

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

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

Именно поэтому я за валидный код, именно поэтому я за строгий (где это возможно) доктайп.

Link to comment
Share on other sites

Вообще как бы, когда человек начинает изучать тот-же html он же его изучает по каким-то стандартам, я к тому, когда мы учимся мы учимся писать

<b>text</b>
а не
<b>text<close_b>
или
<b>{text}
или
<b>([text])

Так вот учимся мы в соответствии с определенными стандартами, объявляя доктайп мы мы фактически выбираем определенный стандарт, допустим выбрали мы XHTML то и писать мы должны

<meta content="..." />
а не
<meta content="...">

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

Так же я согласен с Great Rash...

И потом я вот не вижу проблемы в том чтобы соблюдать стандарт, в чем плюсы того чтобы его не соблюдать? На скорость написания не влияет, после создания 2-3 валидных проектов фактически не влияет. Однако определенно если писать <tr><td></td><tr> опера такую вот конструкцию в большинстве случаев отобразит правильно, однако тот же IE не отобразит...

Edited by stars
Link to comment
Share on other sites

я только отчасти соглашусь как с ТС, так и с Great Rash.

то что код должен быть читабелен и без синтаксических ошибок - Great Rash (имеется ввиду что с ним согласен).

то что нужно ну к примеру подстраивать код тех же счетчиков под валидатор - бред - still swamp (если предполагается то согласен с этим).

вообще конечно надо разделить мнение w3c на такие пункты как:

1) кросс - соблюдать обязательно

2) валидность - желательно

3) семантичность - желательно

как-то так...

Link to comment
Share on other sites

Моё имхо — код должен быть адекватным а) той задаче, которую он призван решать, б) той среде, в которой он будет исполняться. Исходя из этих двух посылок, подбирается наиболее подходящий инструмент. Верстается научная статья с кучей формул и графиков — логично выбрать XHTML+MathML+SVG (и отдавать его как application/xhtml+xml, естественно). Верстается обычный сайт, важную часть аудитории которого занимает IE7-8 — логично выбрать HTML4.01 Transitional или HTML5 (но держа "в уме" незрелость его поддержки и не злоупотребляя новыми тегами и контролами форм). Верстается HTML-письмо (в том 0.01% случаев, когда это нужно не для спама;) — наш выбор HTML3.2 (тоже действующий стандарт, между прочим, как раз для случаев, "когда CSS недоступен").

А изначально выбирать инструмент, исходя не из практической надобности, а из соображений "моды" или "крутизны" (напр., XHTML 1.x, зная, что отдаваться он будет как text/html, или Strict-вариант для сайта с функционалом, построенным вокруг iframe), а потом плясать с бубном, пытаясь и свою задачу решить, и валидатора ублажить (извращаясь через динамическую вставку тегов и атрибутов скриптами и т.п.) — имхо, глупость.

Вообще валидатор — программа очень тупая. Она не знает, зачем вы делаете тот или иной финт (напр., оборачиваете <div> в <ins> — чтобы выделить свежее добавление актуальной информации или всего лишь чтобы "незаметно для валидатора" впихнуть этот див в ссылку;) и не может сказать, адекватный ли вашей задаче код у вас получился. Абсолютно валидный по DTD код может быть абсолютной ересью с точки зрения семантики, здравого смысла и браузеров (особенно если отдается не с тем типом контента, который подразумевал валидатор — например, запись <div/> вполне валидна для пустого дива в XHTML, но при text/html для любого браузера это незакрытый тег!).

Поэтому пользоваться валидатором, безусловно, надо — он прекрасно ловит случайные описки и т.п. и напоминает о неочевидных вещах (особенно в HTML с его неявным закрытием элементов, как в вышеприведенном — кстати, валидном в HTML! — примере с <tr><td></td><tr>). Но не надо приписывать ему всеведения, всемогущести и силы закона. Тем более, валидаторы, как и браузеры, пишутся людьми и тоже порой ошибаются. И если важен самый стандартный режим отображения в браузере (никаких "почти стандартных" и "limited quirks"), HTML5 по каким-то внешним причинам не подходит, но некоторые ссылки непременно должны открываться в новом окне — я не вижу катастрофы в том, чтобы поставить Strict-доктайп и оставить target у ссылок, не заменяя их неочевидными скриптовыми костылями (но обязательно указав эту единственную ошибку валидации как known issue в документации проекта).

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

Link to comment
Share on other sites

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

Это неправда. В первую очередь вспоминаются случаи, когда «невалидные» атрибуты устанавляиваются из js. Такие, как autocomplete или input type="search". Это удобно поддерживать, когда в коде их нет, а на странице — есть?

Link to comment
Share on other sites

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

[...]

Именно поэтому я за валидный код, именно поэтому я за строгий (где это возможно) доктайп.

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

скриптовыми костылями (но обязательно указав эту единственную ошибку валидации как known issue в документации проекта).

Зачем?! Вы себе лишнее ермо вешаете на шею. Не должен заказчик даже ожидать в документации какой либо информации о валидности или не валидности. Это исключительно внутренне дело разработчика.

Link to comment
Share on other sites

некие правила которые очень часто идут в разрез с реальной необходимостью. Дополнительные обременения.

Чаще всего это следствие изначального неверного выбора инструмента (о чем я и говорил выше). На порядок реже — недоработки самих стандартов (типа зазря выкинутого атрибута start для OL). Чем мне нравится HTML5, так это тем, что в нем таких граблей гораздо меньше (не зря разработчики спеки стремились "мостить проторенные тропы").

Не должен заказчик даже ожидать в документации какой либо информации о валидности

Я не про заказчика, а про внутреннюю документацию, для других разработчиков и тестеров.

Edited by SelenIT
Link to comment
Share on other sites

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

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

Link to comment
Share on other sites

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

Вам никогда не давали чужой валидный говнокод?

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

Link to comment
Share on other sites

У меня 90% работы - разгребание чужого невалидного говногода с костылями типа <meta http-equiv="X-UA-Compatible" content="IE=7">, потому что в ИЕ8(!) "ЭТО" не работает...

А как-то раз я увидел в коде такой коммент:

<!-- Извините за это говно -->

хоть стой хоть падай...

P.S. Вы кагбэ не поймите меня неправильно, я не фанат, и target="_blank", и <noscript> мне прописать не в облом...

Link to comment
Share on other sites

Имхо, проблемы с IE8 и т.п. чаще происходят со сложным CSS, натянутым на конструкции, подобранные "методом тыка", без понимания происходящего (схлопывание/несхлопывание маргинов при hasLayout'е, с которым пытаются тупо бороться добавочными отступами, и т.п.). Их возникновение от валидности кода зависит мало.

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

Link to comment
Share on other sites

Ой скока тут лицемерия налили...

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

Отсюда и :

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

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

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

Link to comment
Share on other sites

У меня 90% работы - разгребание чужого невалидного говногода с костылями типа <meta http-equiv="X-UA-Compatible" content="IE=7">, потому что в ИЕ8(!) "ЭТО" не работает…

А что у вас лично получается хотя бы через полтора-два года поддержки интенсивно развивающегося проекта?

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

Link to comment
Share on other sites

Валидный код - это код соответствующий стандартам, которые вы задекларировали в DOCTYPE.

Не обязательно. Валидность — соответствие указанной схеме (что в чем может содержаться и т.п.). Код, в котором абзацы размечены <br/>-ками, заголовки — тегами <b> и <strong>, списки сделаны через <blockquote>, а все названия улиц обернуты в <address>, может быть полностью валиден в HTML4/XHTML1, однако он прямо противоречит букве и духу соотв. спецификаций. Есть старая, но не утратившая актуальности статья по теме, там есть веселый пример и познавательные подробности.

Link to comment
Share on other sites

Моё имхо — код должен быть адекватным

Вот это самое верное.

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

Link to comment
Share on other sites

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

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

Link to comment
Share on other sites

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

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

Edited by still swamp
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share


×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. See more about our Guidelines and Privacy Policy