[HTML5] Validator serieus nemen, of weg er mee!

[livingtale]

Op deze site wordt vaak gewaarschuwd dat je de fouten uit je HTML moet halen via de W3C Validator.
IK haalde vaak mijn schouders daarover op, ondanks fouten deed ie het prima.
Maar ik hoorde toch ook vaak dat veel fouten door rating instanstanties, zelfs Googje, je zwaar aangerekend worden.
Dus ging overstag en begon het monnikenwerk om alle fouten er uit te halen. Soms was het zelfs een èchte fout.
En ziedaar: op het laats had ik nog maar 1 fout, en die werd niet door mij veroorzaakt, maar door AddThis.

Helaas, ik ging verder sleutelen aan de website en besloot een een slideshow op te nemen.
Helemaal perfect. Tot ik ontdekte dat in IE dat helemaal niet perfect was.
Het programma was in XHTML, dus dan maar overstappen naar HTML5 (en de / weghalen...)
Nu ook in IE perfect.

Maarrrr
De validator schoot van 1 fout, naar 274 fouten, 38 waarschuwingen.
Een andere site van mij deed het nog erger: van 1 fout naar 458, 26 waarschuwingen.
En het zat echt niet in het head gedeelte (behalve dat ik geen copyright mag claimen).

Vooral veel fouten over dat cellpadding e.d. niet in HTML maar in CSS moet.
Volgens mij niet echt een fout, en bovendien erg bewerkelijk omdat in CSS te doen.

Mijn vraag “hoe serieus moet je de Validator nemen”
en stelling
Stelling: “de HTML5 Validator schiet zijn doel voorbij”

Twee voorbeelden

in HTML5
http://www.moord-spelen.nl/

omgezet naar HTML4
http://www.moord-spelen.nl/moordspelen.html

in HTML4
http://www.bedrijfs-theater.nl/

omgezet naar HTML5
http://www.bedrijfs-theater.nl/bedrijfstheater.html

[RobIII]

livingtale schreef op donderdag 06 juni 2013 @ 11:05:
Stelling: “de HTML5 Validator schiet zijn doel voorbij”

Stelling: je moet de resultaten leren interpreteren.

Bepaalde "errors/warnings" kun je prima verdedigen en dus gewoon lekker negeren; het is niet zo dat je per sé "0 errors/warnings" moet hebben. De validator is enkel een ondersteunende tool.

Wat je echter, IMHO, niet kunt verdedigen zijn de fouten die er bij jou uitgehaald worden. Dat is gewoon brakke gare HTML uit 't jaar knoop. We hebben anno 2013 CSS you know?

[ Voor 10% gewijzigd door RobIII op 06-06-2013 11:20 ]

[Bosmonster]

De validator geeft je tips over hoe je code beter kan conform de standaarden anno nu. Als het jou niet uitmaakt om kwalitatief goede code te schrijven, dan kun je de validator idd negeren.

Wat jij omschrijft als monnikenwerk noemen we ook wel gewoon je vak beheersen.

Bepaalde "errors/warnings" kun je prima verdedigen en dus gewoon lekker negeren; het is niet zo dat je per sé "0 errors/warnings" moet hebben. De validator is enkel een ondersteunende tool.

In het geval van de webrichtlijnen is 0 fouten wel degelijk een eis

Verder heb je gelijk hoor en is het voornamelijk ondersteuning. Soms kies je bewust voor een bepaalde opstelling die misschien een fout in de validator oplevert, maar wel andere voordelen biedt.

Ik probeer wel altijd 0 fouten uit de ontwikkelde templates te krijgen, want dan is het makkelijk communiceren naar de back-end developers dat ze de output door de validator kunnen halen: groen = goed, rood = faal. Dat soort taal snappen ze

[ Voor 60% gewijzigd door Bosmonster op 06-06-2013 13:41 ]

[NMe]

Bosmonster schreef op donderdag 06 juni 2013 @ 13:38:
In het geval van de webrichtlijnen is 0 fouten wel degelijk een eis

"Richtlijnen" en "eis" in één zin is al ironisch op zichzelf natuurlijk.

Ook ik ga niet zitten hameren op sommige dingen, af en toe heb ik een goeie reden om een error of warning niet te fixen en ik heb zelfs één keer gehad dat een melding gewoon door een bug in de validator veroorzaakt werd, niet door mij. Dat gezegd hebbende ga ik wel voor zo min mogelijk fouten en los ik wél gewoon op wat ik op kan lossen zonder dat dat nare consequenties heeft.

Het klopt wel dat Google soms problemen heeft met niet-validerend spul, maar dat zal eerder door mismatching tags komen dan door dingen als cellpadding-attributen. Beiden zijn dingen die je eigenlijk op hoort te lossen, maar alleen dat eerste gaat je ranking beïnvloeden omdat Google potentieel geen chocola kan maken van je site.

[livingtale]

wat is er mis aan gare brakke code?

Wat mij betreft is het resultaat het enige wat telt. Ik ben slechts een amateur die helaas geen professional kan betalen. Crisis hè. Was vroeger al zo, maar de laatste jaren helemaal.
Dus ehhh ik "beheers" dit vak niet, en heb ook de pretentie niet.

En ja, ik heb een boek over CS3 aangeschaft, en doorgebladerd, maar ik begrijp werkelijk niet wat de meerwaarde van die verniewingen voor MIJ zijn. Echt niet.

[NMe]

Tsja, dan moet je wegblijven van de validator en gewoon aan blijven kloten en begrijp ik niet dat je überhaupt een vraag stelt. Sommige dingen gaan je rank op Google beïnvloeden. Andere dingen beïnvloeden alleen de onderhoudbaarheid van je website. Beiden beïnvloeden potentieel je portemonnee op de lange termijn.

[Barryvdh]

livingtale schreef op donderdag 06 juni 2013 @ 14:34:
wat is er mis aan gare brakke code?

Wat mij betreft is het resultaat het enige wat telt. [..]

Met zo'n instelling hoef je inderdaad niet veel waarde te hechten aan validators

[Verwijderd]

