W3c Validator en webdesigners (disccussie)

[MuisM4t]

Ik ging voor de grap eens met de w3 validator langs ongeveer 10 webdesigners op de eerste pagina van de marktplaats categorie Diensten > Webdesigners en Domeinnamen,

De validator gaf veel foutmeldingen, in totaal had één van die 10 sites een "valid xhtml".
Bij een site gaf hij zelfs 47 foutmeldingen!!
Bij sommigen was geen doctype of character encoding aangegeven.
Op een van die site's kwam ik een valid css button tegen, maar toen ik de url invoerde bij de html validator kreeg ik 32 errors.


Mag ik uit al deze fouten van webdesigners op marktplaats opmaken dat:
-Het schrijven van correcte code niet belangrijk word gevonden en dat eigenlijk ook niet is.
of
-Die "webdesigners" slordige particulieren en zeker geen profs zijn

Wie heeft hier iets leuks aan toe te voegen of iets over te zeggen?

[krvabo]

Je vergeet er een:
- "Webdesigners" die via marktplaats adverteren veelal onvoldoende klantenkring hebben om het te redden. Meestal heeft dat een reden.

[Onbekend]

Een klant ziet toch alleen maar de website in niet de code er achter.
Dus waarom zouden webdesigners er meer tijd aan besteden? Tijd is geld....

[RobIII]

Valid (X)HTML is niet heilig. Hoewel IMHO een site valid hoort te zijn (en niet alleen de 'homepage', wat je ook vaak ziet) denk ik niet dat het een echte graadmeter is. OTOH: Als een webdesign bedrijf z'n eigen site niet eens valid heeft denk ik niet dat ik daar zo snel voor zou kiezen

[rapture]

Velen hebben nooit ervoor gestudeerd, hier en daar wat lezen over html 4.0. Dan wat code rippen, kopiëren en iets bijeen hacken totdat het werkt. Dan doe je ervaring op en de portfolio wordt groter om uiteindelijk in de webmasterwereld te belanden.

Zolang de klant niks van ziet, zal men niet valid leren coderen. Bij ons in MCT (opleiding dat oa webmasters aflevert) is valid coderen een vereiste en we mierenneuken graag op andermans code.

[Blaise]

Semantiek is een betere indicator van de kwaliteit van een website dan het aantal errors van de W3C validator. Misschien wordt steevast '&' gebruikt in plaats van '& amp;' in query URLs. Dan zit je zo op tientallen fouten, terwijl de website prima werkt.

Ook onbekend schreef op zondag 10 juni 2007 @ 18:28:
Een klant ziet toch alleen maar de website in niet de code er achter.
Dus waarom zouden webdesigners er meer tijd aan besteden? Tijd is geld....

Het kost geen extra tijd om je aan de standaarden te houden als je de standaarden eenmaal kent en je ze in het achterhoofd houdt tijdens het bouwen. Het is meer een kwestie van er kennis van nemen. Zo ingewikkeld is correcte HTML niet.

[Palomar]

Die validator gaat wel snel over de zeik als er maar 1 foutje in zit. Dan rekent ie alles erna ook fout en zit je zo op tientallen fouten. Daar moet je wel rekening mee houden. Maar ik ben wel van mening dat een webdesignbedrijf zich erg goed aan de standaarden moet houden. De meeste webdesignbureau's (/eenmanszaakjes) echter worden gewoon gerund door een scholier oid die eigenlijk geen enkele kennis van zaken heeft. Verbaast me ook niks dat die sites dus vol met fouten zitten. Voor kleine sites voor de bakker om de hoek maakt het ook allemaal niet zoveel uit, maar een grotere site die ook met google moet worden gevonden, regelmatig geupdatet moet worden, op verschillende apparaten bekeken moet kunnen worden etc. etc. dan ben je niet echt slim bezig als je maar wat aankloot.

[Mr.Qips]

Oh je wil niet weten wat voor vrezelijke webdesigners er allemaal sites bouwen! En dan ook nog eens voor prijzen als 400 euri de pagina. Kijk voor de grap maar eens op woensdag op retecool.com, dan hebben ze 'webdesign woensdag' en zetten ze altijd een paar van dat soort webdesigners voor lul

[JKVA]

Palomar schreef op zondag 10 juni 2007 @ 18:43:
Die validator gaat wel snel over de zeik als er maar 1 foutje in zit. Dan rekent ie alles erna ook fout en zit je zo op tientallen fouten. Daar moet je wel rekening mee houden. Maar ik ben wel van mening dat een webdesignbedrijf zich erg goed aan de standaarden moet houden. De meeste webdesignbureau's (/eenmanszaakjes) echter worden gewoon gerund door een scholier oid die eigenlijk geen enkele kennis van zaken heeft. Verbaast me ook niks dat die sites dus vol met fouten zitten. Voor kleine sites voor de bakker om de hoek maakt het ook allemaal niet zoveel uit, maar een grotere site die ook met google moet worden gevonden, regelmatig geupdatet moet worden, op verschillende apparaten bekeken moet kunnen worden etc. etc. dan ben je niet echt slim bezig als je maar wat aankloot.

Imho moet elke site met google gevonden worden, ook kleine sites. Sterker nog, juist kleine sites moeten door google gevonden worden, anders komt er niemand. Grote sites, zoals Funda en Marktplaats worden toch wel gevonden. Die hebben niet per sé google nodig, daar is het extra.

De enige soort sites die niet door google gevonden hoeven te worden, zijn in mijn optiek extra- en intranetsites. Overigens zou ik me daar nog steeds zoveel mogelijk aan standaarden houden, op de lange termijn bespaart het je een hoop gezeik.

[ Voor 9% gewijzigd door JKVA op 10-06-2007 20:50 ]

[Blue-eagle]

Je zit inderdaad wel op de meest gerenommeerde website te kijken voor TOP webdesigners, alle neusjes van de zalm staan namelijk op marktplaats.nl.

Maar dan nog. Een webdesigner zijn HTML kan nog zo "slecht" zijn, als zijn websites nou hoog in de rankings staan en voor 99% van de gebruikers goed werkt - maakt het dan uit of hij valideert op de W3C validator? Ik snap je punt, maar staar je er niet blind op. Slechte HTML betekent niet noodzakelijk een slechte website. Goede HTML is dan ook geen garantie voor een goede site.

