Standaarden (W3C, etc.)

Verwijderd schreef op 08 april 2004 @ 11:37:
[...]

Ik denk juist dat het zeer vooruitstrevend is.
Altijd maar weer dat moeten vernieuwen in de IT-wereld gaat ook zo vervelen.
Het is juist erg verfrissend om te zeggen: "..., maar nu even niet!"

Stil blijven staan is nooit innoverend. Het is denk ik wat faabman zegt: grote organisaties zijn gewoon minder flexibel. Maar het heeft niks met onderzoek te maken. De standaarden zijn er, en met kennis van W3C, GoT en de bekende weblogs is het eenvoudig toe te passen. Het probleem is dat de devver er tijd in moet _willen_ steken. Ik, met vele anderen hier, vind het gewoon interessant sites 'netjes' in elkaar te zetten, en profiteer daarbij van de voordelen van de standaarden: flexibiliteit, leesbare code, kleinere bestanden, betere toegankelijkheid voor zowel zoekmachines als mensen met een handicap.

Uiteindelijk komt het natuurlijk ook vanuit de marketing en de consument. Neem bijvoorbeeld FSC-hout (een keurmerk). Dankzij reclamecampagnes weten mensen dat FSC-hout meerwaarde heeft ten opzichte van niet-FSC-hout. Als de massa, en dan vooral bedrijven die een website willen, met hun neus op de voordelen van standaard-compliance worden gedrukt, zullen de webdesignbedrijven vanzelf hun strategie moeten aanpassen.

DiMension schreef op 08 april 2004 @ 12:05:
[...]
Het probleem is dat de devver er tijd in moet _willen_ steken.

Zal ik dat dan even aanvullen met tijd "krijgen" . Opleiding is imho een gedeelde verantwoordelijkheid van werkgever en werknemer...

Uiteindelijk komt het natuurlijk ook vanuit de marketing en de consument. Neem bijvoorbeeld FSC-hout (een keurmerk). Dankzij reclamecampagnes weten mensen dat FSC-hout meerwaarde heeft ten opzichte van niet-FSC-hout. Als de massa, en dan vooral bedrijven die een website willen, met hun neus op de voordelen van standaard-compliance worden gedrukt, zullen de webdesignbedrijven vanzelf hun strategie moeten aanpassen.

Die vergelijking gaat niet op... Je hebt het over een goed wat een hogere "social-value" vertegenwoordigt (FSC speelt ook in op het milieu-bewuste gedrag van de koper)... Ik zie in die context het verschil niet tussen een website die uit tabellen bestaat en een website die gemaakt is mbhv standaarden...

faabman schreef op 08 april 2004 @ 12:13:
Die vergelijking gaat niet op... Je hebt het over een goed wat een hogere "social-value" vertegenwoordigt (FSC speelt ook in op het milieu-bewuste gedrag van de koper)... Ik zie in die context het verschil niet tussen een website die uit tabellen bestaat en een website die gemaakt is mbhv standaarden...

Gebruik maken van standaarden is inderdaad niet milieuvriendelijker dan 'fout' devven, maar wat ik wil zeggen is dat de klant weet van het bestaan van een keurmerk of standaard. Iedereen weet dat bedrijven ISO-gecertificeerd kunnen zijn, al zou ik niet precies weten wat dat inhoudt. Toch straalt een dergelijk keurmerk in zekere zin uit dat een gecertificeerd bedrijf betrouwbaarder of veiliger of op een andere manier beter is dan de concurrentie.

Als er aan de gemiddelde webgebruiker duidelijk gemaakt kan worden dat er standaarden bestaan en dat die duidelijk voordelen hebben ten opzichte van traditioneel gemaakte websites, zal het gebruik van standaarden vanuit het bedrijfsleven zeker toenemen.

DiMension schreef op 08 april 2004 @ 12:22:
[...]
Als er aan de gemiddelde webgebruiker duidelijk gemaakt kan worden dat er standaarden bestaan en dat die duidelijk voordelen hebben ten opzichte van traditioneel gemaakte websites, zal het gebruik van standaarden vanuit het bedrijfsleven zeker toenemen.

Het punt is dat er "voor de gemiddelde webgebruiker" geen enkel voordeel zit aan de standaards. Zolang de site er hetzelfde uit ziet, ziet ie er hetzelfde uit, nietwaar?

Vooral niet gemiddelde gebruikers hebben baat bij standaards: blinden vormen het duidelijkste voorbeeld, maar ook voor mensen met dyslexie zitten er voordelen aan goed opgebouwde site. Pas als de grote bedrijven (als in opdrachtgevers van webdesigners) het besef krijgen dat het bereiken van die mensen voordelen met zich meebrengt zal er bij webdesigners nood bestaan om standaarden toe te passen.

Dat neemt niet weg dat ik van mening ben dat het
A) deels de taak is van webdevelopers om (potentiële) klanten op de hoogte te brengen van de voordelen standaards (desnoods met een prijsopgaaf van de extra kosten), en
niet erg professioneel is om voor een ontoegankelijke oplossing te kiezen als er redelijk eenvoudig een toegankelijk alternatief aanwezig is.

Met dat laatste punt bedoel ik uitdrukkelijk niet dat heel het XHTML en CSS een "redelijk eenvoudig alternatief" is. Maar dat delen ervan zonder veel moeite kunnen worden toegepast. Bijgevolg zullen de standaarden er dan wel in groeien, niet alle veranderingen hoeven bij weg van revolutie nietwaar...

Tot slot nog de overweging dat toegankelijkheid ook met table-layout kan worden bereikt. Kijken we naar de lijst van deelnemers aan drempelsweg dan zien we dat van 1 van de twee met een priority 1&2 (hoogste toegankelijkheid) classificatie gewoon tables gebruikt. Bij degenen met een priority 1 is de table-layout ruimschoots in de meerderheid.....

Ondanks dit alle hou ik het zelf lekker bij de standaard en ik hoop dat browsermakers dat ook een keer gaan doen....

faabman schreef op 08 april 2004 @ 12:13:

[...]

Die vergelijking gaat niet op... Je hebt het over een goed wat een hogere "social-value" vertegenwoordigt (FSC speelt ook in op het milieu-bewuste gedrag van de koper)... Ik zie in die context het verschil niet tussen een website die uit tabellen bestaat en een website die gemaakt is mbhv standaarden...

Volgens mij kun je het zo zien: als het hout in mijn Ikea-kast uit een speciaal daarvoor geplant bos komt, ziet de kast er niet beter uit. Als de ballen die gebruikt worden bij het EK voetbal niet middels kinderarbeid vervaardigd zijn, zullen ze niet ronder zijn. En zo zal een website die gemaakt is volgens de standaarden er ook niet beter uit zien dan een website die niet is gemaakt volgens de standaarden.

We zijn allemaal tegen het kappen van bomen in het tropisch regenwoud en we zijn allemaal tegen kinderarbeid. Dus geeft het een goed geval als je weet dat je zelf in ieder geval niet op welke manier dan ook (indirect) daaraan meewerkt.

De eigenaar van een website zou toch ook blij moeten zijn dat iemand die blind of doof is toch zijn website kan bezoeken (ook al betreft dat 0,1% van de bezoekers en zullen deze bezoekers toch geen producten bij dat bedrijf bestellen). De eigenaar van een website zou toch ook blij moeten zijn dat zijn web development team uitstekend op de hoogte is van alle standaarden en daarom een snellere en toegankelijkere website kan bouwen dan de concurrent. En de eigenaar van een website zou toch ook blij moeten zijn dat hij weet dat als er over 2 jaar een frisse wind door het bedrijf waait er niet zoveel tijd en kosten gemoeid gaan met een nieuw uiterlijk van de website. En dat het nieuwe personeel na een reorganisatie minder moeite heeft om de structuur van de website te doorgronden.

Dit klinkt allemaal wat utopisch, ik weet het. Maar volgens mij zou dat wel het streven moeten zijn. En daarom vind ik een ISO-certificering of keurmerk zo gek nog niet.

"En daarom vind ik een ISO-certificering of keurmerk zo gek nog niet...."





etc...

Ze halen bar weinig uit, en niet zo gek eigenlijk: Toegankelijkheid is - itt tot kinderarbeid en het milieu - niet echt iets waar "normale"() mensen zich druk om maken.
Bovendien is wegblijven vaak niet echt een optie, als jouw bank on-line bankiert met een ontoegankelijke site blijf je toch terug komen. Als jij het wél kan lezen ga je toch niet switchen van bank???
Switchen van bank doe je alleen als je blind bent (of anderszins beperkt) en behoefte hebt aan on-line bankieren. (niet eens zo gek, hoe leest een blinde een afschrift?)

Wat betreft de blijheid van allerlei mensen met standaards: In het economisch verkeer wordt er vaak gesproken van kosten en baten. Hoe blij ik ook zou zijn als ik zou weten dat mijn karbonaadje van een varken komt dat 500 Hectare weiland voor zichzelf had. De prijs van zo'n karbonaadje is alleen zo hoog dat ik als ik het zou moeten betalen er lang zo blij niet mee zou zijn...

T-MOB schreef op 08 april 2004 @ 16:07:
(niet eens zo gek, hoe leest een blinde een afschrift?)

Met een spraaksynthesizer (zo internetten ze ook) in combinatie met een brailleregel en brailletoetsenbord of gewoon toetsenbord. Ooit een blinde klant aan de lijn gehad die mailproblemen had (ik werkte @ helpdesk planet), best blij als je op de achtergrond de spraaksynthesizer het geavanceerd-tabblad van een account hoort oplezen

Waar ik me over blijf verbazen is dat het W3C voor HTML allerlei opmaakzaken deprecate en deze vervolgens in het W3C CSS weer vrolijk toepasbaar zijn

[ Voor 15% gewijzigd door pagani op 08-04-2004 16:11 ]

T-MOB schreef op 08 april 2004 @ 16:07:
"En daarom vind ik een ISO-certificering of keurmerk zo gek nog niet...."
[loze plaatjes die de site een stuk lelijker maken]
etc...

Die buttons zeggen eigenlijk helemaal niks. Dat een site valideert wil nog steeds niet zeggen dat 'ie aan de standaarden voldoet zoals ze bedoeld zijn. Ik zou op mijn site voor geen goud zo'n button neer willen zetten, ook al zit 'ie semantisch correct in elkaar en valideert 'ie op alle manieren.

En je verhaal over drempel en kosten: gebruik maken van standaards kost niets. Een devver die ook maar een beetje into correct CSS en XHTML-gebruik is kan in net zoveel tijd een als een traditionele site een standaard-compliant site in elkaar zetten.

En standaard-compliance is natuurlijk niet alleen voor mensen met een handicap voordelig. Zoals je zei kunnen sites met tabelopmaak ook prima toegankelijk zijn. Maar denk aan zoekmachines. Semantisch correct opgezette pagina's zorgen voor relevantere hits. Ook flexibiliteit en portability zijn grote voordelen. Ik ga dat niet allemaal herhalen, want de voordelen van standard-compliance zijn al duizenden keren uitgelegd in dit topic.

