Fronteers — vakvereniging voor front-end developers

Webrichtlijn 7 & 8: Gebruik de Strict variant voor nieuwe websites, en ontwijk de Frameset variant

Bij de bouw van een nieuwe website: gebruik van HTML 4.01 of XHTML 1.0 de Strict variant. (R-pd.2.4) Gebruik geen frames op overheidswebsites. Gebruik daarom ook niet van HTML 4.01 of XHTML 1.0 de Frameset variant. (R-pd.2.5)

Dus...is er nog iemand die nieuwe templates met een Transitional doctype begint?

Het lijkt alsof we een beetje in herhaling vallen, maar dat is ook zo ;) Misschien moeten we voor de discussie maar wat richtlijnen samen gaan pakken.

Aangezien frames niet meer van deze tijd zijn en niet meer toegestaan zijn op overheidssites, wordt het gebruik van de Frameset doctype ook afgeraden. Is iedereen het met deze richtlijn eens? Zijn frames echt zo slecht voor toegankelijkheid?

Heb jij in de afgelopen 2 jaar nog (i)frames gebruikt? Zo ja, waarvoor?

Reacties

1 Blaise Kal op 12-02-2008 om 14:56 uur:
Ik had een interview gelezen met een blinde gebruiker die een screen reader gebruikte. Helaas kan ik dit interview niet terugvinden.

Deze gebruiker prefereerde frames (met duidelijke titels) boven een pagina die alle sectie bevatte. Bij frames kon deze persoon heel eenvoudig switchen tussen navigatie-frame en inhoud-frame. Bij pagina's die alle secties bevatten had hij er last van om door enorme menu's en lappen tekst te moeten browsen voordat hij aankwam bij wat hij zocht.

Ik bedoel hiermee te zeggen dat frames niet per definitie slecht toegankelijk zijn voor alle gebruikers. Niet dat ik wil pleiten voor frames: anchors zijn ook heel handig om te switchen tussen secties, en bij het linken en bookmarken zijn frames bijzonder onhandig.
2 Krijn op 12-02-2008 om 15:00 uur:
@Blaise: Volgens mij gebruikte Eric Velleman dat voorbeeld bij Evident (hoewel, in Frankrijk :p) ook..

Wellicht dat Raph ons hier meer over kan vertellen :)
3 Kilian Valkhof op 12-02-2008 om 16:09 uur:
Frames hebben problemen met gebruiksvriendelijkheid. Verder vallen ze best wel mee ;) Ze zijn echter door de tijd ingehaald en het is al een flink aantal jaar tijd voor wat anders.

Overigens zijn frames momenteel zo gelimiteerd in de SPEC's dat ze uberhaubt niet bruikbaar én valid tegelijk kunnen zijn.

Overigens herken ik dat verhaal ook, dat had dus best Eric Velleman kunnen zijn.

En inderdaad, een beetje fastforward naar de interessante webrichtlijnen zou wel leuk zijn :)
4 Arjan op 12-02-2008 om 20:17 uur:
Ja, dit voorbeeld kwam bij de meeting bij Evident aan de orde ;)

Volgens mij is het de bedoeling dat in HTML5 user-agents ook bepaalde toetshandelingen kunnen koppelen aan bepaalde elementen. Zo kan je bijvoorbeeld snel naar een element met daarin de navigatie gaan. Zolang de opbouw van de HTML maar goed is (je gebruikt geen elementen voor iets waar het niet voor bedoeld is), kan dit een goed alternatief zijn.

Theoretisch kan het nu al, want ongelooflijk veel webontwikkelaars geven het menu een ID-waarde of klassenaam als navigation, menu, nav etc.

Maar goed, de richtlijn. Voor websites is dit een hele goede. Webapplicaties willen nog wel eens frames gebruiken, maar die vallen buiten de richtlijn.
5 Gerrit Berkouwer op 12-02-2008 om 21:04 uur:
@Arjan: waarom vallen webapplicaties volgens jou buiten de richtlijnen? Hier is al eens over gepraat op het Stijlgids-weblog, zie

http://stijlgids.overheid.nl/actueel/weblog/webapplicaties_en_webrichtlijnen/

en

http://stijlgids.overheid.nl/actueel/weblog/webapplicaties_en_webrichtlijnen_2/

Uiteindelijk zeggen we er als overheid het volgende over:
http://www.webrichtlijnen.nl/vragen/faqs/webapplicaties/

