Standaarden (W3C, etc.)

[Verwijderd]

In professionaliteit van een webdesignbureau werd door meerdere mensen het idee geopperd om een topic te houden over webstandaarden. Het gaan dan vooral om het correct gebruiken van HTML en CSS en toepassingen daarvan op het huidige web.

Er is heel veel over te zeggen en veel dingen zijn ook al uitvoerig besproken in topics, maar in de praktijk blijkt het meestal toch tegen te vallen. Zeker in Nederland zijn er zeer weinig bedrijven die ook maar een beetje aandacht schenken aan broncode en standaarden. Meestal vinden ze maar een paar dingen belangrijk; backend en ontwerp. De broncode wordt dan ook overgelaten aan de ontwerper die er vaak totaal geen verstand van heeft en door een leuke editor een paar tabellen (niet semantisch correct) op maat laat maken.

Op die manier worden sites ongeveer twee keer zo groot als ze kunnen zijn (er zijn natuurlijk extremen te noemen, zoals Google). Daarnaast worden diezelfde sites er minder toegankelijk op. En hoewel toegankelijkheid niet alles met correcte code te maken heeft, hangt er wel veel vanaf. Door het gebruiken van (echte) headers kan de gebruiker bijvoorbeeld makkelijk langs de headers skippen, om te kijken of er relevante informatie in staat.

Tevens zal de site beter geindexeerd worden door zoekmachines, welke veel te maken hebben met de accessibility van een website. Immers, Google is de grootste blinde gebruiker van het web. Een zoekmachine hoeft niet langer door allemaal tabellen heen te spitten op zoek naar relevante informatie, maar vindt deze veel makkelijker (en geeft hogere pagerank etc.) door het gebruik van elementen die ervoor bedoeld zijn, zoals H1, STRONG, EM.

Ook wordt een site veel kleiner en "mobieler" door het gebruik van standaarden. Als je opmaak compleet van semantiek gescheiden hebt kun je je website in principe op elk platform openen met een browser. Doordat de inhoud van opmaak gescheiden is, wordt het te downloaden bestand ook kleiner. Niet alleen scheelt het verhuizen van FONT elementen naar style sheets enorm veel bytes, als een platform geen style sheets ondersteund, download het alleen maar die paar bytes die nodig zijn om het complete LINK element te downloaden (nihil), maar het style sheet zelf zal niet gedownload worden (tenzij het MEDIA attribuut niet goed, of wel goed gebruikt wordt).

Daarnaast wordt het wijzigen van de layout ook een stuk makkelijker, omdat je dan (meestal maar) 1 style sheetje wijzigd en de bedrijfskleuren kloppen weer.

Eigenlijk zijn er geen goede redenen om web standaarden niet te gebruiken, behalve dat je het niet kan, maar dan zou ik overwegen om; of te stoppen, of ze eerst te leren en dan door te gaan.

(Ik reageer later nog wel een keer, als iemand iets zegt wat me inspireert)

[CH4OS]

Verwijderd schreef op 12 maart 2004 @ 09:58:
Eigenlijk zijn er geen goede redenen om web standaarden niet te gebruiken, behalve dat je het niet kan, maar dan zou ik overwegen om; of te stoppen, of ze eerst te leren en dan door te gaan.

Ik denk, en zo heb ik het ook geleerd, is door het gewoon te oefenen, dus eerst leren en dan door te gaan... Sorry, maar ik denk daar anders over. Wat maakt het nou uit, dat de site (in het begin) misschien niet 100% HTML4.01 (als voorbeeld) validated is, daar zijn de validators voor, om die eruit te halen, en zodoende kan ik er dan ook van leren, aangezien het een fout, die ik heb gemaakt...

Om het dus ff samenvattend te zeggen: Oefening baart kunst

[ Voor 5% gewijzigd door CH4OS op 12-03-2004 10:12 ]

[Willem]

Weinig toe te voegen Goed verhaal.

Alleen rest mij een vraag, bestaan er gradaties in standaarden en het toepassen daarvan? Om een voorbeeld te noemen:

HTML:

<p style="font-weight:bold;font-size:14px;margin-bottom:15px;">Pagina titel</p>

is in principe goed, toch?
Maar beter is (zoals je zelf ook al aangeeft)

HTML:

<h1>Pagina titel</h1>

Optie #1 is ranzig, maar is het fout?

[Verwijderd]

willem169 schreef op 12 maart 2004 @ 10:13:

Optie #1 is ranzig, maar is het fout?

Semantisch gezien? ja, je gebruikt een <p> tag voor iets waar de <h1> tag voor is

[ Voor 3% gewijzigd door Verwijderd op 12-03-2004 10:16 ]

[Verwijderd]

Verwijderd schreef op 12 maart 2004 @ 10:15:
Semantisch gezien? ja, je gebruikt een <p> tag voor iets waar de <h1> tag voor is

Goed, voor een P versus Hx tag is het meestal wel duidelijk maar vaak is die distinctie niet zo zwart-wit.

Verwijderd schreef op 12 maart 2004 @ 09:58:
Eigenlijk zijn er geen goede redenen om web standaarden niet te gebruiken, behalve dat je het niet kan, maar dan zou ik overwegen om; of te stoppen, of ze eerst te leren en dan door te gaan.

Dat zou jij misschien overwegen, maar voor veel mensen die gewoon hun werk willen doen is dat niet altijd een optie. Deze skills leren kost tijd. Veel tijd, zelfs, als je die skills op een professioneel nivo wilt kunnen toepassen. Geen wonder dus dat er maar weinig mensen zijn die lekker door blijven gaan met wat ze kennen en kunnen.

[Willem]

OK ander voorbeeld:

HTML:

<p style="margin-bottom:10px;color:#000;">

HTML:

<p>

Cascading Stylesheet:

div#layerNaam p {
  margin-bottom:10px;color:#000;
}

#1 is niet fout
#2 is netter

En dan?...

[Verwijderd]

#1 is fout. STYLE is een presentationeel attribuut, geen semantisch.

Bij je eerste voorbeeld, denk ook aan #3, 'head,title{display:block}'.

Geen wonder dus dat er maar weinig mensen zijn die lekker door blijven gaan met wat ze kennen en kunnen.

Goed punt. Foutje in mijn redenatie inderdaad. Ik ben eigenlijk meer van mening dat bedrijven die weten dat het beter kan, beter met andere bedrijven samen kunnen gaan werken die de expertise wel in huis hebben. Dat soort "samenwerkingscontracten" werken prima. Mijn bedrijf heeft al verschillende keren succesvol met ontwerp/ontwikkel bedrijven samengewerkt voor het creeeren van de juiste HTML en CSS behorende bij de inhoud en het ontwerp dat aangeleverd werd.

[André]

Verwijderd schreef op 12 maart 2004 @ 10:27:
[...]

Goed, voor een P versus Hx tag is het meestal wel duidelijk maar vaak is die distinctie niet zo zwart-wit.


[...]

Dat zou jij misschien overwegen, maar voor veel mensen die gewoon hun werk willen doen is dat niet altijd een optie. Deze skills leren kost tijd. Veel tijd, zelfs, als je die skills op een professioneel nivo wilt kunnen toepassen. Geen wonder dus dat er maar weinig mensen zijn die lekker door blijven gaan met wat ze kennen en kunnen.

Inderdaad, hier op het werk beheren we 110 intranet sites uit heel europa, en dan heb je het over 10 duizenden pagina's. Die bewerken we dan ook voornamelijk met Frontpage omdat het anders niet te doen is. Er zijn bepaalde highlights die elke week weer komen, en die worden aangeleverd in word: met Frontpage is het 5 seconden werk, maar ga het maar eens in een teksteditor doen...

Aan de andere kant, dan neem ik als voorbeeld een bedrijvensite, is het zo dat die semantisch correct moet zijn. Deze sites zijn vaak alleen een visitekaartje en niet veel aan verandering onderheving, daar heeft het dus nut om veel aandacht te besteden aan de semantiek en standaards.

[Verwijderd]

Ik zou voor de tweede gaan, alleen al om je code schoon te houden, hou helemaal niet van inline styles.

Ik ben het gewoon eens met Anne, ik denk ook niet dat we ons moeten concentreren op dit soort voorbeelden, maar de stelling al dan niet moeten ondersteunen met argumenten.

De voorbeelden die je aandraagt, zijn al honderd keer beter dan wat je in het "wild" tegenkomt

Als mensen geen moeite willen doen om de specificaties door te lezen, hebben ze in de webdesign wereld eigelijk niks te zoeken en dat heeft niks te maken met tijd of kosten besparing wat zo vaak wordt aangedragen, een paar goede templates van waaruit je kan werken is in principe genoeg om de meeste situatie te ondervangen.

Ook lees je hier vaak, het hoeft alleen maar in die en die browser te werken, kan allemaal best waar zijn, het gaat echter om jezelf een bepaalde methode aan te leren en die concequent toe te passen op al je projecten.

Mijn eerste aanraking met HTML was rond de introductie van NS 2.0 in de tussentijd is er veel gebeurd en veranderd op het gebied van HTML/DOM/CSS/XML etc etc. echter ik zie om me heen dat mensen soms nog steeds in dat tijdperk zijn blijven hangen qua HTML, eerst een tabel... en dan zien ze wel weer. FOUT! Mensen moeten leren om van die f*cking tabellen los te komen.

<rant>
Stilstand is achteruitgang en dat geldt niet alleen voor mensen (hint hint)
</rant>

[faabman]

ik ben het eigenlijk volledig met je eens, maar, zoals ook al (voor een deel) naar voren kwam in het andere topic...

vooraf:
Ik ga uit van sites die zijn voorzien van een cms met wysiwyg editor die zijn gericht op het MKB. Bij de Tridions van deze wereld zal mijn verhaal wel niet helemaal van toepassing zijn..

1. WYSIWYG: bedrijven willen zelf hun site kunnen editen met een online wysiwyg - editor... er zijn meer dan genoeg editors beschikbaar die lowercase (x)html produceren en daarbij de tags <b> en <i> vervangen door <strong> en <em>, maar de html die zij uitspugen is semantisch nooit correct, het semantisch genereren van data ligt imo niet zozeer aan de gebruikte editor, maar meer aan de gebruiker. Nu zul je zeggen; "die gebruiker is toch op te voeden?", en dat brengt me meteen tot het volgende punt.

2. Geld: valt onder te verdelen in 2 delen, directe en indirecte kosten. Met de directe kosten bedoel ik het geld wat een bedrijf betaalt voor een internetsite (en de opbrengsten van het webdesignbureau). Hoe hoger dit bedrag hoe meer tijd het bureau kan besteden aan het semantisch correct opzetten van de site... Wat voor een onderneming echter eerst belangrijk is, is het uiterlijk van de site! En aangezien de grafisch ontwerper ook betaalt moet worden zal de semantiek in de primaire opzet van een site op basis van kosten al snel een minder belangrijke positie innemen. Daarnaast hebben we nog de indirecte kosten die de gebruiker van het WYSIWYG-gedeelte voor zijn kiezen krijgt, om de site semantisch correct op te zetten moet deze ook weten hoe dat te doen, de webdesigner kan deze gebruiker opvoeden, maar, dat kost wel geld (de designer moet worden betaalt, maar, de gebruiker kan niet doorgaan met zijn overige werkzaamheden en dat kost dus ook geld). En waarom als het toch al werkt (is hetgeen wat ik al een aantal naar mijn hoofd heb gekregen)

Mijn 2e punt kan ik direct bekritiseren, de pagina's woren kleiner en dus sneller / gebruik makend van minder dataverkeer. Hierbij kan je je echter ook weer afvragen of dat nu zo belangrijk is voor een ondernemer die toch weet dat het grootste deel van zijn bezoekers over breedband beschikt en de kosten van dataverkeer vallen tegenwoordig ook wel mee...

_{dit kan een leuke inhoudelijke discussie worden, ik hoop dat mensen zonder inhoudelijke argumenten alleen lezen}

[ Voor 4% gewijzigd door faabman op 12-03-2004 11:03 ]

[Pelle]

Het strong/em versus b/i verhaal heb ik nooit echt begrepen. Ik wil een bepaalde tekst bold hebben, en dan is er niets logischer dan daarvoor een b-tag te gebruiken.
Je kunt semantiek te ver doorvoeren, en daar vind ik dit dus een goed voorbeeld van.