DiMension schreef op 08 april 2004 @ 16:27:
[...]
Die buttons zeggen eigenlijk helemaal niks. Dat een site valideert wil nog steeds niet zeggen dat 'ie aan de standaarden voldoet zoals ze bedoeld zijn. Ik zou op mijn site voor geen goud zo'n button neer willen zetten, ook al zit 'ie semantisch correct in elkaar en valideert 'ie op alle manieren.

Ja leuk verzonnen. ISO-certificering gebeurt volgens strakke en duidelijke richtlijnen. FSC-hout keurmerk gebeurt volgens strakke en duidelijke richtlijnen. Het valideren van je HTML code gebeurt ook volgens strakke en (soms) duidelijke richtlijnen. Echter het begrip semantiek is zo subjectief als de pest, verklaart ook waarom er geen semantic check tool is.

Met andere woorden, als je zegt dat die buttons je niets waard zijn, impliceer je indirect ook dat het 'bouwen volgens de standaarden' ( semantisch correct ipv syntactisch correct ) een opdracht is zonder duidelijke specificaties. Als daarnaast de 'standards advocates' ( niets mis mee overigens ) zelf al beweren dat het enige keurmerk wat er dan is ( W3C Buttons ) voor hunzelf geen waarde heeft, waarom zou dat dan voor een bedrijf wel waarde hebben?

Verwijderd schreef op 08 april 2004 @ 16:45:
[...]
Ooit het woord semantiek voorbij horen komen bij Nederlands (of een of andere studie)? Daar hebben dingen als "background", "alink" etc. niets mee te maken. Daarom zijn ze uit HTML gehaald.

Ooit het woord opmaak voorbij horen komen?
Css is een opmaaktaal en het is de bedoeling om html-dingen die specifiek met opmaak hebben te maken te verwijderen en om te zetten in een css formaat.

oh,when? schreef op 08 april 2004 @ 17:01:
Met andere woorden, als je zegt dat die buttons je niets waard zijn, impliceer je indirect ook dat het 'bouwen volgens de standaarden' ( semantisch correct ipv syntactisch correct ) een opdracht is zonder duidelijke specificaties. Als daarnaast de 'standards advocates' ( niets mis mee overigens ) zelf al beweren dat het enige keurmerk wat er dan is ( W3C Buttons ) voor hunzelf geen waarde heeft, waarom zou dat dan voor een bedrijf wel waarde hebben?

Een tool kan op geen enkele manier checken of jouw <h1>-tag daadwerkelijk de belangrijkste kop van een pagina is, of dat je niet een <blockquote> compleet stylet tot navigatie-element (om maar een scheef voorbeeld te geven). Computers kunnen nou eenmaal geen inhoud begrijpen. Ook kan een tool niet checken of navigatie begrijpelijk en toegankelijk is voor iedereen. Toch is dit eigenlijk wel de bedoeling van de standaards.

Ook moet het woord semantiek ueberhaupt maar eens doordringen in webdesignwereld. Veel van de huidige webdesigners zijn alleen maar met uiterlijk van een site bezig, terwijl dat maar de helft (of minder) van het verhaal is.

[ Voor 13% gewijzigd door David op 08-04-2004 17:13 ]

DiMension schreef op 08 april 2004 @ 17:12:
[...]
Ook moet het woord semantiek ueberhaupt maar eens doordringen in webdesignwereld. Veel van de huidige webdesigners zijn alleen maar met uiterlijk van een site bezig, terwijl dat maar de helft (of minder) van het verhaal is.

Uiterlijk is wel degelijk zeer belangrijk van een website, omdat dat de basis is voor communicatie. En dat is de basis van het internet, communicatie. Via woorden, maar ook zeer zeker visueel. Voor commerciele bedrijven straalt het merk uit waar zij voor staan, hun visie, hun missie, hun filosofie en hun bedrijfscultuur. Zij spenderen hier vaak veel tijd en geld aan. Het uiterlijk van de website speelt juist zeker een zeer grote rol. Daarentegen is de code van een site veel minder van belang, alleen voor diegene die hem bouwen ( de ontwikkelaars dus ). Het statement dat het uiterlijk van een website niet zo'n issue doet is er typisch 1 vanuit developers oogpunt, en zeker niet vanuit de commerciele markt. Je kan wel veel willen, maar je klant betaald uiteindelijk. Voor de rest zal het iedereen aan zijn reet roesten hoe die code eruit ziet. Helaas maar waar.. Vind je van niet?

Welcome to the real world, where money has to be made, budget is tight, and work had to be finished yesterday.

[ Voor 7% gewijzigd door oh,when? op 08-04-2004 17:25 ]

DiMension schreef op 08 april 2004 @ 16:27:
[...]
Die buttons zeggen eigenlijk helemaal niks. Dat een site valideert wil nog steeds niet zeggen dat 'ie aan de standaarden voldoet zoals ze bedoeld zijn. Ik zou op mijn site voor geen goud zo'n button neer willen zetten, ook al zit 'ie semantisch correct in elkaar en valideert 'ie op alle manieren.

Mijn punt was dat er zat keurmerken bestaan... En dat ze niet tot bewustzijn bij de doorsnee internetter leiden.

En je verhaal over drempel en kosten: gebruik maken van standaards kost niets. Een devver die ook maar een beetje into correct CSS en XHTML-gebruik is kan in net zoveel tijd een als een traditionele site een standaard-compliant site in elkaar zetten.

Ben ik met je eens. Het probleem is dan ook dat niet alle devvers voldoende into correct CSS en XHTML zitten. Als je nauwelijks genoeg tijd hebt om binnen de deadline te blijven op de traditionele wijze, dan blijft er weinig tijd over om bij te leren. Daarnaast hebben professionele developers te doen met bazen, managers, mede-ontwikkelaars en natuurlijk de wensen van de klant. (Om een paar argumenten te noemen die me mijn mening hebben doen bijstellen). Een beetje pragmatische houding kan imo dus geen kwaad.
Natuurlijk zou het mooi zijn als iedereen correct CSS en (X)HTML zou gebruiken (dus ook browserbouwers). Ik denk dat iedereen hier het daar wel mee eens is.

oh,when? schreef op 08 april 2004 @ 17:24:
Welcome to the real world, where money has to be made, budget is tight, and work had to be finished yesterday.

Hetgeen dus neerkomt op vraag van de klant. In tijden van laagconjunctuur is de klant vaak toch bereid iets meer geld neer te tellen voor betere kwaliteit. De tijd dat ieder bedrijf een website moest hebben om mee te kunnen tellen is gelukkig voorbij, en nu kan er dus gefocust worden op kwaliteit. Ik wil niet zeggen dat tabelopmaak en gebrek aan semantiek geen kwaliteit tegenover de klant kunnen beteken, maar ik ga ook niet in elke post de voordelen van standaards en semantiek oprakelen.

Een klein lesje marketing: de marketing bepaalt uiteindelijk wat de klant wil.
De klant denk niet 'goh, wat zou ik graag een auto met klimaatregeling willen hebben' totdat er auto's met airco worden aangeprijsd. Zo zal een klant (opdrachtgever of eindgebruiker) niet denken: 'wat zou het mooi zijn als deze site kleiner, toegankelijker en flexibeler zou zijn'.

Een misverstand dat dus nog steeds bestaat is dat het maken van een onsemantische tabelwarboel meer tijd kost dan het maken van een elegante correcte website. Ik kan me voorstellen dat het toepassen van semantiek op een tekst tijd kost, maar ik zeg ook niet dat elke quote in een <blockquote> moet, als de globale (relevante) semantiek maar in orde is. Gebruik maken van <h1> ipv een gestylde <td>, plaatje of <span> kost geen tijd. Wat ik wil zeggen is dat standaards toegepast kunnen worden zonder dat er meer tijd, geld of moeite in hoeft te gaan zitten.

DiMension schreef op 08 april 2004 @ 17:48:
Hetgeen dus neerkomt op vraag van de klant. In tijden van laagconjunctuur is de klant vaak toch bereid iets meer geld neer te tellen voor betere kwaliteit.

In tijden van laagconjunctuur zijn bedrijven bereid meer te betalen en in welk boek / artikel wordt die stelling empirisch onderbouwt

De tijd dat ieder bedrijf een website moest hebben om mee te kunnen tellen is gelukkig voorbij, en nu kan er dus gefocust worden op kwaliteit. Ik wil niet zeggen dat tabelopmaak en gebrek aan semantiek geen kwaliteit tegenover de klant kunnen beteken, maar ik ga ook niet in elke post de voordelen van standaards en semantiek oprakelen.

Die "tijd" is idd voorbij, naar mijn idee begint ligt de focus bij klanten nu meer op het bouwen van interactieve sites met een stevige webbased backoffice voor de leveranciers / afnemers... Kwaliteit wordt dus niet gemeten aan de hand van het toepassen van standaarden, maar aan de hand van functionaliteit...

Een klein lesje marketing: de marketing bepaalt uiteindelijk wat de klant wil.
De klant denk niet 'goh, wat zou ik graag een auto met klimaatregeling willen hebben' totdat er auto's met airco worden aangeprijsd. Zo zal een klant (opdrachtgever of eindgebruiker) niet denken: 'wat zou het mooi zijn als deze site kleiner, toegankelijker en flexibeler zou zijn'.

Jij hebt het over de "latente vraag", maar, ik vind het wel een beetje heel erg kort door de bocht om te stellen dat de marketingafdeling bepaald wat de klant wil... De klant bepaald aan de hand van de opties aangeboden door de marketingafdeling wat hij wil...

DiMension schreef op 08 april 2004 @ 17:48:

[beetje economie /]

Een misverstand dat dus nog steeds bestaat is dat het maken van een onsemantische tabelwarboel meer tijd kost dan het maken van een elegante correcte website. Ik kan me voorstellen dat het toepassen van semantiek op een tekst tijd kost, maar ik zeg ook niet dat elke quote in een <blockquote> moet, als de globale (relevante) semantiek maar in orde is. Gebruik maken van <h1> ipv een gestylde <td>, plaatje of <span> kost geen tijd. Wat ik wil zeggen is dat standaards toegepast kunnen worden zonder dat er meer tijd, geld of moeite in hoeft te gaan zitten.

Zelfs elk citaat in een <blockquote> (of <q> natuurlijk) is zo gepiept. Doorgaans wordt van een website echter wat meer verwacht dan van een goed opgemaakt OpenOffice () documentje.
Zodra er visueel/grafisch wat moet gebeuren dan krijg je te maken met niet-ondersteunde syntax en allerhande IE-browserbugs. In X-browser compatabiliteit en "graceful degradation" gaat wel degelijk veel tijd zitten. Was het maar zo makkelijk dat je er was na het lezen van één W3C reference....

[ Voor 4% gewijzigd door T-MOB op 08-04-2004 18:11 ]

DiMension schreef op 08 april 2004 @ 17:48:

Ik wil niet heel erg lullig overkomen, maar je doet uitspraken waarvan ik me meteen afvraag, heb je uberhaupt wel professionele ervaring op dat gebied omdat ook te staven, of loop je gewoon met de horde mee te brullen.