livingtale schreef op donderdag 06 juni 2013 @ 14:34:
wat is er mis aan gare brakke code?

Die instelling zegt al genoeg he. Als je geen zin hebt om tijd te investeren in kwaliteit moet je ook niet verbaasd zijn dat validators (of mensen) zeggen dat het bagger is.

[Dekaasboer]

Er zitten een hoop voordelen aan web standaarden.

Als je website op meerdere browsers en platformen moet werken en het liefst ook nog enigsinds vindbaar moet zijn in zoekmachines is het verstandig om er zo dicht mogelijk tegenaan te zitten.

De intrepretatie van de standaarden is tegenwoordig redelijk uniform tussen browsers. De intrepretatie van code daarbuiten echter vaak niet!

[Niet Henk]

Je moet simpelweg alleen waarde aan validators hechten, als het doel is correcte HTML te schrijven. Als het alleen gaat over hoe het er uit ziet, kan je wel een validator gebruiken om tikfouten er uit te proberen te halen, maar is 0 fouten op de validator geen doel. Er zijn genoeg dingen die prima werken in vrijwel elke webbrowser, maar incorrecte HTML zijn en dus niet correct zijn volgens elke validator.

Ikzelf vind validators wel leuke tools, om een beetje te kijken wat ik de volgende keer mogelijk anders kan aanpakken, en hoe dingen volgens de standaard moeten. Maar ik heb vaak genoeg dat ik bijvoorbeeld een <style> tag in de body neerzet, gewoon omdat het binnen het CMS waarin ik dan werk minder gedoe is, hoewel dat feitelijk incorrecte HTML is.

[ Voor 0% gewijzigd door Niet Henk op 06-06-2013 15:20 . Reden: spelfouten ]

[Bosmonster]

Je CMS de kwaliteit van je eindproduct laten bepalen is ook weer zoiets dat ik helaas te vaak zie.

[livingtale]

Dat mensen -professionals- mijn code maar niks vinden, daar kan ik mee leven.
Het resultaat is wat telt, denk ik dan.
Het wordt echter anders als dat het resultaat negatief beïnvloed.
Sommigen onder jullie zeggen van wel, anderen van niet.

Waarom ik deze discyssie begonnen ben.
In der eerste plaats omdat ik me zorgen maak.
Maar toch ook:
in de tweede plaats: mijn site wàs goedgekeurd door de Validator.

HTML is oa ontwikkeld omdat het niet meer zo precies hoeft (zegt mijn HTML5 boek).
En dan maakt de Validator de move dat het allemaal juist NIET goed meer is.
Dan snap ik niet, en daarom ging ik deze discussie aan....

En op de 4 major browsers doet ie het goed (wat weer niet zoveel met de Validator te maken heeft, volgens mij...)

Waar ik mij ook zorgen over maak is de opmerking van NMe:
"omdat Google potentieel geen chocola kan maken van je site"
Waarom zou Google dat? Als ik bekijk hoe Google mijn site 'ziet' is er niets aan de hand.

[Verwijderd]

Wel: je meest voorkomende fouten zeggen het zelf: "deprecated". Dat wil zeggen dat dat in oudere versies wel nog toegelaten was, maar nu niet meer. Inline styles toepassen is echt not done, gebruik CSS.

[Bosmonster]

livingtale schreef op donderdag 06 juni 2013 @ 15:10:

Waar ik mij ook zorgen over maak is de opmerking van NMe:
"omdat Google potentieel geen chocola kan maken van je site"
Waarom zou Google dat? Als ik bekijk hoe Google mijn site 'ziet' is er niets aan de hand.

Dat heeft te maken met de semantiek ("betekenis" grofweg). Stel je bouwt heel je site op met tabellen en b-tags voor je headers. Dan staat alles op de goede plek, maar is er geen duidelijke structuur en hierarchie. Een juiste opbouw zorgt voor een goede semantiek en dus leesbaarheid door systemen (zoals crawlers/spiders, maar ook screenreaders). Die weten dan wanneer een onderdeel van je pagina belangrijk is of niet, of welke content aan elkaar gerelateerd is bijvoorbeeld (zoals bij een lijst-element).

[ Voor 14% gewijzigd door Bosmonster op 06-06-2013 15:22 ]

[NMe]

livingtale schreef op donderdag 06 juni 2013 @ 15:10:
Waar ik mij ook zorgen over maak is de opmerking van NMe:
"omdat Google potentieel geen chocola kan maken van je site"
Waarom zou Google dat? Als ik bekijk hoe Google mijn site 'ziet' is er niets aan de hand.

Om het heel simpel te houden:

HTML:

<h1>Dit is de hoofdtitel van de pagina</h2>

Simpele tikfout, kan gebeuren. Je sluit nu een tag af die niet bestaat en je h1 sluit je überhaupt niet meer af. Google zal slim genoeg zijn om dat impliciet te doen zodra je de container afsluit waar die h1 in staat maar dan heb je dus potentieel een titel van enkele paragrafen lang. En laat nou de h1 enigszins van belang zijn voor je ranking...

Zo zijn er meer dingen die van invloed zijn en als jij niet de tijd erin wil stoppen of niet de instelling hebt om te voorkomen dat dit soort troep op je site verschijnt, dan ga je dat geheid een keer voelen in je bezoekersaantallen. Ik begrijp nooit waarom mensen wel hun auto naar een monteur brengen of als ze ziek zijn naar een dokter gaan maar wél denken dat ze zelf een website in elkaar kunnen zetten die net zo goed werkt als iets dat door een pro gemaakt is...

[ Voor 10% gewijzigd door NMe op 06-06-2013 15:20 ]

[Niet Henk]

Vergeet trouwens ook niet, dat de manier waarop je je pagina ontwerpt, (hoewel beperkt) wel invloed heeft op je laadtijd. Als je je inline styles eindeloos zit te copy-pasten, moet dit allemaal weer opnieuw en opnieuw ingeladen worden. Als je echter even snel een in-page stylesheet neerzet, dan hoeft dit allemaal maar 1x opgeschreven te worden. En laadtijd heeft weer invloed op page ranking.

