Nieuwe Opera-functie toont dat weinig sites W3C-check doorstaan

Opera heeft een nieuw soort zoekmachine ontwikkeld, die de structuur van webpagina's inzichtelijk maakt. Uit de eerste resultaten blijkt dat nog geen vijf procent van alle websites de W3C-validatie overleeft.

De Noorse softwaremaker noemt zijn nieuwe zoekmachine Mama. De achterliggende technologie, die door de Opera-ontwikkelaars is bedacht, is in staat websites te indexeren aan de hand van de gebruikte markup-, style- en scripting-elementen. De engine zal de komende maanden publiek beschikbaar worden gemaakt, zo heeft Opera woensdag bekendgemaakt.

De Mama-zoekmachine heeft momenteel ongeveer 3,5 miljoen pagina's geïndexeerd. Hoewel de engine nog niet publiek benaderbaar is, heeft Opera op basis van zijn eerste analyse al wel de enkele resultaten gepresenteerd. Hieruit blijkt onder meer dan de gemiddelde pagina 16.500 karakters bevat en dat slechts iets meer dan de helft van de onderzochte url's een doctype-statement bevat. Wat Opera als 'zorgwekkend' omschrijft is het aantal sites dat de W3C-validatie doorstaat. Slechts 4,13 procent van de 3.509.180 onderzochte url's doorstond deze test.

Opera bekeek ook hoeveel sites Flash gebruiken. Het mondiale gemiddelde ligt op 33 procent. Opvallende uitschieter is China, waar 67 procent van de sites Flash gebruikt. Nederland scoort met 37,2 procent iets hoger dan gemiddeld. Ook met het gebruik van Xmlhttprequest, een Javascript-object dat veelvuldig als ajax-element bij web 2.0-sites wordt gebruikt, loopt Nederland voorop. Iets meer dan 5 procent van de onderzochte Nederlandse sites maakt gebruik van dit dom-object, waarvan het gebruik alleen in Noorwegen met 10,2 procent nog hoger ligt.

Reacties (90)

[buzzin]

Tja....websites ontwerpen is blijkbaar nog steeds moeilijk voor de meesten.
Aan standaarden voldoen staan meestal ergens onderaan het lijstje helaas.
Niet zo vreemd trouwens dat Opera dit onderzoekt, zij krijgen sinds jaar en dag te horen dat hun browser niet zou deugen. Terwijl ze dus, wat nu ook blijkt, altijd terrecht hebben gezegt dat de websites zelf de oorzaak zijn.

[Rob Coops]

Het grote probleem is dat als je een website wilt hebben die op 90% van de moderne browsers er zo uitziet als jij bedacht had dan moet je haast wel van de standaarden afwijken gewoon omdat de browsers zich niet netjes aan de standaarden houden.

Natuurlijk kan het wel en ik doe voor de alle publiek toegangkelijke websites die ik bouw altijd de moeite nemen om te zorgen dat ik me aan de standaarden houd en dat het er correct uitziet in zo veel mogenlijk browsers. Over een jaar of 3 hebben vrijwel alle mensen in de nu nog nieuwe brouwsers die zich netjes aan de standaarden houden. Zelfs Internet Explorer gaat zich met versie 8 eindelijk aan de standaarden houden.
De meeste opensource brouwsers gebruiken webkit of geko die zich netjes aan de standaarden houden. Dus over een paar jaar zal dat wat browsers betreft eindelijk opgelost zijn en heb je als web developer geen rede meer om je er gemakkelijk van af te maken en de brouwsers de schuld te geven. Dan zal het nog vele duizenden jaren duren voor iedere overgebleven web pagina ook voldoet aan de standaarden maar dat komt gewoon omdat er in middels al zo veel totaal vergeten webpagina's op het internet te vinden zijn, die waarschijnlijk nooit meer geupdate gaan worden.

[blouweKip]

Het grote probleem is dat als je een website wilt hebben die op 90% van de moderne browsers er zo uitziet als jij bedacht had dan moet je haast wel van de standaarden afwijken gewoon omdat de browsers zich niet netjes aan de standaarden houden

De enige browser waar ik nog iets aparts voor moet doen is IE (iedere versie, wordt er zelf ook gaar van), de rest van de browsers werkt gewoon perfect (en dan heb ik t over simple html/css/js)

[Crazz]

Beetje off-topic:

Wellicht ook interressant in deze discussie is het verschil tussen "Gracefull Degradation" en "Progressive Enhancement" bij het ontwikkelen van websites. In het kort is het verschil dat bij GD je een site maakt voor de meest vooruitstrevende browser en uitzonderingen maakt voor oudere browsers, bij PE maak je een site voor de meest eenvoudige (oudste) browser en maak je toevoegingen die alleen zichtbaar zijn voor nieuwere browsers. Het laatste krijgt steeds meer aandacht.