Over deze richtlijn specifiek: het wordt een beetje saai, helemaal eens met de bovenstaande comments.
6 Arjan op 12-02-2008 om 22:42 uur:
@ Gerrit:

Niet omdat ik toegankelijkheid van webapplicaties niet belangrijk vind hoor, juist wél. Maar ik zag aan de richtlijn zelf dat daarin staat 'voor nieuwe websites'.

Desalniettemin bedankt voor je uitleg :)
7 Blaise Kal op 13-02-2008 om 15:08 uur:
@ Krijn & Arjan: Ik was niet bij Evident bijeenkomst aanwezig. Volgens mij had het interview gevonden via een Naarvoren Zijlijn, al enige tijd terug. Blijkbaar is het een typisch voorbeeld in deze discussie.

Overigen was hier misschien een interessante discussie ontstaan als er ook de vraag werd gesteld of jij in de laatste twee jaar (i)frames hebt gebruikt, en zo ja, waarom.
8 Krijn op 13-02-2008 om 15:25 uur:
Je mag de vraag hier ook zelf stellen natuurlijk. Heb 'm toegevoegd aan de post.

Ik gebruik nog wel eens iframes in nieuwsberichten op de site van mijn badmintonvereniging, om Live Scoring bij toernooien van een andere site over te nemen. <frameset> en <frame> heb ik al een hele tijd niet meer aangeraakt (volgens mij).

Voor een <iframe> heb je in principe een Transitional doctype 'nodig', maar wat dat betreft gaat validatie me te ver, en pas ik op zo'n moment niet de template aan.
9 Sander op 14-02-2008 om 00:28 uur:
De laatste keer dat ik een iframe heb gebruikt was bij een web-applicatie waar de pagina een zware flash wereldkaart bevatte, en voor elke bestemming in een wereldreis over die kaart moest (HTML) informatie getoond kunnen worden, inclusief links naar de vorige en volgende bestemming.
De gehele pagina herladen was geen optie - de gebruiker één keer laten wachten op die Flash-kaart was al erg genoeg. Gelijk de informatie voor alle bestemmingen laden was ook geen optie; die hoeveelheid informatie was niet te overzien. De informatie met ajax laden is overwogen, maar je wil dat back- en forward gewoon blijven werken, en hoewel daar natuurlijk workarounds voor zijn langs de ajax weg, was een iframe een veel logischere oplossing, die bovendien ook nog werkt als JavaScript uit staat, en een stuk eenvoudiger viel te implementeren (inclusief openen in een nieuwe tab en daarmee de mogelijkheid om individuele bestemmingen te bookmarken).

En ja, ik heb de tijd genomen om de stricte doctype uit de standaard header van die website specifiek voor die ene pagina te vervangen met een transitional doctype.


Overigens zal HTML5 weg doen met het verschil tussen transitional en strict, en is een iframe in HTML5 dan ook altijd toegestaan (zoals het er nu naar uit ziet). Ik denk dat dit een goede zaak is. iframes zijn meestal niet de juiste oplossing, maar ze moeten wel toegestaan zijn in die instanties waar ze dat wel zijn. (Hoewel er eventueel nog beargumenteerd zou kunnen worden dat een dergelijke instantie nooit zou zijn ontstaan zonder een dergelijke flash applicatie waarmee op zichzelf al een minder toegankelijke situatie werd gecreëerd.)
10 Raph de Rooij op 18-02-2008 om 13:16 uur:
@Blaise Kal: Je schrijft: "Ik bedoel hiermee te zeggen dat frames niet per definitie slecht toegankelijk zijn voor alle gebruikers."

Die opmerking is juist, maar in de praktijk (was en) is volledig juiste toepassing van frames tamelijk zeldzaam. En dan nog zijn er, behalve het ene voordeel, een heleboel nadelen aan verbonden.
Volgens mij is, in het voorbeeld dat je beschrijft, het gebruik van skiplinks in combinatie met een goed gestructureerde pagina een beter alternatief dan het gebruik van frames. Maar op de meeste website ontbreken skiplinks, dus dat verklaart mogelijk de voorkeur van de blinde ervaringsdeskundige.