Je beweert kostenbesparingen, dat alles mogelijk is, en dat het ook nog is minder tijd kost; maar dan van mijn kant weer, is dit jouw praktijkervaring of heb je dit ergens gelezen en vond je dat je het moest verder verkondigen

Verwijderd schreef op 08 april 2004 @ 18:25:
Je beweert kostenbesparingen, dat alles mogelijk is, en dat het ook nog is minder tijd kost; maar dan van mijn kant weer, is dit jouw praktijkervaring of heb je dit ergens gelezen en vond je dat je het moest verder verkondigen

Jammer dat er op deze manier gereageerd wordt op mijn posts. Ik denk dat ik genoeg webdesign- en marketingervaring heb om wat ik zeg te kunnen onderbouwen. Ik heb een jaar in een webdesignbureau mee mogen werken, en gezien hoe inflexibel de organisatie is. Ik begrijp dus ook wel dat standards-compliance moeilijk toe te passen is voor bedrijven.

Om even een concreet voorbeeld te geven: ik heb gisteren de website van HTML editor Selida omgebouwd van een tabellenlayout naar CSS en XHTML (niet gevalideerd). De HTML-bestanden zijn nu ongeveer 60% kleiner, uiteraard met een iets grotere stylesheet. De code is veel overzichtelijker. Het feit dat ik dat in een paar uur heb kunnen doen laat al zien dat het omzetten naar CSS en XHTML weinig tijd in beslag neemt. Ik heb het dus nog niet eens over flexibiliteit en toegankelijkheid.

Tevens ben ik bezig met een standards-compliant phpBB-skin. Nu al merk ik dat die veel kleiner is, en vooral veel flexibeler. In een handomdraai plak je de navigatie aan de bovenkant, of geef je de tabellen een andere kleur (forumlisting is wel een tabel uiteraard). Met een beetje mazzel wordt het straks mogelijk voor zoekmachines om het forum op een juiste manier te indexeren.

Er is wel een verschil tussen het overtuigd zijn (of iig inzien) van a) de voordelen van een layout in xhtml ontwikkelen tegenover hetzelfde in tables doen, en b) de haalbaarheid (aanwezigheid en spreiding van kennis, eisen van klant) van het ook daadwerkelijk doen binnen een organisatie. Ik geloof echt dat er hier aan inzicht geen gebrek is maar waar haalbaarheid bij kleinere en middelgrote projecten minder of geen rol speelt is die bij grotere projecten wel een factor. Een paar goeie argumenten die zijn langsgekomen (hier en in het "wie heeft de grootste" topic) zijn imo:

• Je kan jouw hippe kennis wel toepassen, maar als er dan nog 5 anderen aan meewerken die er niets van snappen ga je niet opschieten, en wordt het waarschijnlijk een nog grotere zooi dan wanneer het in het geheel op de "oude manier" gedaan was.
• Je kan hoog en laag springen, maar als een klant ondanks jou dwingende advies het op manier A te doen het toch op manier B wil, heb jij pech. Dit heeft misschien niet altijd met tables te maken maar het kan.

Vanuit een technisch standpunt kan je imo niet anders dan overtuigd zijn van de goedheid van xhtml en css, maar de steeds terugkerende kritiek is zeker niet onterecht. Layout is natuurlijk ook maar een deelaspect hiervan; er zijn nog veel meer (niet technische!) voordelen. Maar als deze voordelen geen doelen zijn (van jou of de klant) ga je daar ook niet wakker van liggen.

Wat betreft praktijkervaring vind ik het trouwens wel terecht dat dat verschil gemaakt wordt. Het is nou eenmaal fundamenteel anders dan alleen of zonder deadlines ergens aan werken en zelf op alle fronten de beslissingen te kunnen nemen.

DiMension schreef op 08 april 2004 @ 18:54:
Jammer dat er op deze manier gereageerd wordt op mijn posts.

Wat is er jammer aan, ik vraag gewoon vriendelijk of je ook ervaring hebt op het gebied, je hoeft dat niet persoonlijk op te nemen. De reden dat ik het vraag is al eerder in het topic genoemd, er zijn gewoon helaas een hoop mensen die meelopen met de hele hype. Want een hype kun je het ondertussen wel noemen.

Ik denk dat ik genoeg webdesign- en marketingervaring heb om wat ik zeg te kunnen onderbouwen. Ik heb een jaar in een webdesignbureau mee mogen werken.

De ene organisatie is de andere niet, bedrijf a prutst maar wat aan en bedrijf b pakt het met dezelfde technieken wel goed aan. En imho kan je met een jaartje ervaring niet echt een reeel beeld van het vak scheppen, maargoed ik kan het mis hebben, ik weet niet hoe andere developers erover denken.

Om even een concreet voorbeeld te geven: ik heb gisteren de website van HTML editor Selida omgebouwd van een tabellenlayout naar CSS en XHTML (niet gevalideerd). De HTML-bestanden zijn nu ongeveer 60% kleiner, uiteraard met een iets grotere stylesheet. De code is veel overzichtelijker. Het feit dat ik dat in een paar uur heb kunnen doen laat al zien dat het omzetten naar CSS en XHTML weinig tijd in beslag neemt. Ik heb het dus nog niet eens over flexibiliteit en toegankelijkheid.

Tevens ben ik bezig met een standards-compliant phpBB-skin. Nu al merk ik dat die veel kleiner is, en vooral veel flexibeler. In een handomdraai plak je de navigatie aan de bovenkant, of geef je de tabellen een andere kleur (forumlisting is wel een tabel uiteraard). Met een beetje mazzel wordt het straks mogelijk voor zoekmachines om het forum op een juiste manier te indexeren.

Dat zijn echte peanuts layouts voor CSS layouted websites. Websites met bijv. de typische weblog layouts zijn heel eenvoudig te layouten met CSS, maar pak bijv. eens een pagina van www.planet.nl, bijv. http://www.planet.nl/plan...ontentid=369325/sc=571120

Dat zijn echt totaal andere layouts, en toch is bovenstaande link ook nog relatief eenvoudig, maar het geeft wel het verschil in bijvoorbeeld de drukte van een layout aan.

@dimension: Je mist nog een Doctype....

@Gordijnstok: Die Planetsite is wel een draak van een site. In bijna 80k code (ex CSS) is dit standards-compliant ook prima te realiseren....