Meer info hier (in het engels).

[bozotheclown]

Dat is mede omdat als je volgens de standaarden werkt en een leuke site maakt er altijd wel een browser is die je ontwerp niet goed weergeeft!

Dit is een kip/ei verhaal. Ja er zijn nogal wat coders die shit code afleveren en er zijn ook heel veel coders die het goed kunnen en doen en de meest belachelijke truuks uit moeten halen om ervoor te zorgen dat een site er in de diverse browsers te pruimen uitziet.

[jurrie]

Onzin. Een beetje competente webdeveloper krijgt dat echt wel voor elkaar. Ik heb jaren code voor enkele erg grote sites geschreven die perfect valideerde en in alle "grote browsers", dus Gecko based, opera, KHTML/Webkit based, IE7 en 'zelfs' IE6 goed werkten. Ik zou best wat links willen geven, maar helaas hebben mensen die zich minder om standaarden bekommeren onderhand genoeg aangepast aan die sites dat ze compleet niet meer valideren.

Het ontbreekt het merendeel van de "webdevelopers" aan 1 (meestal meer) van de volgende punten:

* Kennis van zaken om goede, valide code te schrijven
* De wil om elke bezoeker van goede informatie te voorzien, en niet enkel een clubje dat je makkelijk vindt om te bedienen
* Iets extra tijd uittrekken om het goed te krijgen indien nodig.

Waarbij het laatste punt zo goed als triviaal is als je weet wat je doet. De grootste problemen waarbij je 'truuks' uit moet halen worden veroorzaakt doordat men de beperkingen van het web niet in acht neemt bij het verzinnen van het design / de functionaliteit.

[_JGC_]

Het is maar net hoe je ontwikkelt. Zelf heb ik een jaar lang websites geschreven in ASP.Net. Uitgezonderd de beroerde tags die .Net er soms wel eens tussen wil gooien waardoor je warnings krijgt bij validatie (geen errors dus!), maakte ik over het algemeen gevalideerde websites. Uitgezonderd CSS hacks voor IE6 kwamen deze ook door de CSS validator heen. De laatste website die ik gebouwd heb had daar conditionele stylesheets voor, waardoor die ook gewoon door de CSS validator kwam.

Je bouwt gewoon de structuur van de website op in HTML, gooit hier vervolgens wat CSS omheen en test het geheel in een browser die zich min of meer aan de standaarden houdt (Firefox, maar IE7 doet het ook redelijk). Als je uiteindelijk klaar bent pak je IE6 erbij en gooi je hier en daar wat hacks in de CSS die alleen voor IE6 geldig zijn zodat die er ook goed uitziet. Als resultaat heb je dan een website die gevalideerd is, die met een oude hakkietakkie browser werkt dankzij je hacks en die ook in alle browsers werkt die zich aan de standaarden houdt.

Een collega van me deed het anders: gooi de hele site in tabellen, strip de doctype uit je website omdat anders de helft van je attributen niet meer werken (table height="100%" enzo), maak het werkend in IE6 en ga dan schelden dat Firefox niet helemaal doet zoals "het hoort", om vervolgens daar allemaal lelijke hacks op toe te passen.

[Reactie gewijzigd door _JGC_ op 26 juli 2024 06:45]

[martdj]

Ben ik niet met je eens. De W3C validator kijkt namelijk naar de HTML markup en niet naar de CSS of JS files. De HTML markup is zonder al te veel problemen W3C compatible te maken zonder dat je browser compatibiliteit in gevaar komt. Dat je dan vervolgens in je CSS en JS files allerlei trucs moet uithalen om de pagina er ook in alle browsers fatsoenlijk uit te laten zien, staat hier buiten.

[happyguppy]

Niet mee eens. De W3C heeft ook een tool voor je CSS bestanden, en als je die niet valid hebt, dan komt je browser compatibiliteit JUIST in gevaar.

Mijn eigen ervaring is, dat zolang je met valide en semantische code werkt, er bijna geen problemen zijn met browser compatibiliteit, met uitzondering van wat ranzige bugs in IE6/IE7, die ik dan weer met een conditionele stylesheet oplos.

Ik zie trouwens niet in wat JS in deze context met browser compatibiliteit te maken heeft, tenzij de JS html output geeft.. in dat geval zou ik dus gewoon zorgen dat deze output valid is, heel simpel.

Ik wil hieraan nog toevoegen dat valide code niet alleen belangrijk is voor de browsers, maar ook voor andere doeleinden erg belangrijk is. Denk aan blinde mensen, die hun computer een site (zonder styling/css) laten voorlezen. Wanneer dit in valide code is gebeurd zal het apparaat er een stuk minder moeite mee hebben.