En natuurlijk, stel je gaat een keer eens samenwerken met iemand, of de organisatie waarvoor je de site maakt het beheer gaat overnemen, dan is het erg handig als je beiden ongeveer dezelfde stijl aanhoud. En daarvoor is semantisch correcte HTML5 erg nuttig. Het houdt je broncode lekker leesbaar voor mens en machine.

Oh, en vergeet trouwens niet: werken met CSS maakt het zo enorm veel makkelijker om op een later moment de layout van je pagina te wijzigen. Je hoeft dan namelijk, als je alles braaf van classes en ID's voorziet, soms niet eens de HTML aan te passen om toch grote wijzigingen in je site door te voeren.

[ Voor 17% gewijzigd door Niet Henk op 06-06-2013 15:31 ]

[TERW_DAN]

livingtale schreef op donderdag 06 juni 2013 @ 11:05:
Vooral veel fouten over dat cellpadding e.d. niet in HTML maar in CSS moet.
Volgens mij niet echt een fout, en bovendien erg bewerkelijk omdat in CSS te doen.

Dit in CSS zetten is juist niet bewerkelijk. Het inline in je HTML zetten is juist heel bewerkelijk (en onbegonnen werk in 90% van de gevallen).

En om op je vraag terug te komen. Een validator helpt je om te zien waar fouten zitten in je code. Maar als je nu nog een site in tabellen maakt en die inline styles geeft dan zal het gebruiken van een validator ook niet heel zinvol meer zijn, omdat de eerste stap die je zet al niet handig is.
Als je als doel hebt om goed door een validator te komen (ongeacht of je een paar errors/warnings accepteert), dan moet je beginnen om te zorgen dat je in de basis al goed begint. En dat is dus niet met tabellen, tenzij 't om tabulaire data gaat.

[Nedra]

Volgens mij is het meeste al gezegd hier! Als 't je niet kan schelen, fine, dan niet! Anders kan je de validator errors aangrijpen om je outdated code + kennis eens aan te pakken. In dat geval kan je errors kan je alleen negeren als je ze begrijpt en bewust negeert.

[RM-rf]

Mijn vraag “hoe serieus moet je de Validator nemen”

Het is een stuk gereedschap.. als een hamer; een hamer moet je niet serieus nemen, maar vooral gebruiken waarvoor het geschikt is.

een stuk gereedschap betekent niet dat diegenen die het gebruikt gelijk alles goed zal doen, maar het kan erbij behulpzaam zijn, mits toegepast op de manier die het meest zinnig is

Stelling: “de HTML5 Validator schiet zijn doel voorbij”

dat ligt er vooral aan welk doel je ermee hebt...
ik vermoed dat je het verkeerde doel kiest... de validator zegt niks over browser-implementaties, quirks, hacks of bugs en voorkomt deze ook niet.

een validator kan je helpen je code en werkwijze te controleren, het simuleert de automatische verwerking van je code en kan je snel wijzen op fouten...

Overigens, ook HTML4 kun je valideren en het kan verder een zeer legitieme keuze zijn te kiezen voor een HTML4 doctype (zeker bij die getoonde wedsites zie ik geen echte meerwaarde in de keuze voor html5)

[_Thanatos_]

De validator is een hele technische validatie van je HTML. Hij kijkt of de HTML klopt met de geschreven standaard, en niet of je HTML werkt. Het doel is niet dat een nieuwere HTML minder fouten oplevert, want als jij nog legacy-meuk gebruikt die in HTML5 deprecated is, zoals cellpadding, dan loop je daar tegenaan. Dat is volkomen normaal.

Zoals gezegd, het is slechts een tool. Gebruik em vooral als je niet zeker bent, maar een valide document is geen garantie voor een werkend document. Op dezelfde manier is een invalide document ook geen garantie op een niet-werkend document. Wel kun je ervan op aan dat een valide document in alle browsers hetzelfde zal parsen tot een DOM-tree (dus niet per se hetzelfde renderen), gegeven dat alle browsers dezelfde HTML5-parser regels gebruiken (dat is dacht ik ook zo).

hoe serieus moet je de Validator nemen

Dat ligt eraan wat je doel is. Als je doel is om valide documenten op te leveren, is het een haast onmisbare tool. Maar valide documenten is niet iets waar de klant blij van wordt. Als je niet zeker bent van of je document valide is, en er treden vreemde layout-bugs op, of grote verschillen tussen twee browsers, kan de validator je helpen. Ook kan de validator je helpen bij een upgrade naar HTML5

Om RM-rf aan te vullen: zie het als een hamer, maar niet als een gouden hamer.

de HTML5 Validator schiet zijn doel voorbij

Het doel van de validator is een document tegen de geschreven standaard standaard aan te houden en te rapporteren wat er aan schort. Dat is exact wat de validator doet; niets meer en niets minder. Een voorbijgeschoten doel kun je dus eigenlijk nooit van spreken, bij een validator als deze.

[MueR]

Bosmonster schreef op donderdag 06 juni 2013 @ 13:38:
In het geval van de webrichtlijnen is 0 fouten wel degelijk een eis

De webrichtlijnen zijn antiek en stupide. HTML5 wordt niet ondersteund (het gebruik is al meteen 4 errors oid) en een style attribuut op een element mag ook niet (ook 3 fouten ofzo ). Dat zijn richtlijnen die ik niet meer serieus neem.

[Bosmonster]

MueR schreef op maandag 10 juni 2013 @ 10:51:
[...]

De webrichtlijnen zijn antiek en stupide. HTML5 wordt niet ondersteund (het gebruik is al meteen 4 errors oid) en een style attribuut op een element mag ook niet (ook 3 fouten ofzo ). Dat zijn richtlijnen die ik niet meer serieus neem.

Webrichtlijnen versie 2 is gewoon gebaseerd op WCAG2 en ondersteunt dus wel HTML5

En het klopt dat je geen inline styles mag gebruiken volgens de richtlijnen, wat volkomen terecht is lijkt me. Mensen met kleurenblindheid gebruiken vaak custom stylesheets, waar inline styles mee conflicteren. CSS hoort los te staan van je html.

