Безсмислено ли е съответствието с XHTML?

Все още не съм срещал случай, в който добавянето на нестандартен атрибут е причинило проблем с изобразяването във всеки браузър.

Не се опитвайте да заобиколите тези нестандартни атрибути. Валидаторите са удобни като инструменти за двойна проверка на вашия код за неволни грешки, но както всички знаем, дори напълно валидният xhtml не винаги ще се изобразява последователно в браузърите. Има много случаи, когато дизайнерските решения изискват да използваме специфични за браузъра (и нестандартни) хакове, за да постигнем ефект. Това е животът на един уеб програмист, както се вижда от броя сайтове, движещи технологиите (google, yahoo и т.н.), които не валидират.

Валидирането е полезно, за да се определи кога нещата не отговарят на стандартите, с които предполагаемо сте съгласни. Ако целенасочено използвате инструмент, който специално добавя нещо извън стандартите за валидиране, очевидно това не нарушава вашето лично споразумение за стандарти.

Тази дискусия става много по-трудна, ако имате шеф или клиент, който вярва, че всичко трябва да върне зелена светлина, тъй като ще трябва да им обясните горното и да ги убедите, че не сте просто мързеливи.

Въпреки това, бъдете сигурни, че не сте просто мързеливи. Въпреки че валидаторите могат досадно постоянно да извеждат всеки екземпляр на атрибута на трета страна, това не прави невалидни (ха) другите грешки при валидирането, които споменават. Често си струва да го прегледате като средство за двойна проверка на работата ви.

Съответствието със стандартите е свързано с увеличаване на шанса вашата страница да работи в браузърите, срещу които не сте тествали. Това включва екранни четци и следващата актуализация на браузърите, с които тествате, и браузърите, с които тествате, но които са конфигурирани по неочакван начин от потребителя.

Валидирането не ви гарантира нищо, тъй като е възможно страницата ви да се валидира, но все пак да е достатъчно двусмислена, че да не се държи по начина, по който искате в някой браузър някой ден.

Въпреки това, ако вашата страница се валидира, вие поне имате силата на спецификацията на XHTML, която казва как трябва да се държи. Ако не се потвърди, всичко, което имате, е куп неофициални конвенции между авторите на браузъра.

Вероятно е по-добре да напишете валиден HTML 3, отколкото невалиден XHTML, ако има нещо, което искате да направите, което е разрешено в единия, но не и в другия.

Ако планирате да се възползвате от XHTML като XML, тогава си струва да направите страниците си валидни и добре оформени. В противен случай обикновеният стар семантичен HTML вероятно ще ви хареса. Така или иначе, нуждите на вашата аудитория надвишават нуждите на валидатора.

Само имайте предвид, че XHTML тагът се изобразява по различен начин в повечето браузъри, отколкото без него. Атрибутът DOCTYPE определя в какъв режим се изобразява браузърът и диктува какво е разрешено и какво не. Ако се отклоните от съответствието с XHTML, просто не забравяйте да тествате отново във всички браузъри.

Лично аз се придържам към най-новите стандарти, когато е възможно, но със сигурност трябва да претеглите времето/парите срещу съответствието и това се свежда до лични предпочитания за повечето.

Що се отнася до браузърите, съответствието с XHTML е безсмислено в това, че:

1. Браузърите нямат XHTML анализатори. Те имат неспецифични за версията, уеб-съвместими HTML анализатори, които изграждат DOM около http://www.w3.org/1999/xhtml пространство от имена.

2. Някои браузъри, които имат XML анализатори, могат да третират XHTML маркирането, обслужвано като application/xhtml+xml като XML. Това ще вземе XML и ще даде HTML стил и поведение по подразбиране на елементите в http://www.w3.org/1999/xhtml пространство от имена. Но що се отнася до анализирането, то няма нищо общо с XHTML. Спазват се правилата за разбор на XML, а не някои правила на XHTML DTD.

Така че, когато използвате XHTML маркиране, вие давате нещо чуждо на браузърите и виждате дали ще излезе според вашите намерения. Работата е там, че можете да направите това с всякакво маркиране. Ако се изобразява по предназначение и произвежда правилния DOM, вие се справяте доста добре. Просто трябва да имате предвид превключването на DOCTYPE и да сте сигурни, че не разчитате на грешка в браузъра (така че нещата да не се разпаднат в браузъри, които нямат грешка).