Er is genoeg tekst die bold of italic moet, zonder dat het semantisch gezien benadrukt moet worden. Het gebruik van een strong of em-tag resulteert in dit geval in een waarde die gehangen wordt aan de betreffende tekst, die er helemaal niet aan hangt.

[Genoil]

Pelle schreef op 12 maart 2004 @ 11:10:
Het strong/em versus b/i verhaal heb ik nooit echt begrepen. Ik wil een bepaalde tekst bold hebben, en dan is er niets logischer dan daarvoor een b-tag te gebruiken.
Je kunt semantiek te ver doorvoeren, en daar vind ik dit dus een goed voorbeeld van.

Er is genoeg tekst die bold of italic moet, zonder dat het semantisch gezien benadrukt moet worden. Het gebruik van een strong of em-tag resulteert in dit geval in een waarde die gehangen wordt aan de betreffende tekst, die er helemaal niet aan hangt.

ja maar stel nou dat ik een stylesheet heb waarin staat dat de <p> in italics moet, en binnen die <p> een woord staat dat normaalgesproken schuingedrukt zou worden, omdat er nadruk (emphasis) op ligt. Dan zegt <em> veel meer over de semantiek van het woord dan <i>, immers, de hele <p> is al schuingedrukt...

[ Voor 4% gewijzigd door Genoil op 12-03-2004 11:22 ]

[André]

Genoil schreef op 12 maart 2004 @ 11:22:
[...]


ja maar stel nou dat ik een stylesheet heb waarin staat dat de <p> in italics moet, en binnen die <p> een woord staat dat normaalgesproken schuingedrukt zou worden, omdat er nadruk (emphasis) op ligt. Dan zegt <em> veel meer over de semantiek van het woord dan <i>, immers, de hele <p> is al schuingedrukt...

Dus daaruit blijkt dat de <em> ook niet bedoeld is om iets cursief weer te geven, maar meer om het sematisch correcter te laten lijken. Eigenlijk zou je dan in de <em> weer een <i> moeten doen om het cursief te zetten.

Zelfde geld voor <strong> en <b>.

[Verwijderd]

Verwijderd schreef op 12 maart 2004 @ 10:27:
Dat zou jij misschien overwegen, maar voor veel mensen die gewoon hun werk willen doen is dat niet altijd een optie. Deze skills leren kost tijd. Veel tijd, zelfs, als je die skills op een professioneel nivo wilt kunnen toepassen. Geen wonder dus dat er maar weinig mensen zijn die lekker door blijven gaan met wat ze kennen en kunnen.

Dat geeft dus eigenlijk al aan hoe onvolwassen deze markt nog is. In andere markten is het heel normaal om volgens de geldende standaarden te werken, om je regelmatig bij te scholen over veranderingen in de materie waar je mee werkt.

Overigens denk ik dat het best mee valt met hoe moeilijk het is om correct HTML te leren schrijven. Het moeilijkste is het anders leren denken: niet meer alles door elkaar, maar opmaak en inhoud gescheiden houden. Eigenlijk is HTML 4.0 en hoger veel simpeler dan HTML 3.2 en lager... daarnaast is het, als je gebruik maakt van CSS veel eenvoudiger om later wijzigingen in het ontwerp door te voeren en doordaat de HTML pagina veel simpeler is is het ook eenvoudiger om wijzigingen in de inhoud door te voeren.

Vergelijk het maar met Word: veel mensen kennen de kracht van opmaakprofielen niet, maar als je er eenmaal mee werkt is het zoveel simpeler.

[Verwijderd]

dan ben je imho toch weer bezig opmaak in je code te proppen, als iets schuin of dik gedrukt moet heeft dat vaak een reden. Omdat die tekst een bepaalde functie heeft (nadruk, kopje, naam van iemand ofzo) leg dan die opmaak in de stylesheet vast en geef het element de juiste tag

[Verwijderd]

André schreef op 12 maart 2004 @ 11:31:
Eigenlijk zou je dan in de <em> weer een <i> moeten doen om het cursief te zetten.

Zelfde geld voor <strong> en <b>.

Nee, juist niet... je zet in je stylesheet dat <em> cursief is en dat <strong> bold is. Dan is opmaak en semantiek gescheiden.

/me gebruikt overigens altijd <b> en <i>

[kleautviool]

Ik zie het altijd zo.

<strong> gebruik je om iets met meer nadruk dan <em> weer te geven. En <b> was iets met wiskunde ofzo d8 ik. <i> gebruik je om iets schuin te zetten volgens taalconventies, en <em> gebruik je om iets met nadruk weer te geven.

[Willem]

jeroenr:
Vergelijk het maar met Word: veel mensen kennen de kracht van opmaakprofielen niet, maar als je er eenmaal mee werkt is het zoveel simpeler.

Dit is zeer sterk herkenbaar.

[André]

Verwijderd schreef op 12 maart 2004 @ 11:33:
[...]

Dat geeft dus eigenlijk al aan hoe onvolwassen deze markt nog is. In andere markten is het heel normaal om volgens de geldende standaarden te werken, om je regelmatig bij te scholen over veranderingen in de materie waar je mee werkt.

Klopt, heel veel bedrijven zie je tegenwoordig bezig om alles ISO gecertificeerd te krijgen. Want er is gewoon vraag naar gecertificeerde bedrijven. En dat houd puur in dat een bedrijf zich gewoon aan standaarden houd en er naar werkt.

[Verwijderd]

Lijkt me wel verstandig om de realistische kant van het verhaal te kiezen. Ik hou me nog een beetje buiten het verhaal, maar er is een duidelijk verschil tussen het maken van een website voor je moeders kookclub in je vrije tijd, en het maken van enterprise level websites die ervoor dienen om geld op te leveren in zo kort mogelijke tijd.

Er zitten hier een aantal mensen die heel lang thuis zijn op het ontwikkelen voor het mkb, maar ook een aantal mensen wat al heel wat ervaring heeft met het ontwikkelen van enterprise level projecten.

[Tom]

André schreef op 12 maart 2004 @ 11:42:
[...]


Klopt, heel veel bedrijven zie je tegenwoordig bezig om alles ISO gecertificeerd te krijgen. Want er is gewoon vraag naar gecertificeerde bedrijven. En dat houd puur in dat een bedrijf zich gewoon aan standaarden houd en er naar werkt.

Als ik een PC bestel bij een computerzaak boeit het mij niet of ze met ISO-standaarden werken. Als ik maar een goed werkende PC krijg en ik verwacht goede support

[André]

Tom schreef op 12 maart 2004 @ 11:46:
[...]

Als ik een PC bestel bij een computerzaak boeit het mij niet of ze met ISO-standaarden werken. Als ik maar een goed werkende PC krijg en ik verwacht goede support

Maar als je als multinational je IT afdeling uitbesteed wil je een gecertificeerd bedrijf.

[Verwijderd]

Tom schreef op 12 maart 2004 @ 11:46:

Als ik een PC bestel bij een computerzaak boeit het mij niet of ze met ISO-standaarden werken. Als ik maar een goed werkende PC krijg en ik verwacht goede support

En aan de hand van welke standaarden denk je dat ze die onderdelen produceren?

[Tom]

André schreef op 12 maart 2004 @ 11:48:
[...]

Maar als je als multinational je IT afdeling uitbesteed wil je een gecertificeerd bedrijf.

Mee eens.
Zie post van Gordijnstok..

[Willem]

Tom:
Als ik een PC bestel bij een computerzaak boeit het mij niet of ze met ISO-standaarden werken. Als ik maar een goed werkende PC krijg en ik verwacht goede support

Met (ISO) certificering ben je er wel zeker van.
Zonder niet.

[André]

Het blijft dus een kwestie van: Doel, Tijd en Geld.

Aan de hand daarvan bepaald je hoe de site opgezet word: snel en goedkoop of langzaam en efficient maar duur. (er van uitgaande dat niet iedereen de stof tot in de puntjes beheerst dus het langer duurt om een semantisch correcte site te maken)

[ Voor 27% gewijzigd door André op 12-03-2004 11:55 ]

[418O2]

Tom schreef op 12 maart 2004 @ 11:46:
[...]

Als ik een PC bestel bij een computerzaak boeit het mij niet of ze met ISO-standaarden werken. Als ik maar een goed werkende PC krijg en ik verwacht goede support

En als er wat mis is, kan je niets repareren omdat het raar inelkaar gezet is ?

Ikzelf programmeer voornamelijk in PHP, maar begin me steeds dieper in HTML te verdiepen. Ikzelf bemerk dat ik hoe langer hoe meer op een nette manier programmeer, "zoals het hoort"

Mijn stelling is dus ook "al doende leert men". Je moet imho als programmeur constant bezig zijn met jezelf op een hoger nivo brengen...

[Verwijderd]

André schreef op 12 maart 2004 @ 11:42:
Klopt, heel veel bedrijven zie je tegenwoordig bezig om alles ISO gecertificeerd te krijgen. Want er is gewoon vraag naar gecertificeerde bedrijven. En dat houd puur in dat een bedrijf zich gewoon aan standaarden houd en er naar werkt.

Helaas is dat niet waar. De meeste certificeringen houden in dat je je werkmethoden vastgelegd hebt in procedures. Als jij vastlegt dat "maximaal 95% van de klanten klachten mag hebben" en 90% van je klanten hebben klachten, dan voldoe je nog steeds aan de norm. Natuurlijk is dit iets overdreven, het grote voordeel van zo'n certificeringstraject is dat mensen nadenken over hun werkwijze.

Om even terug te gaan naar webdesign: als webdesigner zou je kunnen vastleggen in je procedures dat je "zo min mogelijk gebruikt maakt van standaarden, om klanten afhankelijk te maken van XYZ design en om op die manier de continuiteit van het bedrijf te waarborgen".

[drm]

Mijn werkgever heeft nogal eens de neiging deze branch (omdat we daar nu eenmaal in werken) te vergelijken met de autohandel en aangrenzende aangelegenheden.

Het grootste probleem is dat iedereen weet wat een APK en niemand wat W3 is. Ik denk dat er een beweging moet komen om bedrijven te informeren over alles wat met standaarden te maken heeft.

Iedereen weet waarvoor tikkertjes in verkeerslichten voor voetgangers zitten. Niemand snapt dat wanneer je site semantisch een crap hole is, een blind persoon er dus niets van kan bakken.

Waarom weet iedereen dat een Lada uit '80 een brakkere auto is dan een Mercedes uit 2004 en niemand dat Internet Explorer op steenkool rijdt en Mozilla op water? Omdat de mensen die het echt aangaat (de mensen die geen weblogs lezen en niet op fora zitten) er niet over geinformeerd worden.

Verder wordt, omdat web-ontwikkeling een vrij rampzalige start heeft gehad, de branche maar weinig serieus genomen. Pietje kan met frontpage toch precies hetzelfde als jullie met jullie hoge uurloon? NEE, dus, dat is niet hetzelfde. Pop the hood!

Kortom: ik opt voor een stichting met een keurmerk en/of een branchevereniging waarin we dat soort dingen naar buiten brengen. Mensen weten het niet omdat wij het ze niet vertellen. (Of in ieder geval maar weinig).

[r0bert]

Ik sluit me voor 200% aan bij drm's verhaal. Niet wettelijk verplichten, maar een soort keurmerk, zoals nu het logootje van w3 bijvoorbeeld bestaat. Zoiets, maar daar meer waarde aan te geven door het in een nederlandse stichting onder te brengen. (Misschien een taak voor w3c nl?)

[ Voor 4% gewijzigd door r0bert op 12-03-2004 12:29 ]

[Verwijderd]

drm schreef op 12 maart 2004 @ 12:11 een hele mooie vergelijking:

niks aan toe te voegen

[curry684]

Ik heb de afgelopen 2 dagen ook wat zitten janken over standaarden... ons bedrijf had een nieuwe website, en de voorpagina is een vrijwel lege Frameset die volgens z'n doctype XHTML 1.0 Frameset zou zijn. Valideert voor geen meter. 2e pagina had niet eens een doctype, en kreeg ik op geen enkele versie gevalideerd. Diepere pagina's, allemaal dezelfde stylesheet inlined ( ), beweerden HTML 4.01 Transitional te zijn, en valideerden ook allemaal op geen enkele versie

