Fronteers — vakvereniging voor front-end developers

Webrichtlijn 5: Gebruik geen deprecated markup (R-pd.2.2)

Gebruik geen markup die in de W3C specificaties staat aangemerkt als deprecated (achterhaald). (R-pd.2.2)

De argumentatie van de webrichtlijnen is als volgt: "Het gebruik van achterhaalde elementen – in de specificatie aangeduid als deprecated – wordt ten zeerste afgeraden. Deze elementen zijn dan wel deel van de standaard, de meeste zijn echter geen betekenisvolle markup en schenden het principe van scheiding tussen structuur en vormgeving."

Afraden is één, maar hoe dwing je het af? Wat doe je als het CMS waar je noodgedwongen in moet bouwen, nog vrolijk <u>, <strike> of God verhoede <font> ondersteunt? Is dit een technisch probleem, of moeten de content managers bepaalde gewoontes gewoon afleren?

Zie ook de volledige lijst met (deprecated) elementen en attributen. Het gaat hierbij inderdaad voornamelijk om markup voor vormgeving (waar CSS voor dient), maar het language attribuut (voor <script>) is ook deprecated. Hoeveel copy & paste scriptjes voor statistieken gebruiken dit nog?

Reacties

1 Tom-Eric op 29-01-2008 om 08:24 uur:
De meeste problemen die je beschrijft zijn ook frontend problemen.

Als de WYSIWYG editor die gebruikt wordt nog <u> en <font> gebruikt, dan is het je taak als frontender om of de editor te updaten, of deze functies uit te schakelen. Vaak is het niet meer dan een javascript regeltje aanpassen ergens.

Als je een script copy/pasted, dan is dat jouw verantwoordelijkheid. Je moet niet blindelings vertrouwen op de kwaliteit van andere mensen.

Veel (onwetende) mensen gebruiken de W3C validator om te kijken of je HTML wel echt correct is. Dat is natuurlijk ook nog een argument om te zorgen dat je HTML ook echt valide is en dus geen deprecated elementen meer bevat.
2 Blaise Kal op 29-01-2008 om 12:29 uur:
Ik kom bijna nooit meer deprecated elementen tegen in CMS'en of copy-paste codes van adverteerderders of webstatistieken. Veel moderne software is gelukkig met zijn tijd meegegaan.

Als ik het sporadisch wél tegenkom probeer ik deprecated onderdelen te verwijderen, of te verangen met een moderne alternatief. Dat is tot nu toe altijd gelukt.
3 Egor Kloos op 29-01-2008 om 13:01 uur:
Helaas zullen we niet van WYSIWYG editors af komen. Wel zullen ze beter worden, maar problematisch zullen ze blijven. Helaas willen deze tools de editor te veel ruimte om zelf stijlen te verzinnen. Het is aan een bedrijf in te zien dat een eenduidige communicatie van groot belang is voor haar corporate identity. Zowel aesthetisch als taalkundig.

De meeste bedrijven hebben geen ervaren en/of opgeleide content managers en moeten terug vallen op wat het systeem hun geeft.
Grappig is dat de meeste sites geen WYSIWYG CMS invoer nodig hebben. Het is vooral een gimmick om tekst en beeld invoer makkelijker te maken. Helaas gaat dat idee vaak niet op, zeker wanneer WYSIWYG alle toeters een bellen aan heeft staan. Aan de andere kant is het soms niet zo eenvoudig om getabuleerde informatie toe te voegen. WYSIWYG is vaak een oplossing voor het ontbrekende informatie structuur.

Hoe je het bekijkt het zijn de architecten, programmeurs, front-end'ers en content managers die hun werk goed moeten doen om tot goede resultaten te komen. Dat alle vier dat werkelijk ook kunnen valt helaas vaak tegen.
4 Krijn op 29-01-2008 om 16:43 uur:
En als een WYSIWYG editor dan toch de mogelijkheid tot het onderstrepen van een tekst wil geven, is <span style="text-decoration: underline;">tekst</span> dan zoveel beter dan <u>tekst</u>, omdat dat laatste niet door een validator komt?