Toegankelijkheid is helaas iets dat te vaak over het hoofd wordt gezien. Er zijn zo veel mensen met een beperking, dat het je zou verbazen hoeveel winst er te behalen is. Nadenken over kleurgebruik, schaalbaarheid, kwaliteit van code, toetsenbordnavigatie, etc is een onderdeel van je vak als serieuze front-end developer.



Nu kun je zoiets simpels als het niet gebruiken van inline styles afschuiven als een absurde eis bij de webrichtlijnen of het w3c, maar eigenlijk is het iets dat je jezelf eenvoudig af kan leren en waarmee je de kwaliteit van je werk kunt verbeteren.

Daarnaast is het ook logisch natuurlijk dat voor overheidsinstanties toegankelijkheid belangrijk is. Dit geldt voor hun gebouwen die rolstoelvriendelijk moeten zijn, maar natuurlijk ook voor hun websites. Ze kunnen de mensen waar de diensten voor bedoeld zijn natuurlijk niet negeren op basis van hun beperking. Zij zijn hier dus ook wettelijk toe verplicht.

Of je er meer of minder rekening mee wilt houden is uiteindelijk een keuze van de opdrachtgever natuurlijk.

[ Voor 45% gewijzigd door Bosmonster op 10-06-2013 11:34 ]

[_Thanatos_]

[slightly offtopic]
@Bosmonster, Waar haal je dat plaatje vandaan? Is een mooi plaatje om aan klanten te kunnen laten zien dat we weldegelijk tijd in accessibility moeten steken.

[MueR]

Bosmonster schreef op maandag 10 juni 2013 @ 11:18:
Webrichtlijnen versie 2 is gewoon gebaseerd op WCAG2 en ondersteunt dus wel HTML5

Nou, ik kreeg gezever over HTML5 van ze iig.

En het klopt dat je geen inline styles mag gebruiken volgens de richtlijnen, wat volkomen terecht is lijkt me. Mensen met kleurenblindheid gebruiken vaak custom stylesheets, waar inline styles mee conflicteren. CSS hoort los te staan van je html.

*knip*

Nu kun je zoiets simpels als het niet gebruiken van inline styles afschuiven als een absurde eis bij de webrichtlijnen of het w3c, maar eigenlijk is het iets dat je jezelf eenvoudig af kan leren en waarmee je de kwaliteit van je werk kunt verbeteren.

Klopt, voor 99.9% van de gevallen. In sommige gevallen is het perfect verdedigbaar om een inline style (of script) te gebruiken, bijvoorbeeld voor een background image op een enkel element wat uit je database komt. Om het compleet af te serveren is imho gewoon kortzichtig, en tot ze dergelijke idioterie uit de richtlijnen halen zal ik ze met een korrel zout nemen. Het slaat natuurlijk nergens op om een hoop extra css te gaan kloppen voor een paar background images die uit een database komen, puur om aan de webrichtlijnen te voldoen.

[Bosmonster]

_Thanatos_ schreef op dinsdag 11 juni 2013 @ 12:45:
[slightly offtopic]
@Bosmonster, Waar haal je dat plaatje vandaan? Is een mooi plaatje om aan klanten te kunnen laten zien dat we weldegelijk tijd in accessibility moeten steken.

http://www.microsoft.com/...id/feiten-en-cijfers.aspx

MueR schreef op dinsdag 11 juni 2013 @ 13:31:
[...]

Nou, ik kreeg gezever over HTML5 van ze iig.


[...]

Klopt, voor 99.9% van de gevallen. In sommige gevallen is het perfect verdedigbaar om een inline style (of script) te gebruiken, bijvoorbeeld voor een background image op een enkel element wat uit je database komt. Om het compleet af te serveren is imho gewoon kortzichtig, en tot ze dergelijke idioterie uit de richtlijnen halen zal ik ze met een korrel zout nemen. Het slaat natuurlijk nergens op om een hoop extra css te gaan kloppen voor een paar background images die uit een database komen, puur om aan de webrichtlijnen te voldoen.

Een contentuele afbeelding hoort sowieso niet als background-image geimplementeerd te worden. Dit is eenvoudig anders op te lossen.

Toegankelijkheid en SEO staan, zoals eerder aangegeven, ook erg dicht bij elkaar. Ook vanuit SEO wil je contentuele afbeeldingen als img-tags oplossen, met bijbehorende beschrijvende alt-tekst.

Ik zal niet ontkennen dat er best wel eens conflicterende belangen zijn tussen toegankelijkheid en modern, performance-gericht, front-enden (responsive of mobile first, om maar iets te noemen). Maar iets eenvoudigs als hierboven is absoluut geen argument en behoort simpelweg tot kwalitatief goede code (scheiden van content en opmaak).

[ Voor 16% gewijzigd door Bosmonster op 11-06-2013 14:27 ]

[incaz]

Ik kan eigenlijk niet echt een fijn overzicht vinden van de eisen van de webrichtlijnen, in een overzichtelijk formaat. Wat ik tegenkwam was vrij abstract met veel doorverwijzingen, en dan ook nog eens voornamelijk toegespitst op klassieke sites met veel inhoud, minder gericht op bv communities.
En 1 set had het nog wel slechts over xhtml en html 4.01.

Want ik ben eigenlijk wel nieuwsgierig hoe de boel er voor staat, maar ik heb liever een vrij eenvoudig overzichtje dan dat ik het allemaal diep moet doorspitten.

Ook wat tips en tricks en voorbeelden voor juiste semantische markup bij community content is trouwens welkom, want ook daar zijn de voorbeelden vaak meer inhoudsgerichte sites, en vind ik het niet altijd vanzelfsprekend hoe je dat zou vertalen naar een marktplaats of een profielpagina etc.

De validator kwam overigens met bemoedigend weinig foutjes aan

[Bosmonster]

Denk dat je het beste even hier kunt kijken
http://versie2.webrichtlijnen.nl