Ik vind dat ronduit beschamend als IT-bedrijf en ga dat zo snel mogelijk fixen. Echter, zit ik daar toevallig net met een collega over te praten hier bij Nedcar, en checken we voor de lol eens www.nedcar.nl en zijn bedrijf (www.centric.nl). Nedcar had geen doctype maar haalde nog wel HTML 4.01 Transitional, dat viel dus nog mee in de schade. Echter bij Centric was het ronduit feest: doctype noch charset gespecificeerd.... en indien beiden hard overruled kwam er dit uit:

code:

   2: <html>
   3: 
   4: Deze browser is niet geschikt voor het bekijken van Web4all. 
   5: 
   6: </html>

Hopeloos beschamend toch

Ik vind niet dat alles ter wereld gestandaardiseerd moet zijn, maar de wereldwijd zo enorm veel gebruikte internetprotocollen mag toch hopelijk wel aan een wereldwijd afgesproken conventie voldoen

[André]

curry684 schreef op 12 maart 2004 @ 12:31:

Ik vind niet dat alles ter wereld gestandaardiseerd moet zijn, maar de wereldwijd zo enorm veel gebruikte internetprotocollen mag toch hopelijk wel aan een wereldwijd afgesproken conventie voldoen

Inderdaad, en dan stap 2: dat de browsers zich ook 100% aan de standaard houden, en dat ze onderling alleen concureren met rendertijd en functionaliteit.

[Verwijderd]

curry684 schreef op 12 maart 2004 @ 12:31:
www.centric.nl

Hopeloos beschamend toch

na het bekijken met Mozilla Firefox wel ja

Deze browser is niet geschikt voor het bekijken van Web4all.

[ Voor 16% gewijzigd door Verwijderd op 12-03-2004 12:52 ]

[Annie]

Ik ben een groot voorstander van het gebruik van standaarden. Maar de praktijk bij het bedrijf waar ik werk leert dat nog niet iedereen (including me) alles tot in de puntjes perfect kan toepassen en zeker niet binnen de tijd waarin we op dit moment projecten moeten opleveren. En ik vermoed dat dat bij veel andere bedrijven niet anders is.
Wanneer we tegen een probleem aanlopen wat niet 1-2-3 op te lossen is dan is voor mij de keuze snel gemaakt: the old-fashioned way. Ik kan niet aankomen bij een klant met "Ja, sorry, we gaan een weekje over de deadline heen omdat de site niet helemaal voldoet aan de standaarden. Op een andere manier had het ook wel gewerkt, maar we prutsen graag nog even verder.". Dat is niet alleen vervelend voor de klant, het zijn vaak ook onbetaalde uren.

Neemt niet weg dat daar waar we wel kunnen voldoen we dit altijd als uitgangspunt moeten nemen. En dat er ook actief vanuit het bedrijf gepleit moet worden voor het bijhouden/bijlezen van de standaarden (en daar ook de middelen voor geeft), zodat het toepassen van de standaarden een steeds makkelijkere taak wordt.

Hoe je het ook wendt of keert het zal altijd een afweging blijven van tijd en geld, hebben we genoeg tijd en/of heeft de klant genoeg geld.
Als alle klanten nu ineens zouden eisen dat we voldoen aan de normen dan denk ik dat het voldoen aan de standaarden geen enkel probleem meer zou zijn. Het MT zou de cursussen/boeken/tijd geregeld hebben voor ik World Wide Web Consortium kan zeggen

[Verwijderd]

Het W3C is anders ook niet altijd een voorbeeld getuige deze blog posting die ik tijdens het struinen van mijn beloved FeedDemon (spam *kuch* alert) tegenkwam

http://www.webstandards.o...hive/2004_03.html#a000310

[oh,when?]

Leuk dat zo'n discussie elke paar jaar weer opduikt, goed om bij de les te blijven. Mijn mening is dat standaarden vooral leuk zijn voor de ontwikkelaars hier en in de praktijk vooral zijn nut bewijzen als ze pragmatisch worden toegepast. D.w.z. pas deze toe als blijkt dat ze in jouw situatie handig zijn, maar ga jezelf niet forceren omwille van 'het valideren van mijn code'. Standaarden zijn heel goed toe te passen op de gemiddelde MKB site, maar zoals Gordijnstok ook zegt, ga je een nivo hoger, dan wordt het al verdomd lastig .

Denk aan migratie oude code -> nieuwe code, denk aan verouderde CMS-systemen die hardcoded HTML outputten of zelfs meerdere CMS-systemen binnen een site, denk aan geintegreerde Advertisement Managment systemen, denk aan Sitestat tracking modules, etc etc etc. Allemaal dingen die om de hoek komen kijken bij de grote sites, en die een validatie van een site in gevaar kunnen brengen.

In het rijtje proposities van een groot webburo staat het gebruik van standaarden vaak niet in dat rijtje, simpelweg omdat het voor de klanten van dat webburo niet relevant is. Er zijn hier genoeg mensen ( Pelle, Bosmonster, Blues, Crisp, wilem169, Gordijnstok, Annie, etc etc ) die al een tijdje meedraaien en het klappen van de zweep inmiddels kennen. Het gebruik van standaarden is mooi meegenomen, maar moet niet het uitgangspunt zijn.

[Genoil]

offtopic:
als het toch over standaarden hebben:
http://developers.slashdo...rs/04/03/12/0454228.shtml

(link is tijdelijk down, maar schijnt dus een stylesheet te zijn waarmee IE6 standards-compliant gemaakt wordt)

[Verwijderd]

Uiteindelijk monden deze discussies altijd uit in de conclusie dat standaarden iets is wat iedereen wil, maar wat niet in de praktijk snel kan worden toegepast.

Nog steeds zeggen veel developers dat ze tijd besparen met standaarden, maar in de praktijk blijkt dat wel even tegen te vallen. Overall blijkt er qua tijd toch meer in css layouted designs te zitten.

[Verwijderd]

Genoil schreef op 12 maart 2004 @ 14:15:

offtopic:
als het toch over standaarden hebben:
http://developers.slashdo...rs/04/03/12/0454228.shtml

(link is tijdelijk down, maar schijnt dus een stylesheet te zijn waarmee IE6 standards-compliant gemaakt wordt)

Nee dit is een behavior die je aan je css kunt hangen, stond een paar dagen geleden al vol op de blogs.

[disjfa]

drm schreef op 12 maart 2004 @ 12:11:
mooi verhaal

Je vergeet alleen een ding. Waarom rijd het gros van de mensen nog op benzine/diesel. Mensen kunnen niet tegen vernieuwing, zelfs niet wanneer dat het zwaarst nodig is.

We zijn het er hier allemaal mee eens dat het tijd is voor een ommekeer. Bedrijven moeten erachter komen dat een site maken net iets meer kan kosten maar het erna onderhouden 90% minder tijd in kan nemen.

Verder absoluut mee eens en dat is ook zeer zeker waarom ik wel op mijn werk het door heb gevoerd. Na een paar verschillende styles op dezelfde pagina willen ze hier ook niet anders. Wij rijden lekker op zonne-energie.

[Verwijderd]

Nog steeds zeggen veel developers dat ze tijd besparen met standaarden, maar in de praktijk blijkt dat wel even tegen te vallen. Overall blijkt er qua tijd toch meer in css layouted designs te zitten.

Ik denk dat dat toch samenhangt met ervaring. Argument van CMS systemen e.d. die gruwelijk zijn om mee te werken is veel meer overtuigend.

Grappig is dat ik precies hetzelfde als DRM zat te denken (mwaj, grappig). Een site met een soort keurmerk en een groot aantal richtlijnen. Zoiets als drempelsweg, alleen dan met een duidelijkere visie. Promoten van zo'n initiatief is natuurlijk het allerbelangrijkst als het eenmaal gerealiseerd is en dan natuurlijk niet alleen via een aantal leuke weblogs want dan blijf je in dezelfde cirkel.

[Verwijderd]

Nog even over EM, STRONG, wat op de vorige pagina begon. Zowel EM als STRONG hebben uiteraard niets met hun visuele presentatie te maken. EM zou net zo goed dikgedrukt kunnen zijn i.p.v. schuin. Sommige mensen vinden dat er voor I en B wel degelijk iets te zeggen valt, I kun je bijvoorbeeld gebruiken voor bootnamen, latijnse namen van dieren (geloof ik) etc.

Aan de andere kant zijn beide elementen puur presentationeel en kun je ze dus eigenlijk beter droppen voor iets als SPAN, aangezien sommige zoekmachines toch nog waarde gaan hechten aan B en I, al is het minder dan aan EM en STRONG.

[curry684]

Verwijderd schreef op 12 maart 2004 @ 14:44:
Een site met een soort keurmerk en een groot aantal richtlijnen.

Is er toch al:

[Not Pingu]

Verwijderd schreef op 12 maart 2004 @ 14:27:
Nog steeds zeggen veel developers dat ze tijd besparen met standaarden, maar in de praktijk blijkt dat wel even tegen te vallen. Overall blijkt er qua tijd toch meer in css layouted designs te zitten.

In wat voor context bedoel je dit? Ik ben het er toch niet mee eens. Vroeger ontwierp ik ook met HTML3.x, wat echt een ramp was voor de onderhoudbaarheid, het doen van kleine verbeteringen en het maken van nieuwe pagina's. Not to mention de overzichtelijkheid van je code.

Een CSS file hoef je maar 1x te schrijven, als je nieuwe pagina's wilt hoef je dan alleen nog maar wat simpele HTML + content te schrijven. Ik vind dat 5x sneller werken dan puur HTML of inline CSS.

[BetuweKees]

Verwijderd schreef op 12 maart 2004 @ 14:54:
Aan de andere kant zijn beide elementen puur presentationeel en kun je ze dus eigenlijk beter droppen voor iets als SPAN, aangezien sommige zoekmachines toch nog waarde gaan hechten aan B en I, al is het minder dan aan EM en STRONG.

ik kom er zelf ook steeds maar niet uit, of ik nou em en strong zou moeten gebruiken ipv i en b. blijft het een lastig onderwerp vinden.

wat je zegt over het puur presentationeel zijn van deze elementen ben ik het echter niet mee eens. wanneer ik nl een <span class="bold"> zou gaan toevoegen snapt lynx er niks meer van en krijg je gewoon normale text te zien.
als je dan toch met toegankelijk ed bezig bent, ben ik van mening dat je beter een b of i tag zou kunnen gebruiken, zodanig dat deze tekst binnen deze tags toch nog op een of andere manier nadruk krijgt, ook in text browsers.

enne.. over dat keurmerk.. ik ben voor, waar mag ik tekenen?

[Verwijderd]

<span class="bold">

da's nu een mooi voorbeeld van verkeerd gebruik van classes, nu leg je nog steeds de opmaak in je content vast en is er geen verschil met gewoon <b> gebruiken.

om anne's voorbeelden erbij te pakken is <span class="latijnseDiernaam"> imho de beste aanpak om zoiets te stylen. Je geeft aan wat het element is en in de class maak je 'm italic. Lijkt mij niet nodig om hier <i> voor te gebruiken

[Blue-eagle]

Mozilla mag dan op water rijden, als je erin zit in deze WindowsXP wereld, zit je wel mooi op een houten bank.

De webstandaarden worden niet doorgevoerd omdat ze niet belangrijk zijn. Afgezien van wat dataverkeer en de status van de iets te ijverige HTMLer, is er niks verloren als je tabellen gebruikt voor je layout. Google past zich wel aan, ze moeten wel. Anders krijg je nooit de mooie resultaten.

Het is een mooi concept dat wel verder besproken gaat worden wanneer Microsoft zijn eigen standaard ontwikkeld, of het W3C adopteerd als standaarden-maker. Zodra CSS3 goed ondersteund wordt, en die vervelende bugs uit IE weg zijn, dan praten we verder over standaarden.

Maar nu? Mijn klant wilt gewoon producten verkopen. Hij, de bezoeker, en de zoekmachine geven er niks om of het W3 die site wel aan de hand van de doctype kan valideren. Als het maar geld oplevert.

Natuurlijk, als de klant een xHtml1.1 Strict site wilt hebben, die voldoet aan al die usability standaarden enzo, tsja. Waarom niet. Dat gaat hem wel meer geld kosten. Niet omdat ik het niet kan, maar omdat een tabel nog altijd makkelijker is dan met CSS lopen ouwehoeren om 5 kolommen naast elkaar te krijgen.

code:

<table id="main">
    <tr>
        <td id="col_1">1</td>
        <td id="col_2">2</td>
        <td id="col_3">3</td>
        <td id="col_4">4</td>
        <td id="col_5">5</td>
    </tr>