@ watercoolertje: jij begrijpt het principe niet, het gaat om nette, onderhoudbare code die elke browser goed kan weergeven. Ook zoekmachines die geven daar WEL om, die lezen goed opgemaakte code 1000x beter dan slechte, niet valide code.

[Reactie gewijzigd door happyguppy op 26 juli 2024 06:45]

[Kjoe_Ljan]

Ben ik het mee eens. Zolang je je aan de standaarden houdt is er niet één browser die een website verkeerd weergeeft, op IE5/6 (en mss een beetje IE7) na.

Tijdens mijn stage bij een webdeveloper ben ik erachter gekomen dat MS af en toe zijn eigen standaarden gebruikt. Het is in de professionele webontwikkelwereld bovendien een bekend feit dat het veel makkelijker is om een gestandaardiseerde website compatible te maken voor IE, dan vice versa.

[watercoolertje]

Oke, maar wat heb je er aan dat je website aan bepaalde voorwaarden voldoet... het is geen keurmerk, de bezoekers geven er niks om en je maakt je site wel voor de bezoekers niet voor 1 of andere standaard.

Zoekmachines geven ook niet meer om sites die wel aan de voorwaarden voldoen.

[Reactie gewijzigd door watercoolertje op 26 juli 2024 06:45]

[QplQyer]

Het doel van standaarden in het algemeen en van W3C in het bijzonder is interoperabiliteit garanderen. Net zoals programmeertalen een bepaalde grammaticale definitie met bijhorende semantiek (betekenis van een element uit de taal) hebben, is dit door het W3C ook voor HTML vastgelegd. Een site die de standaard niet volgt is dan ook hetzelfde als een stuk code met een programmeerfout in. Ik hoor niemand klagen dat gcc hun code niet wilt compileren als ze een fout hebben staan in hun code die "vergeven" (lees: de bedoelde semantiek gegokt) wordt door bv. msvc++, dus het is nogal absurd om bij markup languages plots de schuld en last door te schuiven naar de browserbouwers.

Het antwoord op je vraag is dus hetzelfde antwoord als op de vraag "wat heb je eraan dat je ANSI C++ schrijft": portabiliteit. Bij een browser is dit natuurlijk nog belangrijker dan bij een programmeertaal, aangezien elke gebruiker van je site de code moet kunnen "interpreteren & compileren" en je door het gebruik van de standaard dit garandeert.

[Finraziel]

en je door het gebruik van de standaard dit garandeert.

Als ik Bozotheclown goed begrijp dan is dat dus niet zo. Dan kun je wel die standaard volgen en net als opera roepen dat je gelijk hebt, maar als een belangrijk deel van je doelgroep de site nog altijd niet goed ziet omdat de browser die zij gebruiken zich NIET aan die standaard houdt, dan trek je uiteindelijk toch aan het kortste eind.

[QplQyer]

Uiteraard zitten er soms fouten in browsers (en compilers) waardoor bepaalde zaken niet juist worden weergegeven. Maar wanneer beide de standaard volgen zou dit miniem moeten zijn. Bijgevolg zal een site die aan de standaard voldoet veel minder work-arounds nodig moeten hebben voor bepaalde browserbugs dan één die dit niet doet. Elke afwijking moet ook gemeld worden aan de browsermaker want is een <b>fout</b> in hun renderingcode.

[Xirt]

Helaas gaat de 'interoperabiliteit' niet op zolang Microsoft zijn browser niet op de juiste manier programmeerd. Het grootste probleem bij het houden aan de standaarden is dat deze standaarden niet werken in alle versies van Internet Explorer. Dat IE de standaarden niet volgt kan je ook goed zien aan de scores op de ACID3 tests.

[Siebsel]

Jij snapt duidelijk het principe van de W3C validator niet...

[bozotheclown]

Dat kan dat je het niet met me eens bent maar dat wil niet zeggen dat je gelijk hebt:)

Als je een simpel site ontwerp hebt kan wat jij zegt.

Als je een iets leukere site wilt maken, dan gaat wat jij zegt niet op.

[sandr]

Aan standaarden voldoen staan meestal ergens onderaan het lijstje helaas.

Klopt helemaal, maar dat is opzich ook best logisch, want de browsers houden zich ook maar zelden aan de standaarden (vooral IE). Daarnaast lijkt het mij belangrijker dat een site het in elke browser goed doet en dat hij dan maar niet aan de standaarden voldoet.

[TheFes]

Wanneer maakt een website gebruik van Flash volgens Opera? Is dat ook als een youtube filmpje in een weblog geplaatst wordt, of als er een flash reclamebanner wordt getoond? Want dan is het werkelijk aantal sites wat flash gebruikt natuurlijk veel lager.

[Wilbert de Vries]

Als

* Any PARAM element containing the substrings ".swf" or "flash"
* Any EMBED/Src or OBJECT/Data attribute values pointing to content with a MIME type using the substring "flash"
* Any scripting content with the substring "flash" or ".swf"