Overigens hebben frames nog een belangrijk nadeel in een tijd waarin vaak de meerderheid van het bezoek op de website terecht komt via een zoekmachine: zonder kunstgrepen (die meestal afhankelijk zijn van javascript) mis je in zo'n geval de belangrijkste context (sitenavigatie, look-and-feel, branding). Alleen al om die reden zijn frames niet wenselijk.

Nog een interessante vraag voor de Fronteers: zou het OBJECT element een alternatief kunnen zijn voor IFRAME? In FireFox en Opera werkt het probleemloos, maar in Internet Explorer 6 kreeg ik het zo snel niet aan de praat. Overigens is het antwoord niet afhankelijk van een goede werking in IE, maar de vraag kwam op bij het dichten van deze reactie en het leek me wel een boeiende. Volgens mij is het oneigenlijk gebruik, want OBJECT is bedoeld voor "rendering common data types such as text, GIF images, colors, fonts, and a handful of graphic elements. To render data types they don't support natively, user agents generally run external applications. The OBJECT element allows authors to control whether data should be rendered externally or by some program, specified by the author, that renders the data within the user agent."
Zie ook http://www.w3.org/TR/html401/struct/objects.html#h-13.3 en de daarop volgende alinea's.
11 Sander op 18-02-2008 om 18:40 uur:
@Raph: Ik weet dat de webrichtlijnen zich er nog niets van aan kunnen trekken, maar in het algemeen zou ik bij vragen over wat wel of niet "oneigenlijk" gebruik is al eerder naar HTML5 dan naar HTML4 kijken, net zoals je bij CSS al jarenlang naar CSS 2.1 kijkt en niet naar CSS 2, want de officiële status van CSS 2.1 als "working draft" of "candidate recommendation" betekent een heel stuk minder dan de veel grotere hoeveelheid tijd en aandacht die aan die nieuwere specificatie is besteed.

En HTML 5 zegt:
"The object element can represent an external resource, which, depending on the type of the resource, will either be treated as an image, as a nested browsing context, or as an external resource to be processed by a third-party software package." (nadruk van mijn hand).
12 Michiel op 17-01-2009 om 16:51 uur:
Ik vind het zo'n ongeloofelijke flauwekul, al dat gezeur overal over de nadelen van framesets en frames. Ok, je moet wat kunstgrepen toepassen voor bezoekers die via Google op een losse frame komen, ik snap wel dat dat voor overheidspagina's en die van bedrijven amateuristisch is. Maar voor de rest...Ik heb de afgelopen maanden veel werk verricht om mijn website te verbeteren en heb daar ook framesest voor gebruikt. Voor een hobby-site is dat gewoon heel handig!

Kijk maar op: http://www.rockarolla.nl/gitaartab.htm

zeg nou zelf, je kunt zo toch heel handig door alle informatie navigeren? Waarom zou dat niet gebruiksvriendelijk zijn??? Maar misschien moet ik toch maar eens kijken of ik een alternatieve versie maak voor HTML5 gebruikers (zit dat dan in de nieuwste browsers ?) omdat die anders alleen het onvolledige noframes gedeelte zien..
13 Krijn op 17-01-2009 om 17:50 uur:
@Michiel: wat betreft gebruiksvriendelijk navigeren... Je bezoekers kunnen bijvoorbeeld de meeste links niet in een nieuw tabje openen, zonder meteen de navigatie te verliezen. Meer nadelen vind je op http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/frames/nadelen/.

En een alternatieve versie voor HTML 5 maken is niet zo zinvol. Maar dat mag iemand anders uitleggen :)
14 Michiel op 20-01-2009 om 13:35 uur:
nou..ik zou niet weten waarom op mijn website mensen een link in een nieuw venster zouden willen openen, dat is ook helemaal niet de bedoeiing......!. Alleen bij de pagina's met tablature heb ik een link naar een nieuw venster zodat er altijd geprint kan worden....

En ik heb nu een javascript code toegevoegd aan bepaalde frames, zodat bezoekers via een zoekmachine altijd weer op de index pagina komen, mooi toch?
15 Michiel op 20-01-2009 om 13:38 uur:
nogmaals mij, ik vind juist al die websites waarbij de navagatie aan de bovenkant van het beeld verdwijnt als je naar beneden scollt zo onhandig en niet-proffesioneel ogend!