Het is overigens goed mogelijk om een CMS zonder WYSIWYG mogelijkheden in de markt te zetten. Zelfs de Fronteers hebben voor zo'n CMS gekozen :P
5 Kor Dwarshuis op 03-02-2008 om 10:59 uur:
@Krijn, als reactie op je laatste opmerking: hoe creëer je dan een tabel als je data wilt presenteren, als HTML niet toegestaan is, en een WYSIWYG uit den boze? Werk je dan met http://www.textism.com/tools/textile/?

Als iemand trouwens een WYSIWYG editor weet die inhoud van presentatie scheidt niet met SPAN's strooit, en een juiste kopregelhiërarchie weet af te dwingen, etc.: ik hou me aanbevolen.
6 Raph de Rooij op 04-02-2008 om 08:49 uur:
Veel van de 'deprecated' markup heeft te maken met weergave. Zoals Krijn aangeeft zijn er in dat gevallen prima alternatieven voorhanden in CSS:
<U> => <span class="u">
in CSS:
.u { text-decoration: underline; }

<NOBR> => <span class="nobr">
in CSS:
.nobr { white-space : nowrap }

Een goede HTML-editor, zo een die configureerbaar is op dit soort punten, kan er er voor zorgen dat een redacteur er niet eens over hoeft na te denken; dit soort zaken wordt dan geregeld via de 'cleanup' van de editor.

Punt is alleen dat er nog geen aanpak bestaat voor dit soort alternatieven; zou het zinvol kunnen zijn om een 'referentielijst' aan te leggen van elementen en attributen - en hun alternatieven - die in de Strict DTD's niet (meer) zijn toegestaan? Een dergelijke lijst kan bruikbaar zijn voor website-eigenaren en daarmee ook voor degenen die editors ontwikkelen of aanpassen.
Kunnen we gelijk een lijst gaan aanleggen van editors (en/of configuratiescripts) die syntactisch en semantisch correcte HTML kunnen uitspugen, conform de referentielijst. Volgens mij zijn dergelijke zaken een interessant middel voor een beginnende vereniging als de Fronteers om naam te vestigen ;-)

Een populair attribuut dat als deprecated kan worden beschouwd maar nog wel veel wordt gebruikt is TARGET. Regelmatig krijgen we vragen of het misschien toch mag worden gebruikt. Tuurlijk, iedereen mag doen wat-ie wil; er is immers geen wet die het verbiedt. Maar als je aan Webrichtlijnen wil of moet voldoen, dan is gebruik van TARGET geen optie. Mede naar aanleiding van de vragen hierover heb ik een artikel geschreven waarin het 'probleem' van TARGET wordt toegelicht en een alternatief wordt uitgewerkt, zie www.raph.nl/deprecated/
(En nee, die pagina's zijn niet afgelopen week gemaakt; het staat er al sinds 2006...)

PS:
De genoemde referentielijst zou dus niet alleen CLASS waarden en CCS-alternatieven moeten bevatten, maar in een aantal gevallen (zoals bij TARGET) ook scripts. Volgens mij kan het huidige scriptje dat daarvoor wordt gebruikt wel wat 'leaner & meaner'.
7 Krijn op 04-02-2008 om 09:00 uur:
@Kor: de UI van de editor in m'n CMS is nog te brak voor woorden, maar voor tabellen gebruik ik inderdaad iets als Textile/Markdown.

@Raph: we kunnen best nog wat vrijwilligers gebruiken hoor ;)

Ik begrijp alleen niet wat er zoveel beter is aan <span class="u"> t.o.v. <u>, behalve dat je een validator er blij mee maakt. Hetzelfde eigenlijk voor target="_blank" t.o.v. een JavaScript hack (hoe uitgebreid die hack ook is).
Een editor moet het onderlijnen van tekst gewoon niet mogelijk maken. Die specifieke styling werkt verwarrend voor bezoekers, aangezien het op een link lijkt. Of is dat te kort door de bocht? :)
8 Sander Tekelenburg op 09-02-2008 om 17:15 uur:
Voor wat betreft de kwaliteit van de output van CMS-en zullen jullie misschien geinteresseerd zijn in het Web Repair Initiative, dat tot doel heeft die kwaliteit te verhogen. Zie http://webrepair.org/
9 Krijn op 09-02-2008 om 17:22 uur:
Ik zie dat ik nog een hoop te doen heb :)
Plaats een reactie