</table>

Als ik daar een stylesheet aan hang heb ik een layout die vele malen meer solide aanvoelt als elke willekeurige CSS truuk.

Nogmaals, ik ben een voorstander van standaarden. Maar als de browsers deze niet allemaal ondersteunen, zonder vage hacks te gebruiken, ga ik hier geen moeite in steken.

Kolen zat.

[BetuweKees]

Verwijderd schreef op 12 maart 2004 @ 15:43:
da's nu een mooi voorbeeld van verkeerd gebruik van classes, nu leg je nog steeds de opmaak in je content vast en is er geen verschil met gewoon <b> gebruiken.

daar ben ik het helemaal meet eens, maar dat is mijn punt niet

mijn punt is dat je door het gebruik van span tags er voor zorgt dat text-only browsers je tekst minder overzichtelijk weer zullen geven. ik zou dus eerder gaan voor <i class="latijnseDierennaam">

[xces]

Ook ik ben ainds een 2 maanden bezig met een nieuw CMS en dat word compleet XHTML 1.1 strict.

Een paar nuttige sites zijn voor mij geweest:
* CSS Zen Garden
(vooral dus als je deze site zonder stylesheet gaat bekijken wat o.a. in Firefox 0.8 kan dmv icoon links onderin je venster (het oogje))
* A list part
* Blue Robot
* Listamatic: one list, many options

* Webmasterworld.com

En zo zijn er nog een hele hoop andere..

Wat vooral belangrijk is is je doctype, want als dat al fout is gaat vooral internet explorer je hele document verkeert begrijpen...

[Verwijderd]

Mozilla mag dan op water rijden, als je erin zit in deze WindowsXP wereld, zit je wel mooi op een houten bank.

En waarom? *Gebruikt Mozilla 1.7b met XP

Afgezien van wat dataverkeer en de status van de iets te ijverige HTMLer, is er niks verloren als je tabellen gebruikt voor je layout.

Kreten maar geen argumenten...

Maar nu? Mijn klant wilt gewoon producten verkopen. Hij, de bezoeker, en de zoekmachine geven er niks om of het W3 die site wel aan de hand van de doctype kan valideren. Als het maar geld oplevert.

De zoekmachine geeft daar zeker wel om. Als je iets wil zeggen, onderbouw het dan alsjeblieft. Er zijn ook bezoekers te vinden die het fijn vinden als een site toegankelijk is en goed werkt in hun browser.

Natuurlijk, als de klant een xHtml1.1 Strict site wilt hebben, die voldoet aan al die usability standaarden enzo, tsja.

Wat heeft HTML met usability te maken? Je slaat aardig wat planken mis imo.

Waarom niet. Dat gaat hem wel meer geld kosten. Niet omdat ik het niet kan, maar omdat een tabel nog altijd makkelijker is dan met CSS lopen ouwehoeren om 5 kolommen naast elkaar te krijgen.

Weer onzin. Praat dan a.u.b. over browser ondersteuning en niet over wat CSS wel of niet kan.

Als ik daar een stylesheet aan hang heb ik een layout die vele malen meer solide aanvoelt als elke willekeurige CSS truuk.

Zie bovenstaande.

(Over dat "Drempelsweg" idee, maar dan algemener e.d., lijkt me erg leuk om daar met een paar mensen aan te werken oid of een soort projectje op te zetten. Probleem is alleen dat dat soort dingen bijna altijd verzanden omdat mensen het te druk hebben of halverwege afhaken. Als iemand zoiets wilt starten, mail [at] annevankesteren [dot] nl)

[JeromeB]

curry684 schreef op 12 maart 2004 @ 12:31:
Ik heb de afgelopen 2 dagen ook wat zitten janken over standaarden... ons bedrijf had een nieuwe website, en de voorpagina is een vrijwel lege Frameset die volgens z'n doctype XHTML 1.0 Frameset zou zijn. Valideert voor geen meter. 2e pagina had niet eens een doctype, en kreeg ik op geen enkele versie gevalideerd. Diepere pagina's, allemaal dezelfde stylesheet inlined ( ), beweerden HTML 4.01 Transitional te zijn, en valideerden ook allemaal op geen enkele versie

Ik vind dat ronduit beschamend als IT-bedrijf en ga dat zo snel mogelijk fixen. Echter, zit ik daar toevallig net met een collega over te praten hier bij Nedcar, en checken we voor de lol eens www.nedcar.nl en zijn bedrijf (www.centric.nl). Nedcar had geen doctype maar haalde nog wel HTML 4.01 Transitional, dat viel dus nog mee in de schade. Echter bij Centric was het ronduit feest: doctype noch charset gespecificeerd.... en indien beiden hard overruled kwam er dit uit:

code:

   2: <html>
   3: 
   4: Deze browser is niet geschikt voor het bekijken van Web4all. 
   5: 
   6: </html>

Hopeloos beschamend toch

Ik vind niet dat alles ter wereld gestandaardiseerd moet zijn, maar de wereldwijd zo enorm veel gebruikte internetprotocollen mag toch hopelijk wel aan een wereldwijd afgesproken conventie voldoen

Ik ben nog niet volledig overtuigd van het hele doctype verhaal. Waarom zou een website per sé een doctype moeten hebben als browsers ook een soort van 'standaard interpretatie' (quirksmode) hebben.

Een tijdje terug probeerde ik mijn sites allemaal XHTML 1.1 valid (en symantisch correct) te krijgen met het juiste mime-type etc etc. Heel leuk allemaal, maar is dat wel belangrijk voor bijvoorbeeld een bedrijf?

Ik denk dat een bedrijf zich veel beter kan richten op accesibility en usability. XHTML 1.1 is daar bijvoorbeeld een slecht voorbeeld van vind ikzelf.

Ik zet er mijn vraagtekens bij.

[ Voor 6% gewijzigd door JeromeB op 12-03-2004 16:10 ]

[Blauw]

Ik vind het opzich wel leuk om aan met die webstandaarden proberen te werken. Ik merk zelf dat ik me in toenemende mate ga ergeren aan mensen die zichzelf roemen als 'webdesigners' maar nog steeds wel met tabellen de layout maken en volkomen lomp met bijvoorbeeld stylesheets omgaan.

Mijn toevoeging voor het topic is echter dat ik vind dat die validator voor w3c niet altijd even duidelijk is waarom iets mag en waarom iets niet mag. Misschien denken anderen daar anders over, maar voor mij is het soms gewoon niet helemaal duidelijk wat er met een bepaald regeltje mis is. Dan denk ik wel eens: waren er maar betere handvaten om uit te leggen waarom bepaalde dingen niet kunnen; dan zou het al een stuk makkelijker zijn.

[JeromeB]

Jozzz schreef op 12 maart 2004 @ 16:10:
Mijn toevoeging voor het topic is echter dat ik vind dat die validator voor w3c niet altijd even duidelijk is waarom iets mag en waarom iets niet mag. Misschien denken anderen daar anders over, maar voor mij is het soms gewoon niet helemaal duidelijk wat er met een bepaald regeltje mis is. Dan denk ik wel eens: waren er maar betere handvaten om uit te leggen waarom bepaalde dingen niet kunnen; dan zou het al een stuk makkelijker zijn.

Daar ben ik het wel mee eens en ik las laatst dus ook iets leuks:
- http://annevankesteren.nl...03/validation-is-nice-but
- http://www.virtuelvis.com/archives/162.html

[Verwijderd]

Ik ben nog niet volledig overtuigd van het hele doctype verhaal. Waarom zou een website per sé een doctype moeten hebben als browsers ook een soort van 'standaard interpretatie' (quirksmode) hebben.