http://dev.opera.com/articles/view/mama-key-findings/#flash

[buzzin]

Eh nee? Ook als je youtube filmpjes plaats maak je gebruik van flash. Als er geen flashplayer op je systeem staat zijn er nog steeds missende delen in de pagina....

[kozue]

Ik denk niet dat iemand een ontbrekende flash banner als 'missend deel' zal beschouwen. Ik heb nog nooit van iemand gehoord dat ie speciaal voor die "leuke" flitsende flash banners flash is gaan installeren. Een filmpje is daarentegen misschien een ander verhaal.

[BarôZZa]

Dat slechts 4% gevalideerd wordt terwijl alle browsers pakweg meer dan 95% van de sites goed weergeven geeft maar weer eens aan hoe belangrijk valideren is: niet enorm belangrijk. Je moet wel een enorm grote baggerzooi maken wil het niet meer goed renderen.

W3 validatie is meer een doel op zichzelf geworden voor de fanatieke geeks, maar wordt door grote bedrijven vrijwel genegeerd. De grootste site ter wereld levert zelfs pakweg 50 errors op en naast Google hebben ook Youtube, Yahoo, Ebay etc allemaal tientallen of zelfs honderden fouten. Amazon.com genereert zelfs 1711 errors.

Zoekmachines letten ook niet op W3 validatie en als de website hetzelfde wordt gerenderd in alle browsers, dan is de enige die het opmerkt diegene die je url het door de W3 validator gooit.

[crisp]

Dat slechts 4% gevalideerd wordt terwijl alle browsers pakweg meer dan 95% van de sites goed weergeven geeft maar weer eens aan hoe belangrijk valideren is

Het gaat er niet alleen om of je site goed wordt weergegeven; of je site toegankelijk is ook voor gebruikers voor wie de vormgeving niet uitmaakt, bijvoorbeeld omdat ze een visuele handicap hebben, en/of die niet over bepaalde technologieën beschikken zoals javascript is vele malen belangrijker.

Validatie is inderdaad niet veel meer dan een syntax-check, en zegt daarmee niets over zaken mbt accessibility waar weer andere richtlijnen voor zijn (die vaak ook niet geautomatiseerd getoetst kunnen worden), maar het is wel een aanzet tot schone, semantische code waarbij additionele technologieën unobtrusive worden toegepast. Nette HTML is makkelijker toegankelijk te maken dan tagsoup met allerlei inline eventhandlers en presentationele markup zonder semantische waarde. Daarbij zullen mensen die niet eens de moeite nemen om eenvoudig de syntax van hun prutswerk te valideren waarschijnlijk ook niet de moeite nemen eens naar bijvoorbeeld de WCAG richtlijnen te kijken (als ze al van het bestaan daarvan weten).

Wat dat betreft is het dus jammer dat er niet meer fanatieke geeks zijn; dat zijn imo namelijk wel de professionals die uiteindelijk ook wel een keer tot de conclusie komen dat syntactische validatie slechts een onderdeel is van een groter geheel (als ze dat al niet wisten).

[BarôZZa]

Syntactische validatie eindigt in veel gevallen op mierenneuken. Een nl2br in PHP zet bijvoorbeeld <br/> neer, waar de validator bijvoorbeeld over kan vallen. Kan je het wel veranderen in <br>, maar dan schiet je het hele doel voorbij, aangezien het in de praktijk simpelweg geen zak uitmaakt.

Daarnaast kan je nog steeds de meest onduidelijke html code schrijven, terwijl het wel goed gevalideerd wordt. Niet inspringen, geen enters, onduidelijke names/id's gebruiken voor elementen etc. Andersom is het ook mogelijk om goed leesbare/werkende code te schrijven die wel wat foutjes bevat.

Accessibility is juist datgene waar ik veel van de techgeeks aan voorbij zie schieten. Ik zeg niet iedereen, maar veel van die mensen staren zich blind op zaken als W3C validatie. Daarnaast zie ik veel mensen ook gewoon teveel tijd besteden aan het door de validator komen in plaats van zaken die veel belangrijker zijn. Zo heb je sites die gevalideerd worden, die niet goed worden weergegeven in IE met vervolgens een Get Firefox bannertje erbij. Tsja, dan vraag ik me af waar je mee bezig bent.

De W3C-check is in mijn ogen een leuke richtlijn en handig om wat onhandige foutjes te vinden, maar absoluut niet de heilige graal die sommige mensen ervan maken.

[crisp]

Syntactische validatie eindigt in veel gevallen op mierenneuken. Een nl2br in PHP zet bijvoorbeeld <br/> neer, waar de validator bijvoorbeeld over kan vallen. Kan je het wel veranderen in <br>, maar dan schiet je het hele doel voorbij, aangezien het in de praktijk simpelweg geen zak uitmaakt.