Het is ook niet dat we ieder project volledig volgens de richtlijnen uitvoeren hoor. Alleen als daar behoefte naar is en/of er op getoetst gaat worden. Met name video blijft een pijnpunt als je dat echt goed wilt doen (en daar word je niet vrolijk van )

Maar het geeft je wel een goed inzicht in hoe je kwalitatief goed kunt ontwikkelen en uiteindelijk haal je daar profijt uit voor zowel toegankelijkheid als SEO.

[ Voor 77% gewijzigd door Bosmonster op 11-06-2013 14:36 ]

[MueR]

Bosmonster schreef op dinsdag 11 juni 2013 @ 14:19:
Een contentuele afbeelding hoort sowieso niet als background-image geimplementeerd te worden. Dit is eenvoudig anders op te lossen.

Toegankelijkheid en SEO staan, zoals eerder aangegeven, ook erg dicht bij elkaar. Ook vanuit SEO wil je contentuele afbeeldingen als img-tags oplossen, met bijbehorende beschrijvende alt-tekst.

Nu heb je het over content, ik niet. Ik heb het over een background. Een foto die op de background van de pagina staat, dat soort spul.

[Bosmonster]

MueR schreef op dinsdag 11 juni 2013 @ 14:43:
[...]

Nu heb je het over content, ik niet. Ik heb het over een background. Een foto die op de background van de pagina staat, dat soort spul.

Toegankelijkheid begint bij het design. Denk dat in dit specifieke geval het probleem daar dan ook al begint

Een foto is wel degelijk content natuurlijk. Het is geen nikszeggend lijntje oid, maar een gerelateerde foto bij de pagina die toevallig als achtergrond ingesteld staat. Zonder die foto mis je waarschijnlijk wat in de context of sfeer.

Maar goed, het zijn richtlijnen. Het worden pas eisen als je de site ook daadwerkelijk getoetst wilt hebben (zoals voor de overheid). Het het zijn dan ook afwegingen die je moet maken, maar die beginnen wel al bij het designproces natuurlijk.

[ Voor 18% gewijzigd door Bosmonster op 11-06-2013 15:17 ]

[Nedra]

Mwah daar kan je eindeloos over discusseren, maar ik denk dat je in veel gevallen donders goed kan uitmaken wanneer een foto als een background image of als img geplaatst kan worden.

Ik moet wel zeggen dat ik laatst in een paar projecten ook niet zo netjes ben geweest, gewoon vanwege het feit dat de dingen die ik wou ontzettend makkelijk te regelen waren/zijn met background-position, etc. en anders alleen goed opgelost kon worden met javascript. Dan gebruik ik liever wat CSS met een kleine fallback voor seo en screen readers dan dat ik er weer een heel script aanhang. Afhankelijk van het project moet je soms ook voor wat progressie durven te gaan.

[incaz]

Bosmonster: dat vind ik te simpel gesteld hoor. Natuurlijk kunnen afbeeldingen slechts vormgeving zijn, en er kunnen wel degelijk situaties zijn dat dit het eenvoudigst op te lossen is met inline styles: dynamisch gegenereerde css maken het niet eenvoudiger (en heeft hoe dan ook een performance hit op langzame verbindingen: namelijk of het verlies van caching, of een extra request.)

Overigens is de grap dat als je in Firefox bv kiest voor 'geen stijl' er ook geen inline style geparsed wordt. Dus ik snap de zin van 'geen inline styles' ook niet helemaal.

[Bosmonster]

incaz schreef op dinsdag 11 juni 2013 @ 15:19:
Bosmonster: dat vind ik te simpel gesteld hoor. Natuurlijk kunnen afbeeldingen slechts vormgeving zijn, en er kunnen wel degelijk situaties zijn dat dit het eenvoudigst op te lossen is met inline styles: dynamisch gegenereerde css maken het niet eenvoudiger (en heeft hoe dan ook een performance hit op langzame verbindingen: namelijk of het verlies van caching, of een extra request.)

Styling hoort in CSS, content in de HTML. Das de simpele regel. Nu kunnen we eindeloos zeveren over een grijs gebied zoals een foto als achtergrond, maar dat lijkt me niet heel zinvol. Als je de richtlijnen wilt volgen en je site getoetst wilt hebben zul je over dat soort dingen na moeten denken, maar anders boeit het natuurlijk niet zo heel erg, buiten het idealistische om.

Overigens is de grap dat als je in Firefox bv kiest voor 'geen stijl' er ook geen inline style geparsed wordt. Dus ik snap de zin van 'geen inline styles' ook niet helemaal.

De achterliggende reden is o.a. doordat kleurenblinden of slechtzienden vaak aangepaste styles gebruiken. Deze overschrijven echter niet de inline styles. De richtlijn is ook dat je dit soort aanpassingen niet in de weg mag zitten of blokkeren (en dus ook een van de redenen waarom een stricte scheiding van content en opmaak zo belangrijk is).

[ Voor 3% gewijzigd door Bosmonster op 11-06-2013 15:24 ]

[incaz]

Inline styles zijn anders gewoon toegestaan volgens de spec hoor
Omdat het gewoon styles zijn, en er expliciet is vastgesteld dat styles op drie plekken kunnen worden gedefinieerd: apart css-doc, header en inline.
Bovendien ging de eerste scheiding over de scheiding van opmaak en content. Die scheiding is prima intact.

Ik snap overigens niet waarom die de inline styles niet overschrijven, dat is toch gewoon mogelijk?

[MueR]

incaz schreef op dinsdag 11 juni 2013 @ 15:30:
Inline styles zijn anders gewoon toegestaan volgens de spec hoor
Omdat het gewoon styles zijn, en er expliciet is vastgesteld dat styles op drie plekken kunnen worden gedefinieerd: apart css-doc, header en inline.

Je vergeet scoped nog

[Hydra]

livingtale schreef op donderdag 06 juni 2013 @ 14:34:
wat is er mis aan gare brakke code?

Wat mij betreft is het resultaat het enige wat telt. Ik ben slechts een amateur die helaas geen professional kan betalen.

Dan is dit wel het meest nutteloze topic dat ik in tijden gezien heb. Web validators zijn bedoeld om professionals te ondersteunen. Als jij niet de behoefte hebt kwaliteit te leveren lijkt het me nogal wiedes dat een validator geen nut heeft.