Het probleem wat ik bij sollicitaties tegenkom is dat "ontwerpers" die ook verwachten een HTML-job er op na te houden in twee hokjes te stoppen zijn.

Goede grafische ontwerper -> matige HTML skills.
Goede HTMLer -> slechte grafische skills.

De ideale situatie is natuurlijk een goed ontwerp (gebruikersvriendelijk, mooi geheel) en daarnaast goede HTML. Naar mijn mening zijn dat twee vakken apart. Laat het HTML-en maar over aan een technisch persoon en laat het grafische over aan de creatieveling. Als ze maar samenwerken zodat het ontwerp ook pixel-perfect omgezet wordt naar een juiste HTML-pagina. Met andere woorden.. als het ontwerp of de html niet goed zijn dan is het bedrijf niet goed, of werkt het met prutsers op een van de vlakken in de ontwikkeling.

Nogmaals: slechte HTML betekent niet noodzakelijk dat de webdesigner slecht is -> goede HTML betekent niet noodzakelijk dat de webdesigner goed is.

^{Het bedrijf waar ik voor werk heeft al ~4 jaar de website niet geupdate qua layout of HTML, de layout is in orde, de HTML is gewoon niet van deze tijd, toch ben ik van mening dat we goede sites bouwen. We hebben het gewoon te druk om met onze eigen site bezig te gaan.}

[ Voor 15% gewijzigd door Blue-eagle op 10-06-2007 20:56 ]

[JKVA]

Blue-eagle schreef op zondag 10 juni 2007 @ 20:52:
Het bedrijf waar ik voor werk heeft al ~4 jaar de website niet geupdate qua layout of HTML, de layout is in orde, de HTML is gewoon niet van deze tijd, toch ben ik van mening dat we goede sites bouwen. We hebben het gewoon te druk om met onze eigen site bezig te gaan.

Dat is idd ook een leuke stelling die je weleens hoort. Als een bedrijf een echt gelikte site heeft die vaak verandert en zo, dan zullen ze wel niet genoeg werk hebben.

Ik ben het daar niet helemaal mee eens, je hebt altijd wel vrije momentjes op een vrijdagmiddag of als je ff op iemand moet wachten ofzo. Dan kun je wel ff wat bijwerken.

De complete site restylen is idd weer wat te veel van het goede. Daar zijn afstudeerders voor.

[Blue-eagle]

JKVA schreef op zondag 10 juni 2007 @ 21:03:
[...]


Dat is idd ook een leuke stelling die je weleens hoort. Als een bedrijf een echt gelikte site heeft die vaak verandert en zo, dan zullen ze wel niet genoeg werk hebben.

Ik ben het daar niet helemaal mee eens, je hebt altijd wel vrije momentjes op een vrijdagmiddag of als je ff op iemand moet wachten ofzo. Dan kun je wel ff wat bijwerken.

Ligt ook aan de situatie. In een groot bedrijf heb je meer mensen. In een klein bedrijf ben je constant bezig, en ook met andere taken zoals het verhuizen van domeinnamen, instellen van e-mail adressen, uren inschatting maken voor offertes, etcetera. Zelf ben ik altijd bezig met werk wat geld oplevert, helaas

De complete site restylen is idd weer wat te veel van het goede. Daar zijn afstudeerders voor.

Dat, of gewoon wachten op een wat rustigere periode (zomertijd!) en dan wat "innovatieve" uurtjes draaien: site updaten, bestaande eigen software uitbreiden, etc.

Als een webdevelopment bedrijf vaak zijn site verandert dan hebben ze personeel te veel (fout) of klanten te weinig (fout) of liggen de prioriteiten verkeerd (fout). Al laat je het door afstudeerders of stagaires doen.. er moet altijd iemand de boel leiding geven die zijn tijd beter kan spenderen aan iets wat direct geld oplevert.

Natuurlijk ga ik er dan vanuit dat de site "ok" is. Een klote site kan ook geld kosten, en een goede site kan geld opleveren En wat is de definitie van een goede site? Correcte HTML? Nah..

[Martinspire]

Al zie je tegenwoordig ook veel webbedrijven hun site als testdomein gebruiken om te laten zien wat ze kunnen, maar nog belangrijker: Voor zichzelf om te kijken of iets werkt

Verder denk ik dat als je met webdesigners werkt in plaats van webcoders/programmeurs, dat je dan zoiezo vaker een niet-gevalideerde website hebt.

Ik moet zeggen dat ik er vroeger ook niet zo erg naar keek, maar de laatste tijd toch wel, want dan heb je ook een grotere kans dat het niet alleen in firefox en IE werkt (al moet je voor die laatste vaak dingen aanpassen), maar ook in safari en opera. Oftewel, het scheelt je toch wel wat werk.

[Onbekend]

Blue-eagle schreef op zondag 10 juni 2007 @ 21:36:
En wat is de definitie van een goede site? Correcte HTML? Nah..

Bijna wel. Als de site in bijna alle browsers werkt maakt html niks uit.
Maar als een site alleen in IE goed is te zien moet je toch even achter je oren krabben over de correctheid van html....

[hing]

Ook onbekend schreef op zondag 10 juni 2007 @ 21:43:
[...]


Bijna wel. Als de site in bijna alle browsers werkt maakt html niks uit.
Maar als een site alleen in IE goed is te zien moet je toch even achter je oren krabben over de correctheid van html....

Of een site er wel of niet goed uitziet heeft natuurlijk niets met HTML. Je kunt ook hele foute HTML hebben, maar dat het toch op alle gangbare browsers er goed uitziet. En andersom geldt dat natuurlijk ook. HTML dat door de validator komt, biedt geen garantie dat het er altijd onder alle browsers hetzelfde eruit ziet.

Een goede site is veel meer dan HTML. Een goede site is toegankelijk voor de gebruiker en gebruikersvriendelijk. Ook een goed design speelt een belangrijke rol.
Elke site heeft een eigen doel. Wanneer men met een site dat doel bereikt, is het een goede site.

[BikkelZ]