True, maar om te kunnen bepalen dat het waarschijnlijk geen zak uitmaakt (in HTML5 wordt de extra slash, hoewel nutteloos, gewoon geaccepteerd als valide syntax en er is inderdaad geen enkele browser die er over valt - eigenlijk dankzij het feit dat browsers zich nooit helemaal aan de richtlijnen mbt HTML4 hebben gehouden ) heb je toch wel enigszins kennis van zaken nodig. Het andere uiterste - helemaal niet valideren en als het er in 1 browser goed uitziet maar op het web gooien - is echter natuurlijk ook niet de juiste manier. Dan kan je beter gaan zitten mierenneuken dan dat je er helemaal niets aan doet.

[...]Zo heb je sites die gevalideerd worden, die niet goed worden weergegeven in IE met vervolgens een Get Firefox bannertje erbij. Tsja, dan vraag ik me af waar je mee bezig bent.

Och, vroeger hadden veel sites juist een bannertje 'Best viewed in Internet Explorer'; eigenlijk is het dan ironisch te zien dat het nu soms juist andersom is, en eigenlijk meer terecht als je ziet wat voor draconisch monster IE eigenlijk is als het neerkomt op het verwerken van valide documenten. Dat sommige particulieren gewoon geen zin hebben om tijd te besteden aan workarounds voor IE's quirks kan je ze niet kwalijk nemen. Als professional heb je natuurlijk weinig keus, maar ook ik wordt vaak moedeloos van IE's oneindige aantal rariteiten en tekortkomingen en zou het liefst die support ook zo snel mogelijk droppen zodat ik mijn tijd aan nuttigere zaken kan besteden

[...]
De W3C-check is in mijn ogen een leuke richtlijn en handig om wat onhandige foutjes te vinden, maar absoluut niet de heilige graal die sommige mensen ervan maken.

En dat ben ik dus met je eens, daarom schreef ik al dat validatie in de brede zin veel meer inhoud dan enkel een syntax-check. De validator is een tool, geen (eind)doel.
Overigens is het imo ook compleet verkeerd neergezet door W3C met hun "valid (X)HTML!!!111"-buttons. Ze hadden beter in plaats van die button een tekst neer kunnen zetten als: "Congratulations; your document passed the syntactic requirements for (X)HTML, now you may want to look at the accessibility guidelines etc..."

De experimentele HTML5 validator bevat bijvoorbeeld ook een optie om de alt-attributen van plaatjes te evalueren. Dat zijn dingen die toegevoegde waarde hebben, meer dan het encoderen van ampersands in attributen.

[RuddyMysterious]

De validator zal toch zeggen dat tags zonder een aparte eindtag moeten eindeigen op />? Dat een <br /> dus juist is en een <br> fout.

Hieronder wordt net verklaard dat de <br/> tag enkel nodig is in XHTML, wat te maken heeft met XML specifieke eisen, niet met HTML specifieke eisen.

[Reactie gewijzigd door RuddyMysterious op 26 juli 2024 06:45]

[Verwijderd]

Maakt dat zoveel uit als een site 100% W3C compatibel is of niet?

[crisp]

Maakt dat zoveel uit als een site 100% W3C compatibel is of niet?

"W3C compatible" gaat verder dan puur syntax-validatie. Persoonlijk zie ik syntax-validatie meer als een tool dan als een doel op zich. Het is wel eenvoudiger om met valide syntax ook te voldoen aan andere aanbevelingen, bijvoorbeeld met betrekking tot usability en acessibility, wat imo veel belangrijker is dan een eventueel foutje in de syntax wat door de meeste browsers prima gecorrigeerd wordt.

Ook dient opgemerkt te worden dat XHTML1.x en HTML4.01 alweer behoorlijk verouderde specificaties zijn en dat specifieke zaken die niet 100% conform deze specificaties zijn toch gemeengoed zijn geworden en er geen zwaarwegende bezwaren zijn om dat toch 'officieel' toe te staan. HTML5, de opvolger van HTML4/XHTML1.x, zal in sommige gevallen dan ook zaken goedkeuren die nu niet door de HTML4/XHTML1.x validatie heenkomen.

In het geval van HTML4.01 is het zelfs zo dat geen enkele browser deze standaard als omschreven door het W3C heeft geimplementeerd(!). HTML is namelijk van origine een SGML applicatie, maar browsers behandelen het meer als een eigen syntax en ondersteunen veel van de SGML-specifieke eigenschappen niet.

[Reactie gewijzigd door crisp op 26 juli 2024 06:45]

[Korben]

Dan weet je in ieder geval zeker dat als je die site bekijkt in een browser die zich gedraagt naar de standaarden van W3C, de site eruit ziet zoals de ontwerper het bedoeld heeft.