[Bosmonster]

incaz schreef op dinsdag 11 juni 2013 @ 15:30:
Inline styles zijn anders gewoon toegestaan volgens de spec hoor
Omdat het gewoon styles zijn, en er expliciet is vastgesteld dat styles op drie plekken kunnen worden gedefinieerd: apart css-doc, header en inline.
Bovendien ging de eerste scheiding over de scheiding van opmaak en content. Die scheiding is prima intact.

Ik snap overigens niet waarom die de inline styles niet overschrijven, dat is toch gewoon mogelijk?

Het ging even niet om het volgen van de spec, maar om best practices als het gaat om toegankelijkheid, of specifieker het volgen van de webrichtlijnen.

Uiteraard valideren inline styles prima

Een target="_blank", een Flash-embed of een link naar een Word-document valideren ook prima, maar ook dat is niet toegestaan ivm toegankelijkheid bijvoorbeeld.

[ Voor 14% gewijzigd door Bosmonster op 11-06-2013 16:05 ]

[incaz]

MueR schreef op dinsdag 11 juni 2013 @ 15:51:
Je vergeet scoped nog

Ha, nieuwe horizonten. Alleen de support is nog een beetje mager

Bosmonster: maar waarom dan extra beperkingen opleggen? Vooral als ze technisch gezien niet noodzakelijk zijn? Ik snap wat dat betreft de bezwaren van NMe heel goed. Zelfs al is er in de meeste gevallen een handigere oplossing dan inline styles, soms is het alternatief bijzonder onwerkbaar, en de aanname dat het leidt tot slecht-toegankelijke websites is zeker niet algemeen waar. Dus ik vind het afkeuren nogal rigoreus.

[Hydra]

incaz schreef op dinsdag 11 juni 2013 @ 16:06:
Dus ik vind het afkeuren nogal rigoreus.

Het hele idee is dat de data (html/xml/whatever) en hoe dit weergegeven wordt volledig gescheiden zijn. Inline styles volgen dit princiepe niet. Zie het als voortschreidend inzicht: inline styles zijn een foute toevoeging en niet meer valid in de wereld van vandaag.

De HTML van gisteren doet 't nog wel, maar als je nu een site maakt, maak je die voor de wereld van vandaag. Niet voor die van gisteren (wat niet wegneemt dat je wel compatible moet zijn met de browsers van 100 jaar terug helaas maar dat is een ander verhaal).

[Bosmonster]

incaz schreef op dinsdag 11 juni 2013 @ 16:06:
[...]


Bosmonster: maar waarom dan extra beperkingen opleggen? Vooral als ze technisch gezien niet noodzakelijk zijn?

Omdat je een user interface aan het developen bent, geen stuk "techniek". Wat jij beperkingen noemt, kun je ook verbeteringen noemen, die veel mensen je in dank af zullen nemen.

Dus ik vind het afkeuren nogal rigoreus.

Ik keur alleen af dat dat het afgedaan wordt als een lastige beperking waar je liever met een grote boog omheenloopt. De richtlijnen zijn er om jou als developer en je bezoeker te helpen, niet om je tegen te zitten. (al ben ik met je eens dat de manier waarop wel iets "toegankelijker" had gekund, ironisch genoeg...)

Of je de richtlijnen op de letter wilt volgen hangt af van je opdracht(gever) en/of je potentiele doelgroep. Het is ondoenlijk om dit zomaar met elk project volledig op te volgen, maar het biedt je wel interessante inzichten in waar je op kunt letten. Met als bijkomend voordeel een betere SEO.

[ Voor 4% gewijzigd door Bosmonster op 11-06-2013 16:25 ]

[R4gnax]

Bosmonster schreef op dinsdag 11 juni 2013 @ 16:03:
[...]

Een target="_blank", een Flash-embed of een link naar een Word-document valideren ook prima, maar ook dat is niet toegestaan ivm toegankelijkheid bijvoorbeeld.

En die eerste hoort eigenlijk helemaal niet in dat rijtje thuis, aangezien het zo ongeveer de enige vorm is waarin een auteur aan kan geven dat iets aanbevolen is om in een nieuwe browsing context geopend te worden; aangezien het een declaratief iets is waar de gebruiker via browser instellingen naar eigen smaak en inzicht mee om kan gaan.

Dit in tegenstelling tot bijv. javascript wat het click event afvangt en daarna window.open benut in een poging gebruikers ergens anders heen te sturen. Daarmee worden deftig de in browsers ingebouwde koppelingen, zoals bijv. de middelste muisknop voor het openen van een link in een nieuwe tab, om zeep geholpen.

[incaz]

Bosmonster schreef op dinsdag 11 juni 2013 @ 16:21:
[...]Omdat je een user interface aan het developen bent, geen stuk "techniek". Wat jij beperkingen noemt, kun je ook verbeteringen noemen, die veel mensen je in dank af zullen nemen.

Maar dat is mij nog niet overtuigend aangetoond eigenlijk. Want de verbetering zie ik dus niet, omdat het perfect mogelijk is om inline styles uit te schakelen of te overriden, nog afgezien van het feit dat heel veel styling geen negatief effect heeft op toegankelijkheid, en dus niet overridden (geoverridet?) hoeft te worden.

Ik keur alleen af dat dat het afgedaan wordt als een lastige beperking waar je liever met een grote boog omheenloopt. De richtlijnen zijn er om jou als developer en je bezoeker te helpen, niet om je tegen te zitten.

Maar tegelijkertijd is dit iets wat heel klein lijkt maar developers wel degelijk heel erg dwars kan zitten. Het vervangen van inlinestyles door een variant in een apart document kan namelijk een compleet andere manier van documenten genereren vereisen, omdat je specifieke style-informatie moet plaatsen op een plek waar je normaal gesproken geen toegang hebt tot de data, en als je de data hebt heb je geen toegang tot de styling. Dat kan een heel ingrijpende wijziging vereisen waarin je alle output apart moet cachen bv.