Това, за което е добро съответствие с XHTML, е проверка на синтаксиса (чрез валидиране), за да се види дали маркирането е добре оформено. Това помага да се избегнат грешки при анализиране. Разбира се, това може да се направи и с HTML, така че в този случай няма нищо специално за XHTML. Така или иначе, все още трябва да тествате в браузъри и да се надявате доставчиците на браузъри да направят страхотни HTML анализатори, които могат да приемат всякакви глупости.

Това, което не е безсмислено, е да се опитвате да се съобразите с това, което браузърите очакват. HTML5 помага в това голямо време. И като говорим за HTML5, можете да дефинирате персонализирани атрибути, каквито искате. Просто ги предварете с data-, както в ‹p data-order="Това е валиден персонализиран атрибут."›test‹/p›.

Валидността на HTML обикновено е от полза както за вас, така и за двигателя за изобразяване на браузъра. С колкото по-малко странности трябва да се справят браузърите, толкова повече могат да се съсредоточат върху добавянето на нови функции. Колкото по-стриктни сте, толкова по-малко време ще прекарвате в чудене защо този шибан частен етикет не работи в другите браузъри.

От друга страна, XHTML е, IMHO, по-безсмислен, освен ако не планирате да го интегрирате в някакъв XML документ. Тъй като IE все още не го разпознава, е доста безполезно да се придържате към него.

Мисля, че писането на "валиден код" е важно, просто защото давате пример, като следвате правилата. Ако всеки разработчик беше написал код за Fx, Safari и Opera, мисля, че IE трябваше да "започне да следва правилата" по-рано, отколкото с версия 8.

Опитвам се да напиша съвместим код през повечето време, претегляйки времето/разходите спрямо нуждите на аудиторията във всички случаи освен в един. Когато вашият код трябва да е съвместим с 503, във ваш най-добър интерес и в интерес на вашата аудитория е да напишете съвместим код. Попаднах на куп екранни четци, които издухват, когато кодът е дори леко отклонен.

Както се казва в повечето плакати, наистина всичко зависи от това, от което се нуждае вашата публика.

В никакъв случай не е безсмислено, но има много основания за нарушаването му. По време на началните етапи на разработката на CSS е много полезно за диагностициране на проблеми с браузъра, ако вашето маркиране е валидно. Освен това, ако искате да направите нещо и смятате, че най-подходящият метод е да нарушите валидирането, това обикновено е добре.

Алтернатива на използването на персонализирани атрибути е използването на атрибута „rel“, за пример вижте Litebox (и неговите роднини).

Разбира се, винаги можете просто да го напишете по желания от вас начин, като се уверите, че поне работи. Разбира се, ние вече страдахме от този манталитет и станахме свидетели на неговия резултат, Internet Explorer 6.

Аз съм голям фен на подхода на Майк Дейвидсън към ориентирано към стандартите развитие.

Това, че можете да потвърдите кода си, не означава, че сте по-добър от всеки друг. По дяволите, това дори не означава непременно, че пишете по-добър код от всеки друг. Някой, който може да напише банково приложение изцяло във Flash, е по-добър програмист от вас. Някой, който може да интегрира код на трета страна в сложна среда за публикуване, е по-добър програмист от вас. Мислете за валидирането като за използване на перфектна граматика; помага ви да представите идеите си и е знак за добро образование, но не е толкова важно, колкото идеите и концепциите, за които мислите и впоследствие съобщавате. Най-харизматичният и вероятно най-умният човек, за когото съм работил, беше от Юга и използваше думата „не е“ доста редовно. Това не го направи по-малко умен и всъщност го направи по-запомнящ се. Така че всичко, което казвам, е, че има много неща, по които да съдите някого... валидирането е едно от тях, но със сигурност не е най-важното.

Много хора разбират погрешно тази публикация, за да означава, че не трябва да кодираме според стандартите. Очевидно трябва, но това не е нещо, за което дори трябва да се мисли. Армията за валидиране винаги ще критикува тези, които не валидират, но валидирането означава много повече от валиден код.

Така че, не губете принципите си, но помнете, че ако следвате стандартите, е много по-малко вероятно да се окажете в дълбокия край на проблемите в бъдеще. Съдържанието, което се опитвате да предоставите, е много по-важно от това как се показва.