Praktisch gezien maakt het helemaal niks uit, omdat bijna alle browsers ook prima overweg kunnen met non-compliant HTML en CSS.

[Verwijderd]

Vind van wel, er is steeds meer concurrentie tussen de browsers tegenwoordig dus mensen zullen eerder geneigd zijn om verschillende browsers te proberen. Het is daarom steeds belangrijker dat je je aan de standaarden houdt als je een website gaat maken.

[Olaf van der Spek]

Maakt dat zoveel uit als een site 100% W3C compatibel is of niet?

Ja. Het meer iedereen zich aan de standaarden houdt, hoe beter sites onder alle browsers zullen werken en hoe beter browsers zich aan de standaarden zullen houden.

[i-chat]

ja dat maakt wel degelijk uit,

kijk voor jans-eigen-hobby.webstek.ergens.nl zal 't niet zo boeien, maar voor sites die een grotere publiek doel dienen scholen, webwinkels, overheids zaken, bangzaken en zelfs sites als tweakers. is de gegarendeerde bereikbaarheid gewoon heel belangrijk

net als dat je in een winkel centrum rekening moet houden met mensen in een rolstoel, moet je op internet rekening houden met mensen en alternatieve browsers en zeker wanneer die brouwsers meer dan alleen maar van een ander merk zijn. bijv voor blinden.

[Bosmonster]

Validatie is dan ook geen doel, maar een middel. Dat het uiteindelijke product op een paar punten niet valideert is imho niet belangrijk, zolang dat maar geen fouten zijn in de opmaak.

Als voor een applicatie een custom attribute nodig is bijvoorbeeld, ga ik dat niet laten omdat dan de pagina niet meer valideert. Of als de klant graag een link in een nieuw venster opent, maar ik volgens de doctype eigenlijk geen target-attribute zou mogen gebruiken, ga ik de klant niet vertellen dat ie pech heeft, omdat zn site anders niet meer valideert.

Das dan jammer zeg maar, maar zegt verder niks over de kwaliteit van de code.

Imho kun je dus niet zomaar alle 'niet-validerende sites' op één hoop gooien en is dit resultaat dus compleet irrelevant.

[Reactie gewijzigd door Bosmonster op 26 juli 2024 06:45]

[buzzin]

Tja zo kan iedereen altijd wel een uitzondering op alles verzinnen.
Of je doet het niet, of je veranderd het doctype....en ja, dat is meer werk, maar daar mag een klant ook gewoon voor betalen hoor...

[Bosmonster]

Je kunt niet zomaar doctypes veranderen, dat zou je als ervaren developer toch moeten weten. Tijd/geld is ook het punt niet (dat noem ik toch ook niet?).

Wensen wel. Tuurlijk kun je met een of ander raar script proberen bijvoorbeeld een target="_blank" proberen te emuleren, maar imho ga je dan compleet voorbij aan het doel van validatie en doctypes en maak je het alleen maar erger.

Dat bedoel ik met dat het geen doel is, maar een middel. Het helpt je een goed site te bouwen die voldoet aan de standaarden tijdens het ontwikkelproces, maar het moet geen doel an sich worden om alle mogelijkheden af te schieten omdat anders je site niet meer valideert. Zolang die verder werkt in alle browsers en er geen reden is om aan te nemen dat dit in de toekomst niet meer zo is, is er geen probleem om hier vanaf te wijken.

Misschien dat inderdaad in de toekomst het deprecated target-attribuut verwijderd wordt, dan werkt het openen in een nieuw venster niet meer. Boeien, dat is het risico van een deprecated attribute implementeren, maar nog geen reden het niet te doen als dat op dat moment de beste oplossing is.

Uiteraard hangt het wel compleet af van het type fout dat je veroorzaakt. Zoals het voorbeeld een deprecated attribuut gebruiken dat door alle browsers ondersteund wordt is een heel ander verhaal dan dat de opbouw of encoding van je document niet klopt..

[Reactie gewijzigd door Bosmonster op 26 juli 2024 06:45]

[buzzin]

Das waar, maar je snapt m'n punt?
Tuurlijk moet er ruimte zijn voor interpetatie, maar je kent de uitspraak "80% van de bestuurder vind zichzelf beter rijden als 50% van alle andere bestuurders"?
Oppassen dus met uitzonderingen, en liever niet.

Overigens ben ik geen ervaren developer van websites hoor. (Ben geen noob, maar developer zou ik mezelf niet durven noemen)

[Bosmonster]

Tuurlijk, liever niet

Waar ik een beetje over val met alle reacties hier ook, is dat er gedacht wordt dat validerende code goede code is en dat is absoluut niet waar.

Validerende code kan verschrikkelijk slecht zijn en niet validerende code heel goed.

Daarom vind ik de conclusie die uit resultaat van het onderzoek van Opera wordt getrokken wat onsubtiel.