Oftewel: het is in een aantal gevallen een lastige beperking, waarvan het voordeel gewoon niet goed concreet gemaakt wordt.

Het is ondoenlijk om dit zomaar met elk project volledig op te volgen,

En dat vind ik een teken aan de wand, want zo moeilijk zou het niet moeten zijn vind ik eigenlijk. (En ik vind het jammer, want ik zou graag de basis halen. Gewoon, omdat het stoer staat en past bij mijn uitgangspunten. Maar het is niet belangrijk genoeg om veel te tijd te besteden om aan vrij abstracte en moeilijk te verantwoorden normen te voldoen.)

Met als bijkomend voordeel een betere SEO.

Dat SEO-argument voelt soms een beetje als met de haren erbij gesleept. Want ik kan echt geen enkele context verzinnen waarin een geinlinede style, zoals een niet-contentbevattende background-imag, of een fontweight, de SEO werkelijk beinvloedt.

Overigens zijn links naar flash en word-bestanden natuurlijk ook gewoon toegestaan volgens bepaalde uitgangspunten: meld bij het word-bestand waar het is, en als je flash niet van zichzelf toegankelijk is, biedt dan een voldoende alternatief.

(En het is natuurlijk een slecht idee als je bepaalde behulpzame vormen van content niet aan zou mogen bieden omdat sommige mensen dat niet in volle glorie kunnen benutten, ook al ben je er open over en bied je alternatieven met de correcte content. Alsof je geen kleur meer zou mogen gebruiken omdat sommige mensen kleurenblind zijn. Dat zou de wereld enorm verarmen.)

[Hydra]

incaz schreef op dinsdag 11 juni 2013 @ 22:32:

Maar tegelijkertijd is dit iets wat heel klein lijkt maar developers wel degelijk heel erg dwars kan zitten. Het vervangen van inlinestyles door een variant in een apart document kan namelijk een compleet andere manier van documenten genereren vereisen, omdat je specifieke style-informatie moet plaatsen op een plek waar je normaal gesproken geen toegang hebt tot de data

Dat later blijkt dat de opzet van je database of je systeem brak is en voor dat soort problemen zorgt is geen enkel argument tegen dergelijke standaarden.

[Bosmonster]

R4gnax schreef op dinsdag 11 juni 2013 @ 21:18:
[...]


En die eerste hoort eigenlijk helemaal niet in dat rijtje thuis, aangezien het zo ongeveer de enige vorm is waarin een auteur aan kan geven dat iets aanbevolen is om in een nieuwe browsing context geopend te worden; aangezien het een declaratief iets is waar de gebruiker via browser instellingen naar eigen smaak en inzicht mee om kan gaan.

Dit in tegenstelling tot bijv. javascript wat het click event afvangt en daarna window.open benut in een poging gebruikers ergens anders heen te sturen. Daarmee worden deftig de in browsers ingebouwde koppelingen, zoals bijv. de middelste muisknop voor het openen van een link in een nieuwe tab, om zeep geholpen.

Was ook geen goed voorbeeld bedenk ik me achteraf. Hoewel je als website geen invloed mag uitoefenen op de chrome (zoals een nieuw venster), zijn er wel degelijk geaccepteerde uitzonderingen. Bijvoorbeeld als de gebruiker een proces aan het doorlopen is dat niet onderbroken mag of kan worden. Maar dan nog wil je er wel bij vermelden dat die link afwijkend gedrag vertoont.

De javascript-variant staat overigens op 1 lijn met de target:blank. Hiermee omzeilde je bij de oude webrichtlijnen misschien validatie-problemen, maar is voldoet nog steeds niet aan de richtlijnen.

incaz schreef op dinsdag 11 juni 2013 @ 22:32:
[...]


Maar dat is mij nog niet overtuigend aangetoond eigenlijk. Want de verbetering zie ik dus niet, omdat het perfect mogelijk is om inline styles uit te schakelen of te overriden, nog afgezien van het feit dat heel veel styling geen negatief effect heeft op toegankelijkheid, en dus niet overridden (geoverridet?) hoeft te worden.

Je moet het ook wat breder zien denk ik dan specifieke voorbeelden of details. De enige manier om een consistente user experience te bieden is door richtlijnen op te stellen. Uiteindelijk ben je vrij om hiermee om te gaan of deze te interpreteren zoals je zelf wilt.

De enige reden om je er echt op de letter aan te houden is als je een toetsing wilt ondergaan. Of dat dan terecht is of niet, is een andere discussie denk ik.

Maar tegelijkertijd is dit iets wat heel klein lijkt maar developers wel degelijk heel erg dwars kan zitten. Het vervangen van inlinestyles door een variant in een apart document kan namelijk een compleet andere manier van documenten genereren vereisen, omdat je specifieke style-informatie moet plaatsen op een plek waar je normaal gesproken geen toegang hebt tot de data, en als je de data hebt heb je geen toegang tot de styling. Dat kan een heel ingrijpende wijziging vereisen waarin je alle output apart moet cachen bv.

Oftewel: het is in een aantal gevallen een lastige beperking, waarvan het voordeel gewoon niet goed concreet gemaakt wordt.

Toegankelijkheid begint al bij het ontwerpproces. Het is inderdaad een stuk lastiger om een bestaande website toegankelijk te krijgen als er geen enkele rekening mee gehouden is vanaf dag 1.

Maar tegelijkertijd kan ik ook vertellen dat er bijna altijd wel een passende andere opmaak-oplossing is die hetzelfde resultaat levert. Dit soort dingen vereisen wat oefening en hebben ook mij meerdere projecten gekost om te leren.

En dat vind ik een teken aan de wand, want zo moeilijk zou het niet moeten zijn vind ik eigenlijk. (En ik vind het jammer, want ik zou graag de basis halen. Gewoon, omdat het stoer staat en past bij mijn uitgangspunten. Maar het is niet belangrijk genoeg om veel te tijd te besteden om aan vrij abstracte en moeilijk te verantwoorden normen te voldoen.)

Is het extra werk? Jazeker. Beperkt het je in je vrijheid van design? Ook.