Mijn zwarte W3C-nazi laarzen liggen inmiddels ongepoetst & amp ; afgetrapt onder in mijn schoenenbak, zeker wat betreft die validator. Wat hebben die blinden er nou aan dat ik een ALT-tekst gebruik bij het plaatje van een miepje met een headset op op de contactpagina? Wat heeft een blinde er aan dat mijn pagina perfect valideert, waaronder die table layout en BLOCKQUOTE die ik misbruik als een soort DIV om een plaatje over het scherm te laten zweven?

Ik valideer mijn pagina's nooit meer, ben het gezeur over &-tekens en ontbrekende ALT-teksten bij plaatjes die geen enkele functie hebben beu. Semantisch correcte HTML moet ik wel gebruiken voor een goede Google ranking, en een DTD gebruiken heb ik weer nodig om FF en IE nog ietsje meer compatible te krijgen met elkaar.

Om mensen af te gaan rekenen op hoeveel fouten hun pagina's oproepen in de W3C-validator vind ik echt belachelijk, zoals iemand al eerder aanhaalde, je scoort met een goede pagina vaak toch snel minputen en met een slechte pagina is het niet moeilijk om te valideren. De enige manier waarop je iemand kunt afrekenen is daar a) te kijken naar het resultaat en b) de manier waarop het gedaan is met je eigen ogen.

[Boelie-Boelie]

Whizzkid92 schreef op zondag 10 juni 2007 @ 18:23:
Ik ging voor de grap eens met de w3 validator langs ongeveer 10 webdesigners

Ik denk dat het iets meer zegt als je de sites in hun portfolio beoordeelt. Zoals hierboven ergens al werd gezegd, soms heeft men geen tijd voor de eigen website, vandaar dat hun portfolio wellicht een betere indicatie geeft. En ook daar zul je de ene keer gare HTML vinden en de andere keer nagenoeg validerende HTML; dat ligt waarschijnlijk aan een combi van de eisen van de klant en aan de werknemer die er aan heeft gewerkt. Je kunt niet door alleen de frontpage te checken oordelen of een bedrijf goed is.

Je kunt aan de code van sites uit hun portfolio vaak wel opmaken in hoeverre men zichzelf op de hoogte houdt van ´best practices´ in webdevelopment, waarbij het ook gaat om duurzaamheid, toegankelijkheid en vindbaarheid. Je doel is dus niet validatie, je doel is vaak om een vindbare website te hebben die voor iedereen toegankelijk is en een tijdje meekan. Daarbij kan een validerende site alsnog bestaan uit slechte code.

Dus de gebruikte meetmethode is geen goede graadmeter om een goede webdesigner te vinden, maar mits juist toegepast kan het een indicatie geven van in hoeverre men zichzelf bijschoolt. Het is vervolgens aan een combinatie van nog een hoop andere factoren of je een bedrijf professioneel mag noemen.

[Verwijderd]

Voor mij is valide gebruik van CSS en (X)HTML gewoon beroeps integeriteit, dat is voor iedereen anders.

Verder ben ik van mening dat het gebruik van valide (X)HTML en CSS mogelijke probleempunten voorkomt.

[ Voor 35% gewijzigd door Verwijderd op 11-06-2007 14:02 ]

[OkkE]

BikkelZ schreef op maandag 11 juni 2007 @ 10:46:
Wat hebben die blinden er nou aan dat ik een ALT-tekst gebruik bij het plaatje van een miepje met een headset op op de contactpagina?

Zodat ze weten dat het een "miepje met een headset" is, en niet een kaartje met route, die ze misschien aan een ziende kunnen geven. Ik noem maar iets.

Wat heeft een blinde er aan dat mijn pagina perfect valideert, waaronder die table layout en BLOCKQUOTE die ik misbruik als een soort DIV om een plaatje over het scherm te laten zweven?

Table layout is voor een blinde (of wie dan ook een screenreader gebruikt) een ramp. En waarom zou je een Blockquote (om dus te quoten) misbruiken als soort Div? Waarom dan niet een Div gebruiken?

Ik valideer mijn pagina's nooit meer, ben het gezeur over &-tekens en ontbrekende ALT-teksten bij plaatjes die geen enkele functie hebben beu.

Ik valideer mijn pagina's af en toe. En foutjes in mijn HTML probeer ik op te lossen. Valideren gebruik ik meer voor mijzelf om echte fouten op te sporen, niet als heilig doel.

Semantisch correcte HTML moet ik wel gebruiken voor een goede Google ranking, en een DTD gebruiken heb ik weer nodig om FF en IE nog ietsje meer compatible te krijgen met elkaar.

Dus als je Google PageRank er niet van afhankelijk was, zou je nu nog font-tags en tabellen gebruiken?

Om mensen af te gaan rekenen op hoeveel fouten hun pagina's oproepen in de W3C-validator vind ik echt belachelijk, zoals iemand al eerder aanhaalde, je scoort met een goede pagina vaak toch snel minputen en met een slechte pagina is het niet moeilijk om te valideren. De enige manier waarop je iemand kunt afrekenen is daar a) te kijken naar het resultaat en b) de manier waarop het gedaan is met je eigen ogen.

Om iemand af te reken op het aantal fouten van de W3C validator vind ik ook niet de juiste manier. Maar aan de hand van vooral welke fouten het zijn kan je in sommige gevallen wel achterhalen hoe goed iemand is (en/of hoeveel tijd iemand er in gestoken heeft). Om het helemaal af te doen als belachelijk, vind ik ook weer wat te ver gaan.

[Blue-eagle]

Valideren is nooit belachelijk. Semantiek ook niet. Het is echter niet noodzakelijk voor een functioneel goede website. Er is geen enkele reden om geen goede HTML te schrijven, er zijn legio redenen om slechte HTML links te laten liggen.

Om tegenwoordig nog een site op te zetten mbv. tabelstructuren, font tags en tientallen framesets... Dan ben je gewoon dom bezig.

[BasieP]

ik denk dat validatie opzich niet veel voorstelt, echter check ik wel vaak bij websites.

