Webrichtlijn 10 & 11: Gebruik ECMAScript en het W3C DOM volgens de specificatie
Indien client-side script wordt gebruikt, gebruik ECMAScript volgens de specificatie. (R-pd.2.7) Indien men elementen in de HTML hiërarchie manipuleert, maak gebruik van de W3C DOM volgens de specificatie. (R-pd.2.8)
Van ECMA-262 is de 3e editie de huidige standaard. Zijn er al scripting goeroes die met de laatste editie aan het spelen zijn?
Is ECMA-262 trouwens de enige standaard die we kennen, of gebruiken we ook wel 'ns E4X?
En in welke omgevingen schrijf jij je scriptjes zoal?
Wat betreft het DOM; de Webrichtlijnen spreken alleen over DOM Level 1. Het is mij niet helemaal duidelijk of Level 2 en/of 3 ook 'toegestaan' zijn.
Hoe fanatiek ben jij wat betreft deze richtlijn? Is innerHTML hiermee ook uit den boze?
Reacties
- 1 Wilco op 26-02-2008 om 11:25 uur:
- Op het Accessibility forum hebben we onlangs een discussie (http://forum.accessibility.nl/viewtopic.php?id=171) gevoerd precies over dit vraagstuk; Kun je innerHTML gebruiken en toch aan R-pd 2.8 voldoen? Voor iedereen geïntereseerd in die discussie zou ik je daar naar toe willen verwijzen.
DOM level 2 en 3 zijn hierbij ook toegestaan, al heeft 3 niet zo veel zin op het moment vanwege gebrekkige ondersteuning. - 2 Marc op 26-02-2008 om 13:34 uur:
- Ik loop alleen tegen deze richtlijn aan bij het embedden van Flash. Zoals ook al in de thread op accessibility.nl naar voren komt, gebruiken scripts als SWFobject en UFO innerHTML, wat niet mag van de richtlijn.
Zelf heb ik er absoluut geen moeite mee om innerHTML te gebruiken, zeker zolang de alternatieven (en dan met name de alternatieven om flash te embedden) wat mij betreft niet beter zijn.
De situatie is echter dat het helemaal niet uitmaakt wat ik ervan vind. Als een klant eist (wettelijk moet eisen) dat de site aan de richtlijnen voldoet, dan heb ik te gehoorzamen. Exit innerHTML/SWFobject, enter Flash Satay.
Het is jammer dat deze webrichtlijn heel stellig geformuleerd is. Dit in tegenstelling tot andere richtlijnen, waar zinsnedes als "gebruik zoveel mogelijk" in staan. - 3 Raph de Rooij op 26-02-2008 om 14:06 uur:
- @Marc: Donderdag 20 maart komt de normcommissie van het Waarmerk drempelvrij.nl bij elkaar om dit soort zaken te bespreken. Op zichzelf is er niet heel veel mis met de richtlijn zelf, maar bij toetsing op deze richtlijn is wat mij betreft best wel wat 'speelruimte' mogelijk. Die is alleen op dit moment niet beschreven in het normdocument.
Op http://forum.accessibility.nl/viewtopic.php?pid=997#p997 heb ik hierover een reactie geplaatst. Ik ben benieuwd wat de Fronteers vinden van hetgeen daar wordt voorgesteld. - 4 Stephen Hay op 26-02-2008 om 19:35 uur:
- Ik ben het eens met Raph: er is best wat speelruimte mogelijk, ook al is dit niet in het normdocument expliciet gemaakt. Deze richtlijn is bedoeld om het gebruik van open standaarden en best practices op het gebied van client-side scripting te ondersteunen. Omdat afhankelijkheid van client-side scripting door de Webrichtlijnen niet gewenst is, lijken discussies over bijv. innerHTML weinig zinvol mbt het resultaat voor de eindgebruiker. Hier maak ik me altijd zorgen over: dat het doel van de oorspronkelijke Webrichtlijnen uit het oog wordt verloren, en dat discussies over techniek en proces gaan in plaats van eindresultaat. Dit is job security voor de testers van websites, maar de Webrichtlijnen zijn bedoeld om de kwaliteit van websites te verbeteren, en niet om de praktijk in de weg te staan.
Om in te haken op de discussie van Accessibility, en met name het commentaar van Raph: we moeten niet vergeten dat een van de redenen dat sommige kundige JavaScript programmeurs innerHTML nog/soms gebruiken is om dezelfde reden dat wij uberhaupt Flash gebruiken: bereik.
Wel opmerkelijk dat een hele discussie is ontstaan over het correct toepassen van een open standaard om een propietary technologie te kunnen implementeren. - 5 Sander A op 26-02-2008 om 20:49 uur:
- Bij het gebruik van JavaScript houdt ik me eigenlijk helemaal niet zo bezig met het feit of het volgens de standaarden is, in ieder geval niet die van ECMA. Ik probeer wel, wanneer ergens zowel een IE- als een W3C-methode voor bestaat, de W3C-methode voorrang te geven indien mogelijk. Maar ik gebruik dus tevens propretaire methodes en properties daar waar nodig.
De rede dat ik hier minder strict in ben dan bij HTML en CSS is denk ik dat je bij JavaScript allerlei condities kunt checken waardoor je het unobtrusive kunt maken/houden.
Maar misschien wordt het inderdaad tijd om eens in de ECMA specificaties te duiken. Maar eerst 'Pro JavaScript Design Patterns' eens uitlezen, pfff.
@Stephen: de voornaamste rede om innerHTML te blijven gebruiken is gemak en snelheid (http://www.quirksmode.org/dom/innerhtml.html) - 6 Koen Willems op 26-02-2008 om 22:49 uur:
- Om praktische redenen ben ik geen tegenstander van de gedachten van Raph en Stephen, maar ik meen wel dat de essentie van de discussie daarbij enigszins uit het zicht verloren dreigt te gaan.
Er dient immers onderscheid te worden gemaakt tussen:
- de norm
- de toetsing aan de norm.
De norm is vastgelegd in de Webrichtlijnen.
De toetsing daaraan is beschreven in een tweetal door de Stichting Drempelvrij beheerde documenten, te weten het Normdocument (dat misschien voor de duidelijkheid anders had moeten heten) en het Caesura en sampling-document.
Als nu in de praktijk aan volledige naleving van een webrichtlijn zwaarwegende bezwaren kleven, dan kan het onder omstandigheden (bijvoorbeeld omdat dat sneller kan) overwogen worden de toetsing aan die webrichtlijn soepeler te maken.
Daarmee echter wordt voorbij gegaan aan de kern van de zaak, te weten de vraag of de webrichtlijn zelf niet aanpassing behoeft!!!
Dat is dus de kanttekening die ik de 20e maart zal maken als ik 'mee ga' met de gedachtengang van Raph.
Als 'Toute le Monde' het erover eens is dat gebruik van innerHTML onder bepaalde condities zou moeten mogen, dan moet het ook mogen! - 7 Colin Meerveld op 28-02-2008 om 23:10 uur:
- Ik heb al wel wat zitten spelen met ES4 (Lijkt erg op Actionscript 3.0) maar moet zeggen dat ik het jammer vindt dat het erg complex wordt. Volgens mij is javascript ooit ontwikkeld om een eenvoudig te leren script taal te zijn. ECMAScript is hier de standaard versie van en editie 4 is alles behalve eenvoudig.
Zelf werk ik voornamelijk met de ECMAScript implementatie van Rhino. Hier heb ik ook de mogelijkheid om met E4X te werken. Dit maakt voor het grootste deel de DOM Core en helemaal innerHTML overbodig. Maar helaas heeft niet iedereen de luxe om voor 1 browser te ontwikkelen ;)
Wat betreft je vraag over welk level DOM je mag gebruiken voor de webrichtlijnen is heel eenvoudig. wanneer je aan de webrichtlijnen voldoet voldoe je ook aan WCAG 1.0 (Web content Accessibility Guidelines). Hier staat in checkpoint 11.1 het volgende:
"Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported."
M.a.w. De meeste modules van DOM 3 zijn aanbevolen door het w3c en is dus de laatste versie.
Helaas wordt deze nog niet door elke browser ondersteund maar dit is ook het geval bij DOM level 1. Welk level je gebruikt maakt dus eigenlijk niet zoveel uit. - 8 ppk op 29-02-2008 om 12:09 uur:
- Ik ben al maandenlang aan het nadenken over deze richtlijn, en ben voorlopig tot de conclusie gekomen dat het gebruik van niet-gestandaardiseerde methods en properties in elk geval geoorloofd is als er geen gestandaardiseerde varianten bestaan.
Een goed voorbeeld is offsetWidth, waarmee je de daadwerkelijke breedte van een element kunt uitlezen. Strikt genomen is dit een MS-uitbreiding, maar alle browsers ondersteunen het perfect en er was (tot een paar dagen geleden*) geen specificatie voor, en ook geen W3C property die dezelfde informatie biedt. Derhalve gebruik ik zonder aarzeling offsetWidth en dergelijken.
Ook voor innerHTML bestaat geen directe gestandaardiseerde variant; de W3C DOM geeft geen ruimte om de inhoud van een tag als string weer te geven of te gebruiken.
Tenslotte is er natuurlijk het punt dat IE sommige W3C DOM functionaliteiten niet ondersteunt en we wel de IE-varianten moeten gebruiken.
Derhalve interpreteer ik deze richtlijn als "Gebruik bij voorkeur JavaScript conform de specificaties, tenzij het echt niet anders kan."
* Inmiddels is http://www.w3.org/TR/cssom-view/ gepubliceerd; een draft met een definitie van offsetWidth die overeenkomt met wat browsers daadwerkelijk doen. - 9 Koen Willems op 22-03-2008 om 17:51 uur:
- Naar aanleiding van de hiervoor genoemde datum van 20 maart: we hadden zo'n volle agenda dat we aan dit punt niet toegekomen zijn.
De normcommissie komt op 10 april a.s. weer bij elkaar. - 10 Jules op 26-01-2010 om 23:00 uur:
- InnerHTML en webrichtlijnen:
Webrichtlijnen wiki R-pd.2.8