Omdat je dan (1) tegen PPK ingaat (non-argument) en (2) browsers je pagina zullen renderen op de manier waarop je het kunt verwachten uit de standaarden (merk op dat je bij IE nergens vanuit kunt gaan en dat het bij deze niet zoveel uitmaakt, maar dat je Opera, Safari, Mozilla wel in compliant mode wilt hebben, zie ook: http://annevankesteren.nl/archives/2004/02/box-model

Een tijdje terug probeerde ik mijn sites allemaal XHTML 1.1 valid (en symantisch correct) te krijgen met het juiste mime-type etc etc. Heel leuk allemaal, maar is dat wel belangrijk voor bijvoorbeeld een bedrijf?

Absoluut niet. Ten eerste is XHTML 1.1 alleen leuk voor mensen die bezig zijn met de modularisatie van XHTML (het is daarop gebaseerd). Ook is het gebruik van content-types "verplicht" (SHOULD, niet MUST), maar je kunt niet naar IE 'application/xhtml+xml' gaan sturen.

Ik denk dat een bedrijf zich veel beter kan richten op accesibility en usability. XHTML 1.1 is daar bijvoorbeeld een slecht voorbeeld van vind ikzelf.

Eens. XHTML1.0 Strict of HTML4.01 Strict voldoen prima.

[disjfa]

De validator laat data door die al eeuwen veroudert is kwa usability en gebruik van nette (x)html. Aan de ene kant kan je daar aan werken mbv de validator, alleen je weet dat als er hier iemand aankomt die een site heeft gemaakt mbv de validator hij mischien een perfecte site heeft maar de source eruit ziet als oude geocitys prut.

De validator kan leuk zijn, maar hij zal er niet toe doen om mensen echt goed te laten scripten. Daar is veel veel meer voor nodig.

Ik vind niet dat de validator HET keurmerk voor nette code kan zijn.

[chris]

Verwijderd schreef op 12 maart 2004 @ 16:05:
[...]
Weer onzin. Praat dan a.u.b. over browser ondersteuning en niet over wat CSS wel of niet kan.

Het is voor hem makkelijk om 5 kolommen met tables naast elkaar te krijgen, wat opzich helemaal geen onzin hoeft te zijn. En voor sommige dingen zijn tables gewoon een stuk makkelijker, maar dit gaat dan ten koste van de structuur in je site. En voor veel mensen boeit de structuur (nog) niet zo.

Don't get me wrong: ik ben voor een css-oplossing en tegen een tables-oplossing in het algemeen, maar ik kan me voorstellen dat het soms makkelijker is (of lijkt te zijn).

(Over dat "Drempelsweg" idee, maar dan algemener e.d., lijkt me erg leuk om daar met een paar mensen aan te werken oid of een soort projectje op te zetten. Probleem is alleen dat dat soort dingen bijna altijd verzanden omdat mensen het te druk hebben of halverwege afhaken. Als iemand zoiets wilt starten, mail [at] annevankesteren [dot] nl)

Altijd leuk, maar dat lukt je niet op vrijwilligers-basis. Je zou moeten kijken of je ergens bij de overheid een potje geld kan vinden

[We Are Borg]

Verwijderd schreef op 12 maart 2004 @ 16:15:
Eens. XHTML1.0 Strict of HTML4.01 Strict voldoen prima.

Vergis ik mij dan wanneer ik zeg dat de about="_blank" (of target ) niet meer is toegestaan? Uiteraard kan je de validator omzeilen door JS te gebruiken, maar het idee is er achter dat je de user zelf laat bepalen of een pagina in een nieuw venster wordt geopend.

Wat vind jij en andere GoT'ers hiervan? Is de W3C standaard alles bepalend en ben je het ook altijd eens met de gedachtegang? Vind dit namelijk een typisch voorbeeld van "ja, snap de beredenering vanuit W3C, maar ben het er niet helemaal mee eens"

[ Voor 14% gewijzigd door We Are Borg op 12-03-2004 16:38 . Reden: iets met ", mieren en neuken ]

[RSpliet]

We Are Borg schreef op 12 maart 2004 @ 16:27:
[...]


Vergis ik mij dan wanneer ik zeg dat de about=_blank niet meer is toegestaan? Uiteraard kan je de validator omzeilen door JS te gebruiken, maar het idee is er achter dat je de user zelf laat bepalen of een pagina in een nieuw venster wordt geopend.

Dan zou ik op z'n minst target="_blank" gebruiken . En deze is volledig valid volgens de standaarden van het W3C, net als <base target="_blank">, Zie ook deze pagina

[ Voor 33% gewijzigd door RSpliet op 12-03-2004 16:37 . Reden: Verkeerde mier fellow-borg ;) ]

[We Are Borg]

S3v3n_0f_n1n3 schreef op 12 maart 2004 @ 16:31:
[...]


Dan zou ik op z'n minst target="_blank" gebruiken . En deze is volledig valid volgens de standaarden van het W3C, net als <base target="_blank">, Zie ook deze pagina

Daar kan je gelijk hebben, geen idee . Dacht altijd dat dit nooit was toegestaan volgens de richtlijnen van W3C.

* We Are Borg gaat gewoon weer verder lezen en houdt zijn klep dicht

[disjfa]

offtopic:
Dat is in strict modus We are borg, in transitional mag het wel.

[Verwijderd]

Hij is deprecated, wat inhoud dat hij wel in TRANSITIONAL staat, maar niet in de STRICT DTD en waarschijnlijk ook niet zal terugkeren. M.i. ook een totaal overbodig attribuut wat niks toevoegt aan de inhoud van het document (behalve irritatie).
Als je het niet eens ben met het W3C kun je gewoon naar een van de mailing lists een e-mail sturen. Heel simpel (CSS3 heeft trouwens opties om bovenstaande op te lossen, css3-hyperlinks).

[Mx. Alba]

Mijn filosofie mbt webstandaarden is heel simpel: Ik probeer me zoveel mogelijk aan de standaarden te houden.

Alleen al het nut van validatoren om domme foutjes uit de code te halen is ongelofelijk! Vandaag nog had ik in een stukje CSS "heignt" staan. Het hoeft aan de rendering niet eens op te vallen dat er iets fout is, en in een oogopslag zie je het zo over het hoofd, maar een validator ziet het meteen.

Ik heb trouwens in mijn code wel bewust een paar dingen zitten die niet valideren, zoals een HTML comment voor de doctype definitie om IE6 in quirks mode te schoppen - jammer, maar helaas, dan maar niet valideren, maar de layout van mijn site gaat voor: het is veel makkelijker om een layout er (bijna) het zelfde (of in ieder geval correct) uit te laten zien in twee verschillende boxmodels dan in drie...

Kortom: ik vind standaarden zeer nuttig om platformonafhankelijkheid enzo te garanderen, maar ik schroom niet om een stukje niet-validerende code te gebruiken als dat een goed doel dient...

[Verwijderd]

Ik vraag me af hoe het komt dat je daardoor niet valideert. Gaat prima

[JeromeB]

Hoe denken jullie trouwens over Accesibility en Usability? Het zijn 2 zeer hoge prioriteiten, maar in bepaalde gevallen gaan deze niet goed samen.

Wat heeft jullie voorkeur? of ligt dat per ding verschillend?

http://www.digital-web.co...ility_and_usability.shtml

[Verwijderd]

Verwijderd schreef op 12 maart 2004 @ 16:15:

Je gaat dan wel hard in tegen het verhaal van Blue-eagle, maar overall geeft hij wel precies aan wat er aan de hand is met het standaarden verhaal. Ik voel wel wat voor zijn verhaal hoor

Als ik mijn rss lezer, FeedDemon, open en eens browse door de dagelijkse threads dan valt me vooral op dat de postings die dmv tables zijn opgezet er altijd perfect uitzien in mijn preview pane. Dit kan ik niet zeggen van de layouts die zijn opgezet dmv CSS. Diverse blocks in de pagina's schuiven over elkaar heen, zodra tekst niet meer op een regel past (bijvoorbeeld titles) springt het over op 2 regels waarbij de 2de regel door een overflow property half verdwijnt, etc, etc.

Dit ligt hem dan niet aan CSS in het algemeen, maar wel over de wijze waarop ze wordt toegepast. CSS is heel erg gevoelig voor foutjes. Verkijk je je op een overflow property of een positionering dan zie je sneller als met html, dat een layout compleet verkloot wordt.

Ik ben nu uit purisme en om snelheidswinsten te bepalen al een hele tijd bezig met het ontwikkelen van een cms backend, maar je komt toch behoorlijk wat zaken tegen die niet instant werken. Daarvoor zijn gewoon heel veel workarounds nodig. Extra nestings, extra properties, andere semantische opbouw (zodat de boel zonder stylesheet alsnog onbegrijpelijk is).

De hoeveelheid code is absoluut een verbetering, de code die ik nu heb staan is zeker 75% minder, maar daarvoor investeer je bakken meer qua tijd dan als je het met tables had gedaan.

[Verwijderd]

JeromeB schreef op 12 maart 2004 @ 17:23:
Hoe denken jullie trouwens over Accesibility en Usability? Het zijn 2 zeer hoge prioriteiten, maar in bepaalde gevallen gaan deze niet goed samen.

Wat heeft jullie voorkeur? of ligt dat per ding verschillend?

http://www.digital-web.co...ility_and_usability.shtml

Accesibility is een verhaal dat nog steeds niet lekker van de grond komt. De eerste stapjes zijn er, aanpassen van font sizes door een bezoeker, kiezen van een andere stylesheet maar te vaak wil een klant niet in de buidel tasten om al deze extra snufjes door te voeren in zijn website.

Accesibility is overigens niet gerelateerd aan css. Ook zonder css is er accesibility.

Wat ik persoonlijk een grote misser vind, is dat een client niet kan definieren wat zijn handicap is. Bijvoorbeeld in de browser. Wat heeft een blinde bezoeker nu aan een grafische layout, wat is dan het nut van het inladen van een stylesheet met presentatie logic erin. Je zou iets moeten hebben wat via een meta tag definieert wat zijn/haar handicap is

<meta name="handicap" content="visual" level="1">

Nu zou ik als developer weten dat mijn client visueel gehandicapped is. Met een level kun je evt. aangeven of de persoon echt niets ziet en gewoon plaintext moet hebben, of dat een persoon behoefte heeft aan meer contrast, grotere lettertypes, etc.

Usability is een vak apart. Toch zijn er zaken die toch wel direct op deze richting aansluiten zoals font grootte, alt text, tabindex, duidelijke buttons, etc.

Wat mensen echter vaak vergeten is dat usability 90% van je content inhoudt. Duidelijke teksten, wat kan ik doen, hoe moet ik iets doen, waar kan ik dat doen, wat gebeurt er als ik hier klik, waar kan ik afrekenen, waar kan ik details bekijken, of iets simpels als waar vind ik de contactgegevens.

Een goede usability begint bij een goede definiering van het doel van je website. Weet je niet wat je wilt bereiken met je website, hoe weet je dan wat je in je content moet zetten? .. niet dus. dan flodder je wat aan, en schiet je website zijn doel voorbij.

Layout is ook een belangrijke kant, waar zet ik de navigatie, hoe loods ik de bezoeker visueel naar de juiste informatie. Zijn die submit buttons in het roze nu wel opvallend genoeg? .. het kan je zomaar een contactmoment schelen met een potentiele klant.

[chris]

Verwijderd schreef op 12 maart 2004 @ 18:06:
[...]
Wat ik persoonlijk een grote misser vind, is dat een client niet kan definieren wat zijn handicap is. Bijvoorbeeld in de browser. Wat heeft een blinde bezoeker nu aan een grafische layout, wat is dan het nut van het inladen van een stylesheet met presentatie logic erin. Je zou iets moeten hebben wat via een meta tag definieert wat zijn/haar handicap is

<meta name="handicap" content="visual" level="1">

Nu zou ik als developer weten dat mijn client visueel gehandicapped is. Met een level kun je evt. aangeven of de persoon echt niets ziet en gewoon plaintext moet hebben, of dat een persoon behoefte heeft aan meer contrast, grotere lettertypes, etc.

[...]

http://www.w3.org/TR/REC-CSS2/media.html

[Verwijderd]

chris schreef op 12 maart 2004 @ 18:52:
[...]

http://www.w3.org/TR/REC-CSS2/media.html

Ja maar hoe specificeer je dan in hoeverre je handicapped bent? Ik vind de mediatypes die er zijn niet echt uitblinken in mogelijkheden.

[Verwijderd]

Ik denk dat een META element een _bezoeker_ al helemaal niet gaat helpen. Media types zijn bij uitstek geschikt voor dit soort dingen. Naarmate browsers meer media types gaan ondersteunen (meeste ondersteunen, print en screen; Opera ook nog projecten, handheld en wellicht meer) en sites deze gaan gebruiken kan de bezoeker instellen wat voor opmaak hij wilt zien.

Iemand die dus moeite heeft met lezen oid kan "reader" (CSS3 WD) gebruiken. Ook door de mogelijkheid van het kiezen van alternatieve style sheets sla je een brug met dit soort gebruikers.

[oh,when?]

Om te voorkomen dat deze discussie in een wellus/nietus spelletje verzandt ff een nieuwe richting inblazen. Ik merk dat een hoop mensen hier erg fervent aanhanger zijn van de eerder genoemde standaarden, en waar het even kan hard CSS roepen en verwijzen naar de W3C documentatie. Om ff een wat concreter voorbeeld te pakken, een uit de praktijk ipv home-grown websites:

Wehkamp.nl is een van onze grote accounts. Deze webshop is oa uitgeroepen tot de beste webwinkel van de Nationale Thuiswinkel Awards (2003) , en volgens Forrester Research neemt Wehkamp de 11e plaats in op de Europese online retail top-50 van 2003. Met een omzet van 100 miljoen in 2003 zeer succesvol te noemen.

De HTML van Wehkamp.nl is samen te vatten als "tagsoup" en dat heeft verschillende redenen die hier niet echt relevant zijn. Wat mij wel leuk lijkt, om van de CSS / webstandards adepten hier, eens wat feedback / concrete punten op te noemen, die aangeven wat de voordelen zouden zijn als wij Wehkamp.nl helemaal om zouden zetten naar een HTML4.01 Transitional of zelfs Strict variant icm CSS die als het mogelijk is zelfs valideert.

Als er daadwerkelijk goede argumenten naar voren komen ( misschien van de TS zelf? ) dan zal ik deze meenemen en bij ons intern eens aankaarten...en wie weet?

Suprise me!

[chris]

oh,when? schreef op 12 maart 2004 @ 19:00:
Om te voorkomen dat deze discussie in een wellus/nietus spelletje verzandt ff een nieuwe richting inblazen. Ik merk dat een hoop mensen hier erg fervent aanhanger zijn van de eerder genoemde standaarden, en waar het even kan hard CSS roepen en verwijzen naar de W3C documentatie. Om ff een wat concreter voorbeeld te pakken, een uit de praktijk ipv home-grown websites:

Wehkamp.nl is een van onze grote accounts. Deze webshop is oa uitgeroepen tot de beste webwinkel van de Nationale Thuiswinkel Awards (2003) , en volgens Forrester Research neemt Wehkamp de 11e plaats in op de Europese online retail top-50 van 2003. Met een omzet van 100 miljoen in 2003 zeer succesvol te noemen.

De HTML van Wehkamp.nl is samen te vatten als "tagsoup" en dat heeft verschillende redenen die hier niet echt relevant zijn. Wat mij wel leuk lijkt, om van de CSS / webstandards adepten hier, eens wat feedback / concrete punten op te noemen, die aangeven wat de voordelen zouden zijn als wij Wehkamp.nl helemaal om zouden zetten naar een HTML4.01 Transitional of zelfs Strict variant icm CSS die als het mogelijk is zelfs valideert.

Als er daadwerkelijk goede argumenten naar voren komen ( misschien van de TS zelf? ) dan zal ik deze meenemen en bij ons intern eens aankaarten...en wie weet?

Suprise me!

In principe kan zo goed als iedere bestaande website worden omgezet naar validerende xhtml & css, heb er nog geen gezien waarbij het niet lukte. Natuurlijk is het wel makkelijk om hier advies te vragen (waar je normaalgesproken veel euro's voor neerlegt).

Het idee an sich is wel oké, maar zullen we het dan met een niet-commerciele site doen? /. bijvoorbeeld, helaas is het al wel een keer eerder gedaan door alistapart. Iemand suggesties?

[disjfa]

oh,when? schreef op 12 maart 2004 @ 19:00:
Als er daadwerkelijk goede argumenten naar voren komen ( misschien van de TS zelf? ) dan zal ik deze meenemen en bij ons intern eens aankaarten...en wie weet?

Hiermee krijg je alleen maar meer een welles nietes spelletje. We kunnen nu met zn allen whekamp ombouwen tot een strict/transitional (x)html 1.0/1.1 pagina maar wie word er beter door. Wat er beter kan kan je hier in het algemeen wel lezen. Je kan het bovenste gedeelte snel omzetten naar een net gedeeltje, het menu met een lijst netjes vullen, etc etc. Alles kan. Het gaat er maar net om of whekamp dit wilt.

Het enige jammere aan de site zoals het nu is is dat je hem niet in een keer om kan zetten naar een nieuw design of even snel wat anders neerzetten omdat het zoals jij zegt een "tagsoep" is. Dat is helemaal niet erg omdat een site van die grootte toch overal hetzelfde opgebouwd is en niet zo snel wat aan zal veranderen.

Ik zou zelf nog niet eens al te gek opkijken als de site nu door een validator heen komt omdat hij vrij net is opgebouwd. Maar dan kom je weer terug op mijn stelling een paar post hierboven.

Er kan zat aan gedaan worden het geheel netjes (x)html op te zetten maar zoals het nu staat zal het zeker ook nog een tijd goed werken. De discussie gaat hier geloof ik meer over dat er zoveel bedrijven zijn die juist de geheel simpele oplossing pakken en het heel ranzig opbouwen. En daar ben ik ook tegen.

[Johnny]

oh,when? schreef op 12 maart 2004 @ 19:00:
[wehkamp bla]

Als er daadwerkelijk goede argumenten naar voren komen ( misschien van de TS zelf? ) dan zal ik deze meenemen en bij ons intern eens aankaarten...en wie weet?

Suprise me!

De code is inderdaad nogal yukkie.

Wat me opvalt is dat de hele website, vergeleken met anderen, zelfs die op buitenalndse servers gewoon traag is, niet alleen het downloaden, maar ook het renderen zie ik hier echt gebeuren, terwijl iedere andere pagina bij mij meestal meteen is geladen.

Het gebruik maken van netter HTML/CSS/JavaScript zou er voor zorgen dat zowel het downloaden als het renderen sneller gaat, en het scheelt jullie ook nog eens bandbreedte en de website wordt beter toegankelijk voor mobiele apparaten/gehandicapten (grotere doelgroep, vooral als je ziet dat er steeds meer draadloze internetverbindingen komen), en dan is het ook nog eens makkelijker te onderhouden omdat je presentatie en inhoud hebt gescheiden.

[Verwijderd]

disjfa schreef op 12 maart 2004 @ 19:14:
[...]
Het enige jammere aan de site zoals het nu is is dat je hem niet in een keer om kan zetten naar een nieuw design of even snel wat anders neerzetten omdat het zoals jij zegt een "tagsoep" is. Dat is helemaal niet erg omdat een site van die grootte toch overal hetzelfde opgebouwd is en niet zo snel wat aan zal veranderen.

Waar komen toch die verhalen vandaan dat je met een andere stylesheet je site compleet kunt redesignen, dat is pure larie.

Hoe wil je om nested elements heen dan? ..

Zengarden alla, maar je hebt stukken complexere layouts dan Zengarden.

[ Voor 7% gewijzigd door Verwijderd op 12-03-2004 19:23 ]

[disjfa]

Verwijderd schreef op 12 maart 2004 @ 19:19:
[...]
Waar komen toch die verhalen vandaan dat je met een andere stylesheet je site compleet kunt redesignen, dat is pure larie.

Hoe wil je om nested elements heen dan? ..

? Dat ligt er toch juist aan hoe je een site opbouwd. En zelfs om nested elements kan je heen, als je maar wilt. Ik voel alleen wel even een uitdaging aankomen.

edit:
jammer, kan hem niet te veel beinvloeden....

[ Voor 7% gewijzigd door disjfa op 12-03-2004 19:27 ]

[Verwijderd]

disjfa schreef op 12 maart 2004 @ 19:21:
als je maar wilt. Ik voel alleen wel even een uitdaging aankomen.

En daar gaan we al... als... als.. als.. prima voor je vrije tijd, echt top om standaarden in je vrije tijd toe te passen, doe ik ook. Maar dan neem ik er ook de tijd voor.

In het web development wereldje bestaat keiharde concurrentie, met keiharde marges. Als het management geld wil verdienen, gaan ze niet de filantropische standaard geile organisatie uithangen die met alle liefde extra tijd en geld gaat uitgeven aan opbouw van source code.

Wil de klant standards, dan krijgt de klant standards. Maar niet gratis.

[Blauw]

disjfa schreef op 12 maart 2004 @ 19:14:
[knip] .

Volgens mij gaat het oh-When meer om goede redenen waarom je als bedrijf zou kiezen voor de standaarden, niet om het feit of het kan of niet.

[disjfa]

Verwijderd schreef op 12 maart 2004 @ 19:27:
[...]
Wil de klant standards, dan krijgt de klant standards. Maar niet gratis.

Dat is een heel andere discussie. Die is in het topic waarvan deze is ontschoten. Tuurlijk is niets gratis, duh. Maar dan is het de vraag waarom kunnen we niet deze standaarden zo doorvoeren zodat iedereen ze wel kent. Als je opgegroeid bent met ranzige table constructies en dat altijd perfect voor je werkt, waarom zou je dan zomaar overgaan en html helemaal opnieuw leren. Het punt meer is waarom zou je dat niet doen sinds als je het goed kan je sneller iets zou kunnen opzetten en of verbouwen dan vroeger. Waarom zijn er standaarden die dan maar niet gebruikt worden door mensen die zichzelf profesioneel noemen.

Simpele stelling, waarom windows 2k als 95 hetzelfde schermpje kan laten zien. En hier niet op in gaan met de redenen want die zijn er zat maar die zijn er ook voor de stelling van dit topic.

@Jozzz, als ik hier zo de topics lees komen er elke keer dezelfde redenen naar boven. Dan is het de vraag ze te gebruiken sinds iig hier iedereen er zo ongeveen zo over denkt.

@Gordijnstok en zo kom je weer bij de topic start.

[ Voor 12% gewijzigd door disjfa op 12-03-2004 19:40 ]

[faabman]

oh,when? schreef op 12 maart 2004 @ 19:00:
Als er daadwerkelijk goede argumenten naar voren komen ( misschien van de TS zelf? ) dan zal ik deze meenemen en bij ons intern eens aankaarten...en wie weet?

Suprise me!

Gewoon in geld praten lijkt me... Wanneer jullie wehkamp omzetten van html met veel onnodige tags naar xhtml met geen of veel minder onnodige tags en een volledig externe stylesheet dan is er per pagina minder data te versturen en dat heeft in ieder geval 2 gevolgen:
- Wehkamp heeft minder dataverkeer;
- De site is sneller.

Waar kan ik de factuur heen sturen

[Verwijderd]

disjfa schreef op 12 maart 2004 @ 19:31:
Waarom zijn er standaarden die dan maar niet gebruikt worden door mensen die zichzelf profesioneel noemen.

Dat zet je wel aan het denken, zijn al die professionals nu zo dom? Of... zou er toch een andere reden zijn.

[Verwijderd]

FvKnijff schreef op 12 maart 2004 @ 19:35:
Gewoon in geld praten lijkt me... Wanneer jullie wehkamp omzetten van html met veel onnodige tags naar xhtml met geen of veel minder onnodige tags en een volledig externe stylesheet dan is er per pagina minder data te versturen en dat heeft in ieder geval 2 gevolgen:
- Wehkamp heeft minder dataverkeer;
- De site is sneller.

Waar kan ik de factuur heen sturen

Ik zou zeggen begin dan maar met het omzetten, geen woorden maar daden.

Hou dan vooral even bij hoeveel tijd je kwijt bent. Als je het namelijk goed wilt doen moet er ook een symantische opmaak inzitten, moet met een enkele stylesheet je hele website ineens er totaal anders uitzien, draait het geheel crossbrowser en dit alles binnen een vaste deadline onder extreme druk.

[ Voor 23% gewijzigd door Verwijderd op 12-03-2004 19:49 ]

[faabman]

Verwijderd schreef op 12 maart 2004 @ 19:42:
[...]


Ik zou zeggen begin dan maar met het omzetten, geen woorden maar daden.

Was niet van plan om te gaan omzetten hoor Consulting is nog steeds een van de best betaalde beroepen .

Maar, ff zonder gekheid, o when vroeg om argumenten die hij kan gebruiken om zijn collega's / klant over te halen en die probeer ik te geven...

Verwijderd schreef op 12 maart 2004 @ 19:42:
Hou dan vooral even bij hoeveel tijd je kwijt bent. Als je het namelijk goed wilt doen moet er ook een symantische opmaak inzitten, moet met een enkele stylesheet je hele website ineens er totaal anders uitzien, draait het geheel crossbrowser en dit alles binnen een vaste deadline onder extreme druk.

tijd = geld en daarom waren mijn argumenten dan ook op financiele maatstaven gebaseerd... Ik heb het bewust niet over semantiek gehad, daar zal de klant waarschijnlijk toch niet veel in zien...

[ Voor 42% gewijzigd door faabman op 12-03-2004 19:51 ]

[Bluestorm]

Ik ben het met gordijnstok eens dat iedere gecompliceerdere site absoluut niet zomaar met een nieuwe stylesheet opnieuw kan worden vormgegeven. Denk alleen al aan iets simpels als het omdraaien van twee elementen. Zodra het niet over een stuk tekst gaat is dit eigenlijk alleen een vormgeving kwestie, maar niet meer mooi met een stylesheet te regelen.

Dit 'probleem' vloeit volgens mij direct uit dat HTML nog altijd vooral een standaard is voor hypertext documenten. Daar zijn dan ook veel semantische tags voor beschikbaar. En teksten met links er in kun je mooi opnieuw vormgeven met alleen een andere stylesheet.

Maar een webpagina is meer dan een stuk hypertext. De interface rondom de tekst heeft een heel ander doel. Het groeperen van elementen heeft soms nu eenmaal gewoon alleen een visuele (wellicht voor de usability) betekenis. Je bent genoodzaakt om ook hier html voor te gebruiken waardoor de vormgeving toch eigenlijk ook in de HTML komt te liggen. Je zou je zelfs af kunnen vragen of de paginagebaseerde werking wel aansluit bij de beleving van mensen. Zou het niet beter zijn om een bepaald deel interface te kunnen definieeren wat niet herladen hoeft te worden. Natuurlijk moet je dan wel zorgen dat de URL nog steeds naar een bepaald stuk content wijst, anders loop je tegen de problemen aan van het gebruik van Flash / Frames / etc. aan.

Bovendien zou ik willen stellen dat een deel van de accesibility te wijten is aan het niet (goed) gescheiden zijn van de navigatie naar de content toe en de daadwerkelijke content onderdelen. Met verschillende beperkingen van de gebruiker is nu eenmaal een andere manier van navigeren nodig, terwijl de content zelf eigenlijk op een triviale manier aan te passen zou moeten zijn. tekst blijft immers altijd tekst.
Al zou ik wel blij zijn als in xhtml 2.0 het gebruik van section en h mogelijk wordt want dan ben je af van die vreselijk niet semantische h1,h2,h3.
Want als je je tekstje die begint met h1 in een grotere tekst plaats mag je opeens al je nummertjes gaan veranderen.

Ik zou dus willen stellen dat de huidige standaarden eigenlijk onvoldoende zijn afgestemd op de toepassing waar ze voor gebruikt worden. Natuurlijk is het al wel een stuk beter dan opmaken met tabellen. Maar daar staat tegenover dat voor het vormgeven met tabellen al tijden bekend is hoe dat werkt, hoe je precies krijgt wat je wilt. Terwijl het met de nieuwere standaarden toch ook voor een groot deel experimenteren is. Het houden aan de standaard garandeerd niet dat je krijgt wat je wilt.

Dus hoewel CSS en HTML4 al weer een aantal jaren bestaan zou ik willen stellen dat de standaarden eigenlijk nog zo erg in ontwikkeling zijn dat het niet gek is dat bedrijven moeite hebben dit bij te houden. Tot nog niet zo lang geleden kon in verband met browser compatibiliteit nog een hoop niet gebruikt worden, nu dit niet meer zo vreselijk erg speelt (op in vergelijking toch een stuk kleinere problemen met het ondersteunen van standaarden) zal allicht snel meer ervaring worden opgedaan met de standaarden.

[ Voor 13% gewijzigd door Bluestorm op 12-03-2004 20:01 ]

[djluc]

Als je absoluut gaat positioneren dan kun je eventueel wel met een stylesheet in 1x je hele site verbouwen. Maar dat heeft ook weer een hoop nadelen, en is voor de meeste site totaal niet praktisch.

[Bluestorm]

Ja, absoluut positioneren, scrollende overflows op alle elementen (want anders gaan ze overlappen) dan moet het kunnen. Dan heb je een mooi rechthoekig vlak wat je site is. Vormgevers zouden daar wel blij van worden misschien, als er dan ook meteen een standaard maat is voor dat rechthoekige vlak

[Verwijderd]

Dat vind ik nou een goed idee van oh,when?
Ipv alleen maar met engelse termen te komen die ook in het nederlands geschreven hadden kunnen worden een echt concreet voorbeeld

Ziet er mooi uit op het eerste gezicht . Wel veen beetje druk, maar toch...
Maar als ik view-source doe . Het ziet er niet uit, echte spaghetti-code.

Dat moet wel slecht zijn voor de ranking bij google, en inderdaad..., zoeken op wehkamp en hij staat er niet eens bij

[Verwijderd]

Verwijderd schreef op 12 maart 2004 @ 16:05:
[...]
En waarom? *Gebruikt Mozilla 1.7b met XP

Nou, bij mij thuis en op mijn werk start IE nog altijd stukken sneller op dan IE. Daarbij, ik kom ook vaker sites tegen die in Mozilla er "minder" (wel acceptabel vaak) uit zien dan in IE. Duidelijke redenen natuurlijk, maar voor een kolen apparaat is IE zeker niet slecht

[...]
Kreten maar geen argumenten...

Okay, argument 1: tabellen zijn statischer. Als voorbeeld kun je de website van het W3 nemen. Versmal je venster maar eens overdreven en alle kolommen vallen onderelkaar als rijen. Met tabellen heb je dit niet. Misschien is dit een kwestie van voorkeur...

[...]
De zoekmachine geeft daar zeker wel om. Als je iets wil zeggen, onderbouw het dan alsjeblieft. Er zijn ook bezoekers te vinden die het fijn vinden als een site toegankelijk is en goed werkt in hun browser.

Vanaf 1998 ben ik al bezig met professionele websites. Al deze sites zijn goed in de zoekmachines opgenomen. Ook de vervolg pagina's. Een product wordt gedisplayed met zijn naam, en niet met informatie die niet relevant is. Ik zie dus geen enkele reden om te denken dat zoekmachines wel om een betere structuur geven. Tenzij je bedoelt dat het belangrijk is dat de Google bot mijn pagina's sneller kan indexeren...? In plaats van .0002 seconden misschien .00000001 seconden?

[...]
Wat heeft HTML met usability te maken? Je slaat aardig wat planken mis imo.

Ik bedoel eigenlijk die andere "keurmerken" die je hebt, zoals van www.contentquality.com etc. Sorry voor mijn verkeerde zinsopbouw.

[...]
Weer onzin. Praat dan a.u.b. over browser ondersteuning en niet over wat CSS wel of niet kan.

Browser ondersteuning... ok. Laat ik het anders formuleren. Dit gaat je waarschijnlijk niet aan staan
CSS kan wat de browser kan, niet andersom. CSS3 bestaat voor mij niet. Ik zie concept cars ook niet als realistisch bruikbare auto's. CSS2 is naar mijn mening veel te gelimiteerd (CSS2 = CSS2 in IE5.x tot IE6.) in vergelijking met CSS3. Dat bedoel ik dus met het voordeel van een tabel (zie mijn stukje code.) Natuurlijk kan het met behulp van wat DIVjes, een beetje CSS, misschien een CSS/IE hack hier en daar. Maar het kan ook met tabellen. De bedoeling van een tabel ligt wel heel ergens anders, maar het is makkelijk en betrouwbaar. Oh, en ik ben lui, en mijn baas wilt geld zien

Ik zeg dus niet dat CSS2 te gelimiteerd is, ik zeg dat Microsoft IE5.x en IE6 CSS2 niet goed genoeg ondersteunen. En aangezien Microsoft de martkleider is in browserland, kan de CSS2 specificatie zijn wat het wilt, de standaard wordt bepaald door Microsoft. CSS2 = CSS2 in MS IE.

En dan een verhaal apart.. hacks. Iedereen probeert hacks te gebruiken voor zijn/haar site. Je weet wel, die dingen die op ALA regelmatig voorbij komen. Vervuilt men hiermee het web ook niet? Als Microsoft straks wel die bugs fixt, zit je met overbodige code/css trucjes. Hell, sommigen daarvan zullen niet eens meer werken. Dit is eigenlijk nog zo'n reden waarom ik (nog) voor het gebruik ben van de "klassieke" methode. Maargoed, dit is misschien off-topic


Anyway.. je moet goed begrijpen dat ik me erg verdiep in deze "nieuwe" dingetjes. Ik vind het heel erg interessant om te lezen, doen, experimentjes uit te voeren, etc. Maar voor mij is het niet realistisch om complexere websites op te zetten via het box model ontwerp. Ik loop te vaak tegen beperkingen aan die veel te veel tijd gaan kosten op "de goede manier", terwijl een simpele tabel vaak binnen 5 minuten de oplossing biedt.

Ik kijk dan ook uit naar de volledige implementatie van CSS2 (of CSS3 hopelijk) in Internet Explorer. Al denk ik dat dit nog wel enkele jaren kan gaan duren. Het gaat me niet verbazen als Microsoft pas een nieuwe IE versie uitbrengt met de komst van zijn nieuwe Operating System. Ja, leuk is anders

Wat ik daarom op het moment doe.. ik mix de boel. Tabellen gebruik ik indien nodig in plaats van CSS om tijd te winnen. Ik gebruik H1 voor de pagina titels, ABBR tags voor abbreviations, P tags voor de paragrafen, EM tags voor emphasized stukjes. You name it. De CMS die ik samen met collega's heb geschreven heeft als output pure xHTML1.0. Sommige elementjes worden niet gevalideerd, maar over het algemeen is de code ouput zeker niet slecht.

En volgens mij is dat de overgang die de meesten aan moeten houden, voorlopig.

Maar nee, ik ben hier absoluut niet tevreden mee.

edit:
Blue-eagle hier dus.. zit op account van collega

[ Voor 2% gewijzigd door Verwijderd op 12-03-2004 21:36 . Reden: Eigen nick toevoegen ]

[Verwijderd]

Verwijderd schreef op 12 maart 2004 @ 21:25:
Dat moet wel slecht zijn voor de ranking bij google, en inderdaad..., zoeken op wehkamp en hij staat er niet eens bij

Bij mij staat wehkamp anders pal bovenaan.

[Verwijderd]

Huh? Ooooohhhhhh, als reclame. Ja, zo zullen mensen je nooit vinden. Wie kijkt er nou naar reclame?

[coubertin119]

Verwijderd schreef op 12 maart 2004 @ 21:30: een heel verhaal

Al eens naar Dean Edwards gekeken? Een hoop CSS2-support erbij voor IE5.5 en 6 .

En dat volgens de standaarden coden langer duurt kan ik niet bepaald beamen. Mijn ervaring leert me dat het net veel makkelijker werkt. Je HTML leest erg gemakkelijk, je CSS is volgens dezelfde methodiek opgebouwd dus ook lekker makkelijk te maken. Ik vind het gewoon een pak makkelijker omdat alles logisch is, en je vanuit die logica kan voort denken over de pagina. Designs met tables lijken me een crime om iets aan te passen.

Jij noemt het luiheid, maar als jij je design moet aanpassen kan ik genieten van mijn gedane zaken terwijl jij heul erg veel werk mag gaan verrichten.

[Verwijderd]

Verwijderd schreef op 12 maart 2004 @ 21:37:
Huh? Ooooohhhhhh, als reclame. Ja, zo zullen mensen je nooit vinden. Wie kijkt er nou naar reclame?

wat een onzin imho, Wehkamp is een goed merk met een bulk aan reklame-budget.
een nr 1 ranking bij google hebben ze niet eens nodig. Iedereen kent Wehkamp, en de link naar wehkamp.nl is zo gelegd.

En daarnaast waar moet je bij wehkamp op zoeken voor een nummer 1 positie?

op "webwinkel" en "jas" ofzo? Dat is echt niet haalbaar met zo`n assortiment.

[ Voor 17% gewijzigd door Verwijderd op 12-03-2004 21:56 ]

[Verwijderd]

coubertin119 schreef op 12 maart 2004 @ 21:42:
[...]

Al eens naar Dean Edwards gekeken? Een hoop CSS2-support erbij voor IE5.5 en 6 .

Knap wat hij heeft gedaan, maar behalve een hoog gadget gehalte heb je er niet veel aan. Je gaat je projecten niet uitrusten met allerhande grote behaviours. Dit valt typisch onder het gedeelte hacks.

[Clay]

Voor een normale browser is het natuurlijk totaal niet belangrijk of je met tabletagsoup aan komt zetten of met goede xhtml. De browser kan het alletwee wel, dus dan is op beide manieren wel een goed toegankelijke site te bouwen. Zodra je met een ander medium aan komt zetten ben je wel de sjaak.

Als je site dus alleen in een normale browser hoeft te werken voor de gemiddelde ziende en horende internetter, wat boeit jou die standaard dan? niets misschien, en dan mag het wat mij betreft (als ik maar niet aan je code hoef te werken ).

Maar als je jezelf zomaar de vraag stelt "zal ik standaarden gebruiken, of troepcode bakken", dan stel je al de verkeerde vraag, en kan je net zo goed de voor jou makkelijkste methode pakken. De techniek bestaat omdat die een oplossing biedt voor een eerder gesteld probleem. Onderhoudbaarheid, flexibiliteit, overzichtelijkheid maar ook toegankelijkheid en usability ... met standaarden zijn al deze dingen beter te ontwikkelen dan zonder, maar natuurlijk niet uitsluitend met standaarden.

Een standaard is dus ook alleen maar een middel om tot een bepaald doel te komen, het is geen doel op zich. Zo kan je de back-end voor een verzekeraar ook ueberranzig in elkaar zetten, en als het maar werkt en het hoeft nooit aangepast te worden zal er geen haan naar kraaien.

Wat betreft mijn technische .02€; Layouts zijn met CSS makkelijker en sneller te maken dan met tables. Het ontbreekt soms aan ondersteuning in een niet nader te noemen browser en de techniek is inderdaad nog in ontwikkeling, maar het werkt schitterend als je op de hoogte bent van de do's en don'ts.
Die do's en don'ts gelden voor tables net zo hard, alleen zijn die bij de meesten (nu nog) bekender, en kiezen velen daarom de makkelijke weg. De grootste misverstanden zijn wat mij betreft dan ook:

• Dat tables handiger zijn voor layout.
  Tables zijn nooit bedacht voor pixel layout. CSS wel.
• Dat layout in CSS voor 80% uit hacks zou bestaat.
• Dat CSS layout minder stabiel is.

Vooral die laatste grondt op pure onwetendheid CSS bracht niet alleen een nieuwe techniek, het bracht ook een nieuwe manier om te knoeien; 90% van de problemen met CSS komen voort uit:

• Onwetendheid over boxmodels
• Onwetendheid over gedrag van floats
• Onwetendheid over flow en het samenspel van display types
• Overmatig gebruik van width en height

Floats zijn de grootste boosdoener;

Versmal je venster maar eens overdreven en alle kolommen vallen onderelkaar als rijen. Met tabellen heb je dit niet.

Dan zijn die dus gefloat. De essentie van floats is dat ze aan de kant kunnen gaan als er te weinig ruimte is, en dus naar onderen klappen. Dat maakt ze uitermate ongeschikt om te gebruiken voor je layout. Het is dus gewoon een implementatie fout van die site, niet van CSS. Je kan kolommen namelijk net zo hard vasttimmeren met CSS als met tables; zonder float.

En aangezien Microsoft de martkleider is in browserland, kan de CSS2 specificatie zijn wat het wilt, de standaard wordt bepaald door Microsoft. CSS2 = CSS2 in MS IE.

Onzin. MS ondersteunt ook gewoon de standaarden, IE6 is alleen stokoud. Het handige aan CSS is dat het niets doet als het niet ondersteund wordt. Ook CSS3 is dus prima te gebruiken, al is dat omdat IE zo groot is voorlopig alleen voor extra's, en dus waarschijnlijk hobby/eigen sites.

En dan een verhaal apart.. hacks. Iedereen probeert hacks te gebruiken voor zijn/haar site. Je weet wel, die dingen die op ALA regelmatig voorbij komen.

Ook dat is een misvatting. 90% van wat een hack genoemd word is gewoon goede CSS (faux columns b.v.), alleen is de denkwijze die erachter ligt gewoon anders.
Onbekend maakt onbemind.

[Verwijderd]

coubertin119 schreef op 12 maart 2004 @ 21:42:
[...]

Al eens naar Dean Edwards gekeken? Een hoop CSS2-support erbij voor IE5.5 en 6 .

Die techniek moet zich nog bewijzen. De auteur zegt zelf al dat het alpha-code is.
Bovendien biedt het vooral ondersteuning voor selectors, ik denk dat het zelfs problemen kan geven als IE opeens allemaal css dingen kan lezen die normaliter expres worden verborgen voor die browser.
Ik denk toch dat het een (ontzettend knap gemaakte) geek tooltje blijft.

En dat volgens de standaarden coden langer duurt kan ik niet bepaald beamen. Mijn ervaring leert me dat het net veel makkelijker werkt. Je HTML leest erg gemakkelijk, je CSS is volgens dezelfde methodiek opgebouwd dus ook lekker makkelijk te maken. Ik vind het gewoon een pak makkelijker omdat alles logisch is, en je vanuit die logica kan voort denken over de pagina. Designs met tables lijken me een crime om iets aan te passen.

Jij noemt het luiheid, maar als jij je design moet aanpassen kan ik genieten van mijn gedane zaken terwijl jij heul erg veel werk mag gaan verrichten.

Niet vaak mee gewerkt, hoor maar er schijnen wysiwyg-editors te zijn die in ontzettend weinig tijd ontzetten veel (spaghetti-) code kunnen produceren...

[CrashOne]

Verwijderd schreef op 12 maart 2004 @ 21:30:
[...]
Nou, bij mij thuis en op mijn werk start IE nog altijd stukken sneller op dan IE. Daarbij, ik kom ook vaker sites tegen die in Mozilla er "minder" (wel acceptabel vaak) uit zien dan in IE. Duidelijke redenen natuurlijk, maar voor een kolen apparaat is IE zeker niet slecht

Het gaat hier om standaarden, en die implementeerd Mozilla een stuk beter dan IE.
Doordat jij sites bezoekt die door mensen is gemaakt die niks van deze standaarden weten en IE only ontwikkelen.

[...]
Okay, argument 1: tabellen zijn statischer. Als voorbeeld kun je de website van het W3 nemen. Versmal je venster maar eens overdreven en alle kolommen vallen onderelkaar als rijen. Met tabellen heb je dit niet. Misschien is dit een kwestie van voorkeur...

W3 heeft er voor gekozen om het op deze manier te doen, dus ik begrijp je niet helemaal.


Waar ik zelf een hekel aan heb: kom ik met mijn moderne browser (mozilla 1.6) op een IE only site, krijg ik de melding dat ik de "moderne browser" IE moet downloaden....

[Mx. Alba]

Nog iets over standaarden: Stel, je maakt een tagsoep-site. Het ziet er heel erg mooi uit, het werkt perfect - maar het blijft natuurlijk een tagsoep. Wat nou als jij er op een gegeven moment niet meer bent, om wat voor reden dan ook? Dan zit jouw opvolger met een gigantische draak op handen, en het zal voor hem zeer moeilijk zijn om de site aan te passen... Inderdaad, met schone xhtml en css zou een complexe site ook moeilijk over te nemen zijn door een andere onderhoudsman of -vrouw, maar in ieder geval is het een heel stuk makkelijker (mits de vervanger de standaard ook kent, natuurlijk...)

Bij mijn sites (één tagsoep-site en één schone xhtml + css sites) los ik trouwens het onderhoudsprobleem op met een beetje zeer simpele PHP. Het skelet inclusief het menu wordt door PHP gebouwd, en de content die daarin geladen wordt staat in losse files. Zelfs een zeer ingrijpende verandering van de sites kan ik doen door slechts één PHP-script aan te passen - als ik er een paar dagen vrije tijd in zou steken, zou ik die tagsoep-site zo om kunnen bouwen tot schone xhtml (hoewel ik daarvoor trouwens wel in alle individuele content-bestanden zou moeten ingrijpen om alle <tr><td>'s in <p>'s te veranderen (en </td></tr>'s in </p>'s natuurlijk), maar dat is ook zo gepiept). Een pagina toevoegen? Content schrijven, een handjevol array-entries toevoegen zodat het menu-item gegenereerd wordt, en klaar is Henk. Als ik zou willen zou ik er zo een update-script omheen kunnen bouwen.

Inderdaad is met XHTML + CSS de layout nog niet goed genoeg van de content gescheiden, maar voeg PHP toe (of ASP als je dat liever hebt) en dat probleem lost zich als sneeuw voor de zon op. [edit] En een ander groot voordeel van PHP is dat je lekker kwistig met commentaar kan strooien zonder dat de bezoeker van je website dat ooit te zien krijgt - maar wel heel handig voor je opvolger als je ooit het roer overgeeft!

[ Voor 9% gewijzigd door Mx. Alba op 12-03-2004 22:19 ]

[Verwijderd]

coubertin119 schreef op 12 maart 2004 @ 21:42:
[...]

Al eens naar Dean Edwards gekeken? Een hoop CSS2-support erbij voor IE5.5 en 6 .

Ja die ken ik, en ik moet toegeven dat het erg leuk is allemaal. Maar dit is dus niet standaard. Als een client Javascript heeft uitstaan...

Clay:
Dan zijn die dus gefloat. De essentie van floats is dat ze aan de kant kunnen gaan als er te weinig ruimte is, en dus naar onderen klappen. Dat maakt ze uitermate ongeschikt om te gebruiken voor je layout. Het is dus gewoon een implementatie fout van die site, niet van CSS. Je kan kolommen namelijk net zo hard vasttimmeren met CSS als met tables; zonder float.

Ik geloof je direct, maar dat heb je te danken aan je reputatie Scheelt weer wat zoeken enzo. Maargoed, dit is een voorkeur zoals ik aangaf. Ik wil echt niet die kolommen onderelkaar zien. Voorkeur, staat dus los van css "issues".

Clay:
Onzin. MS ondersteunt ook gewoon de standaarden, IE6 is alleen stokoud. Het handige aan CSS is dat het niets doet als het niet ondersteund wordt. Ook CSS3 is dus prima te gebruiken, al is dat omdat IE zo groot is voorlopig alleen voor extra's, en dus waarschijnlijk hobby/eigen sites.

Ik volg je niet helemaal, maar... voor zover ik weet, ondersteund MSIE6 CSS2 nog niet volledig (selectors e.d.). Hoe kun je nou zeggen dat ze wel de standaarden ondersteunen?

Explain please

Verder, over hacks. Ik doel eigenlijk niet op de "think out of the box" methoden, met enig denken kan iedereen dat soort dingetjes bedenken. Ik doel eigenlijk meer op dit implementaties zoals dat Dean Edwards project. Ook dit soort gedoe:

code:

#header a {
    float:left;
    display:block;
    background:url("right.gif")
      no-repeat right top;
    padding:5px 15px 4px 6px;
    text-decoration:none;
    font-weight:bold;
    color:#765;
    }
  /* Commented Backslash Hack
     hides rule from IE5-Mac \*/
  #header a {float:none;}
  /* End IE5-Mac hack */

Ik weet niet goed uit te leggen waarom, maar dit staat mij gewoon helemaal niet aan, voor de toekomst. Dit soort dingen zijn er ook voor IE, dacht ik.

We missen gewoon heel wat features in IE, en ik ga niet vertrouwen op "third party" software (javascript) van een onbekende om bepaalde features the laten werken in een browser. Dit staat me gewoon tegen. Leuk voor een personal homepage, maar niet voor een website zoals die Wehkamp site.

[Verwijderd]

Verwijderd schreef op 12 maart 2004 @ 23:43:
[...]
Ja die ken ik, en ik moet toegeven dat het erg leuk is allemaal. Maar dit is dus niet standaard. Als een client Javascript heeft uitstaan...

Hoewel ik het hier helemaal met je een ben. Is het uitschakelen van JS op grote sites meestal vragen om problemen. Vaak werken die uitklap menuutjes ook gelijk niet meer (en die zouden kunnen werken in Mozilla, ook met JS uit).

Ik geloof je direct, maar dat heb je te danken aan je reputatie Scheelt weer wat zoeken enzo. Maargoed, dit is een voorkeur zoals ik aangaf. Ik wil echt niet die kolommen onderelkaar zien. Voorkeur, staat dus los van css "issues".

W3C gebruikt 'float', jij wilt 'display:table' of iets met 'max-width' etc.

Ik volg je niet helemaal, maar... voor zover ik weet, ondersteund MSIE6 CSS2 nog niet volledig (selectors e.d.). Hoe kun je nou zeggen dat ze wel de standaarden ondersteunen?

Omdat geen enkele browser CSS1, laat staan CSS2, volledig ondersteund (daarom is er ook een CSS2.1 uitgebracht -> browsergerichte specificatie, net zoals alle volgende specificaties.

Ook dit soort gedoe: [knip] Ik weet niet goed uit te leggen waarom, maar dit staat mij gewoon helemaal niet aan, voor de toekomst. Dit soort dingen zijn er ook voor IE, dacht ik.

Wat is er mis mee? Lijkt me redelijk forward compatible. Alle moderne browsers ondersteunen dat gedeelte van floats goed, ze parsen de style sheet comments goed. MacIE (inmiddels overleden) doet beide niet en kun je dus een truucje gebruiken.

We missen gewoon heel wat features in IE, en ik ga niet vertrouwen op "third party" software (javascript) van een onbekende om bepaalde features the laten werken in een browser. Dit staat me gewoon tegen. Leuk voor een personal homepage, maar niet voor een website zoals die Wehkamp site.

Je hebt helemaal gelijk, feit is dat die CSS2 dingen nou net het minst belangrijke zijn om iets neer te zetten. Internet Explorer ondersteund wel degelijk een groot gedeelte van CSS2, dit werd eerst CSS-P genoemd en later werd dat opgenomen in CSS2.

Dat is dus het positionerings gedeelte. Doordat IE dat vanaf IE5 ondersteund is er erg veel mogelijk. Dit is ook online te zien, wired.com bijvoorbeeld.

[Verwijderd]

In reactie op 'oh,when?'.

Een voordeel van het omzetten van Wehkamp naar een standard-compliant site valt sowieso af, zoekmachines. Met zo'n naamsbekendheid en reclamebudget denk ik niet dat je geindexeerd hoeft te worded. Mogelijkheid om individuele pagina's te bookmarken was echter wel handig geweest. Ik vraag me af waarom er voor een frameset gekozen was (merkt nu op dat de pagina wel degelijk in 1 frame staat, maar dat er twee andere frames zijn voor...).

Site lijkt ook prima cross-browser te werken (even alleen getest in IE, Opera, Mozilla; laatste versies).

Wat wel opvalt is dat het geheel niet al te snel opbouwt en dat lijkt me te verklaren door een hoop geneste tabellen, overbodige attributen etc., want bandbreedte was het probleem niet echt.

Ik denk dat het prima moet lukken om deze site om te zetten. Uiteraard zal het tijd kosten, zeker omdat de expertise van het team nog niet perfect is aangaande webstandaarden. Het is namelijk ook gewoon een manier van werken, dit soort tag-soup creeeren zou mij nooit lukken bijvoorbeeld .

De layout (ik concentreer me even op de homepage) is volgens mij nu erg pixel gebaseerd ("1600,*,*"). Alles staat exact vast en als dat zo gehouden wordt is het een koekie om het om te zetten, als het meer flexibel moet worden iets lastiger wellicht, maar nog steeds niet heel erg.

Om veel met floats te gaan werken lijkt me riskant. Voor die product boxjes zou je bijvoorbeeld een DIV kunnen nemen met daarin een P welke de 2 hyperlinks plus tekst bevat. De P schuif je naar rechts met 'margin-left' en de DIV geef je een achtergrondplaatje, bijvoorbeeld van het koffiezet-apparaat of de PC-compleet. Uiteraard zou je ipv een DIV ook een UL ervan kunnen maken en een klein beetje spelen met floats om ze leuk onder elkaar te krijgen (niet al te moeilijk), je moet dan alleen rekening houden met default 'margin' en 'padding', welke uiteraard uit te schakelen zijn, maar veel designers denken daar niet aan .

Concrecte voordelen zijn snelheid en toegankelijkheid en kostenbesparing op de lange termijn.