Ik kijk dan naar de fouten en kijk of het echte denkfouten zijn of foutjes zoals het vergeten van alt tags bij plaatjes.
Wanneer iemand geen doctype boven zijn pagina heeft staan is het voor mij al iemand die niet goed op de hoogte is en zichzelf geen webdevver mag noemen.
Wanneer hij tags vergeet te sluiten is het een ammateur
Wanneer hij domme dingen doet (bijv. css in html of dingen als onnodig javascript, IE only zut etc. dan zou ik hem ook absoluut afschrijven.

Echter vallen die laatste categorie dingen niet op in een validator.
Toch vind ik dat de belangrijkste, dit geeft ongeveer aan wat ik bedoel.
Validator is een tool die je kan helpen, maar ik zou neit zeggen 'ow validator zegt dat het fout is dus doei'
en al helemaal niet 'ow validator zegt dat het goed is dus je bent goed'
dit laatste doen wel veel mensen, maar vind ik echt niet kunnen

Blue-eagle schreef op maandag 11 juni 2007 @ 14:24:
Valideren is nooit belachelijk. Semantiek ook niet. Het is echter niet noodzakelijk voor een functioneel goede website. Er is geen enkele reden om geen goede HTML te schrijven, er zijn legio redenen om slechte HTML links te laten liggen.

Om tegenwoordig nog een site op te zetten mbv. tabelstructuren, font tags en tientallen framesets... Dan ben je gewoon dom bezig.

je spreekt jezelf tegen..

verder vind ik goede html schrijven en semantiek juist wel erg belangrijk, want dit is ongeveer de belangrijkste stap richting een 'functioneel goede website'

[ Voor 43% gewijzigd door BasieP op 11-06-2007 14:27 ]

[Zerora]

Slechts 15% van alle sites op het internet hebben 0 fouten in hun code. De overige 85% hebben er minstens 1 of meer.
Ooit eens ergens gelezen.

[RM-rf]

BasieP schreef op maandag 11 juni 2007 @ 14:25:

verder vind ik goede html schrijven en semantiek juist wel erg belangrijk, want dit is ongeveer de belangrijkste stap richting een 'functioneel goede website'

als je dat zo stelt, dat het dé 'belangrijkste' stap zou zijn naar een functioneel goede website

offtopic:
(wat een ontzettend lelijke woordkeuze, noem het dan bv en 'goed functionerende website')

Dat is echter niet waar, omdat dat zou impliceren dat je zònder validatie of semantiek geen goed functionerende website zou kunnen bouwen en dat klopt gewoon niet...
Er zijn genoeg prima functionerende websites die niet valideren en in theorie kan het best voorkomen dat een redelijk ongeschoolde website bouwer een voor hem prima functionerende website bouwt met tabellen en/of framesets en niet validerende code...

Je kunt wel stellen dat het zeer goed bedoeld advies is om wél aandacht te bsteden aan validatie en semantiek, omdat dat methodieken zijn die veel fouten kunnen voorkomen, of het eenvoudiger maakt bugs te vinden en op te lossen... verder zorgt het voor een beter begrip en bewustzijn van de website bouwer van zijn code en hierdoor is de kans ook groot dat hij 'beter' en makkelijker eventuele knelpunten zal opruimen...

maar een 'moeten' is het niet, en volgens mij is dat ook terecht, het is onzin wat sommige mensen ebweren dat je de 'kwaliteit' van een website zou kunnen afmeten aan zijn score bij validator.w3.org

Zerora schreef op maandag 11 juni 2007 @ 14:26:
Slechts 15% van alle sites op het internet hebben 0 fouten in hun code. De overige 85% hebben er minstens 1 of meer.
Ooit eens ergens gelezen.

als dat zo zou zijn, zou dat een zeer mooi cijfer zijn en beteken dat we al een heel end gekomen zijn...
ik vermoed echter dat het getal aan validerende sites een stuk lager ligt dan die 15%

[ Voor 12% gewijzigd door RM-rf op 11-06-2007 15:02 ]

[Zerora]

RM-rf schreef op maandag 11 juni 2007 @ 15:01:
[...]

als dat zo zou zijn, zou dat een zeer mooi cijfer zijn en beteken dat we al een heel end gekomen zijn...
ik vermoed echter dat het getal aan validerende sites een stuk lager ligt dan die 15%

Die 15% zijn over het algemeen nog websites uit de HTML 1.0 periode die nog steeds bestaan. Daar kun je weinig fouten in maken opzich.

[Palomar]

idd, 15% lijkt me wel erg veel. Ik check voor de grap ook wel es wat sites die ik tegenkom (met zo'n firefox-plugin waarmee je dat in 1 klik doet) en ben bijna nooit een site tegengekomen die 100% valid is.

[BikkelZ]

OkkE schreef op maandag 11 juni 2007 @ 14:10:Table layout is voor een blinde (of wie dan ook een screenreader gebruikt) een ramp. En waarom zou je een Blockquote (om dus te quoten) misbruiken als soort Div? Waarom dan niet een Div gebruiken?

Dat is nou precies wat ik bedoel. Validerende HTML is helemaal geen goede HTML. Er worden alleen een x aantal zaken die meestal fout zijn niet gedaan op een validerende pagina. Het zegt helemaal niets over de kwaliteit. Een quirks mode HTML 4 pagina kan perfect zijn voor een blinde, en een perfecte CSS en HTML validerende pagina een complete nachtmerrie.

[

OkkE schreef op maandag 11 juni 2007 @ 14:10:Dus als je Google PageRank er niet van afhankelijk was, zou je nu nog font-tags en tabellen gebruiken?

Bij mij en de meeste mensen die ik ken is er geen betere stok achter de deur dan dat. Het is meestal het argument waarmee mensen overstag gaan om semantisch(er) te gaan werken: Google is blind.

OkkE schreef op maandag 11 juni 2007 @ 14:10:Om iemand af te reken op het aantal fouten van de W3C validator vind ik ook niet de juiste manier. Maar aan de hand van vooral welke fouten het zijn kan je in sommige gevallen wel achterhalen hoe goed iemand is (en/of hoeveel tijd iemand er in gestoken heeft). Om het helemaal af te doen als belachelijk, vind ik ook weer wat te ver gaan.

Ik denk dat één blik in de sourcecode meer zegt dan wat een validator rapporteert.

[OkkE]

BikkelZ schreef op maandag 11 juni 2007 @ 15:17:
Dat is nou precies wat ik bedoel. Validerende HTML is helemaal geen goede HTML. Er worden alleen een x aantal zaken die meestal fout zijn niet gedaan op een validerende pagina. Het zegt helemaal niets over de kwaliteit. Een quirks mode HTML 4 pagina kan perfect zijn voor een blinde, en een perfecte CSS en HTML validerende pagina een complete nachtmerrie.

Je hebt gelijk dat een valide pagina niet perse goed is, en anders om. Maar over het algemeen geeft een valide pagina wel aan dat er (meer) over is nagedacht.

Bij mij en de meeste mensen die ik ken is er geen betere stok achter de deur dan dat. Het is meestal het argument waarmee mensen overstag gaan om semantisch(er) te gaan werken: Google is blind.

Aan de ene kant ben ik blij dat door deze redenatie nog iets van semantiek gebruikt wordt. Ik vind het alleen wel erg jammer dat mensen het alleen voor Google (e.a.) doen. Het is over het algemeen een kleine moeite en geeft veel plezier en gemak, dus waarom niet semantisch werken.

Ik denk dat één blik in de sourcecode meer zegt dan wat een validator rapporteert.

Daar heb je wel gelijk in ja. Neemt niet weg dat de validator een prima extra tool is om een website te checken.

[BasieP]

RM-rf schreef op maandag 11 juni 2007 @ 15:01:

offtopic:
(wat een ontzettend lelijke woordkeuze, noem het dan bv en 'goed functionerende website')

offtopic:
niet mijn woorden

Dat is echter niet waar, omdat dat zou impliceren dat je zònder validatie of semantiek geen goed functionerende website zou kunnen bouwen en dat klopt gewoon niet...

nou dat impliceerd het in mijn ogen echt niet hoor. Ik zie het als een guideline, wat je helpt bij het maken van een goed functionerende website. Echter je kan verschrikkelijk ranzig werken en toch een goed functionerende website maken.
Echter draait een website om veel meer dan alleen maar 'goed functioneren'
dingen als hergebruik, onderhoudbaarheid, schaalbaarheid etc. etc. zijn ook erg belangrijk, alleen worden vaak vergeten.
De validator (en semantisch werken) helpen je (vaak onbewust) om hier rekening mee te houden

maar een 'moeten' is het niet, en volgens mij is dat ook terecht, het is onzin wat sommige mensen ebweren dat je de 'kwaliteit' van een website zou kunnen afmeten aan zijn score bij validator.w3.org

mee eens, het is een tool die je helpt. Je tool moet niet je doel worden.

Dat is nou precies wat ik bedoel. Validerende HTML is helemaal geen goede HTML.

ik denk dat je dat anders bedoelt als het er uit komt
ik mis het woord 'hoeft' een beetje

[ Voor 10% gewijzigd door BasieP op 11-06-2007 15:44 ]

[Tom]

Wat een baggersite

[Martinspire]

Mja dat van google is al lang bekend dat die niet goed is, maar die is geoptimaliseerd op snelheid meen ik. Verder denk ik ook niet dat ze daar veel mee bezig zijn, maar wel met die iGoogle en de zoekresultaten.

Overigens brengt Javascript ook een hoop bagger mee, maar omdat daar geen fatsoenlijke validatie voor is (als het werkt dan is het goed) heb je zoiezo een hoop slome en vage sites.

Daarnaast heb ik nog niet echt een fijn framework gevonden waarmee ik gemakkelijk mysql opdrachten kan geven, maar ook layout makkelijk kan beheren. Want niet alleen zijn de functionaliteiten van frameworks vaak ondermaats, ook de code rommelt nogal.

[Onbekend]

Tom schreef op maandag 11 juni 2007 @ 17:17:
Wat een baggersite

Google is een heel mooi voorbeeld.
Voldoet niet aan de webstandaard, maar probeert wel zoveel mogelijk verschillende bezoekers te trekken. Ook Safari, Opera en Netscape gebruikers zijn de doelgroep.

Zolang een website maar overal goed wordt weergegeven is het goed.

[BikkelZ]

djmantri schreef op maandag 11 juni 2007 @ 21:49:
Daarnaast heb ik nog niet echt een fijn framework gevonden waarmee ik gemakkelijk mysql opdrachten kan geven, maar ook layout makkelijk kan beheren. Want niet alleen zijn de functionaliteiten van frameworks vaak ondermaats, ook de code rommelt nogal.

Dan schrijf je zelf toch wat, als je al weet wanneer code rammelt, dan kun je zelf ook iets schrijven.

[crisp]

Validatie is een tool, geen doel. Zeker gezien het feit dat browsers van mallformed (of liever: non-conforming) HTML toch vaak wel iets weten te maken en dat deze error-correctie straks in HTML5 ook gespecificeerd zal gaan worden (en afstapt van versioning) en dus uniform zal zijn is conformance puur een stuk gereedschap om je code overzichtelijk te houden en eventuele non-conformities die daadwerkelijk problemen opleveren snel te kunnen vinden. Vanuit dat oogpunt is het voor authors dus wel degelijk van (hun eigen) belang om conformant HTML te schrijven, maar voor bezoekers is het totaal niet relevant.

[Verwijderd]

Bovendien is het de vraag of organisaties een code audit willen toepassen als uitgangspunt voor kwaliteit. De reacties dat valide code minder tijd kost om te produceren zijn ondoordacht. Om tot valide code te komen zul je net zoals elke andere taal waarin je code klopt extra aandacht moeten besteden. Het is vaak de vraag of bedrijven daar geld in willen stoppen, want er zijn zeer weinig klanten die er aandacht aan besteden.

[crisp]

Verwijderd schreef op maandag 11 juni 2007 @ 23:47:
Bovendien is het de vraag of organisaties een code audit willen toepassen als uitgangspunt voor kwaliteit. De reacties dat valide code minder tijd kost om te produceren zijn ondoordacht. Om tot valide code te komen zul je net zoals elke andere taal waarin je code klopt extra aandacht moeten besteden. Het is vaak de vraag of bedrijven daar geld in willen stoppen, want er zijn zeer weinig klanten die er aandacht aan besteden.

Agreed, voor het produceren van valide (conforming) code is zeker extra aandacht nodig, maar die tijd verdient zich meestal bij maintenance wel terug; het is immers makkelijker om na een wijziging een missende close-tag te vinden in een pagina die van origine al conforming was dan in eentje die al tig conformance-errors had (hence: het is een tool)

Even praktisch gezien is validatie in de huidige vorm met HTML4 en XHTML1.x een beetje een wassen neus; gezien de implementaties van browsers biedt conformance nog steeds geen enkele garantie. Sterker nog: de reden dat XHTML 'werkt' en valideerd is juist omdat browsers HTML niet volgens de letter hebben geimplementeerd - de meeste XHTML pagina's worden immers gewoon als text/html geserveerd - en omdat de validator geen rekening houdt (of kan houden) met mimetypes.

[Verwijderd]

Ik ben eigenlijk van mening dat een website danwel validated hoort te zijn, maar het geen vereiste is overigens. Zolang het maar goed werkt in alle type PC danwel Mac browsers, vind ik het prima.

Het gaat tenslotte vooral om hoe het eruit ziet.

Dat ik 1 foutje haal lig ik niet wakker van. Dat als ik een job gehad heb > website opgeleverd heb en vervolgens de eigenaar zelf aan gaat rommelen, is ook niet meer mijn probleem

Ik lever zoals gevraagd wordt en verder kijk ik daar niet meer mee om

[Suepahfly]

Om maar even een qoute aan te halen uit Pirates 2
"it's more like guidelines and your actual rules".

Uiteindelijk wil de klant een site die er goed uitziet en goed werkt. validated code helpt enigszins maar is geen absolute must. Zoals eerder gezegd is valide code geen garantie voor interoperability.

[Verwijderd]

Correct Html is persoonlijk, javascript en php kunnen ook op één regel geplaatst worden. Maar toch spring ik altijd twee spaties in en sluit alles correct af.

IMHO siert het een designer/programeur als je code er ook net uit ziet.

[Verwijderd]

crisp schreef op dinsdag 12 juni 2007 @ 00:02:
[...]

Agreed, voor het produceren van valide (conforming) code is zeker extra aandacht nodig, maar die tijd verdient zich meestal bij maintenance wel terug; het is immers makkelijker om na een wijziging een missende close-tag te vinden in een pagina die van origine al conforming was dan in eentje die al tig conformance-errors had (hence: het is een tool)

Het hangt ook een beetje van de werkomgeving af en de tooling die je gebruikt. Een editor met color coding geeft al aan waar code incorrect is. Ik merk zelf als ik de uren controleer dat bij projecten waar validators gewenst zijn nog best wat tijd meer in beslag nemen, dan die waar niet volgens die kwaliteitseisen gewerkt moet worden.

Bij maintenance zie ik hier niet direct een verband, maar dat komt ook omdat de meeste maintenance werkzaamheden niet zo complex zijn dat er gevalideerd moet worden om fouten te vinden, en omdat de code die we maken leesbaar en netjes in elkaar steekt. Ik kan me voorstellen dat je in specifieke situaties hier wel voordeel uit gaat halen.

Wat ook meespeelt is een structureel gebrek aan goed personeel, en uit die grote bak met mensen zitten er maar een paar die uberhaupt op de hoogte zijn van doctypes en hier in hun vrije tijd graag tijd aan willen besteden. Op de werkvloer blijft niet altijd veel tijd over om hier echt goed in te duiken.

Ik verwacht de komende jaren ook niet echt een aanzienlijke verbetering op het gebied van validated code, puur omdat de arbeidsmarkt voor echt webontwikkelaars nu al krap is en de komende jaren steeds krapper zal worden. De werkzaamheden worden steeds dynamischer en complexer, maar de prijsstelling zal minimaal veranderen. Dat zal ten koste gaan van tijd, budget of kwaliteit.

Ik denk dat kwaliteit (op het gebied van markup en validatie) voor de meeste studios hier de makkelijkste weg is, en voor weinig klanten echt van belang is. Als de bezoekers de website kunnen bezoeken, en het werkt prima in de gebruikelijke browsers, dan is markup iets extras maar niet per direct nodig voor het functioneren van de website. Het is meer iets vanuit de ideeën van het vakgebied, waarvan andere ontwikkelaars zeggen "het moet zo werken, want.".

[ Voor 23% gewijzigd door Verwijderd op 12-06-2007 23:08 ]

[crisp]

Verwijderd schreef op dinsdag 12 juni 2007 @ 22:59:
[...]


Het hangt ook een beetje van de werkomgeving af en de tooling die je gebruikt. Een editor met color coding geeft al aan waar code incorrect is. Ik merk zelf als ik de uren controleer dat bij projecten waar validators gewenst zijn nog best wat tijd meer in beslag nemen, dan die waar niet volgens die kwaliteitseisen gewerkt moet worden.

In mijn ervaring zijn template-based omgevingen of in ieder geval een omgeving waarbij markup en logic goed gescheiden zijn makkelijker te valideren. Veel projecten maken er echter nogal een zooitje van
Als validatie een kwaliteits-eis is dan kan ik me voorstellen dat dat extra tijd kost, ook ik ben zo'n beetje de enige hier die generated code af en toe eens door de validator heenhaalt...

Bij maintenance zie ik hier niet direct een verband, maar dat komt ook omdat de meeste maintenance werkzaamheden niet zo complex zijn dat er gevalideerd moet worden om fouten te vinden, en omdat de code die we maken leesbaar en netjes in elkaar steekt. Ik kan me voorstellen dat je in specifieke situaties hier wel voordeel uit gaat halen.

Het is een kwestie van uitsluiten, net zoals we hier in WEB verwachten dat mensen met validated voorbeelden komen als ze een renderprobleem ondervinden - vaak ligt het daar niet aan maar otoh is het wel weer een goede reden om te wijzen op de specificaties

Wat ook meespeelt is een structureel gebrek aan goed personeel, en uit die grote bak met mensen zitten er maar een paar die uberhaupt op de hoogte zijn van doctypes en hier in hun vrije tijd graag tijd aan willen besteden. Op de werkvloer blijft niet altijd veel tijd over om hier echt goed in te duiken.

Dat eerste is inderdaad een onfortuinlijk feit; in een ideale wereld zouden mensen enkel werk doen waar ook hun interesse ligt, maar zo is het helaas niet. Als mensen op de werkvloer gewoonweg niet de mogelijkheid krijgen om zich te onwikkelen op dit gebied dan is dat echter een meer kwalijke zaak; een baas zou moeten begrijpen dat dat juist in deze markt-sector van uiterst belang is...

Ik verwacht de komende jaren ook niet echt een aanzienlijke verbetering op het gebied van validated code, puur omdat de arbeidsmarkt voor echt webontwikkelaars nu al krap is en de komende jaren steeds krapper zal worden. De werkzaamheden worden steeds dynamischer en complexer, maar de prijsstelling zal minimaal veranderen. Dat zal ten koste gaan van tijd, budget of kwaliteit.

Met pijn in mijn hart moet ik hierbij toegeven dat dat inderdaad het geval is...

Ik denk dat kwaliteit (op het gebied van markup en validatie) voor de meeste studios hier de makkelijkste weg is, en voor weinig klanten echt van belang is. Als de bezoekers de website kunnen bezoeken, en het werkt prima in de gebruikelijke browsers, dan is markup iets extras maar niet per direct nodig voor het functioneren van de website. Het is meer iets vanuit de ideeën van het vakgebied, waarvan andere ontwikkelaars zeggen "het moet zo werken, want.".

Mijn angst is dat een dergelijke visie uiteindelijk de ontwikkeling zelf zal doen stilstaan. Op dit moment zitten we al in een dergelijke kip-ei situatie: Microsoft heeft al jaren de boel laten versloffen met IE waardoor de HTML WG en CSS WG enorm in een slop zijn geraakt (geen major implementaties) en waardoor ontwikkelaars zich (onterecht) zijn gaan focussen op implementaties ipv de specificaties. Dat laatste geeft uiteraard ook weer geen drijfveer aan vendors om hun foute implementaties te fixen.

[Verwijderd]

Veel websites zijn ook gemaakt met content management systemen erachter, dan kan de ontwikkelaar nog zo z'n best hebben gedaan om alles perfect W3C valid te maken (wat een andere discussie is hoe haalbaar en nuttig dat is), als de klant dan vervolgens lekker vanuit Word gaat copy pasten komt er nog de meest ranzige code in de pagina's te staan.

Ook werken veel mensen hun portfolio niet zo vaak bij en vooral de grotere klanten hebben weinig behoefte om in zo'n portfolio te staan (not to mension hoeveel tussenhandel er is in die branche), dus de mooiste sites staan waarschijnlijk niet in het portfolio.

Voor de eigen site is al helemaal geen tijd.

Door verschillende redenen hangt het hele HTML/XHTML/CSS verhaal aan elkaar van hacks ed, zo kun je niet eens fatsoenlijk een flash element in een valide pagina zetten zonder een workaround te gebruiken om dat ding streaming te krijgen (iets wat op zich wel te doen is, maar niemand die het verschil merkt buiten de validator en het kost je gewoon extra tijd).

De W3C validator is dus een leuke tool, maar je kunt em absoluut niet gebruiken als kwaliteitscheck, het heeft simpelweg niets met kwaliteit te maken.

Het zegt enkel of je voldoet aan (hun interpretatie van en voor zo ver te controleren door de validator) de W3C regels. Het is op z'n minst twijfelachtig of een valide pagina per definitie een kwalitatieve pagina is.

[BlackWhizz]

Palomar schreef op zondag 10 juni 2007 @ 18:43:
Die validator gaat wel snel over de zeik als er maar 1 foutje in zit. Dan rekent ie alles erna ook fout en zit je zo op tientallen fouten. Daar moet je wel rekening mee houden. Maar ik ben wel van mening dat een webdesignbedrijf zich erg goed aan de standaarden moet houden. De meeste webdesignbureau's (/eenmanszaakjes) echter worden gewoon gerund door een scholier oid die eigenlijk geen enkele kennis van zaken heeft. Verbaast me ook niks dat die sites dus vol met fouten zitten. Voor kleine sites voor de bakker om de hoek maakt het ook allemaal niet zoveel uit, maar een grotere site die ook met google moet worden gevonden, regelmatig geupdatet moet worden, op verschillende apparaten bekeken moet kunnen worden etc. etc. dan ben je niet echt slim bezig als je maar wat aankloot.

Er zijjn genoeg scholieren die het wel kunnen. Op dit moment heb ik ook nog geen portfolio. Die komt wel. Maar ik vind het persoonlijk ook al niet staan als je op een portfolio adressen hebt als index.php?pagina=blaat&dit=dat&dat=ookzo ik vind dat er cheapo uitzien. Ik heb liever gewone mod_rewrite urls
{paginanaam}.htm => index.php?p={paginanaam}

[Verwijderd]

w3c is zeker een leuke tool maar verder dan niveau 0 kan ik niet halen. Omdat ik het dan gewoon niet meer begrijp, dan gaat het heel erg vaag worden. Dan moet je dat weer gaan opzoeken en dat kost weer tijd enz.

Wat ik ook heb gemerkt is dat javascript niet zo goed werkt bij het w3c. Dan krijg je al heel snel fouten erin, dat is dus ook de reden dat veel sites fouten vertonen want een site bestaat nooit uit 100% html. Altijd een mengeling van html of xml, php, asp enz. En de sites die uit 100% html bestaan zijn meestal verouderd.

[mithras]

Verwijderd schreef op woensdag 13 juni 2007 @ 10:44:
w3c is zeker een leuke tool maar verder dan niveau 0 kan ik niet halen. Omdat ik het dan gewoon niet meer begrijp, dan gaat het heel erg vaag worden. Dan moet je dat weer gaan opzoeken en dat kost weer tijd enz.

Als jer weet wat de standaarden zijn dan heb je het 'al doende' geleerd en kan je na een tijdje gewoon valid html schrijven. Er is eigenlijk niets moelijks aan, alleen vaak de onwil om het even goed te leren bij de designers

Wat ik ook heb gemerkt is dat javascript niet zo goed werkt bij het w3c. Dan krijg je al heel snel fouten erin, dat is dus ook de reden dat veel sites fouten vertonen want een site bestaat nooit uit 100% html. Altijd een mengeling van html of xml, php, asp enz. En de sites die uit 100% html bestaan zijn meestal verouderd.

Je moet wel serverside en clientside uit elkaar halen. Je kan prima met php/asp/rube/whatever valid html genereren. Verder komt met xmlHttpRequests wel steeds vaker xml aan bod, maar het gros is en blijft 100% html hoor

[crisp]

Verwijderd schreef op woensdag 13 juni 2007 @ 10:44:
w3c is zeker een leuke tool maar verder dan niveau 0 kan ik niet halen. Omdat ik het dan gewoon niet meer begrijp, dan gaat het heel erg vaag worden. Dan moet je dat weer gaan opzoeken en dat kost weer tijd enz.

"ik wil wel websites kunnen maken maar de theorie wil ik niet leren"?
Tsja, volgens mij is kennis opdoen toch een noodzaak bij alles wat je wilt beoefenen...

Wat ik ook heb gemerkt is dat javascript niet zo goed werkt bij het w3c. Dan krijg je al heel snel fouten erin, dat is dus ook de reden dat veel sites fouten vertonen want een site bestaat nooit uit 100% html. Altijd een mengeling van html of xml, php, asp enz. En de sites die uit 100% html bestaan zijn meestal verouderd.

PHP en ASP zijn serverside talen, dat zie je (als het goed is) niet terug in de gegenereerde code.
Met inline javascript hoef je eigenlijk enkel op te passen voor close-tags in strings (forward slash escapen). De meeste sites zijn echter toch grootendeels uiteindelijk HTML op het moment dat het bij de client aankomt

[Bigs]

Blaise schreef op zondag 10 juni 2007 @ 18:41:
Semantiek is een betere indicator van de kwaliteit van een website dan het aantal errors van de W3C validator. Misschien wordt steevast '&' gebruikt in plaats van '& amp;' in query URLs. Dan zit je zo op tientallen fouten, terwijl de website prima werkt.


[...]

Het kost geen extra tijd om je aan de standaarden te houden als je de standaarden eenmaal kent en je ze in het achterhoofd houdt tijdens het bouwen. Het is meer een kwestie van er kennis van nemen. Zo ingewikkeld is correcte HTML niet.

Inderdaad.. semantiek vind ik veel belangrijker dan een pagina die niet door de validator komt door een missend alt-attribuut op een plaatje of het gebruik van browser-specifieke CSS (dan bedoel ik geen hacks, maar gewoon uitbreidingen van mozilla of webkit).

Van de andere kant is het ook zo dat als je je eenmaal verdiept hebt in standaarden het niet zoveel meer voorstelt. Onze site (no spam intended) wordt aan browsers die daar om vragen geleverd als xhtml 1.1 met het juiste mimetype, en aan anderen als xhtml 1.0 met text/html. Hij valideert voor beide.

Dat is wel leuk om op te fappen, maar veel belangrijker vind ik dat de site semantisch goed in elkaar zit (alhoewel de indeling in h1,h2,h3 nog niet helemaal klopt) en dat de site door middel van stylesheets helemaal getransformeerd kan worden om te printen of op een gsm te kijken, met dezelfde HTML.

Door de cleane code die volledig aan de standaarden voldoet kan ik er ook (vrijwel) zeker van zijn dat de site in alle toekomstige browsers goed blijft werken. En oudere browsers of hulpmiddelen voor slechtzienden kunnen er prima mee uit de voeten door gewoon de stylesheets te negeren.

[mithras]

Bigs schreef op woensdag 13 juni 2007 @ 10:59:
[...]

Van de andere kant is het ook zo dat als je je eenmaal verdiept hebt in standaarden het niet zoveel meer voorstelt. Onze site (no spam intended) wordt aan browsers die daar om vragen geleverd als xhtml 1.1 met het juiste mimetype, en aan anderen als xhtml 1.0 met text/html. Hij valideert voor beide.

[...]en dat de site door middel van stylesheets helemaal getransformeerd kan worden om te printen of op een gsm te kijken, met dezelfde HTML.

Je schrijft dus html met een xhtml doctype. Inderdaad leuk die validatie, maar zo te zien doe je weinig met xml (als in: niets ) dus kan je beter html4.01 valideren dan xhtml1.1 of 1.0.

* mithras snapt nog steeds niet waarom iedereen die xhtml gebruikt terwijl ze html bedoelen

[BasieP]

Tom schreef op maandag 11 juni 2007 @ 17:17:
Wat een baggersite

maar pak er nu eens een rekenmachine bij, en ga alle quotes die ze niet op hun site hebben, de tekens van de doctype, de "amp;" etc. etc.
maal het aantal hits op die pagina = aantal bytes aan dataverkeer dat ze uitsparen.

Dit is dus heel bewust gedaan, en er is echt wel rekening gehouden met of het nog werkt op alle browsers.
alle dingen die ze dus niet volgens de standaard hebben zijn (in hun ogen) acceptabel.

[Bigs]

mithras schreef op woensdag 13 juni 2007 @ 11:03:
[...]
Je schrijft dus html met een xhtml doctype. Inderdaad leuk die validatie, maar zo te zien doe je weinig met xml (als in: niets ) dus kan je beter html4.01 valideren dan xhtml1.1 of 1.0.

* mithras snapt nog steeds niet waarom iedereen die xhtml gebruikt terwijl ze html bedoelen

Html4 voelt verouderd aan, xhtml helpt in het schrijven van nette code doordat en hoop legacy tags en attributen ongeldig zijn gemaakt. Firefox en Safari halen XHTML bovendien ook echt door een XML parser (mits het als application/xhtml+xml wordt aangeleverd), wat theoretisch een marginaal snellere rendertijd oplevert.

[mithras]

Bigs schreef op woensdag 13 juni 2007 @ 11:12:
[...]


Html4 voelt verouderd aan, xhtml helpt in het schrijven van nette code doordat en hoop legacy tags en attributen ongeldig zijn gemaakt. Firefox en Safari halen XHTML bovendien ook echt door een XML parser (mits het als application/xhtml+xml wordt aangeleverd), wat theoretisch een marginaal snellere rendertijd oplevert.

Dan zou ik zeggen valideer toch nog lekker html4.01 strict, zijn al je legecy attributen ook ongeldig, en is het over een bepaalde tijd ook makkelijker om over te gaan op html5