[kozue]

Als je code niet valideert, hoe kun je dan weten of er geen fouten zitten in je opmaak? Omdat het er nog goed uit ziet in browser X en Y waarin je het getest hebt? En browser Z dan? En versie +1 van browser X? De enige manier om het zeker te weten is door valide code te schrijven. Als het dan alsnog niet werkt is het een browser bug en kun je naar de browsermaker wijzen als iemand vraagt waarom je site er daarin niet goed uit ziet.
Als je denkt custom attributen nodig te hebben of dingen tegen het doctype in doet, duidt het hoogst waarschijnlijk op een gebrek aan coding skills, en zegt het wel degelijk iets over de kwaliteit van je code.

[Bosmonster]

Zoals ik al zei, is validatie een goed middel om een goede site te bouwen en wel degelijk iets om rekening mee te houden.

Maar ik val in herhaling, misschien moet je gewoon beter lezen.

[kozue]

Ik heb goed gelezen, en ben het niet met je eens met de andere helft van je post. Jij zegt dat je best de regels voor goede code zelf aan mag passen als het niet binnen jouw straatje valt, en ik zeg dat dat onverstandig is en je waarschijnlijk slechte code produceert vanwege jouw gedachtenset. Misschien moet je mijn post eens nog een keer doorlezen voordat je jouw mening probeert op te dringen aan mensen die het toch niet met je eens zijn (mij).

[Reactie gewijzigd door kozue op 26 juli 2024 06:45]

[Bosmonster]

Dus wat jij zegt is dat je briljante code geschreven kan hebben die compleet valideert, in alle browser werkt, volledig semantisch correct opgebouwd, gebruik maakt van 100% onubtrusive javascript en 100% volgens de ARIA-richtlijnen en drempels weg. Maar dat de code dan slecht is omdat je een deprecated of custom attribute gebruikt waardoor je validatie niet 100% meer is? Of doordat de backend developer nl2br gebruikt heeft in je html4 doctype en er een <br />tje in staat?

Ik ben inderdaad van mening dat dat onzin is ja.

[Reactie gewijzigd door Bosmonster op 26 juli 2024 06:45]

[kozue]

En dan ga jij je niet afvragen waarom je er uberhaupt een custom attribute nodig hebt, en waarom je het niet gewoon op een standaard manier doet? En waarom niet even je <br /> in <br> terug veranderen, tis een kwestie van 2 keer op backspace rammen...

[Bosmonster]

Dynamisch gegenereerde content, nl2br (waar ik het over had) gebruikt standaard <br />? Valt er weinig op backspace te rammen.

En custom attributes.. zeker nog nooit een complexe RIA gebouwd?

Nofi, maar volgens mij heb je gewoon geen idee waar je het over hebt.

[spNk]

Tja, volgens mij was dat al algemeen bekend... zijn alle pagina's die w3c valid zijn ook meteen hetzelfde weergegeven in elke browser?

http://validator.w3.org/c...ent=W3C_Validator%2F1.591
pricewatch is niet helemaal in orde

_{en bekijk voor de gein hyves eens}

[MarCreative]

offtopic:
Ik wist dat hyves slecht in elkaar zat, maar dit slaat echt alles...

Dat terzijde, het is ALTIJD (naar mijn mening) mogelijk om een website W3C valid te maken. Nu is het zo, dat met name IE 6 en andere oudere browsers bijna altijd de fout in gaan. d

Dat is altijd wel te verhelpen met CSS, zo niet ben ik gewoon van mening dat ze maar eens moeten updaten. Het is geen 2002 meer...

[Verwijderd]

Vaak draagt het CMS een groot deel mee aan niet valide code. Redacteuren knippen en plakken bv uit Word en sturen zo de meest ranzige code mee. Door user input te schonen kom je een heel eind maar karakters die sommige users erin krijgen doet mij nog steeds verbazen.

[Reactie gewijzigd door Verwijderd op 26 juli 2024 06:45]

[crisp]

<br /> heeft niets met strict te maken maar met XHTML waar XML wellformedness noodzakelijk is (althans, als je het ook echt als XHTML verstuurd, anders behandelen browsers het gewoon als HTML en negeren de slash).

<br> is een empty element net als <img> en heeft dus inderdaad in HTML geen sluittag. Een slash voor de tag-end token is in HTML helemaal niets (maar sluit in HTML als SGML-applicatie wel de tag af waardoor de ">" feitelijk (unescaped) content is). <br /> in HTML(4) is eigenlijk gewoon fout en levert dus een warning op.

De sluittag voor <li> is trouwens niet verplicht in HTML

[Reactie gewijzigd door crisp op 26 juli 2024 06:45]

[Olaf van der Spek]

Slechts 4,13 procent van de 3.509.180 onderzochte url's doorstond deze test.