Praktijkervaring is volgens mij geen beperking of pre wat betreft de discusie over standaarden. Argumenten daarentegn wel, argumenten uit de beroepspraktijk zijn wat mij betreft even relevant als die uit hobby. (Zoniet dan zoeken de pro's het lekker zelf uit ). Om op de discussie terug te komen, mijn conclusies uit dit topic zijn ongeveer de volgende:

1. Een standaard als (X)HTML of CSS bestaat puur uit de syntactische omschrijving van deze techniek. Wat betreft de 2 genoemde geldt dat browsers "er maar wat mee doen" zodat er defacto niet echt sprake is van een standaard, meer een "toekomstige manier van doen"...of iets dergelijks.

2. Toegankelijkheid heeft weinig te maken met het toepassen van XHTML en CSS. Zonder is toegankelijkheid ook prima te realiseren, mét is evenwel een ontoegankelijke warboel te creeëren. De wil, mogelijkheden en kwaliteit van de ontwikkelaar zijn wat dat betreft doorslaggevender dan de gehanteerde "standaard".

3. Wat onder 2 staat geldt evengoed voor semantische correctheid (hangt er iig mee samen). HTML 3 kan al semantisch correct worden gehanteerd, evengoed kan XHTML lekker <span class="sub_title"> worden ingezet. Als er al een verschil is in semantische correctheid tussen gebruikers van *standaarden* en anderen dan heeft dit meer te maken met interesse (of bewustzijn) dan met de standaard an sich.

4. Dat ik nog steeds vóór het gebruik van standaarden ben omdat dit in de toekomst allicht leidt tot een situatie waarin je niet voor 1001 browsers hoeft te checken of alles het doet zoals bedoeld. Als browserbouwers en developers zich conformeren aan de standaard is er namelijk nérgens een probleem. (En dat is toch het essentiële doel van een standaard...). En aangezien en beter milieu bij jezelf begint....

....Hobby't T-MOB lekker verder...

T-MOB schreef op 09 april 2004 @ 02:29:
Praktijkervaring is volgens mij geen beperking of pre wat betreft de discusie over standaarden. Argumenten daarentegn wel, argumenten uit de beroepspraktijk zijn wat mij betreft even relevant als die uit hobby. (Zoniet dan zoeken de pro's het lekker zelf uit ). Om op de discussie terug te komen, mijn conclusies uit dit topic zijn ongeveer de volgende:

Het is alsof een chirurg met 8 jaar ervaring in de praktijk wordt tegengesproken door een student medicijnen die de beste man maar eens komt uitleggen dat hij het verkeerde gereedschap op de verkeerde manier gebruikt om de boel aan elkaar te hechten.

Ik doe in mijn hobby ook aan opereren, gaat u maar liggen dan snijd ik u open. .. Maar meneer, weet u wel hoe dat moet dan, .. ja, ik heb er wat whitepaper over gelezen en de argumenten erin zijn belangrijker dan de praktijkervaring.

Verwijderd schreef op 09 april 2004 @ 09:22:
[...]
...ja, ik heb er wat whitepaper over gelezen en de argumenten erin zijn belangrijker dan de praktijkervaring.

Ik heb gehoord dat er binnenkort een nieuw product op de markt komt van Ravensburger:

"Iedereen kan websites bouwen, nu goedgekeurd door het W3C!" (TM)

Is een hele kit, inclusief alle standaarden, XHTML 1.0, XHTML 1.1, CSS2, CSS3 ( Alle modules ), Javascript1.5, en de uitgebreide variant komt zelfs met Flash. Dan hoef je alleen maar de nummertjes te volgen, en kun je elke site maken die je maar wilt. Inclusief handleiding geschreven door de Heer Zeldman.

Er zijn trouwens ook plannen om addon-kits op de markt te brengen. Deze zijn al vrijgegeven:

- Google © Addon kit, volg het stappenplan en je hebt gelijk een zoekmachine.
- Amazon © Addon kit, met 3 stappen een complete eCommerce site!

vet man!

oh,when? schreef op 09 april 2004 @ 11:45:

Er zijn trouwens ook plannen om addon-kits op de markt te brengen. Deze zijn al vrijgegeven:

- Google © Addon kit, volg het stappenplan en je hebt gelijk een zoekmachine.
- Amazon © Addon kit, met 3 stappen een complete eCommerce site!

vet man!

Ik hoop dat die php-plugin er ook bij komt

Ik wil graag de standaard versie bestellen

Verwijderd schreef op 09 april 2004 @ 09:22:

Het is alsof een chirurg met 8 jaar ervaring in de praktijk wordt tegengesproken door een student medicijnen die de beste man maar eens komt uitleggen dat hij het verkeerde gereedschap op de verkeerde manier gebruikt om de boel aan elkaar te hechten.

Het spijt me dat je me verkeerd begrepen hebt. Wat ik bedoelde te zeggen was zegmaar dat een student en een chirurg prima kunnen discussieëren over de te gebruiken tools. En wat blijkt: de gereedschappen die in het theorieboekje (van student) staan en pima toepasbaar zijn op de oefenpop blijken in de chirurgische praktijk een aantal haken en ogen te hebben. De student ziet in dat de nieuwe tools niet heilig zijn en wil graag verder discussiëren over evt toekomstige gebruik van deze tools... vanuit technisch oogpunt zijn de tools namelijk superieur aan die van de chirurg.
Dus zonder dat mensen elkaar vertellen wat ze moeten doen....

@Oh When: LOL! ...Maar als je het sarcastisch tegen mij bedoeld dan had je mijn post beter moeten lezen. Daar staat juist dat iedereen een whitepaper kan doornemen maar dat dat niet automatisch leidt tot een toegankelijke, semantisch correcte site die in alle browsers functioneert. Om nog maar te zwijgen over een deugdelijke lay-out, intuïtief interface en allerlei andere zaken waarin jij zonder twijfel beter in bent dan ik...

BtM909:
Ik hoop dat die php-plugin er ook bij komt

Die is al lang uit man
Volgens mij loop je achter

Ik hoop dat de mensen die hier een voor semantisch-correcte code zijn net zo vooruitstrevend willen zijn om de owl-standaard toe te passen. Wanneer je het hebt over semantiek dan zou naast code-semantiek ook analogie-semantiek wel eens bestudeerd mogen worden op veel websites.

http://www.w3.org/TR/owl-features/

Om is een ander onderwerp erbij aan te halen, welke knurft bij het W3C was zo dronken dat <b> moest worden vervangen door <strong> en <i> door <em>. Ik bedoel, dan ben je toch niet helemaal goed bij je hoofd. B = Bold, I = Italic, en wat doe je, je verzint een tag die niet alleen factor 5 in bytes groter is (x toepassingen in je sourcecode) maar ook nog qua naamgeving zo vergezocht is.

Ja.. hoe kom je erop he

Waarschijnlijk omdat Bold en Italic refereren naar hoe de tekst eruitziet, terwijl strong en emphasized verwijzen naar de functie van die uiterlijkheid.... Zo vergezocht is de naamgeveing dus niet.

Qua bytes heb je wle een punt, maar goed van <table> maken ze ook geen <t>. Ik denk dat het is om HTML wat toegankelijk te houden. Alleen maar één- en tweelettertags maken een document niet bepaald overzichtelijk.

Verwijderd schreef op 09 april 2004 @ 15:04:
Om is een ander onderwerp erbij aan te halen, welke knurft bij het W3C was zo dronken dat <b> moest worden vervangen door <strong> en <i> door <em>. Ik bedoel, dan ben je toch niet helemaal goed bij je hoofd. B = Bold, I = Italic, en wat doe je, je verzint een tag die niet alleen factor 5 in bytes groter is (x toepassingen in je sourcecode) maar ook nog qua naamgeving zo vergezocht is.

Ja.. hoe kom je erop he

Dát vind ik nou jammer.... ik heb je posts redelijk serieus gelezen in dit en andere topics, maar nou wordt je toch echt te flamerig. Je kan toch niet serieus genomen worden als je dit soort replies plaatst? IMHO geldt ook zoiets voor oh,wen?. Een website is niet simpeler te bouwen door gebruik van xhtml/css dingen, het is alleen een andere manier die sommige mensen preferen boven tables. En ook al kunnen ze jou niet overtuigen, als zij het liever op die manier doen, wat is daar dan mis mee?

Sommige mensen hier komen trouwens wel ontzettend arrogant over, dit komt niet altijd ten goede van je geloofwaardigheid.

trouwens:

The <strong> and <em> tags are "logical" tags. This means that they are used deliberately when the designer wants to add emphasis to particular words or phrases. Some screen readers may use a different inflection when they come across these tags to communicate the emphasis. The <b> and <i> tags are primarily for visual effect on a page when designing layout.

[ Voor 16% gewijzigd door chris op 09-04-2004 17:49 ]

chris schreef op 09 april 2004 @ 17:47:
[...]
Dát vind ik nou jammer.... ik heb je posts redelijk serieus gelezen in dit en andere topics, maar nou wordt je toch echt te flamerig. Je kan toch niet serieus genomen worden als je dit soort replies plaatst? IMHO geldt ook zoiets voor oh,wen?.

Tis oh,when? maar das een detail. Volgens mij begon de TS zelf met flamen, nota bene in zijn openingspost:

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.

Hier wordt doodleuk beweerd, dat het niet gebruiken van standaarden gelijk staat met het onvermogen van de developers, en dat je dan maar beter ander werk kan zoeken. Er zijn hier genoeg mensen die fulltime werken in deze industrie, dat is wat anders dan de hobbybob uithangen met een weblog, no pun intended. En er zijn vele goede redenen aangegeven hoe en wat.

Dus och..ligt er maar aan wat je jammer vindt. Vrolijk Pasen iedereen trouwens.

oh,when? schreef op 09 april 2004 @ 18:18:
[...]


Tis oh,when? maar das een detail. Volgens mij begon de TS zelf met flamen, nota bene in zijn openingspost:
[...]
Hier wordt doodleuk beweerd, dat het niet gebruiken van standaarden gelijk staat met het onvermogen van de developers, en dat je dan maar beter ander werk kan zoeken. Er zijn hier genoeg mensen die fulltime werken in deze industrie, dat is wat anders dan de hobbybob uithangen met een weblog, no pun intended. En er zijn vele goede redenen aangegeven hoe en wat.

Dus och..ligt er maar aan wat je jammer vindt. Vrolijk Pasen iedereen trouwens.

Nou en dan nog, het zou je juist sieren en het zou een blijk van professionaliteit zijn om niet terug te flamen. Maar dat laatste ben ik heel erg met je eens, vrolijk pasen iedereen

edit: @hieronder:

Hoe kun je mijn opmerking nou flamen noemen, het zou anders worden als ik zei dat je ongesteld reageerde

Ehm, om nou mensen knurft oid te gaan noemen en zonder echte argumentie is afkraken is wel flamen imho. maar dat is natuurlijk geen objectieve mening

[ Voor 15% gewijzigd door chris op 09-04-2004 20:39 ]

chris schreef op 09 april 2004 @ 18:22:
[...]
ou en dan nog, het zou je juist sieren en het zou een blijk van professionaliteit zijn om niet terug te flamen. Maar dat laatste ben ik heel erg met je eens, vrolijk pasen iedereen

Hoe kun je mijn opmerking nou flamen noemen, het zou anders worden als ik zei dat je ongesteld reageerde

Om even op het verhaal terug te komen, harstikke leuk en aardig dat de heren bij het W3C die never nooit niet naar de developers luisteren, de tags wijzigen, maar geef me nou één goede reden, die ook nog is functioneel is, waarom bijv. <b> <strong> moet worden

Verwijderd schreef op 09 april 2004 @ 20:12:
[...]


Hoe kun je mijn opmerking nou flamen noemen, het zou anders worden als ik zei dat je ongesteld reageerde

Om even op het verhaal terug te komen, harstikke leuk en aardig dat de heren bij het W3C die never nooit niet naar de developers luisteren, de tags wijzigen, maar geef me nou één goede reden, die ook nog is functioneel is, waarom bijv. <b> <strong> moet worden

Zoals Anne al zegt:

Ik vind deze tekst in het bold erg mooi staan <- BOLD <- lay-out
Ik vind deze tekst in het bold erg mooi staan <- STRONG <- nadruk

[ Voor 12% gewijzigd door We Are Borg op 09-04-2004 22:53 ]

We Are Borg schreef op 09 april 2004 @ 22:53:
[...]

Zoals Anne al zegt:

Ik vind deze tekst in het bold erg mooi staan <- BOLD <- lay-out
Ik vind deze tekst in het bold erg mooi staan <- STRONG <- nadruk

En ook nog het feit dat <b> door text-readers genegeerd zal (moeten) worden, en <strong> niet. Stel je deze twee teksten voor:

And the general said: <b>"Move Out!"</b>

And the general said: <strong>"Move Out!"</strong>

In het eerste geval gaat een (toekomstige) textreader gewoon droogjes die tekst lezen, in het tweede geval legt de textreader extra nadruk op die tekst, want hij herkent strong als zijnde nadruk leggend.

Misschien een uitbreiding aan de faq:

http://www.brainstormsand...cles/semantics/structure/

Documentje over Semantiek... Een must voor iedereen, zeer verhelderend!

En een leuk artikel van Jeffrey Zeldman: Metrics Reloaded.

En voor mensen die twijfelen aan de mogelijkheden van css:
CSS Zen Garden, dit soort dingen zijn niet mogelijk met tables....

[ Voor 42% gewijzigd door chris op 11-04-2004 17:16 ]

Toch nog even op deze mooie paasdag reageren. Ik wil nog even teruggaan naar de mensen die roepen dat met CSS je website in 1 keer omgezet kan worden naar een andere layout. Dave Shea en Doug Bouwman hebben op 1 april een grap uitgehaald door de layouts van hun sites te verwisselen. Beide zijn vooraanstaande developers in de 'Webstandards' community ( om het maar ff samen te vatten ) en gebruiken dan ook XHTML en CSS compliant websites.

Appeltje eitje zou je denken toch? 1 keer de stylesheet verwisselen en je bent klaar.

Niets is minder waar, zowel Dave als Doug beschrijven hoe ze deze grap hebben uitgehaald. Schrik niet, het omvat het aanpassen van de originele Photoshop bestanden, het weglaten van menu-structuren, en het toepassen van obscure CSS hacks om het daadwerkelijk voor elkaar te krijgen.

Nu wil ik niet beweren dat het gebruik van Tables en font tags hier wel zou hebben geholpen, maar het toont wel aan dat zelfs de groten onder ons niet 1-2-3 een 'layout verwisselen'.

oh,when? schreef op 12 april 2004 @ 13:19:
Nu wil ik niet beweren dat het gebruik van Tables en font tags hier wel zou hebben geholpen, maar het toont wel aan dat zelfs de groten onder ons niet 1-2-3 een 'layout verwisselen'.

Het aanpassen van een CSS layout is veel makkelijker dan het aanpassen van een table layout - mits die CSS layout "goed" opgezet is. Dat betekent niet dat het aanpassen van een CSS layout makkelijk is - dat betekent slechts wat het zegt: dat het makkelijker is dan een table layout aanpassen.

Als je grafische onderdelen gebruikt, zul je inderdaad moeten gaan soepen om je layout te veranderen, of je nou tables of CSS gebruikt...

We spent about 30 minutes each, making minor markup tweaks to fix over-obvious imperfections. The results we shared with each other were impressive, but weren’t good enough given the rendering problems caused by differences in our underlying markup structure.

Slechts 30 minuten nodig hebben om stylesheets uit te wisselen van sites die qua structuur erg verschillend zijn, en dan een resultaat over te houden wat, hoewel niet goed genoeg, toch al een heel eind in de buurt komt.
Ik zou dit toch echt niet opvatten als teken dat het uitwisselen van CSS erg moeizaam gaat.

Schrik niet, het omvat het aanpassen van de originele Photoshop bestanden, het weglaten van menu-structuren, en het toepassen van obscure CSS hacks om het daadwerkelijk voor elkaar te krijgen.

Overdrijven is een kunst het 'aanpassen van de originele Photoshop bestanden' was alleen zodat ze nieuwe plaatjes konden maken met hun tijdelijke 'nieuwe' logo's.

[edit] ik moet wel zeggen dat de commentaren van Doug en Dave beiden erg verschillen.

[ Voor 7% gewijzigd door Not Pingu op 12-04-2004 15:52 ]

oh,when? schreef op 12 april 2004 @ 13:19:
Nu wil ik niet beweren dat het gebruik van Tables en font tags hier wel zou hebben geholpen, maar het toont wel aan dat zelfs de groten onder ons niet 1-2-3 een 'layout verwisselen'.

Dat is ook niet zo, maar zoals gezegd is het gewoon veel makkelijker. En wat ook handig is, is dat je je layout puur op css kan baseren. Dit betekent dus dat je maar 1 bestand hoeft aan te passen als je je layout update. Je zit in ieder geval niet meer met 10+ php-bestanden waarin je in functies moet gaan klooien omdat een ander design ook andere html vereist.

Zie bijvoorbeeld (heb 'm hierboven ook genoemd): http://www.csszengarden.com/
Je hoeft dus niet meer in de html/php/whatever te kutten, maar je zit met een css-bestandje. Het is in ieder geval een stuk _overzichtelijker_.

Ik vraag me af hoe moeilijk het voor hun was geweest als ze met zn tweeen een gestandaardizeerde XML-structuur hadden gebruikt. Dan zou het waarschijnlijk al een stuk simpeler zijn geweest. Ik weet bijna zeker dat je met een table-based structuur toch wel meer dan een half uur bezig bent hoor...

@Chris: als je een goed PHP Framework heb en logic scheidt van weergave, dan is dat geen enkel probleem. CSS heeft voordelen hoor, dat wel

Verwijderd schreef op 12 april 2004 @ 17:12:
@Chris: als je een goed PHP Framework heb en logic scheidt van weergave, dan is dat geen enkel probleem. CSS heeft voordelen hoor, dat wel

Dan heb je het wel centraal, maar je bent alsnog je html aan het aanpassen, en ik weet uit ervaring dat dat gewoon veel meer werk is.

De voordelen die ik nu nog van table-based layouts zie:

Het is soms makkelijker in te zien hoe elementen zijn gepositioneerd.
Het is veel meer compatible met oudere browsers.

en voor sommige mensen zal het ook nog een voordeel zijn dat ze de techniek hiervan wel onder de knie hebben, maar van css nog niet. Dit is een non-argument imho.

Wow, kijk mij eens registreren op GoT en zowaar reageren op deze interressante discussie (die helaas al een tijdje dood was )

oh,when? schreef op 12 april 2004 @ 13:19:
Toch nog even op deze mooie paasdag reageren. Ik wil nog even teruggaan naar de mensen die roepen dat met CSS je website in 1 keer omgezet kan worden naar een andere layout. Dave Shea en Doug Bouwman hebben op 1 april een grap uitgehaald door de layouts van hun sites te verwisselen. Beide zijn vooraanstaande developers in de 'Webstandards' community ( om het maar ff samen te vatten ) en gebruiken dan ook XHTML en CSS compliant websites.

Appeltje eitje zou je denken toch? 1 keer de stylesheet verwisselen en je bent klaar.

Niets is minder waar, zowel Dave als Doug beschrijven hoe ze deze grap hebben uitgehaald. Schrik niet, het omvat het aanpassen van de originele Photoshop bestanden, het weglaten van menu-structuren, en het toepassen van obscure CSS hacks om het daadwerkelijk voor elkaar te krijgen.

Nu wil ik niet beweren dat het gebruik van Tables en font tags hier wel zou hebben geholpen, maar het toont wel aan dat zelfs de groten onder ons niet 1-2-3 een 'layout verwisselen'.

Ja, leuk verhaal. Maar je schetst eigenlijk een heel verkeerd beeld, m.i.

Dave en Doug hebben twee sites waarbij hun gekozen HTML sturctuur zeer verschilt, op sommige punten (Mezzoblue's navigatie is vele malen complexer en anders samengesteld dan die van StopDesign). Toch hebben die twee elkaars layout met "minimal effort" kunnen switchen. Tuurlijk moet je de photoshop bestanden aanpassen - ze namen elkaars logo ook over qua stijl, maar gebruikten desondanks nog wel hun EIGEN logo. Dat is een redesign kwestie.

Al met al zijn de twee heren niet lang bezig geweest.

En NU ga je vergelijken met hoe dat zou zijn geweest in het geval van table-based layouts. Daar zou zo'n redesign (want dat is het in principe gewoon) enkele dagen zoniet weken hebben gekost.

Vaak is het zo dat wanneer een bedrijf, gemeente, school of wat dan ook, hun site vernieuwt, het enkele weken kost om alle pagina's om te zetten naar het nieuwe design. Dit omdat elke pagina vol staat met inline opmaak, gemaakt is met tables zodat alles perfect in het design paste, etc.
Door een goede scheiding te maken van content, structuur en opmaak, kan je oneindig veel flexibeler spelen met elk van de drie. De CSS Zen Garden is een vaak-genoemd voorbeeld, simpelweg omdat het ook het perfecte voorbeeld is van de onvoorstelbare kracht van CSS.

Stel, je bent een bedrijf dat heel erg inspeelt op huidige trends en moderne zaken en alles. Je site geef je een redesign elke 12 maanden om bij te blijven en trendy te blijven. Met tables zouden de webdevelopers en designers, afhankelijk van de grootte van de site, minstens een week of twee bezig zijn, elke keer, om deze klus te klaren. Sure, dat brengt voor de site-ontwikkelaar lekker geld in het laadje, maar voor jou is dat eigenlijk niet zo fijn.
Met een goed-voorbereide, goed-gestructureerde site heb je in theorie vaak slechts 2 dagen nodig om de klus te klaren, waarbij een groot deel van de tijd opgaat aan het maken van het nieuwe Design. Dat is voor jou als bedrijf veel aantrekkelijker, en stelt je zelfs in staat om zonder veel geld kwijt te zijn, elke 6 maanden ipv. elke 12 je site te redesignen.

Mezzoblue en Stopdesign waren in principe slechts een ruim half uur bezig met het belangrijke werk (Photoshop zut moet je niet meetellen, dat is design en heeft niks met XHTML, CSS en goede structuur te maken).

Beeld je nu eens in dat bijvoorbeeld www.yahoo.com en www.msn.com ditzelfde grapje zouden uithalen. Die zijn echt niet in 30 minuten klaar hoor, en ook niet in 60 minuten. Alleen via knippen en plakken kan je die twee voorpagina's enigszins snel van layout wisselen, maar dan nog ben je 30+ minuten bezig, en dat is slechts 1 enkele pagina die je dan gedaan hebt. NIET je hele site van een paar honderd tot paar duizend pagina's. En bij een MSN en Yahoo switch hou je ECHT niks meer van elkaars HTML structuur behouden. Bij Mezzoblue en Stopdesign was dat voor 99% wel zo (alleen dat menu van Mezzoblue was een echt heikel punt, maar goed).

Wereldje van verschil.

Tuurlijk, ook met CSS en goede XHTML ben je niet in 5 minuten klaar met een volledig nieuw design voor je site, maar als je de hoeveelheid tijd, werk en dus kosten goed gaat vergelijken, dan kan je niet anders dan inzien dat je met XHTML/CSS en een goed geschreven structuur, veel sneller, makkelijker en goedkoper klaar bent.

Poehee, sorry voor de rant.

Uitzonderingen zijn leuk:

http://mezzoblue.com/arch...5/15/tables_oh_th/#000585

Blue-eagle schreef op 18 mei 2004 @ 16:26:
Uitzonderingen zijn leuk:

http://mezzoblue.com/arch...5/15/tables_oh_th/#000585

Er is een groot verschil tussen een website die 1 tabel gebruikt om bijvoorbeeld een aantal kollomen te maken en een website die meteen kleur informatie erin zet en dingen als border dikte en kleur, of nog erger, websites die er een grote tagsoup van maken met geneste tables in geneste tables in geneste tables.

Verwijderd schreef op 18 mei 2004 @ 15:37:

Je bent nu ook een relatief kleine site gericht op één type content aan het vergelijken met een portal size website Dat is ook een wereld van verschil.

Waar het owen ook om ging was niet de hoeveelheid tijd die je kwijt bent met een redesign, maar wel dat je zoals zoveel zealots beweren met 1 stylesheet je hele site kunt wijzigen, en dat in de praktijk blijkt dat voor commerciele projecten ook de inhoud zodanig wijzigt dat een stylesheet wijziging ook een andere richting krijgt.

Verder geven zelfs de groten indirect aan dat het te ver gaat met het hele onderwerp, vandaar ook mijn signature. Eerst nadenken, dan doen

Ik lees heel vaak dat tabellen "not done" zijn voor opmaak, dus 2 vraagjes:

1 - Waarom niet?
2 - Zie bv. de Ati.com website, die stikt van de tabellen. Stel dat ik diezelfde layout wil maken, met (denk ik) CSS, waar moet ik beginnen? Iemand een link naar een goede HOWTO ofzo?

Ten eerste gebruik je een element waarvoor het bedoelt is, een tabel is niet voor layout doeleinde bedoelt.
Ten tweede heb je bij een tabel based layout vaak een erge tag soep, veranderingen daarin zijn complex (vooral geneste tabellen).

Op alistapart.com kan je leuke dingen vinden qua css, maar surf wat rond, er is zat over.

Verwijderd schreef op 18 mei 2004 @ 16:36:
[...]
Je bent nu ook een relatief kleine site gericht op één type content aan het vergelijken met een portal size website Dat is ook een wereld van verschil.

Waar het owen ook om ging was niet de hoeveelheid tijd die je kwijt bent met een redesign, maar wel dat je zoals zoveel zealots beweren met 1 stylesheet je hele site kunt wijzigen, en dat in de praktijk blijkt dat voor commerciele projecten ook de inhoud zodanig wijzigt dat een stylesheet wijziging ook een andere richting krijgt.

Verder geven zelfs de groten indirect aan dat het te ver gaat met het hele onderwerp, vandaar ook mijn signature. Eerst nadenken, dan doen

Mijn enige punt, wat ik trachtte duidelijk te maken en wat nog steeds volledig overeind staat, is dat het wel degelijk veel tijd, moeite en (dus) geld kan schelen om goed-geschreven XHTML met CSS-layouts te gebruiken ipv. Tables voor de layout en alles op de ouderwetse manier blijven doen. Owen deed voorkomen dat dat niet zo was en dat het zelfs "de groten" in de CSS-wereld er 'moeite' mee hebben om dat in 1 keer te bewerkstelligen, maar dat is dus echt niet het geval.

Tha's all

Verwijderd schreef op 18 mei 2004 @ 17:10:
[...]


Mijn enige punt, wat ik trachtte duidelijk te maken en wat nog steeds volledig overeind staat, is dat het wel degelijk veel tijd, moeite en (dus) geld kan schelen om goed-geschreven XHTML met CSS-layouts te gebruiken ipv. Tables voor de layout en alles op de ouderwetse manier blijven doen. Owen deed voorkomen dat dat niet zo was en dat het zelfs "de groten" in de CSS-wereld er 'moeite' mee hebben om dat in 1 keer te bewerkstelligen, maar dat is dus echt niet het geval.

Tha's all

Ja hallo, laten we alles wel eventjes reeel houden En ja de groten hadden er wel moeite mee, ik heb er toch redelijk veel van meegekregen om het zo te zeggen

Ja, ze hadden er moeite mee. Nee, tables gebruiken is niet beter, het is en blijft gewoon veel makkelijker met XHTML en CSS dan met tables. Simpel toch? Waarom blijf je nou doorhameren?

[ Voor 3% gewijzigd door Verwijderd op 18-05-2004 17:30 ]

Verwijderd schreef op 18 mei 2004 @ 17:10:
[...]
Owen deed voorkomen dat dat niet zo was en dat het zelfs "de groten" in de CSS-wereld er 'moeite' mee hebben om dat in 1 keer te bewerkstelligen, maar dat is dus echt niet het geval.

Zonder dat het een wellus-nietus verhaal gaat worden...dat heb ik nooit beweerd en nooit de intentie gehad om dat te suggereren. Verder vindt ik deze discussie nogal verloren moeite. Ik heb al mijn punten ooit al eens vermeld, ik sta open voor suggesties, maar om elke maand mijn punten te verdedigen tegen mensen die net komen kijken in dit wereldje heb ik eerlijk gezegd geen zin an, ik heb genoeg ander werk te doen. Hiermee doel ik dus op de mensen die het licht hebben gezien in XHTML en/of CSS en dit krampachtig bij elke post moeten vermelden.

Dionysus007281 schreef op 18 mei 2004 @ 16:38:
Ik lees heel vaak dat tabellen "not done" zijn voor opmaak, dus 2 vraagjes:

1 - Waarom niet?
2 - Zie bv. de Ati.com website, die stikt van de tabellen. Stel dat ik diezelfde layout wil maken, met (denk ik) CSS, waar moet ik beginnen? Iemand een link naar een goede HOWTO ofzo?

2 - kijk hier eens: http://www.cssref.be/cursus/cursus.asp. Wellicht niet de allerbeste tutorials, maar je komt er al een heel eind mee. Check ook deze site eens: http://www.handleidinghtml.nl/css/inhoud-css.html.

Ikzelf heb altijd met tables gewerkt, en sinds kort ben ik overgestapt op XHTML/CSS. Het gaat me nog niet allemaal even goed af, en ik betwijfel of je een compleet nieuw design voor je site kunt maken zonder aan de HTML te hoeven komen (niet iedereen is zo'n CSS expert als de mensen van CSS Zen), maar vooralsnog vind ik het erg mooi om zulke compacte en nette code te hebben. Daarnaast laden je pagina's wat sneller (aangezien het style bestand slechts één keer gedownload hoeft te worden en dan in de chache van je browser staat), is het makkelijker om wat veranderingen in de lay-out door te voeren, en is je website beter compatible met niet-grafische browsers.

Overigens bereik je veel van deze effecten ook door slechts één HTML pagina te maken met de hele lay-out, en via php-include de afzonderlijke pagina's steeds in deze lay-out te laten laden. Ik zie niet echt in wat hier verkeerd aan zou zijn (behalve dat het wellicht niet al te best zal zijn voor je positie bij zoekmachines), maar ergens heb ik het gevoel dat veel mensen hier toch bezwaar tegen hebben.

[ Voor 6% gewijzigd door Verwijderd op 18-05-2004 17:50 ]

[b]Verwijderd schreef op 18 mei 2004 @ 17:48

Troost je, voor Zen heb je geen ultieme CSS skills nodig, de hoeveelheid content en complexiteit ervan in een Zen template is heel minimaal, en is leuk om de kracht van CSS te laten zien, maar meer ook niet.

Ik ben tegenwoordig bezig met behoorlijke complexe datastructuren icm xhtml en css en daarbij komt wel wat meer kijken dan ZenGarden, maar weet wel dat dit veel meer tijd kost om te ontwikkelen dat de table based layout. Je loopt tegen diverse zaken aan die je normaliter bij een basic template niet tegenkomt maar waarbij je in css al je hacks en tricks uit de kast moet halen.

Het uiteindelijk resultaat haal je altijd, maar voordat het zover is loop je op tegen onvoorspelbaar gedrag, en ja meestal is dit in MSIE, maar wat verwacht je ook bij een browser die zo oud is. Vind het eerder knap dat het allemaal nog te halen is in MSIE, hetzij met wat sloppy hacks.

Ik had laatst nog een site gemaakt voor een klant, met mn CMS, en ik hoefde slechts 1 template aan te passen qua HTML. De rest van de default HTML kon ik laten zoals het was, enkel de CSS was echt anders. Leuke was nog wel dat het in IE allemaal ook gewoon meteen werkte, behalve IE 4 (die position: niet kent...)

CrashOne schreef op 18 mei 2004 @ 16:44:
Ten eerste gebruik je een element waarvoor het bedoelt is, een tabel is niet voor layout doeleinde bedoelt.
Ten tweede heb je bij een tabel based layout vaak een erge tag soep, veranderingen daarin zijn complex (vooral geneste tabellen).

Op alistapart.com kan je leuke dingen vinden qua css, maar surf wat rond, er is zat over.

Het argument dat je elementen moet gebruiken waarvoor ze bedoeld zijn vind ik een non-argument. De meest geniale doorbraken in de techniek en wetenschap zijn juist voortgevloeid uit juist het gebruiken van een bekend element op een compleet nieuwe manier, die totaal niet de originele bedoeling was.

Radio bijvoorbeeld, was in eerste instantie "bedoeld" voor draadloze communicatie op afstand. De eerste radiotechnici zouden iemand voor compleet voor gek verklaren die het over radio-uitzendingen zou hebben, waarna geluisterd wordt met behulp van radio-ontvangers waarmee niet uitgezonden kan worden. Maar toch is dat de basis voor onze huidige media. De geschiedenis staat boorde(n?)vol van dat soort voorbeelden.

Als je bijvoorbeeld PHP gebruikt om de content in een template te laden, kan je zonder enige problemen een tabellensoep site maken die vrij makkelijk om te zetten is. Content en layout is immers via een andere techniek gescheiden, waardoor je de content niet hoeft aan te passen. Op mijn persoonlijke website, http://eaglestorm.net, gebruik ik die techniek. Ik zie niet in waarom dat fout zou zijn...

Op zich zit daar wel een kern van waarheid in internet was ooit gruwelijk lelijk, totdat die table tag geintroduceerd werd en men erachter kwam dat die goed te misbruiken was om niet alleen tabulaire data op te maken, maar ook designs om te zetten naar mooie sites. Tot een zekere hoogte heeft dat ertoe bijgedragen dat Internet ueberhaupt populair is geworden, want lelijke dingen kijkt niemand graag lang tegenaan. En echt mooi is iets niet te maken als je alleen maar dingen onder elkaar kan zetten.

Maar een non-argument is het imo niet. Toen was er geen alternatief. Nu is dat alternatief er wel (ook al is het misschien niet perfect, maar dat is de table ook niet). De table heeft z'n tijd gewoon gehad, de mogelijkheden (ook buiten het oorsponkelijke doel) zijn allemaal al lang gevonden en uitgekauwd, en nu is het de beurt aan buiten getrede paden denkende mensen om de (al dan niet "onbedoelde") mogelijkheden van CSS te vinden die met tables simpelweg onmogelijk zijn.

Daar zijn er zat van, en die zijn nog lang niet allemaal gevonden. CSS is niet alleen een visuele techniek, je kan er ook functionele/interactieve dingen mee doen.

Clay schreef op 19 mei 2004 @ 12:35:
Op zich zit daar wel een kern van waarheid in internet was ooit gruwelijk lelijk, totdat die table tag geintroduceerd werd en men erachter kwam dat die goed te misbruiken was om niet alleen tabulaire data op te maken, maar ook designs om te zetten naar mooie sites. Tot een zekere hoogte heeft dat ertoe bijgedragen dat Internet ueberhaupt populair is geworden, want lelijke dingen kijkt niemand graag lang tegenaan. En echt mooi is iets niet te maken als je alleen maar dingen onder elkaar kan zetten.

Maar een non-argument is het imo niet. Toen was er geen alternatief. Nu is dat alternatief er wel (ook al is het misschien niet perfect, maar dat is de table ook niet). De table heeft z'n tijd gewoon gehad, de mogelijkheden (ook buiten het oorsponkelijke doel) zijn allemaal al lang gevonden en uitgekauwd, en nu is het de beurt aan buiten getrede paden denkende mensen om de (al dan niet "onbedoelde") mogelijkheden van CSS te vinden die met tables simpelweg onmogelijk zijn.

Daar zijn er zat van, en die zijn nog lang niet allemaal gevonden. CSS is niet alleen een visuele techniek, je kan er ook functionele/interactieve dingen mee doen.

Goed, dus is er een alternatief. En inderdaad is het een goed alternatief, dat ik voor mijn nieuwere sites ook gebruik: CSS2. Maar waarom zou ik mijn goed functionerende oude tabellensites ombouwen tot CSS2sites? Ik heb wel zinnigere dingen te doen in mijn vrije tijd

Er zijn vele alternatieven voor diesel en benzine als autobrandstof: LPG, aardgas, plantaardige dieselolie, brandstofcellen, etc. Maar vrijwel niemand gebruikt ze. Er bestaat de Motionless Electromagnetig Generator, die alomaanwezige magnetische winden gebruikt om een inputstroom te versterken (een soort van windmolen zegmaar, maar dan electromagnetisch), resulterend in gratis electriciteit - een gratis booster die in vrijwel elke mogelijke bestaande electriciteitsgenerator ingezet zou kunnen worden - maar nog nergens wordt deze (overigens redelijk recente) techniek grootschalig, of ook maar kleinschalig, toegepast.

Mx. Alba schreef op 19 mei 2004 @ 12:50:
Er zijn vele alternatieven voor diesel en benzine als autobrandstof: LPG, aardgas, plantaardige dieselolie, brandstofcellen, etc. Maar vrijwel niemand gebruikt ze. Er bestaat de Motionless Electromagnetig Generator, die alomaanwezige magnetische winden gebruikt om een inputstroom te versterken (een soort van windmolen zegmaar, maar dan electromagnetisch), resulterend in gratis electriciteit - een gratis booster die in vrijwel elke mogelijke bestaande electriciteitsgenerator ingezet zou kunnen worden - maar nog nergens wordt deze (overigens redelijk recente) techniek grootschalig, of ook maar kleinschalig, toegepast.

De voorbeelden die jij schetst zijn niet echt relevant voor de Standaarden-discussie. Toepassen van een alternatieve aandrijving voor auto's heeft wat meer voeten in aarde dan het gebruiken van webstandaards in een website. Het gebruiken van een standaard kost, als je ze eenmaal kunt toepassen, geen geld en vereist ook geen verandering van de infrastructuur.

Mx. Alba schreef op 19 mei 2004 @ 12:50:
[...]


Goed, dus is er een alternatief. En inderdaad is het een goed alternatief, dat ik voor mijn nieuwere sites ook gebruik: CSS2. Maar waarom zou ik mijn goed functionerende oude tabellensites ombouwen tot CSS2sites? Ik heb wel zinnigere dingen te doen in mijn vrije tijd

Er zijn vele alternatieven voor diesel en benzine als autobrandstof: LPG, aardgas, plantaardige dieselolie, brandsto....

Dat er een alternatief is betekent dat wanneer je wat nieuws gaat maken dat je meerdere keuzes hebt (en onderzoek doet, afwegingen maakt), niet dat je met terugwerkende kracht alles moet gaan lopen ombouwen.

DiMension schreef op 19 mei 2004 @ 13:00:
De voorbeelden die jij schetst zijn niet echt relevant voor de Standaarden-discussie. Toepassen van een alternatieve aandrijving voor auto's heeft wat meer voeten in aarde dan het gebruiken van webstandaards in een website. Het gebruiken van een standaard kost, als je ze eenmaal kunt toepassen, geen geld en vereist ook geen verandering van de infrastructuur.

Het compleet ombouwen van een bestaande site, bijvoorbeeld van HTML + Tables naar XHTML + CSS, heeft net zoveel voeten in de aarde als bijvoorbeeld het inbouwen van een LPG-installatie in een auto, of het toevoegen van een MEG-module aan een bestaande electriciteitscentrale.

Om dat laatste voorbeeld te nemen, kan je door de uitbreiding van een bestaande electriciteitscentrale met een MEG-module, door een éénmalige investering, de output van die centrale permanent verdubbelen (om een arbitrair getal te pakken). Daar is geen enkele verandering van de bestaande infrastructuur voor nodig.

Clay schreef op 19 mei 2004 @ 13:53:
Dat er een alternatief is betekent dat wanneer je wat nieuws gaat maken dat je meerdere keuzes hebt (en onderzoek doet, afwegingen maakt), niet dat je met terugwerkende kracht alles moet gaan lopen ombouwen.

Eens.

Zie bijvoorbeeld (heb 'm hierboven ook genoemd): http://www.csszengarden.com/
Je hoeft dus niet meer in de html/php/whatever te kutten, maar je zit met een css-bestandje. Het is in ieder geval een stuk _overzichtelijker_.

Die site is niet echt representatief. Ik erger me aan het "kijk hoe ultiem en probleemloos CSS is" terwijl CSS door elke browser er weer anders uitziet (overdrijving). Het kost me heel wat tijd om iets gecompliceerds in Safari 1.2, IE6, Opera7 en Firefox er hetzelfde uit wil laten zien. Met tabellen is dat veel minder lastig.

Waarom CSSzengarden IMO schijnheilig () is:

• Er zitten allemaal overbodige tags in die enkel bedoeld zijn voor opmaak-doeleinden die bij veel skins overbodig zijn. Dat is even incorrect als een tabelletje hier en daar.

  <!-- These extra divs/spans may be used as catch-alls to add extra imagery. -->

• De helft van de skins gebruikt achtergrondplaatjes voor de headers, wat bij een dynamische pagina onmogelijk is.
• De inhoud/structuur is totaal niet gecompliceerd en het gemak van een redesign is daardoor niet hetzelfde voor een grote site die veel informatie tegelijk op een pagina weergeeft.
• CSSzengarden bevat geen <img> tags, terwijl die tag in veel gevallen nog onmisbaar is. Je kan dat wel allemaal wegwerken met ingenieuze CSS maar dat neigt dan toch naar instabiele CSS hacks. Je moet dus alsnog allemaal plaatjes vervangen wat niet kan met CSS (helaas ).

Blaise
[...]
Die site is niet echt representatief. Ik erger me aan het "kijk hoe ultiem en probleemloos CSS is" terwijl CSS door elke browser er weer anders uitziet (overdrijving). Het kost me heel wat tijd om iets gecompliceerds in Safari 1.2, IE6, Opera7 en Firefox er hetzelfde uit wil laten zien. Met tabellen is dat veel minder lastig.

Dat is maar deels waar. CSS heeft ook problemen en eigenaardigheden, maar het is net zo hard een kweste van kennisniveau. Persoonlijk vind ik CSS niet lastiger dan tables.

Waarom CSSzengarden IMO schijnheilig () is:
[list]
• Er zitten allemaal overbodige tags in die enkel bedoeld zijn voor opmaak-doeleinden die bij veel skins overbodig zijn. Dat is even incorrect als een tabelletje hier en daar.

Klopt. Helemaal zuiver op de graad is het niet. Maar het geeft wel duidelijk aan dat het ueberhaupt kan.

• De helft van de skins gebruikt achtergrondplaatjes voor de headers, wat bij een dynamische pagina onmogelijk is.

In die zin dat wanneer je er tekst inzet wel ja. Alhoewel je dat voor b.v. een aantal hoofdcategorien dat niet zo aan verandering onderhevig is best kan doen trouwens. En een tilende deco background waar dan verder gewone tekst overheen staat kan natuurlijk helemaal prima.

• De inhoud/structuur is totaal niet gecompliceerd en het gemak van een redesign is daardoor niet hetzelfde voor een grote site die veel informatie tegelijk op een pagina weergeeft.

In de praktijk zul je bij een redesign ueberhaupt vaak alles opnieuw gaan doen. Functionaliteit en informatiearchitectuur zijn dan immers net zo vaak aan een "redesign" onderhevig, aangezien je een redesign niet zomaar gaat doen om enkel dezelfde dingen er anders uit te laten zien. Je boodschap komt misschien niet goed over, en je gaat de informatie die je biedt op andere manieren toegankelijk maken om iedere (sub)doelgroep op een gepaste manier aan te kunnen spreken. Dat zal dus inderdaad vaak betekenen dat je markup niet meer voldoet.
Skinnability is een heel ander verhaal, en dat laat CSSZenGarden imo ontzettend goed zien. Maar zowel redesign als skinnen zijn ook maar onderdelen van CSS, die je bovendien in de praktijk ook amper toepast. Er is veel op aan te merken en het is idd niet perfect, maar het is dus alles behalve het kernpunt van het bestaan van CSS.

• CSSzengarden bevat geen <img> tags, terwijl die tag in veel gevallen nog onmisbaar is. Je kan dat wel allemaal wegwerken met ingenieuze CSS maar dat neigt dan toch naar instabiele CSS hacks. Je moet dus alsnog allemaal plaatjes vervangen wat niet kan met CSS (helaas ).[/list]

Het is misschien vloeken in de kerk, maar ik wil graag de discussie aangaan dat de <img /> tag ook helemaal niet bedoeld is voor designs van een site, en daar zelfs zwaar ongeschikt voor is. Dat het wegwerken van die <img /> tag tot instabiele CSS hacks leidt is een vooroordeel dat ik niet deel. Veel van die zogenaamde hacks zijn schitterende staaltjes van stabiele en betrouwbare CSS waar niets engs aan is, en worden in de toekomst net zo ingeburgerd en geaccepteerd als het misbruiken van tables voor layout, met als verschil dat het een gebruik van de techniek is waar die wel voor bedoeld is.

Onbekend maakt onbemind Ligt een beetje in het verlenge van:

De table heeft z'n tijd gewoon gehad, de mogelijkheden (ook buiten het oorsponkelijke doel) zijn allemaal al lang gevonden en uitgekauwd, en nu is het de beurt aan buiten getrede paden denkende mensen om de (al dan niet "onbedoelde") mogelijkheden van CSS te vinden

Het is misschien vloeken in de kerk, maar ik wil graag de discussie aangaan dat de <img /> tag ook helemaal niet bedoeld is voor designs van een site, en daar zelfs zwaar ongeschikt voor is. Dat het wegwerken van die <img /> tag tot instabiele CSS hacks leidt is een vooroordeel dat ik niet deel.

Dat ben ik met je eens, en ik vind het zelfs geen "vloeken in de kerk". Ik doelde zelf op plaatjes die content aanduiden zoals smiles en "dit is mijn kat" (had ik moeten zeggen, ja ).

Bij een redesign maar vooral skinnable site zullen plaatjes niet in alle layouts passen (als je oude content wil bewaren). Door het gebrek aan content-plaatjes in zengarden lijkt het net alsof het allemaal zo ultiem werkt.

Bij het maken van mijn skinnable site stuitte ik echter een paar keer op dat probleem. Zo kon bijvoorbeeld de achtergrond niet te donker omdat de .gif anti-aliasing (of gebrek daaraan?) dan zichtbaar werd.

Ik schop hem weer omhoog uit de vochtige, duistere kelders van /13. Sprak laatst met mijn goede concollega's @ Lost Boys want een site van hun viel me op: http://www.vaya.nl/vaya/

check de sourcecode eens...zit gestructureerd en heel netjes in elkaar.

"...we leveren nog louter XHTML 1.0 op..."

Dus het kan wel

Het is valid XHTML ja, maar semantisch kan het allemaal nog veel beter. Overal gebruiken ze div's en span's, in plaats van headers en paragraphs en lists etc.

De sourcecode is een beetje op driekwart blijven steken. Het heeft er alle schijn van dat de author(s) de klok wel hebben horen luiden maar niet weten waar de klepel hangt.

Dat er een XHTML doctype staat wil nog niet zeggen dat het ook XHTML is. En hoe 'dieper' (meer genest) je een div element tegenkomt, hoe meer je er vanuit kunt gaan dat deze onnodig wordt gebruikt. Syntactisch gezien is het geen XHTML of HTML, dit is alleen te parsen met een parser die wel een beetje vergevingsgezind is.

Ik vind het niet veel bijzonders dus. Ja, het kan op zich wel, maar dan moet je dus eerst zorgen dat je weet wat je doet. Helaas zijn de Boys dus nog steeds een beetje Lost

Verwijderd schreef op 03 september 2004 @ 11:45:
Helaas zijn de Boys dus nog steeds een beetje Lost

Ondanks kunnen een aantal dingen wel beter (semantiek), ben ik ook benieuwd of de 'Boys' daar uberhaupt over nadenken of bewust hiervoor kiezen (al dan niet vanuit een CMS die dit uitpoept).

[ Voor 9% gewijzigd door BtM909 op 03-09-2004 12:00 ]

Opera 7.6, identify as Opera: http://www.vaya.nl/vaya/browsermelding.html

Ze zijn m.i. nog definitely lost, en je wordt notabene nog onload op deze manier geredirect nadat je eerst gewoon de pagina zag:



hoe vaak moet ik nog roepen dat location een property van het window object is?...

Verwijderd schreef op 03 september 2004 @ 12:15:
* Anne ziet 660 fouten....

Ik vraag me af of ze niet beter voor HTML hadden kunnen gaan.

Nee, de validator zegt dat. En als je 1 echte fout in je pagina hebt maakt de validator daar wel eens meer van omdat dan andere dingen ook niet kloppen

André schreef op 03 september 2004 @ 12:25:
Nee, de validator zegt dat. En als je 1 echte fout in je pagina hebt maakt de validator daar wel eens meer van omdat dan andere dingen ook niet kloppen

Of doordat je dezelfde fout 660 keer maakt

Dus alle kommaneukers hier vinden dit niet een stap in de goede richting?

* oh,when? zijn petje valt af...

Op projecten van deze schaal ben ik iig blij dat deze stap gezet wordt. Van de grote webbouwers in Nederland lopen ze redelijk voorop. ik moet zelf toegeven dat wij bij Clockwork nog niet op dit nivo zitten. Ik doel hier met name op de grote webbouwers ( > 80 man ) omdat ik weet hoeveel moeite het kost om in een grote organisatie waarbij vaak meerdere partijen betrokken zijn, iedereen op 1 lijn te krijgen, en omdat het hier gaat om grote klussen waarbij de ordergrootte vaak boven een ton zitten en waarbij juist zoiets het toepassen van webstandaarden niet ter sprake komt ( als je echt geen argumenten hebt, verschuil je je maar achter standaarden nietwaar )

Wat ik me dan wel afvraag, wat vindt de 'Web standards' politie hier dan wel een acceptabel nivo?

oh,when? schreef op 03 september 2004 @ 12:59:
Wat ik me dan wel afvraag, wat vindt de 'Web standards' politie hier dan wel een acceptabel nivo?

Als het hele ontwikkelteam dagenlang gaat lopen prutsen en miereneuken over semantische punten, en zo de marge erdoorheen jaagt. Ik hoor de opmerkingen al komen..... stampede! .. wheeheehee dat hoeft helemaal niet zoveel tijd te kosten, kost zelfs minder tijd, en geld, en is sneller, en, en, en.. toen was er een ontwikkelteam dat moet samenwerken,... anyone ook ervaring hiermee?

Ik vind die code er niet zo slecht uitzien, overigens. Als je over alle miniscule zaken gaat dwarsliggen komt een project van dergelijk formaat nooit af. En we weten allemaal dat elke zelfrespecterende web developer tijd overhoud om tijdens het schijten op de plee de w3c pocket editie open te slaan

Nu serieus, ik vind het een mooi resultaat kan niets anders zeggen, alleen op usability vlak zie ik nog wat verbeteringen.

oh,when je hebt helemaal gelijk. Tuurlijk valt er ontzettend veel op zo'n site aan te merken; er heeft tenslotte niemand van /13 aan gewerkt Dat neemt niet weg dat het goed is van Lost Boys om deze weg in te slaan. Executie zal van project tot project beter worden.

oh,when? schreef op 03 september 2004 @ 12:59:
Dus alle kommaneukers hier vinden dit niet een stap in de goede richting?

* oh,when? zijn petje valt af...

* André zet petje terug

Het is zeer zeker wel een stap in de goede richting, dat ben ik helemaal met je eens. Nu staat de weg open voor de volgende stappen

oh,when? schreef op 03 september 2004 @ 12:59:
Dus alle kommaneukers hier vinden dit niet een stap in de goede richting?

* oh,when? zijn petje valt af...

Jij hebt het over XHTML terwijl het geen XHTML is. Het is zelfs geen juist toegepaste HTML. Wat je van 'onze' kant hoort is geen mening, zuiver een vaststelling van feiten. Als je die feiten niet kent moet je het onderwerp ook niet ter sprake brengen, vind ik.

Met zoveel mensen zou je zeggen dat er toch wel voldoende kennis in huis moet zijn. Je hebt dan ongetwijfeld specialisten die de layout en markup in elkaar zetten. Als iemand kan bedenken dat er geen tabellen gebruikt moeten worden voor een bepaald element had die persoon moeten weten dat div en span elementen niet veel toevoegen. Anders is het dus echt zonde van je tijd.

Het is een stap in de goede richting, maar voldoet nog niet aan de eisen om iets een goede (X)HTML pagina te kunnen noemen. Dat jij dat wel vindt. Tja, zoals ik al zei, dat is geen kwestie van een mening hebben. Het is niet zo. Feit.

Verwijderd schreef op 03 september 2004 @ 13:18:
oh,when je hebt helemaal gelijk. Tuurlijk valt er ontzettend veel op zo'n site aan te merken; er heeft tenslotte niemand van /13 aan gewerkt Dat neemt niet weg dat het goed is van Lost Boys om deze weg in te slaan. Executie zal van project tot project beter worden.

Ik hoop het.. het is een stap in de goede richting, maar ik vraag me af waarom ze dan 'half werk' doen.

_{offtopic: kreeg gister overigens een mailtje van je baas..}

Toegeven; het ziet er qua code gestructureerd uit, maar als je het bekijkt zonder stylesheet is het 1 grote puinhoop - over semantiek is dus niet echt nagedacht en dat is gewoon een gemiste kans.
Die browsercheck is het eerste wat eruit gesloopt dient te worden, want op dit moment sluit je alsnog groepen uit - niet dat de site werkbaar is in een screenreader, maar capabele browsers als Opera en Konquerer worden nu ook uitgesloten en dat is gewoon jammer.

Als ik de entity-fouten in de links weglaat hou ik nog een handjevol foutjes over; o.a. een lege UL-tag, INPUT-tags die niet afgesloten worden, 2x een dubbele ID, een verdwaalt BORDER-attribuut en een dubbel NAME-attribuut in een FORM-tag. Dat valt dus nog wel mee, en er is geen browser die daarover struikelt, maar zoals o.a. ook Cheatah terecht opmerkt is het vervangen van tables door div's en span's gewoon niet genoeg.

[ Voor 11% gewijzigd door crisp op 03-09-2004 13:38 ]

Verwijderd schreef op 03 september 2004 @ 13:38:
Behalve dat in je XHTML (als het goed gebruikt wordt) zo'n leuke XML Fatal error op je browser scherm krijgt als mensen niet juist omgaan met entiteiten.

Even een aanvulling hierop:
Om dit goed te kunnen testen moet je maar eens een Content-Type header meesturen die zegt dat het een document van het type application/xhtml+xml is. Bekijk de website met Firefox en je weet genoeg.

Verwijderd schreef op 03 september 2004 @ 13:44:
[...]

Even een aanvulling hierop:
Om dit goed te kunnen testen moet je maar eens een Content-Type header meesturen die zegt dat het een document van het type application/xhtml+xml is. Bekijk de website met firefox en je weet genoeg.

Op die manier doe ik het ook met mijn eigen site, ik vind dat een perfecte manier om te kijken of je doucment valide is. Ik vind ook dat de fout-tolerantie uit browsers gesloopt moet worden, zo scheid je het kaf van het koren.

Zodra dat gebeurt stapt de helft van alle mozilla/firefox gebruikers over op IE, welke natuurlijk nooit van zijn levens dagen mee doet.

Al lijkt het me een prachtig idee, een mooie stap richting een perfecte wereld.

André schreef op 03 september 2004 @ 13:46:
Op die manier doe ik het ook met mijn eigen site, ik vind dat een perfecte manier om te kijken of je doucment valide is. Ik vind ook dat de fout-tolerantie uit browsers gesloopt moet worden, zo scheid je het kaf van het koren.

Grote sites worden meestal niet uit één bron opgebouwd. Daar komen CMS'en, clicktrackers, ad-generators, weet ik wat voor rotzooi bij kijken. Vaak heeft de 'eigenaar' van een site geen directe controle over al die aspecten.

Verwijderd schreef op 03 september 2004 @ 13:38:
Het is uiteraard wel mooi dat ze ermee begonnen zijn, maar van zo'n groot bedrijf zou je kunnen verwachten dat er een stel client-side specialisten bijzaten.

Specialisten hebben ook maar 2 handen, en als er tig projecten liggen tja. Voor de rest ga ik ervanuit dat het project onder leiding van Lost Boys is gemaakt, en niet door Lost Boys omdat het overgrote deel van Lost Boys opdrachten ge-outsourced wordt, maar wellicht dat Owen daar wat meer van weet.

Wie weet zijn er speciale redenen geweest voor het opdelen in blokken van de source. Want dat is wat ze hebben gedaan als je goed kijkt. Wellicht dat een building block in het achterliggende systeem echt door div's werd gedefinieerd op zo de inhoud van een block vast te zetten zodat layout eromheen minder invloed heeft op de layout .

[ Voor 24% gewijzigd door Verwijderd op 03-09-2004 13:54 ]

* Clay heeft er al best wel respect voor hoor

Het kost best wat moeite om bij zeer grootschalige projecten als client side ontwikkelaar je stempel te drukken op de html die er door de applicatie uitgepoept gaat worden. Veel die hard serverside coders weten vaak a) niet hoe je "hoort" te htmllen, en b) kan het ze ook niet altijd even veel schelen.

Wat ik overigens wel grappig vind is de whitespace Zie ik het goed dat het java is? je kan uit whitespace de jstl / jsp / struts / wathetookis indents terugzien

Verwijderd schreef op 03 september 2004 @ 13:51:
[...]

Grote sites worden meestal niet uit één bron opgebouwd. Daar komen CMS'en, clicktrackers, ad-generators, weet ik wat voor rotzooi bij kijken. Vaak heeft de 'eigenaar' van een site geen directe controle over al die aspecten.

Klopt, ik liep met mijn lullige site'je al tegen zo'n probleem aan: De Nedstat teller doet het niet. Maar door het JS bestandje zelf lokaal te hosten en aan te passen doet hij het nu wel weer. Ik heb overigens Nedstat hiervan op de hoogte gebracht in een joekel van een mail: en ik kreeg een keurig antwoord terug dat ze dit interessant vinden en dit zeker in het achterhoofd gehouden zou worden.

Clay schreef op 03 september 2004 @ 13:52:
* Clay heeft er al best wel respect voor hoor

Het kost best wat moeite om bij zeer grootschalige projecten als client side ontwikkelaar je stempel te drukken op de html die er door de applicatie uitgepoept gaat worden. Veel die hard serverside coders weten vaak a) niet hoe je "hoort" te htmllen, en b) kan het ze ook niet altijd even veel schelen.

Daarom is het voor een goede html'ler ook noodzaak om de serverside taal te kunnen spreken/coden.

[ Voor 30% gewijzigd door André op 03-09-2004 13:56 ]

crisp: Opera 7.6, identify as Opera: http://www.vaya.nl/vaya/browsermelding.html

Zelf Firefox (0.9.3 op Linux) wordt doorgegestuurd naar deze pagina. Ik vraag me af wanneer het nu eindelijk eens aan de bezoeker zelf wordt overgelaten of hij een pagina kan zien of niet.

mbravenboer schreef op 03 september 2004 @ 13:59:
[...]

Zelf Firefox (0.9.3 op Linux) wordt doorgegestuurd naar deze pagina. Ik vraag me af wanneer het nu eindelijk eens aan de bezoeker zelf wordt overgelaten of hij een pagina kan zien of niet.

Tja, zodra pagina's op de goede manier gemaakt worden ben je geen browsercheck nodig omdat ze overal werken.