zo die zit..
16 Krijn op 20-01-2009 om 13:48 uur:
En of die zit :)
17 Wybe op 20-01-2009 om 13:57 uur:
Motorhead is wel cool!
18 Michiel op 20-01-2009 om 17:12 uur:
he, thanks!
19 Joop op 08-09-2009 om 04:19 uur:
Krijn op 17-01-2009 om 17:50 uur:
@Michiel: wat betreft gebruiksvriendelijk navigeren… Je bezoekers kunnen bijvoorbeeld de meeste links niet in een nieuw tabje openen, zonder meteen de navigatie te verliezen. Meer nadelen vind je op http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/frames/nadelen/.

Daar staat dan ook een enorme hoeveelheid bagger ien non-argumenten. Als sites niet toestaan dat je in een frame iets van hun opneemt staan ze ook niet toe dat je hun pagina laadt als je op hun site bent, want dat is identiek. Alleen met een frame doe je dat via een gebruiksschil. Wel bemerk ik dat veel sites met frames slecht zijn ontworpen en dat er niet is nagedacht over de functie van het toe te passen frame. Maar dat ligt dan niet aan frames, maar aan de ontwerper. Dat spiders last hebben van mijn frames is ook precies de bedoeling, ik ben er helemaal niet van gecharmeerd dat alles maar zonder mijn toestemming direct benaderbaar wordt. Zo worden belangrijke berichten van mijn zijde ondermijnd, zoals bijvoorbeeld copyright en aansprakelijkheid. Als de gebruiker via de voordeur komt worden ze daar op gewezen. Dat gebruikers de pagina niet kunnen plaatsen in hun favorieten is ook onjuist. Bij een juist ontworpen frame geeft dat geen problemen en verder kan de in het frame getoonde worden gekozen met de andere muisknop. Het zal echter niet de eerste keer zijn dat mensen GEEN handleiding lezen, maar dat moet je dan ook niet gaan promoten door daar dan maar op in te spelen. Frames zijn helemaal van nu, mits goed ontworpen. En zonder frames gaat het gewoon niet. Veel sites hebben het in zich om RSI problemen op te lopen die zich niet voordoen bij een juist geformuleerd frame.
20 Krijn op 08-09-2009 om 08:27 uur:
@Joop: Heb je voorbeelden van sites die het goed en prettig gebruiken?
21 Sander Aarts op 08-09-2009 om 11:31 uur:
@Joop: "Dat spiders last hebben van mijn frames is ook precies de bedoeling, ik ben er helemaal niet van gecharmeerd dat alles maar zonder mijn toestemming direct benaderbaar wordt. Zo worden belangrijke berichten van mijn zijde ondermijnd, zoals bijvoorbeeld copyright en aansprakelijkheid. Als de gebruiker via de voordeur komt worden ze daar op gewezen."

Dat is dan weer helemaal niet van nu volgens mij (net als frames overigens). Mensen zoeken bepaalde informatie en als die op een achterliggende pagina staat, dan zijn zij het meest geholpen wanneer ze daar direct kunnen komen.
22 Raph de Rooij op 08-09-2009 om 12:12 uur:
@Joop: Het 'RSI-probleem' is ook met CSS eenvoudig oplosbaar. En het spider-probleem moet je helemaal niet met frames willen oplossen; één enkele tag op een pagina volstaat, bijvoorbeeld
<meta name="robots" content="noindex, nofollow">

Vanuit het oogpunt van usability hebben frames juist grote nadelen. In een artikel uit 1996(!), met als titel 'Why frames suck', gaf usability-expert Jacob Nielsen dat al aan (zie www.useit.com/alertbox/9612.html en ook www.useit.com/alertbox/styles_vs_frames.html).

Kortom: het enkele (veronderstelde) voordeel weegt niet op tegen het grote aantal nadelen. Frames zijn helemaal niet van nu. In tegendeel: ze zijn een achterhaald concept*, zóóóó jaren negentig!

*: voor het IFRAME element maak ik hier even een uitzondering ;-)
23 Raph de Rooij op 08-09-2009 om 12:23 uur:
Een aanvullend argument waarom frames een achterhaald concept zijn, is te vinden op www.w3.org/TR/2009/WD-html5-diff-20090825/#absent-elements:

The following elements are not in HTML 5 because their usage affected usability and accessibility for the end user in a negative way:

* frame
* frameset
* noframes

Hieruit zou je mogen concluderen dat het argument dat frames "helemaal van deze tijd zijn" is minderheidsstandpunt vertegenwoordigt.
Plaats een reactie