Maar dat het je werk als front-end developer onmogelijk maakt vind ik absoluut niet. Het vereist een andere kijk op bepaalde zaken, maar dit is iets dat je jezelf eenvoudig aan kunt leren en simpelweg een kwestie van ervaring is met het onderwerp.

Dat SEO-argument voelt soms een beetje als met de haren erbij gesleept. Want ik kan echt geen enkele context verzinnen waarin een geinlinede style, zoals een niet-contentbevattende background-imag, of een fontweight, de SEO werkelijk beinvloedt.

Inline styling zal inderdaad weinig effect hebben op SEO. Maar de basis van toegankelijkheid (goed gestructureerde documenten, scheiding van content en opmaak, juiste semantiek, etc) zijn ook van toepassing op SEO.

Overigens zijn links naar flash en word-bestanden natuurlijk ook gewoon toegestaan volgens bepaalde uitgangspunten: meld bij het word-bestand waar het is, en als je flash niet van zichzelf toegankelijk is, biedt dan een voldoende alternatief.

Ik noemde Word omdat een onderdeel van toegankelijkheid ook is, dat er open standaarden gebruikt worden (in ieder geval volgens de Nederlandse richtlijnen). Word is geen open formaat. Meestal kun je dan beter PDF/a hanteren bijvoorbeeld.

Flash mag inderdaad ook als er voldoende alternatief is, maar daarmee komen we op je volgende punt:

(En het is natuurlijk een slecht idee als je bepaalde behulpzame vormen van content niet aan zou mogen bieden omdat sommige mensen dat niet in volle glorie kunnen benutten, ook al ben je er open over en bied je alternatieven met de correcte content. Alsof je geen kleur meer zou mogen gebruiken omdat sommige mensen kleurenblind zijn. Dat zou de wereld enorm verarmen.)

Maar dan bepaal je als developer wat nut heeft of correct is voor je bezoeker. Stel dat een architect in een gebouw dat ie ontwerpt bedenkt.. ow, maar deze ruimtes of toiletten zijn niet nodig voor mensen in een rolstoel, want we hebben ook toiletten aan de andere kant van het pand. Of de ontwikkelaar vindt het vast lastig om een fonteintje te maken op rolstoelhoogte, dus laat ik dat maar weg. Dat is niet een keuze die een architect dient te maken als hij een gebouw ontwerp dat toegankelijk dient te zijn.


Afgerond:
Je wilt dit ook niet maar blindelings voor elk project gaan hanteren. Als je werkt voor de overheid zul je er vaker mee te maken krijgen en als je het mij vraagt is dat ook volkomen terecht. De overheid heeft als plicht de volledige bevolking te bedienen en mensen met een beperking niet uit te sluiten.

Wat je wel leert na een aantal dergelijke trajecten is dat de basis prima toepasbaar is in algemene scope. Het verruimt je beeld van hoe een website opgebouwd en geinterpreteerd wordt. En dan kom je erachter dat je er door met wat simpele dingen rekening te houden, of elementen op een bepaalde manier op te bouwen, je vanzelf toegankelijker aan het ontwikkelen bent en de kwaliteit van je code verbetert.

[ Voor 5% gewijzigd door Bosmonster op 12-06-2013 10:06 ]

[incaz]

Bosmonster schreef op woensdag 12 juni 2013 @ 09:56:
Maar dan bepaal je als developer wat nut heeft of correct is voor je bezoeker. Stel dat een architect in een gebouw dat ie ontwerpt bedenkt.. ow, maar deze ruimtes of toiletten zijn niet nodig voor mensen in een rolstoel, want we hebben ook toiletten aan de andere kant van het pand. Of de ontwikkelaar vindt het vast lastig om een fonteintje te maken op rolstoelhoogte, dus laat ik dat maar weg. Dat is niet een keuze die een architect dient te maken als hij een gebouw ontwerp dat toegankelijk dient te zijn.

Ten eerste lijkt het bedenken wat nuttig is voor je bezoeker me bij uitstek een taak voor de ontwerpers. (Minder voor de developers per se.) Praktische behoefte is hoe dan ook belangrijker dan theoretisch correct lijkt mij.

En wat jij nu aanhaalt is dan ook niet het voorbeeld dat ik gaf. Waar ik op doelde is dat je de mogelijkheden bewust gaat beperken. Bijvoorbeeld dat je je rolstoeltoiletten goed verspreid door het pand hebt zitten, op een haalbare afstand overal, kortom: voldoende. Maar je hebt een hoekje over waar je prima een normaal toilet kunt plaatsen en dat kan altijd handig zijn, want minder wachttijden en voor sommige mensen toevallig minder ver lopen. En dan zou je moeten zeggen, nee, dat voordeel willen we niet geven want dat voordeel hebben mensen in een rolstoel ook niet.

Je wilt dit ook niet maar blindelings voor elk project gaan hanteren. Als je werkt voor de overheid zul je er vaker mee te maken krijgen en als je het mij vraagt is dat ook volkomen terecht. De overheid heeft als plicht de volledige bevolking te bedienen en mensen met een beperking niet uit te sluiten.

En dan toch krijgt de overheid het voor elkaar om sites te maken die qua bediening behoorlijk niet handig zijn. (Wetteksten wel eens proberen te lezen door dat brievenbusje?) Pfffft.

Wat je wel leert na een aantal dergelijke trajecten is dat de basis prima toepasbaar is in algemene scope.

Die basis zit er allang al in hoor Juist daarom had ik het interessant gevonden om de laatste stappen ook te zetten - maar ik wist niet dat een aantal daarvan zo vergaand zijn en vrij rigoreuze veranderingen noodzakelijk kunnen maken.

En dat is jammer, want dat houdt in dat eigenlijk alleen vrij statische sites (waar de bouwer / ontwerper veel controle heeft over het proces, om niet alleen in grote lijnen maar ook qua details precies te voldoen) en sites die verplicht zijn uiteindelijk het waarmerk krijgen. En dat vind ik dan weer zonde, daarmee wordt het iets exclusiefs ipv iets wat heel vanzelfsprekend kan zijn.