Is het geen idee om standaard in de status bar aan te geven of een site valid is of niet?

[Crazz]

In principe is het natuurlijk beter als een site aan de standaarden voldoet, omdat ie dan op de meerderheid van browsers goed te zien is. Maar ik denk dat voor de gemiddelde internetgebruiker het niet zoveel uitmaakt of een site 100% valideert of niet, zolang alles maar werkt. Het valideren is meer iets voor webontwikkelaars lijkt me.

[Olaf van der Spek]

Maar ik denk dat voor de gemiddelde internetgebruiker het niet zoveel uitmaakt of een site 100% valideert of niet, zolang alles maar werkt.

Meten is weten.
Hoe eenvoudiger het is te 'meten' of een site aan de standaarden voldoet, hoe sneller daar werk van wordt gemaakt.

[joostvanpinxten]

FireFox plugins FTW! Heb al een hele tijd HTML Validator draaien. Deze draait bv een implementatie van de SGML en Tidy HTML parsers.

Tot mijn vreugde zie ik steeds vaker een groen vinkje onderaan staan, ipv een rood kruis, of een geel warning driehoekje.

Ik test de scripts en pagina's die ik maak ook altijd op validity. Het helpt ook met het snel vinden van fouten!

[Verwijderd]

Webdeveloppers moeten zich eigenlijk gewoon schamen als ze niet juist kunnen valideren zonder minder dan 10 fouten (ja; ik vind dat fouten t.b.v. de correctheid van de code moeten kunnen). Ik zie in mijn beroepsveld té vaak andere webdeveloppers die zowat alleen in IE devven, en dan totaal niet valideren. En dan maar zeuren als de site er niet uitziet in Firefox/Opera/Safari! Dan ligt het blijkbaar niet aan de website (want ja; die doet het in IE ), maar aan de alternatieve browsers.....

[ZeroXT]

Als webdeveloper houd ik juist rekening met die webstandaarden. Ik maak geen enkele website die niet voldoet aan die standaarden. Ik probeer "zelfs" user input te laten validaren (denk aan een forum waar mensen alles kunnen posten wat ze willen).

Mijn eigen site ziet er in alle browsers die ik heb getest hetzelfde eruit. (IE6, IE7, FF3, Safari, Chrome en Opera) Ook maak ik gebruik van Xmlhttprequest. En mochten er mensen zijn die JavaScript uit hebben staan.. geen probleem, alles werkt ook zonder javascript!

En dat mensen, is een instelling die een webdeveloper moet hebben! (zonder eigendunk)

[Reactie gewijzigd door ZeroXT op 26 juli 2024 06:45]

[Bosmonster]

Amen, maar dat heeft alleen niks te maken met het artikel. Dat gaat puur over validatie en niet over het usability, goede code en het gebruik van onubtrusive javascript bijvoorbeeld.

[ZeroXT]

Dit heeft juist erorm veel met het artikel te maken want in het artikel staat dat er minder dan 5% van de websites die zijn gechecked door de validatie heen komt en ik denk dat, dat komt vanwege de instelling van de webdeveloper of het gebrek aan kennis.

Als alle webdevelopers nu zo'n instelling zouden hebben dan was er niet 5 maar misschien wel 70% door de validator heen gekomen!

[Verwijderd]

Is natuurlijk maar net de vraag hoe erg de fouten waren. Kijk naar de 'fouten' in Tweakers.net zoals hierboven vermeld... Dat waren onbenulligheden, die op geen enkele manier afbreuk deden aan de site.

Ja, strict genomen was het niet valide. Maar een mens zou zeggen dat de site prima in orde is. Vraag me af voor hoeveel andere sites dat ook gold....

[kozue]

Das allemaal leuk en aardig, maar heb je het ook op iets anders dan je eigen windowsbakkie getest? Werkt het onder OS X en Linux ook?
En waarom gebruik je javascript als je site zonder ook 100% werkt?

[ZeroXT]

Ik heb mn site ook getest op de Mac met Safari, FF3 en Opera en het ziet er nog steeds allemaal hetzelfde uit. Linux niet getest.

En de reden waarom ik JavaScript gebruik is om de site interactiever en gebruikersvriendelijker te maken.

Voorbeeld:
De huidige pagina toevoegen aan ! interne ! favorieten (dus niet van de browser).

Met JavaScript:
Klik op sterretje er verschijnt een div met daarin een input veld. Je klikt op opslaan en met AJAX worden de gegevens opgeslagen in de database zonder dat er ook maar 1 pagina refresh is geweest.

Zonder JavaScript:
Klik op het sterretje, je wordt doorverwezen naar een aparte pagina waarin je daar op opslaan kan klikken waardoor de gegevens in de database word gezet en je word weer terug gestuurd naar de pagina waar je vandaan kwam. In totaal 2 refresh dus.