Standaarden (W3C, etc.)

[Clay]

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?

Je zou het ook om kunnen draaien, en b.v. beweren dat IE geen standaarden ondersteunt. Maar dat klinkt toch ook raar als je je dan bedenkt dat een groot deel van CSS1 het gewoon doet in IE, en met de herkenning van doctypes in IE6 ook redelijk volgens de specs. Het is niet alsof je nog in NS4 zit te hakken waar je niet eens het verschil tussen inline en block kan gebruiken; met 1 CSS file (zonder hacks, en met wat kennis van zaken) kan je in alle moderne browser en IE hetzelfde laten zien!

Het probleem van IE is dat 6 gewoon een upgrade van 5 is waar niet bijsterveel aan veranderd is, op grove bugs en wat nieuwere implementaties na. 5.0 zat bij win98 geloof ik, en 6 is nu zo'n 3 jaar oud? dan verbaast het me niet dat IE6 nog zo weinig kan. Maar ik geloof niet dat er bij MS onwil is om standaarden te ondersteunen, en/of dat ze hun eigen gaan bedenken.

IE7 zal hoe dan ook backward compatible moeten zijn met 6, en dus ondersteunen wat 6 nu kan. En waarom andere "standaarden" bedenken als er al goede zijn? Daar gaat bergen nodeloze tijd (en kosten) inzitten, waarna alle developers deze technieken nog een keer zouden moeten willen gaan leren. Het aandeel IE kan alleen nog maar achteruit gaan, dus als ze met iets totaal anders komen aanzetten snijden ze alleen zichzelf maar in de vingers

[Not Pingu]

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


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.

Nou weet ik verder niets van jullie werkwijze, maar een goede opbouw van source code is toch alleen in jullie voordeel? het lijkt mij zelfs vreemd dat je dat al niet meteen uit jezelf doet.
Als applicatieprogrammeur kun je het toch ook niet flikken om de meest slordige code op te leveren? Om de redenen dat het 1) goed te debuggen moet zijn en 2) andere mensen er ook mee aan de slag moeten kunnen. Datzelfde geldt toch voor webdesigners ook?

IMHO moet je zeker in een bedrijfstak als deze, die nog volop in ontwikkeling is, bereid zijn mee te gaan met nieuwe ontwikkelingen. Je klanten weten dan niet eens wat het belang van goede code is, maar dat de klant niet weet wat goed voor hem is, zou toch geen belemmering voor jou moeten zijn om hem toch een perfect product te leveren? Zo werk ik ook, en een site die sneller opbouwt en over het algemeen een stuk flexibeler te tweaken is, zorgt alleen maar voor meer tevredenheid bij je klanten.

[Verwijderd]

Gunp01nt schreef op 13 maart 2004 @ 13:44:
Nou weet ik verder niets van jullie werkwijze, maar een goede opbouw van source code is toch alleen in jullie voordeel? het lijkt mij zelfs vreemd dat je dat al niet meteen uit jezelf doet.
Als applicatieprogrammeur kun je het toch ook niet flikken om de meest slordige code op te leveren? Om de redenen dat het 1) goed te debuggen moet zijn en 2) andere mensen er ook mee aan de slag moeten kunnen. Datzelfde geldt toch voor webdesigners ook?

Ja en nee. Websites gaan over het algemeen minder lang mee dan applicaties, is mijn ervaring. Bovendien is het hergebruik van de oude code voor de nieuwe site maar zeer zelden een eis. Als dat al het geval is, gaat het meestal om business-logic en andere server-side dingen. Heldere sourcecode is fantastisch maar budgetten reiken maar zelden verder dan quick and dirty. Dan moet je HTML en CSS-gewijs behoorlijk sterk in je schoenen staan om voor de 'mooie' code te gaan.

IMHO moet je zeker in een bedrijfstak als deze, die nog volop in ontwikkeling is, bereid zijn mee te gaan met nieuwe ontwikkelingen. Je klanten weten dan niet eens wat het belang van goede code is, maar dat de klant niet weet wat goed voor hem is, zou toch geen belemmering voor jou moeten zijn om hem toch een perfect product te leveren? Zo werk ik ook, en een site die sneller opbouwt en over het algemeen een stuk flexibeler te tweaken is, zorgt alleen maar voor meer tevredenheid bij je klanten.

Dit is absoluut waar maar je gaat er van uit dat de ontwikkelaar die kennis heeft en/of veel tijd kan steken in zichzelf ontwikkelen. Dit is nou eenmaal gewoon niet zo. Voor mij persoonlijk is het ook een bepaalde 'beroepseer' om de klant het beste te leveren wat ik te bieden heb. Zelfs als die klant geen idee heeft van hoe geavanceerd de code is maar alleen kijkt naar hoe het werkt en hoe het eruit ziet.

Helaas is 'de voorkant' nog altijd een ondergeschoven kindje in deze bedrijfstak. De WYSIWYG-ers hebben voorlopig nog de overhand. De enige manier waarop de HTML beter zal worden gebruikt in sites is als de WYSIWYG tools beter worden.

[AkaXakA]

Het is natuurlijk leuk als een professioneel webdesign bedrijf iets mooi bouwt wat overal werkt, valideert, rekening houdt met iedereen en schone code eropna houdt.

In werkelijkheid ligt het een beetje moeilijker. Als een layout gewoon niet schaalt zonder tabellen zoals het moet, dan moet óf het design aangepast worden óf er moet met tabellen gewerkt worden. En áls dat laatste het geval is, dan zullen die tabellen tenminste met css aangestuurd moeten worden.

Het gaat er natuurlijk aan het einde van de dag om of de doelgroep een mooie site te zien krijgt...als die doelgroep blinden omvat, dan is moet je de hele site daarop aanpasssen, anders is het maar meegenomen.

Van een professioneel webdesign bedrijf is te verwachten dat ze een hele sloot verschillende templates voor layouts al liggen hebben die aangepast worden voor elke klus.

Als het gewenste design niet zonder tabellen (cross-browser) gemaakt kan worden (die zijn er nog zekerweten), dan moet dat maar. Ik vind dat je daar niet mensen over kan aanvallen.

Je kan ze natuurlijk wel duidelijk maken dat ze een cms ofzo behoren te gebruiken als ze klagen dat dingen niet zonder word/frontpage te beheren is. Een duidelijke cms voor inhoud in combinatie met css voor de stijl zal altijd veel beter werken dat wat voro frontpage oplossing dan ook.

[Verwijderd]

En weer worden ondersteuning en CSS door elkaar gehaald.

Wat jij trouwens op je site beschrijft, in Mondriaan Magazine oid kan al lang ( http://steve.pugh.net/test/test57.html ). Er was laatst ook een artikel door een NL op A List Apart geschreven daarover (vind persoonlijk test57 een stukje mooier).

Wellicht is het handig om eerst is onderzoek te doen voordat je begint af te geven op een bepaalde techniek.

Het gaat er natuurlijk aan het einde van de dag om of de doelgroep een mooie site te zien krijgt...als die doelgroep blinden omvat, dan is moet je de hele site daarop aanpasssen, anders is het maar meegenomen.

Ik snap deze niet helemaal.

Eigenlijk snap ik geen van de punten die je maakt echt, heb je misschien een aantal concrete voorbeelden oid?

[Verwijderd]

AkaXakA schreef op 13 maart 2004 @ 18:01:
Van een professioneel webdesign bedrijf is te verwachten dat ze een hele sloot verschillende templates voor layouts al liggen hebben die aangepast worden voor elke klus.

yak! dat meen je niet serieus hoop ik? Of ontwerp/bouw je zelf alles via een soort
"standaard" templates annex designs?

of is daar een cd-rommetje voor?

"uh ik zoek een layout zus en zo"

"ja dat staat op cd rom nr 35 ,.. templateje 87a"

edit:

ah ik lees net je ondertitel,.. zucht van verlichting

[ Voor 35% gewijzigd door Verwijderd op 13-03-2004 18:48 ]

[Verwijderd]

http://www.stijlstek.nl/a...waarom_webstandaarden.php

[Verwijderd]

Verwijderd schreef op 15 maart 2004 @ 08:52:
http://www.stijlstek.nl/a...waarom_webstandaarden.php

Wat een kutartikel. Er staan zaken opgesomd die de hele horde standaard geile developers roepen, er staan zaken in die nergens op slaan (zoals een table van 700px op je handheld .. , een div van 700px breed op je handheld dan?), dat je als je symantisch bezig bent je totaal niet meer in je achterhoofd hoeft te houden hoe de uiteindelijke look & feel eruit komt te zien.

Ook werkt het artikel de intentie dat je alleen als je met standaarden werkt, een gecachde css file kunt gebruiken, wat een crap.

Voor de rest schrijft hij/zij "

"Er hoeven op deze manier geen verschillende versies ontwikkeld te worden voor de verschillende browsers en andere apparaten."

En even later

"Omdat webstandaarden ervoor zorg dragen dat een pagina toegankelijk is (en als er bij de ontwikkeling rekening is gehouden met oudere, zwak-CSS capabele browsers) dan maakt het niet uit welke browser iemand gebruikt: de inhoud is altijd bereikbaar"

Hoezo elkaar tegenspreken. De eerste alinea geeft al direct voor mij aan dat de schrijver niet weet waar hij/zij over schrijft.

Standaarden zijn hardstikke mooi, maar verpak de boodschap niet in een artikel waarvan de schrijver denkt iets over het onderwerp te weten. Laat zo'n persoon aub asperges plukken ipv het woord verkeerd te verkondigen.

"Send to recyle bin"

[Spider.007]

Verwijderd schreef op 15 maart 2004 @ 10:11:
[...]

Wat een kutartikel. Er staan zaken opgesomd die de hele horde standaard geile developers roepen,

voorbeelden?

er staan zaken in die nergens op slaan (zoals een table van 700px op je handheld .. , een div van 700px breed op je handheld dan?),

Het punt wat daar wordt gemaakt dat je beter een div kunt maken waarvoor je 1 css hebt voor een webbrowser, en 1 css voor een handheld, in plaats van een tabel van 700px, die niet zal passen op een handheld.

dat je als je symantisch bezig bent je totaal niet meer in je achterhoofd hoeft te houden hoe de uiteindelijke look & feel eruit komt te zien.

Daar ben ik het mee eens; je moet je eerst richten op het structureren van de content; en pas daarna naar je layout gaan kijken

Ook werkt het artikel de intentie dat je alleen als je met standaarden werkt, een gecachde css file kunt gebruiken, wat een crap.

Als je een externe CSS file gebruikt kun je het bandbreedte gebruik verlagen. Alle opmaak in de HTML code zal de bestandgrootte doen toenemen

Voor de rest schrijft hij/zij "

"Er hoeven op deze manier geen verschillende versies ontwikkeld te worden voor de verschillende browsers en andere apparaten."

En even later

"Omdat webstandaarden ervoor zorg dragen dat een pagina toegankelijk is (en als er bij de ontwikkeling rekening is gehouden met oudere, zwak-CSS capabele browsers) dan maakt het niet uit welke browser iemand gebruikt: de inhoud is altijd bereikbaar"

Hoezo elkaar tegenspreken. De eerste alinea geeft al direct voor mij aan dat de schrijver niet weet waar hij/zij over schrijft.

Het punt is wederom dat een goede semantische structuur in elke browser leesbaar is; een CSS is er dan om het mooier te maken.

Standaarden zijn hardstikke mooi, maar verpak de boodschap niet in een artikel waarvan de schrijver denkt iets over het onderwerp te weten. Laat zo'n persoon aub asperges plukken ipv het woord verkeerd te verkondigen.

"Send to recyle bin"

Jij hebt voorbeelden van 'betere' artikelen?

[curry684]

Verwijderd schreef op 12 maart 2004 @ 17:19:
Ik vraag me af hoe het komt dat je daardoor niet valideert. Gaat prima

Hij had het over een typfout in de CSS, dan moet je wel de CSS validator gebruiken [/laat]

chris schreef op 12 maart 2004 @ 19:13:
[...]
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?

http://gathering.tweakers.net ?

[Verwijderd]

[quote]Spider.007 schreef op 15 maart 2004 @ 10:27:

Waarom lees jij zo selectief over mijn opmerkingen heen, echt verbazingwekkend Maar ik geef wel iets extra onderbouwing.

Het punt wat daar wordt gemaakt dat je beter een div kunt maken waarvoor je 1 css hebt voor een webbrowser, en 1 css voor een handheld, in plaats van een tabel van 700px, die niet zal passen op een handheld.

Alleen al je opmerking klopt van geen kanten. Het wel of niet gebruiken van een table heeft niets maar dan ook niets te maken met het feit of iets op je handheld te zien is. Ook aan een table kan ik een andere css rule hangen, ook bij een table kan ik de childs specificeren via css.

Als ik een div 700px breed maakt past deze ook niet op je handheld, dus wat in vredesnaam wilt een auteur nu met dit voorbeeld bereiken. Tables afschilderen als de boeman.. dat is het enige wat hij wilt bereiken. De argumentatie is echter onder de maat. Elke element kan ik zo stylen dat het niet meer op een handheld past. Dat heeft niets te maken met tables.

Daar ben ik het mee eens; je moet je eerst richten op het structureren van de content; en pas daarna naar je layout gaan kijken

Als je niet weet wat je layout wordt, hoe kun je dan structuur in je content aanbrengen? Dit is iets wat altijd samen zal gaan. Ook content heeft een layout, een textuele layout in de vorm van eerst title, dan teaser, dan body, etc. Maar is dat wel altijd zo? .. is dat wel de vaste structuur? ..

Als je een externe CSS file gebruikt kun je het bandbreedte gebruik verlagen. Alle opmaak in de HTML code zal de bestandgrootte doen toenemen

Dit heeft wederom niets te maken met tabeless layouts en standards. Op het moment dat ik in een standards based xhtml document inline styles ga gebruiken, zal het document nog steeds voldoen aan de standaarden en valideren als valid. Afhankelijk van je http headers wordt get geheel nog gecached ook.

Het punt waar het in het artikel van de auteur over gaat is, dat hij aangeeft, dat door het gebruik van standards, je bandbreedte bespaart omdat je css file wordt gecached. Dat komt bij mij over als je hebt de klok horen luiden maar je weet niet waar de klepel hangt. Het is complete stierepoep wat hij hier verkondigd.

Al maak ik een html 3 document, met marquee, blink en alle ranzige shit erin, en ik zet in de head een stylesheet referentie, dan wordt die stylesheet referentie gecached. Dat heeft niets te doen met standards.

Het punt is wederom dat een goede semantische structuur in elke browser leesbaar is; een CSS is er dan om het mooier te maken.

Het punt hier is dat het ene moment hij beweerd dat je nooit meer rekening hoeft te houden met meerdere platformen, en het andere moment wel. Dat klopt gewoon niet.

Jij hebt voorbeelden van 'betere' artikelen?

Er zijn genoeg voorbeeld van betere artikelen. Een gedeelte van alistapart staat ermee vol, complete goede weblogs zijn gewijd aan standards, en dan niet alleen het oeveloze geblaat, gepreek en naäperij, maar echt goede artikelen met praktijkvoorbeelden.

Mijn hele kritiek op het artikel gaat met name om het feit, dat de auteur wel een dergelijk artikel durft te publiceren maar zaken zo grof door elkaar haalt dat er een vertekend beeld wordt geplaatst. Ga niet zaken verkondigen qua standards als je zelf niet eens weet wat het zijn.

[ Voor 8% gewijzigd door Verwijderd op 15-03-2004 11:57 ]

[Verwijderd]

Hier is een goed artikel, met mensen die wel weten waar het over gaat:
http://devedge.netscape.com/viewsource/2002/wired-interview/

Er wordt keurig aangegeven waarom en hoe ze het hebben gedaan, leuk voorbeeld ook, want het gaat hier over wired.com niet echt een kleine site, laat wel degelijk zien dat standard based design mogelijk is voor complexe grote sites.

[ Voor 56% gewijzigd door Verwijderd op 15-03-2004 12:01 ]

[X-Lars]

Verwijderd schreef op 15 maart 2004 @ 11:53:
[...]

Alleen al je opmerking klopt van geen kanten. Het wel of niet gebruiken van een table heeft niets maar dan ook niets te maken met het feit of iets op je handheld te zien is. Ook aan een table kan ik een andere css rule hangen, ook bij een table kan ik de childs specificeren via css.

Als ik een div 700px breed maakt past deze ook niet op je handheld, dus wat in vredesnaam wilt een auteur nu met dit voorbeeld bereiken. Tables afschilderen als de boeman.. dat is het enige wat hij wilt bereiken. De argumentatie is echter onder de maat. Elke element kan ik zo stylen dat het niet meer op een handheld past. Dat heeft niets te maken met tables.
[...]

Op je handheld wordt een andere CSS gebruikt of de CSS wordt helemaal niet ingeladen, zodat je gewoon de tekst kan lezen.

Als je niet weet wat je layout wordt, hoe kun je dan structuur in je content aanbrengen? Dit is iets wat altijd samen zal gaan. Ook content heeft een layout, een textuele layout in de vorm van eerst title, dan teaser, dan body, etc. Maar is dat wel altijd zo? .. is dat wel de vaste structuur? ..

Als het goed is kun je de hele content van tevoren bepalen en dan pas aan de layout werken. Dat is ook belangrijk, want de layout is ondergeschikt aan de inhoud. Je zou nooit concessies moeten doen aan de content om een bepaalde layout te kunnen realiseren.

Dit heeft wederom niets te maken met tabeless layouts en standards. Op het moment dat ik in een standards based xhtml document inline styles ga gebruiken, zal het document nog steeds voldoen aan de standaarden en valideren als valid. Afhankelijk van je http headers wordt get geheel nog gecached ook.

Het wordt wel gecached, maar alleen voor die ene pagina. Een inline style op de ene pagina wordt niet gecached voor een andere pagina. CSS geldt voor elke pagina waar je die aan hangt.

[flame]

[...]
Ik heb helemaal niets aan gezwets, ik wil het zien, voelen en zelf uitproberen. Daar kan ik tenminste wat mee doen.

Mijn hele kritiek op het artikel gaat met name om het feit, dat de auteur wel een dergelijk artikel durft te publiceren maar zaken zo grof door elkaar haalt dat er een vertekend beeld wordt geplaatst. Ga niet zaken verkondigen qua standards als je zelf niet eens weet wat het zijn.

Laat het dan lekker links liggen. Je zou een en ander wel iets flexibeler kunnen bekijken misschien. Volgens mij interpreteer jij het artikel niet helemaal zoals de bedoeling is (dat maak ik op uit je argumenten). Maar dat geflame richting auteur vind ik sowieso irritant (btw, ken hem niet). Zeg dan gewoon dat je het ergens niet mee eens bent.

[Verwijderd]

X-Lars schreef op 15 maart 2004 @ 12:09:
[...]
Laat het dan lekker links liggen. Je zou een en ander wel iets flexibeler kunnen bekijken misschien. Volgens mij interpreteer jij het artikel niet helemaal zoals de bedoeling is (dat maak ik op uit je argumenten). Maar dat geflame richting auteur vind ik sowieso irritant (btw, ken hem niet). Zeg dan gewoon dat je het ergens niet mee eens bent.

+1
Ik ben het trouwens niet erg eens met het artikel

[Verwijderd]

X-Lars schreef op 15 maart 2004 @ 12:09:
[...]

Op je handheld wordt een andere CSS gebruikt of de CSS wordt helemaal niet ingeladen, zodat je gewoon de tekst kan lezen.

Neemt niet weg dat de auteur zaken gewoon misbruikt en in een verkeerd daglicht stelt. Een div van 700px breed ziet er net zo brak uit als een table van 700px breed. Dat is hier de hele issue, en niet het gebruik van een andere css file.

Als het goed is kun je de hele content van tevoren bepalen en dan pas aan de layout werken. Dat is ook belangrijk, want de layout is ondergeschikt aan de inhoud. Je zou nooit concessies moeten doen aan de content om een bepaalde layout te kunnen realiseren.

Dat hangt geheel af van je doelgroep. Bij voornamelijk marketing gerichte websites moet het geheel voornamelijk aantrekkelijk zijn.

Het wordt wel gecached, maar alleen voor die ene pagina. Een inline style op de ene pagina wordt niet gecached voor een andere pagina. CSS geldt voor elke pagina waar je die aan hangt.

Mijn hele punt ging om het include van een stylesheet in een standards based pagina, en het includen van een stylesheet in een niet standards based pagina. Volgens de auteur is het cachen te wijten aan het gebruik van standards, en dat daarom standards gebruikt moeten worden. Een niet standards gebaseerde pagina cached ook stylesheets. Dat was het hele punt.

Laat het dan lekker links liggen. Je zou een en ander wel iets flexibeler kunnen bekijken misschien. Volgens mij interpreteer jij het artikel niet helemaal zoals de bedoeling is (dat maak ik op uit je argumenten). Maar dat geflame richting auteur vind ik sowieso irritant (btw, ken hem niet). Zeg dan gewoon dat je het ergens niet mee eens bent.

Ik heb al een aatal postings aangegeven dat ik het niet met het artikel eens ben, ook nog eens onderbouwd met duidelijke argumenten. Welk gedeelte je niet snapt moet je maar aangeven. Ik denk dat het duidelijk is aangegeven nl.

Het hele begrip standards is al een begrip dat door niet alteveel mensen wordt begrepen, en door teveel mensen maar worden gebruikt als buzzword. Standards zijn cool, maar wat zijn standards dan ?? .. uhhehh.

Je ziet in het artikel gewoon zowiezo aan de schrijfwijze dat de persoon behoorlijk bevooroordeelt is.

Een minder bevooroordeelde auteur is bijv. Jeffrey Zeldman, hij is dan wel idolaat van css layouts, standards, etc. maar geeft wel aan waar de pijnpunten liggen. Negatieve aspecten van css, waarom het niet altijd in de praktijk tot uiting komt, etc.

[ Voor 5% gewijzigd door Verwijderd op 15-03-2004 12:46 ]

[Verwijderd]

Hij had het over een typfout in de CSS, dan moet je wel de CSS validator gebruiken

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

[Spider.007]

Verwijderd schreef op 15 maart 2004 @ 11:53:

Waarom lees jij zo selectief over mijn opmerkingen heen, echt verbazingwekkend Maar ik geef wel iets extra onderbouwing.

Ik doe mijn best alleen inhoudelijk te reageren op je opmerkingen; en ik sla de ongefundeerde flames over.

[...]


Alleen al je opmerking klopt van geen kanten. Het wel of niet gebruiken van een table heeft niets maar dan ook niets te maken met het feit of iets op je handheld te zien is. Ook aan een table kan ik een andere css rule hangen, ook bij een table kan ik de childs specificeren via css.

Als ik een div 700px breed maakt past deze ook niet op je handheld, dus wat in vredesnaam wilt een auteur nu met dit voorbeeld bereiken. Tables afschilderen als de boeman.. dat is het enige wat hij wilt bereiken. De argumentatie is echter onder de maat. Elke element kan ik zo stylen dat het niet meer op een handheld past. Dat heeft niets te maken met tables.

Inderdaad, het gaat hier ook niet over het wel of niet gebruiken van tabellen; de auteur heeft het hier over 'gebieden' waar hard een breedte aan wordt meegegeven. Mijn opmerking wordt door jou verkeerd geintepreteerd; ik zeg niet dat div's de voorkeur hebben boven tabellen; ik zeg dat het netter is om dit soort maten op te nemen de CSS; en niet in de semantische (HTML) structuur van het document.

[...]


Als je niet weet wat je layout wordt, hoe kun je dan structuur in je content aanbrengen? Dit is iets wat altijd samen zal gaan. Ook content heeft een layout, een textuele layout in de vorm van eerst title, dan teaser, dan body, etc. Maar is dat wel altijd zo? .. is dat wel de vaste structuur? ..

Het feit dat de meeste pagina's op Internet zich richten op de layout betekent niet dat dit ook de bedoeling is. De structuur van een site als GoT bijvoorbeeld is redelijk goed te bepalen. Zo kun je goed gebruik maken van headers, paragraphs en id's/classes. De layout heeft hier niets te maken.

[...]


Dit heeft wederom niets te maken met tabeless layouts en standards. Op het moment dat ik in een standards based xhtml document inline styles ga gebruiken, zal het document nog steeds voldoen aan de standaarden en valideren als valid. Afhankelijk van je http headers wordt get geheel nog gecached ook.

Het punt waar het in het artikel van de auteur over gaat is, dat hij aangeeft, dat door het gebruik van standards, je bandbreedte bespaart omdat je css file wordt gecached. Dat komt bij mij over als je hebt de klok horen luiden maar je weet niet waar de klepel hangt. Het is complete stierepoep wat hij hier verkondigd.

Al maak ik een html 3 document, met marquee, blink en alle ranzige shit erin, en ik zet in de head een stylesheet referentie, dan wordt die stylesheet referentie gecached. Dat heeft niets te doen met standards.

Ik denk dat de auteur hier het verschil tussen het opnemen van inline opmaak, en het gebruik van een css wil aanduiden. Kijk wederom naar een site als GoT; een externe stylesheet kan gecached worden voor iedere pagina; in plaats van dat er elke keer font tags uit de pagina moeten worden geintepreteerd. Dit is slechts een voorbeeld van een voordeel van de auteur; jouw interpretatie ervan klinkt inderdaad als stierenpoep.

[...]


Er zijn genoeg voorbeeld van betere artikelen. Een gedeelte van alistapart staat ermee vol, complete goede weblogs zijn gewijd aan standards, en dan niet alleen het oeveloze geblaat, gepreek en naäperij, maar echt goede artikelen met praktijkvoorbeelden.

Mijn hele kritiek op het artikel gaat met name om het feit, dat de auteur wel een dergelijk artikel durft te publiceren maar zaken zo grof door elkaar haalt dat er een vertekend beeld wordt geplaatst. Ga niet zaken verkondigen qua standards als je zelf niet eens weet wat het zijn.

Goed dit artikel zit misschien niet zo goed in elkaar; maar jouw kritiek erop slaat ook als een tang op een varken aangezien je voorbeelden van de auteur gebruikt om kritiek op te geven (tabellen enzo). De strekking van dat verhaal is gewoon redelijk duidelijk, redelijk beargumenteerd en kloppend

[curry684]

Verwijderd schreef op 15 maart 2004 @ 12:47:
[...]

[...]

Ah ik dacht dat je het over deze passage had:

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.

Hij had zowel een CSS als HTML probleem in dezelfde post

[oh,when?]

Verwijderd schreef op 13 maart 2004 @ 08:21:
In reactie op 'oh,when?'.

[...]

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

Ten eerste dank aan iedereen voor het reageren. Ten tweede, wat is dat voor een holle oneliner hierboven? Of zoals onze consultants zeggen: "je praat wel maar je zegt eigenlijk niets". Overigens was Wehkamp 2 jaar geleden al drempelsweg gecertificeerd, dus aan de toegankelijkheid kan het niet liggen.

Waar ik even verder op wil gaan zijn de verschillende argumenten die ik hier van sommige mensen hier hoor ( en ook in het 'artikel' tegenkom ).

Ten eerste, het argument dat 'je met een stylesheet in 1 keer heel je site kan veranderen'. Dat zal misschien wel zo zijn, maar mijn ervaring is dat het in de praktijk bijna tot nooit voorkomt. Echt ieder project waar ik de afgelopen 5 jaar aan heb gewerkt dat te maken had met een of ander redesign, hield automatisch in dat de CONTENT op een bepaalde pagina veranderd ( vaak meer / andere content ). Ik hoor mensen al neuzelen over 'semantiek van een pagina'. Welkom to reality, semantiek heeft daar weinig mee te maken...daar krijg ik heus geen recordset van terug uit mijn DB ( en dus andere content op een pagina ). Iedereeen hier die mij kan vertellen hoe ik slechts met 1 stylesheet andere content tevoorschijn tover, laat het me weten en ik heb een baan voor je.

Een ander argument wat ik vaak lees: "wij gebruiken valid xhtml dus dat scheelt je bandbreedte en dus kosten"

Dat gaat eigenlijk uit van de volgende aannames:

1) dat valid XHTML ALTIJD compacter is dan <insert andere tagsoup>
2) dat je veel bezoekers krijgt ( dus veel bandbreedte )
3) dat bandbreedte heel erg duur is

Tis eigenlijk een paradox, als je een "high-traffic" website hebt, dat je wilt gaan besparen op minor details als kleinere / valid code, terwijl de echte kostenbesparing dan op heel andere vlakken liggen ( managment nivo ). Ooit gehoord van "Premature Optimization"?

Leuk al dat kommageneuzel van sommige mensen hier, maar ik hecht meer waarde aan mensen met ervaring uit de praktijk, en dan bedoel ik niet diegene die 3 gevalideerde websites in hun leven hebben gemaakt ( 1 voor de lokale bakker, 1 voor het bedrijf van zijn oom en 1 tijdens zijn studie ). No pun intended.

[ Voor 3% gewijzigd door oh,when? op 15-03-2004 20:47 ]

[Civil]

chris schreef op 12 maart 2004 @ 19:13:
[...]
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?

curry684 schreef op 15 maart 2004 @ 10:31:

[...]

http://gathering.tweakers.net ?

Tweakers.net remake

O-)

[Verwijderd]

oh,when? schreef op 15 maart 2004 @ 20:44:
Leuk al dat kommageneuzel van sommige mensen hier, maar ik hecht meer waarde aan mensen met ervaring uit de praktijk, en dan bedoel ik niet diegene die 3 gevalideerde websites in hun leven hebben gemaakt ( 1 voor de lokale bakker, 1 voor het bedrijf van zijn oom en 1 tijdens zijn studie ). No pun intended.

Ik heb toch wel aardig wat ervaring uit de praktijk en zie tegenwoordig geen reden meer om niet standaarden-gericht te ontwikkelen. Let wel: ik bedoel niet dat (a) code altijd moeten valideren, (b) tabellen nooit voor layout gebruikt mogen worden of (c) element X moet altijd worden gebruikt voor content-type Y. Wenselijk? Ja, maar soms is dat gewoon onhandig en kost het rotzooien daarmee iemand € 100/uur.

Maar aan de andere kant kunnen we met HTML en CSS nu zulke coole dingen. Het kan nu allemaal zoveel efficiënter en mooier dan, zeg, twee jaar geleden, dat het voor mij onbegrijpelijk is dat anderen dat niet zouden willen gebruiken.

Ik ben het met je eens: dat bandbreedte-argument is verwaarloosbaar. Aan de andere kant ben ik ervan overtuigd dat sites met CSS veel sneller en efficiënter ontwikkeld kunnen worden. Uiteindelijk hoeft er minder code geschreven te worden. Dat bespaart de klant wél geld.

[Verwijderd]

@oh, when? : Als je ergens wilt beginnen, begin dan eens met dat menu op die site, dat is zo onvriendelijk, pas na twee keer doorklikken kom ik op de submenu`s.

[Verwijderd]

Blues, waar owen vooral op doelt is het zeer ver doorzetten van symantiek, css layouts, gebruik van elementen waarvoor ze bedoelt zijn.

Nog erger de stortvloed aan argumenten die vaak makkelijk onderuit te halen zijn.

[oh,when?]

Let wel: ik bedoel niet dat (a) code altijd moeten valideren, (b) tabellen nooit voor layout gebruikt mogen worden of (c) element X moet altijd worden gebruikt voor content-type Y. Wenselijk? Ja, maar soms is dat gewoon onhandig en kost het rotzooien daarmee iemand € 100/uur.

Dan zijn we het in ieder geval eens...maar dat had punt had ik al eerder gemaakt:

oh,when? schreef op 12 maart 2004 @ 14:13:
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'.

[oh,when?]

Verwijderd schreef op 15 maart 2004 @ 21:51:
@oh, when? : Als je ergens wilt beginnen, begin dan eens met dat menu op die site, dat is zo onvriendelijk, pas na twee keer doorklikken kom ik op de submenu`s.

Dat lijkt misschien zo maar is dat ook daadwerkelijk zo? Gebruikerstesten wijzen keer op keer toch echt uit dat mensen niet navigeren via de submenu's maar via de search engine, en foto's / plaatjes van bekende merken op een pagina. Daarnaast is de navigatie het onderdeel van een Interaction Design en niet van een ontwikkelaar.

[Verwijderd]

Verwijderd schreef op 15 maart 2004 @ 21:52:
Blues, waar owen vooral op doelt is het zeer ver doorzetten van symantiek, css layouts, gebruik van elementen waarvoor ze bedoelt zijn.

Waar ik vooral op doel is dat er een heel scala aan mogelijkheden tussen toen en nu ligt.

Nog erger de stortvloed aan argumenten die vaak makkelijk onderuit te halen zijn.

Niet zo erg als die stortvloed aan tabellen en spacer GIFs die ik nog dagelijks over me heen krijg.

Het belangrijkste argument is tijd/geld en ik weet één ding: ik bouw nu meer voor minder geld dan een jaar geleden.

[Clay]

oh,when? schreef op 15 maart een mooi verhaal:

[...]

* knip!

Goed, en duidelijk maar wat wil je daarmee beweren? dat tabletagsoup beter is dan xhtml, bandbreedte niet boeit, en dat het verschil in benodigde tijd voor tabletroep of xhtml updaten niet van belang is? Natuurlijk gaat een redesign content op andere plekken neerzetten, en (belangrijker) anders verdelen. Dat kan inderdaad betekenen dat je opnieuw moet htmllen (heb ik vooralsnog ook nooit anders gezien idd) maar er is ook een groot verschil tussen:

- een site met CSS een redesign geven,
- een site met CSS een skin geven, en
- een site met CSS voor verschillende media bruikbaar maken.

In het eerste geval verandert je data [dus vaak] ook, klopt. In het 2e geval niet (of ik definieer "skin" anders), maar toon je dezelfde data op een andere manier, en in het 3e toon je dezelfde data op een ander medium, en dat is veel belangrijker dan een skin of redesign in hetzelfde media type. Skinnen is gewoon spelen met CSS, het is niet de essentie.

Een redesign doe je ook niet zomaar. Blijkbaar komt je boodschap niet over, of je hebt een nieuwe, en ja, dan verandert je data [hopelijk] ook. Op dat moment is het niet de vraag of je dus een nieuwe skin kan maken, maar hoe je die nieuwe applicatie gaat bouwen.

En dan ben je weer terug bij af je moet een site gaan maken en vraagt je af, ga ik tagsoup bakken die niet te updaten is en veel tijd kost in onderhoud en aanpassingen en eigenlijk uit 1 grote hoop onvoorspelbare htmlhacks bestaat? Of pas ik een technisch goede, mooie, en voor het doel ontwikkelde methode toe? want dat is de keuze die je maakt. Alleen kunde en daarmee gemoeide tijd beinvloeden dit, veel meer niet. Als je voor het toevoegen van iets aan een site ergens op een totaal bizarre plek een col- of rowspan moet aanpassen, waar gaat dat dan over? Ik html en css met de hand, en ik wil &^!$@ trots zijn op de code die ik schrijf!

[mullah]

Verwijderd schreef op 12 maart 2004 @ 14:44:
[...]
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.

http://www.struikelblok.nl/ is nog geen keurmerk, maar wel artikeltjes met info ter promotie (vind de layout niet mooi, maar dat is een smaakprobleem)

de nederlandse ALA http://www.naarvoren.nl/ is trouwens ook interessant

tot zover mijn spam voor vandaag

[Annie]

Het wordt nog spannend hier, ik kijk effe een dag niet en het topic is verworden tot een kluwe over elkaar rollende zealots

Ik was toch wel erg nieuwsgierig geworden naar het artikel op stijlstek en heb het even doorgelezen. Alleen kan ik helaas ook niet anders concluderen dan dat de schrijver of een uiterst ongelukkige manier van uitdrukken heeft, of dat hij de klok op een aantal punten wel heeft horen luiden, maar mijlenver verwijderd is van de klepel.
Het doel van het verhaal mag duidelijk zijn, maar de argumenten helpen niet echt. Sterker nog, ik vind het een draak van een artikel.

offtopic:
p.s. Om de opmerkingen van Gordijnstok af te doen als flame vind ik overigens een beetje flauw. Ok, ze worden hard ingezet, maar een flame??

Wat wel een flame zou zijn (): "Voor iemand die pretendeert zo te zijn begaan met de standaarden moet ik zeggen dat de code van zijn pagina nogal wat gebreken vertoond bij de javascript (onnodige comments, foutmeldingen in de preview, antieke objectreferentie) en semantische opbouw (dubbele <br/> om witregels te maken in de preview? een h3 voor de datum?).
En dan kijk ik even vluchtig de pagina door, de echte azijnpissers moeten nog wel meer puntjes van aandacht kunnen vinden."
- pun intended

[Verwijderd]

oh,when? schreef op 15 maart 2004 @ 22:01:
[...]

Dat lijkt misschien zo maar is dat ook daadwerkelijk zo? Gebruikerstesten wijzen keer op keer toch echt uit dat mensen niet navigeren via de submenu's maar via de search engine, en foto's / plaatjes van bekende merken op een pagina. Daarnaast is de navigatie het onderdeel van een Interaction Design en niet van een ontwikkelaar.

precies, maar ik dacht dat het hier ook ging om usability.

hier stond een heel verhaal,.. maar dat ging te ver ot

[ Voor 90% gewijzigd door Verwijderd op 15-03-2004 23:52 ]

[Annie]

Om even wat anders aan te snijden (of was dit al genoemd?).

Wat vinden we eigenlijk van de ingeslagen weg van het w3c (excuses voor het op 1 hoop gooien van alle werkgroepen)? Lopen we met het steeds verder uitbouwen van de CSS specs niet het gevaar dat we de tag-soup, die html voorheen vaak was, verplaatsen naar de stylesheet? En is CSS in de huidige vorm daar wel geschikt voor?
_{(het zal wel aan mij liggen maar een complexe stylesheet vind ik niet prettig lezen)}

Wordt misschien de CSS zo moeilijk gemaakt dat we daarvoor in de toekomst (bijna) verplicht zijn een gecertificeerd template-bouwer aan te nemen? De vormgevers die op dit moment verguisd worden omdat ze met tables en klik-klak-klaar programma's werken daar kan je over het algemeen niet van verwachten dat ze de CSS standaarden helemaal gaan begrijpen (dat hoeft dus niet per se veroorzaakt te zijn door onkunde!) en veel server-side-scripters staan weer te ver van de layout af.

Hoe zien jullie dat?

Ik heb zelf af en toe het gevoel dat het w3c een beetje te veel doordraaft. Een absolute scheiding tussen content en layout is simpelweg te moeilijk haalbaar (als het uberhaupt al mogelijk is). Moet je dan proberen deze zover mogelijk te benaderen, of geldt het KISS principe niet veel eerder? M.a.w. moet de theorie niet ergens ten dienste van de praktijk komen te staan?

[Bluestorm]

Annie schreef op 15 maart 2004 @ 23:30:
Om even wat anders aan te snijden (of was dit al genoemd?).

Wat vinden we eigenlijk van de ingeslagen weg van het w3c (excuses voor het op 1 hoop gooien van alle werkgroepen)? Lopen we met het steeds verder uitbouwen van de CSS specs niet het gevaar dat we de tag-soup, die html voorheen vaak was, verplaatsen naar de stylesheet? En is CSS in de huidige vorm daar wel geschikt voor?
_{(het zal wel aan mij liggen maar een complexe stylesheet vind ik niet prettig lezen)}

CSS wordt inderdaad ook heel snel groot. Vooral ook als je in CSS nog een beetje met het ontwerp experimenteert loop je het risico om het overzicht te verliezen. Aan de andere kant zou ik niet graag terug willen naar meer vormgeving in de HTML zelf, dus moet je het dan zoeken in een verbetering van CSS. Sowieso is CSS nog voor veel verbetering vatbaar. Misschien komt een deel van de onoverzichtelijkheid ook juist wel door het gebrek aan bepaalde krachtige mogelijkheden waardoor veer properties nodig zijn en soms zelfs extra HTML elementen wat ook weer uitgebreidere CSS regels oplevert.

Ik merk vaak dat ik toch wel meerdere keren een stukje stylesheet schrijf. Vaak los ik dat dan op met iets als:

Cascading Stylesheet:

selector1, selector2, selector3 {gemeenschappelijke eigenschappen}
selector1 {.... specifiek.... }
selector2 { ..... specifiek.... }
selector3 {...... specifiek .... }

maar dat draagt niet echt bij aan de leesbaarheid. zeker niet als die selectors wat groter zijn. Ik heb me nog niet heel erg in de mogelijkheden van CSS3 verdiept. Maar ik kan me toch voorstellen dat je in de toekomst iets zou willen om bepaalde eigenschappen binnen een stylesheet te groeperen en hergebruiken.

Iets anders wat ik vaak gebruik is

Cascading Stylesheet:

a b c {...}
a b d {...}
a b e {...}

ook niet echt compact en lekker leesbaar. Syntax om dit soort zaken te groeperen zou ook niets mis mee zijn.

Maar net als er voor layout met tables gewoon dingen zijn die beter werken dan andere dingen geld dat voor CSS natuurlijk net zo. En momenteel wordt daar volgens mij heel snel meer over bekend. Want als je eenmaal alle beperkingen kent moet met CSS en mooie semantisch correcte HTML toch minstens net zo hersenloos een site te bouwen zijn als het vertalen van een PSD naar een tablebased layout.

[Verwijderd]

Om even wat anders aan te snijden (of was dit al genoemd?).

Nope.

Wat vinden we eigenlijk van de ingeslagen weg van het w3c (excuses voor het op 1 hoop gooien van alle werkgroepen)? Lopen we met het steeds verder uitbouwen van de CSS specs niet het gevaar dat we de tag-soup, die html voorheen vaak was, verplaatsen naar de stylesheet? En is CSS in de huidige vorm daar wel geschikt voor?

Ik denk vooral dat het W3C naar mogelijkheden zoekt om alles wat visueel is aan de HTML elementen (de manier waarop form elementen worden getoond etc.) uit te drukken in CSS. Op die manier kan HTML visueel beschreven worden met CSS en wellicht qua scripting via het DOM en ECMAScript.

(X)HTML elementen zijn dan niet meer speciaal voor een UA (alhoewel CSS3 FIELDSET, LEGEND, FRAMESET en meer nog niet heeft beschreven) waardoor deze, als hij de weergave via CSS doet, automatisch ook met XML om kan gaan. Eigenlijk wordt alles dus abstracter en verdeeld over meerdere documenten.

Dit leidt uiteraard tot meer moeilijkheden voor de designer, maar dat zie je nu ook al. Heel vaak worden dingen als HTTP headers e.d. ook verwaarloosd op pagina's of content-types (helaas heeft IE daar op ingesteld en heeft die browser nu de meest buggy content-type handling die je je maar kunt wensen)...

Maar ik denk dat alles nog steeds behapbaar blijft als je maar af en toe gewoon wat artikelen leest op A List Apart of een dergelijk magazine.

W3C heeft trouwens wel een nieuwe maatregel genomen met nieuw specificaties, zodat het CSS2 verhaal niet meer kan voorkomen, elke specificatie moet vanaf nu door tenminste 2 applicaties ondersteund worden anders kan het geen REC worden (als een spec CR is komt er een test suite om dat te gaan testen).

[Verwijderd]

Ten eerste dank aan iedereen voor het reageren. Ten tweede, wat is dat voor een holle oneliner hierboven?

Kleine samenvatting van de rest van de reactie.

Ten eerste, het argument dat 'je met een stylesheet in 1 keer heel je site kan veranderen'. Dat zal misschien wel zo zijn, maar mijn ervaring is dat het in de praktijk bijna tot nooit voorkomt. Echt ieder project waar ik de afgelopen 5 jaar aan heb gewerkt dat te maken had met een of ander redesign, hield automatisch in dat de CONTENT op een bepaalde pagina veranderd ( vaak meer / andere content ). Ik hoor mensen al neuzelen over 'semantiek van een pagina'. Welkom to reality, semantiek heeft daar weinig mee te maken...daar krijg ik heus geen recordset van terug uit mijn DB ( en dus andere content op een pagina ). Iedereeen hier die mij kan vertellen hoe ik slechts met 1 stylesheet andere content tevoorschijn tover, laat het me weten en ik heb een baan voor je.

http://www.w3.org/TR/css3-content

Maar dat is niet echt belangrijk. Wat vooral het voordeel is dat, mocht je het willen, je de bezoeker kunt laten kiezen uit meerdere layouts, bijvoorbeeld zwart-op-wit en wit-op-zwart. Een ander voordeel is dat je bijvoorbeeld een style sheet voor de 'printer' kunt maken zodat er geen aparte 'print deze pagina' knopjes nodig zijn en mensen gewoon ctrl+p; enter; kunnen klikken.

Een ander argument wat ik vaak lees: "wij gebruiken valid xhtml dus dat scheelt je bandbreedte en dus kosten"

Is onzin natuurlijk. Met HTML kan je veel compactere pagina's maken. Al is het alleen al omdat je een hoop start en end tags mag weglaten (elementen zelf niet).

2) dat je veel bezoekers krijgt ( dus veel bandbreedte )

Lijkt me een feit voor wehkamp of niet?

[Verwijderd]

Clay schreef op 15 maart 2004 @ 22:31:
Ik html en css met de hand, en ik wil &^!$@ trots zijn op de code die ik schrijf!

Amen!

Annie schreef op 15 maart 2004 @ 23:30:
Lopen we met het steeds verder uitbouwen van de CSS specs niet het gevaar dat we de tag-soup, die html voorheen vaak was, verplaatsen naar de stylesheet? En is CSS in de huidige vorm daar wel geschikt voor?

Ja, maar er zijn een aantal redenen waarom dat niet erg is. De belangrijkste daarvan is dat de CSS 'vies' wordt zodat de HTML (de data) schoon kan blijven. Zolang die data schoon is ligt de weg naar heldere presentatie altijd open.

De vormgevers die op dit moment verguisd worden omdat ze met tables en klik-klak-klaar programma's werken daar kan je over het algemeen niet van verwachten dat ze de CSS standaarden helemaal gaan begrijpen (dat hoeft dus niet per se veroorzaakt te zijn door onkunde!) en veel server-side-scripters staan weer te ver van de layout af.

Daarom zie ik alleen een (wijdverspreide) toekomst voor CSS als er goede commerciële tools ontstaan die dat de designer uit handen nemen. Ik weet zeker dat dat mogelijk is.

[ Voor 16% gewijzigd door Verwijderd op 16-03-2004 08:29 ]

[Verwijderd]

Annie schreef op 15 maart 2004 @ 23:30:
Om even wat anders aan te snijden (of was dit al genoemd?).

Wat vinden we eigenlijk van de ingeslagen weg van het w3c (excuses voor het op 1 hoop gooien van alle werkgroepen)? Lopen we met het steeds verder uitbouwen van de CSS specs niet het gevaar dat we de tag-soup, die html voorheen vaak was, verplaatsen naar de stylesheet? En is CSS in de huidige vorm daar wel geschikt voor?
_{(het zal wel aan mij liggen maar een complexe stylesheet vind ik niet prettig lezen)}

De weg die ze zijn ingeslagen is in ieder geval een goed begin. Het hele verhaaltje is echter te complex om eventjes in een draft uit te werken, en dat zie je terug in de praktijk. Voor een aantal problemen zijn niet zo 123 css oplossingen te bedenken die tevens clean zijn.

Vaak kom je uit op ranzige nestings om je resultaat te bereiken. Niks mis mee als het resultaat er goed uit ziet, maar ook qua onderhoud maak je het jezelf steeds lastiger want 3 weken later weet je niet meer waarom je het destijds nu zo had gedaan.

Het zou ook veel schelen als layout wat minder nest afhankelijk is, met een css wijzig je niet de layout als het geheel complex is genest.

Het W3C wordt vaak verweten niet naar de developers te luisteren, maar teveel bezig te zijn in hun eigen wetenschappelijke wereldje.

[ Voor 6% gewijzigd door Verwijderd op 16-03-2004 08:43 ]

[Grijze Vos]

Bluestorm schreef op 16 maart 2004 @ 00:18:

Cascading Stylesheet:

a b c {...}
a b d {...}
a b e {...}

ook niet echt compact en lekker leesbaar. Syntax om dit soort zaken te groeperen zou ook niets mis mee zijn.

Bedoel je iets als dit:

Cascading Stylesheet:

a b c, a b d, a b e {...}

Dat kan nl. gewoon.

[Verwijderd]

Grijze Vos schreef op 16 maart 2004 @ 08:44:
[...]


Bedoel je iets als dit:

Cascading Stylesheet:

a b c, a b d, a b e {...}

Dat kan nl. gewoon.

Maar nu gebruik je a b c d, maak daar eens termen van en zie de onleesbaarheid van je stylesheet grote vormen aannemen.

[Grijze Vos]

Verwijderd schreef op 16 maart 2004 @ 08:47:
[...]

Maar nu gebruik je a b c d, maak daar eens termen van en zie de onleesbaarheid van je stylesheet grote vormen aannemen.

Been there, done that. Kga binnenkort mn eerste echte CSS project opnieuw CSSen/HTMLen. Want het is nu echt een onleesbare code-soep geworden. En het is nog niet semantisch correct helemaal.

[Spider.007]

De huidige manier van CSS programmeren is inderdaad niet echt leesbaar te noemen Nu heb ik in een ander topic al een aantal voorbeelden van mogelijke een syntax voorbij zien komen; zijn er al ideeen over om dit in verdere CSS versies te verbeteren? Wat is er mogelijk aan verbetering om CSS leesbaarder, begrijpbaarder en compacter te maken? Een soort van programmeertaal als HTC's ofzo?

[Clay]

* Clay vindt het best meevallen.

Het kan vrij lang worden, maar de overzichtelijkheid heb je zelf in de hand. b.v. met een beetje inspringen ala:

Cascading Stylesheet:

html,body {
   margin:0;
   padding:0;
   height:100%;
}
   * {
      font-family:verdana,arial,tahoma;
      font-size:11px;
   }

/* layout, wat comments enzo om verschillende blokken af te scheiden */

body div#container {
   ...
}
   div#container h1 {
   }

   ...

kan je imo prima CSS files maken van 2 tot 300 regels die je misschien niet op het 1e gezicht snapt, maar ze zijn wel leesbaar.

[Verwijderd]

Clay, nu is het alleen wel zo dat je zo veel mogelijk herbruikbare code wilt hebben. Als er 20 elementen zijn die dezelfde font-family gebruiken, dan wil je niet die 20 element allemaal apart voorzien van een font-family. Nu kun je inderdaad op de body, of zelfs met * een font-family zetten, maar afwijkende gedeelten hou je vaak.

Immers wil je bij een wijziging maar één locatie in je bestand wijzigen en niet aankomen met find & replace tools. Als je dus een behoorlijke layout hebt, en niet een simpele weblog layout (want dat zijn gewoon de peanuts onder de layouts), dan krijg je al heel snel dat heel veel zaken gecombineerd worden in je css file.

Je ziet nu al steeds vaker dat er een shitload aan css files worden geincluded. Kijk naar wired.com, of macromedia.com. Ik vind persoonlijk niet dat je bij grotere webprojecten heel veel overzicht houdt op je css. Je kunt het zelf door netjes werken beperken, maar de techniek heeft zijn grenzen op dat vlak.

Wat ik wel een nadeel vind van css, is dat je niet direct als developer uit de code kunt opmaken hoe iets eruit komt te zien. Bij tables zag je direct al aan de code, zus en zo komt het eruit te zien. Een dergelijke benadering met css zou het een stuk prettiger werken maken, maar dat is nogal lastig te realiseren.

[Bluestorm]

Grijze Vos schreef op 16 maart 2004 @ 08:44:
[...]


Bedoel je iets als dit:

Cascading Stylesheet:

a b c, a b d, a b e {...}

Dat kan nl. gewoon.

Nee ik bedoel meer dat als je een layout in onderdelen verdeelt. Dat je dan steeds een hele hoop regels hebt waarvan a en b gelijk zijn en dat je dan alleen het laatste element in die context wil stijlen. bijvoorbeeld:

code:

#sidebar .belangrijk h1 {font-size: 16px; }
#sidebar .belangrijk h2 {font-size: 14px; }
#sidebar .belangrijk h3 {font-size: 11px; font-weight: bold; }
#sidebar .belangrijk p {font-size: 11px; }

er is natuurlijk niets mis mee op deze manier, maar iets in de trant van:

code:

#sidebar .belangrijk [
     h1 {font-size: 16px;}
     h2 {font-size: 14px;}
     h3 {font-size: 11px; font-weight: bold;}
     p {font-size: 11px}
]

zou imho veel wenselijker zijn, het blijft natuurlijk syntax dus niet echt belangrijk voor deze discussie.
Wat misschien wel belangrijker is is het deels ontbreken van de mogelijkheid om zeg maar de logica achter een layout vast te leggen. Regels als 'a net zo groot als b' , etc. zijn eigenlijk alleen uit te drukken als je precies weet hoe groot alles wordt.

[Clay]

Als er 20 elementen zijn die dezelfde font-family gebruiken, dan wil je niet die 20 element allemaal apart voorzien van een font-family. Nu kun je inderdaad op de body, of zelfs met * een font-family zetten, maar afwijkende gedeelten hou je vaak.

Daarom zou ik het juist met een * doen, dan hoeft het nergens anders meer, behalve idd voor de uitzonderingen, maar dat kan je ook beperken tot selectors die de uitzondering in CSS op 1 plek definieren.

Wat ik wel een nadeel vind van css, is dat je niet direct als developer uit de code kunt opmaken hoe iets eruit komt te zien. Bij tables zag je direct al aan de code, zus en zo komt het eruit te zien. Een dergelijke benadering met css zou het een stuk prettiger werken maken, maar dat is nogal lastig te realiseren.

Aan table code kan ik niet -direct- zien hoe de layout in elkaar zit hoor Ik zou zelfs beweren dat je dan aan CSS juist makkelijker kan zien, als je maar duidelijk CSS't, en b.v. globale positionering ook weer scheidt van grafische en typografie;

Cascading Stylesheet:

div#container {
   position:relative;
   width:700px;
}

   div#container div#menu {
      position:absolute;
      left:0;
      width:200px;
   }

   div#container div#content {
      margin-left:200px;
   }

lijkt me weinig meer aan de verbeelding overlaten

[Verwijderd]

Verwijderd schreef op 16 maart 2004 @ 11:02:
Je ziet nu al steeds vaker dat er een shitload aan css files worden geincluded. Kijk naar wired.com, of macromedia.com. Ik vind persoonlijk niet dat je bij grotere webprojecten heel veel overzicht houdt op je css. Je kunt het zelf door netjes werken beperken, maar de techniek heeft zijn grenzen op dat vlak.

Hoe hou je het overzicht op elke andere source? Kwestie van naamgeving en goed documenteren. En de hoeveelheid CSS is bij de veel projecten toch peanuts vergeleken bij de hoeveelheid server-side code. Ik zie het probleem niet zo.

[Verwijderd]

Daarom zou ik het juist met een * doen, dan hoeft het nergens anders meer, behalve idd voor de uitzonderingen, maar dat kan je ook beperken tot selectors die de uitzondering in CSS op 1 plek definieren.

Het lijkt me toch beter om het te baseren op cascading. Stel je dit voor:

code:

*{font:.9em/1.4 Arial,sans-serif}

Snap je?

Bij descendent selectors is het trouwens bijna altijd mogelijk om i.pv. "a b c", "a c" te schrijven.

[Verwijderd]

Verwijderd schreef op 16 maart 2004 @ 12:29:
[...]

Hoe hou je het overzicht op elke andere source? Kwestie van naamgeving en goed documenteren. En de hoeveelheid CSS is bij de veel projecten toch peanuts vergeleken bij de hoeveelheid server-side code. Ik zie het probleem niet zo.

Verschil tussen css en serverside code is dat je in principe veel sneller ziet waarvoor het te gebruiken is, en wat het resultaat is.

Op zich is het nog niet eens een ramp, maar het is zeker voor verbetering vatbaar.

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

[Verwijderd]

Verschil tussen css en serverside code is dat je in principe veel sneller ziet waarvoor het te gebruiken is, en wat het resultaat is.

Zou natuurlijk ook aan de persoon kunnen liggen en hoe vaak je met iets bezig bent.

Op zich is het nog niet eens een ramp, maar het is zeker voor verbetering vatbaar.

Ik ben benieuwd . De huidige syntax is imo erg goed, en vooral makkelijk om te begrijpen.

[Verwijderd]

Verwijderd schreef op 16 maart 2004 @ 13:07:
... hoe vaak je met iets bezig bent.

Precies, .. hoe vaak je met iets bezig bent. Op het moment dat ik nu kijk naar bepaalde code zie ik meteen waarom iets 3x genest is. Niet omdat de code me dat verteld, maar omdat ik nog herinner dat het anders problemen gaf met bepaalde absolute divs die gingen fungeren als contextmenu's en daardoor een hogere z-index moesten krijgen.

Ga ik dat echter 6 maanden verder onderhouden, dan weet ik dat echt niet meer. Tenzij ik een shitload aan documentatie schrijf, alles overvloedig commentarieer etc. maargoed

De hele situatie kan je in een situatie als deze wel weer verplaatsen naar de issues mbt nesten. Vooral dit is een beperking van je vrijheid, oa, als je layouts compleet afhankelijk wil maken (met dezelfde content) van een css file. Dwz, navigatie ineens ergens anders plaatsen, andere kleuren, etc.

Ik ben dus ook best benieuwd in hoeverre de firstchild lastchilds selectors geaccepteerd gaan worden. Ik denk persoonlijk dat ze meer kapot maken dan goed doen.

[Clay]

Verwijderd schreef op 16 maart 2004 @ 12:45:
[...]
Het lijkt me toch beter om het te baseren op cascading. Stel je dit voor:

code:

*{font:.9em/1.4 Arial,sans-serif}

Snap je?

Bij descendent selectors is het trouwens bijna altijd mogelijk om i.pv. "a b c", "a c" te schrijven.

Nee, snap ik niet De hele font: achter een * overrulen vind ik wel heel ver gaan namelijk. Daarmee sloop je dan ook meteen alle default instelling (line-height, style, weight, etc) van headers, b/i/strong/em etc. Juist daarom zou ik alleen family met een * doen, en size kan ook wel omdat die vaak ook maar op een paar plekken anders moet dan je default.

dit ga je toch ook nooit doen:

Cascading Stylesheet:

* {
   margin:0;
   padding:0;
}

[Verwijderd]

dubbel

[ Voor 98% gewijzigd door Verwijderd op 16-03-2004 15:07 ]

[Verwijderd]

Clay schreef op 16 maart 2004 @ 13:46:
dit ga je toch ook nooit doen:

Cascading Stylesheet:

* {
   margin:0;
   padding:0;
}

Je doet het anders wel op je eigen site

code:

* {
font-size : 11px; 
font-family : verdana, arial, helvetica, tahoma; 
vertical-align : top; 
text-align : left; 
margin : 0; 
padding : 0; 
border : 0 none inherit; 
}

... sorry

[Clay]

Doh! Ik zeg nooit meer wat hier!!!!

Naja, van je fouten leer je nietwaar? wat jij niet weet is dat dit oud is (bla bla smoesjes ), en dat ik met een nieuwe site bezig ben waar dat dus NIET in gebeurt

[Blue-eagle]

Clay schreef op 16 maart 2004 @ 15:22:
Doh! Ik zeg nooit meer wat hier!!!!

Naja, van je fouten leer je nietwaar? wat jij niet weet is dat dit oud is (bla bla smoesjes ), en dat ik met een nieuwe site bezig ben waar dat dus NIET in gebeurt

Preview?

[drm]

Anne:
Ik ben benieuwd . De huidige syntax is imo erg goed, en vooral makkelijk om te begrijpen.

Ik heb een voorstel: XPath gebruiken voor selectors. Scheelt weer een lap documentatie.

Ik heb nooit begrepen waarom ze dat niet gedaan hebben.

[InZane]

Clay schreef op 16 maart 2004 @ 15:22:
Doh! Ik zeg nooit meer wat hier!!!!

Naja, van je fouten leer je nietwaar? wat jij niet weet is dat dit oud is (bla bla smoesjes ), en dat ik met een nieuwe site bezig ben waar dat dus NIET in gebeurt

Kun je niet alvast een tipje van de sluier oplichten?

Zat me laatst al een keer af te vragen of je met iets nieuws bezig zou zijn

[Genoil]

drm schreef op 16 maart 2004 @ 16:59:
[...]
Ik heb een voorstel: XPath gebruiken voor selectors. Scheelt weer een lap documentatie.

Ik heb nooit begrepen waarom ze dat niet gedaan hebben.

Op zich helemaal geen slecht plan. maar:

code:

//*[@class='myClass'] {
   ...
}

is wel een beetje overhead vgl. met:

code:

.myClass {
   ...
}

[edit]
omdat voor CSS toch alleen de attributen class en id relevant zijn, zouden ze wat dat betreft een soort van macro's kunnen toevoegen aan XPath, zodat je dingen krijgen als:

code:

//*.myClass {
   ...
}

of 

//*#myID {
   ...
}

en nog mooier, bij alles waar geen axis + element voor staat er standaard //* voorzetten, ben je mooi weer terug bij af:

code:

.myClass {
   ...
}

[ Voor 33% gewijzigd door Genoil op 16-03-2004 17:21 ]

[Clay]

Mijn xpath is niet zo goed, maar zijn het toch niet een soort van 2 (conceptueel) totaal verschillende dingen ? Ik bedoel;

Cascading Stylesheet:

div#fiets h1 + p {}

lijkt me in xpath niet zo kort te schrijven... De verschillende selectors specifiek voor html (id, class, generated content) zijn er in CSS niet voor niets, dat soort dingen.

_{en nee er komen geen previews of sluiers!}

[coubertin119]

Clay schreef op 16 maart 2004 @ 13:46:
[...]


Nee, snap ik niet De hele font: achter een * overrulen vind ik wel heel ver gaan namelijk. Daarmee sloop je dan ook meteen alle default instelling (line-height, style, weight, etc) van headers, b/i/strong/em etc. Juist daarom zou ik alleen family met een * doen, en size kan ook wel omdat die vaak ook maar op een paar plekken anders moet dan je default.

dit ga je toch ook nooit doen:

Cascading Stylesheet:

* {
   margin:0;
   padding:0;
}

Ik gooi standaard ook alle margin's, padding's en font-zut in *, kan je per element stylen wat je nu eigenlijk net wil. Geen problemen met standaardinstellingen en dingen die plots fout lijken te gaan. Maar het is puur de mening van de developer, iemand anders kan het net een ware hel vinden .

[Bluestorm]

Toevallig dacht ik daar gisteren ook nog over na, waarom je niet gewoon xpath zou gebruiken, maar met xpath lijkt het mij moeilijk om zaken als hover, etc netjes uit te drukken. Dus je zou dan xpath moeten aanvullen en dan valt het voordeel van één standaard voor alles eigenlijk al weg. Daarom is het aanvullen van de mogelijkheden van de css selectors, zoals nu gebeurd eigenlijk net zo'n goede optie.

[ Voor 5% gewijzigd door Bluestorm op 16-03-2004 17:31 ]

[Verwijderd]

Nou ik heb niet deze hele thread doorgelezen maar wel een aardig stuk er en is 1 ding dat me opvalt. Als je zo erg voor webstandards bent (net zoals ik, nu alleen nog Microsoft, overigens prima bedrijf hoor daar niet van) waarom zou je dan (als webdesigner/programmer/whatever) een klant dan extra laten betalen voor een site die volgens standards gebouwd is? Als je wilt dan web standards door meer mensen gebruikt gaan worden moet je zelf ook wel even meewerken natuurlijk...

[coubertin119]

Als je het topic net had doorgelezen had je dit geweten. Uitbreidbaarheid en aanpasbaarheid zijn de grootste voordelen.

[Genoil]

Clay schreef op 16 maart 2004 @ 17:25:
Mijn xpath is niet zo goed, maar zijn het toch niet een soort van 2 (conceptueel) totaal verschillende dingen ? Ik bedoel;

Cascading Stylesheet:

div#fiets h1 + p {}

lijkt me in xpath niet zo kort te schrijven... De verschillende selectors specifiek voor html (id, class, generated content) zijn er in CSS niet voor niets, dat soort dingen.

da's precies wat ik bedoel met overhead, maar het KAN wel :

code:

//div[@id='fiets']//p[name(preceding-sibling::*[position()=1]) = 'h1']

bewijs:

XHTML:

<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet type="text/xsl" href="cssxslt.xsl"?>
<html>
    <body>
        <div id="fiets">
            <h1>Fiets</h1>
            <p>deze wil ik rood</p>
            <p>deze niet</p>
        </div>
        <div id="auto">
            <h1>Auto</h1>
            <p>deze wil ik ook niet rood</p>
            <p>en deze al helemaal niet</p>
        </div>
    </body>
</html>

XSLT:

<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:output method="html" indent="yes" />
    
    <xsl:template match="*">
        <xsl:copy>
            <xsl:apply-templates />
        </xsl:copy>
    </xsl:template>
    
    <xsl:template match="//div[@id='fiets']//p[name(preceding-sibling::*[position()=1]) = 'h1']">
        <xsl:copy>
            <xsl:attribute name="style">color:#f00</xsl:attribute>
            <xsl:apply-templates />
        </xsl:copy>
    </xsl:template>
    
</xsl:stylesheet>

[Verwijderd]

coubertin119 schreef op 16 maart 2004 @ 18:06:
Als je het topic net had doorgelezen had je dit geweten. Uitbreidbaarheid en aanpasbaarheid zijn de grootste voordelen.

Ik heb t/m pagina 4 gelezen hoor maar ok, ik snap niet helemaal wat je bedoelt met "Uitbreidbaarheid en aanpasbaarheid zijn de grootste voordelen". Voordelen waarvan, van een standards-compliant en semantisch correcte website? Dat lijkt mij logisch, dat probeer ik dus duidelijk te maken . Mijn vraag was toch echt waarom iemand meer zou moeten betalen voor een standards-compliant en semantisch correcte website dan voor een niet-standards-compliant en een niet-semantisch correcte website. Ik snap dat er in het eerste geval beter werk afgeleverd wordt, maar ja, dat ligt dan aan de designer/programmer (ik wil niet de discussie ingaan of (X)HTML een programmeertaal is of niet).

[coubertin119]

Wel, een pagina met tables. Een hele constructie met rowspans, colspans enzo. Als jij opeens beslist een andere lay-out te maken, ga jij helemaal van vooraf aan mogen beginnen. Een site die een beetje een logische structuur heeft is veel makkelijker te updaten.

Of dit ook van toepassing is op sites waarvoor betaald, is voor jou uit te maken. Voor hobbyisten is het in elk geval een must .

[Annie]

Verwijderd schreef op 16 maart 2004 @ 17:36:
waarom zou je dan (als webdesigner/programmer/whatever) een klant dan extra laten betalen voor een site die volgens standards gebouwd is?

Omdat de praktijk leert dat het voor veel mensen (op dit moment) nog extra werk kost om volgens de standaarden te werken (valideren), semantisch correcte data op te leveren en te testen. En tijd = geld.

Verder is het extra bedrag op de factuur ook vaak een factor waarmee risico's wordt afgedekt. Als er nog niet voldoende ervaring is met het werken volgens de standaarden dan loop je een groter risico (bijv. dat je tegen voor jou onbekende bugs of gedragingen aanloopt). Een paginaatje in elkaar rossen met tables weet iedereen intussen wel hoe dat moet.
Een klein foutje is voor een klant vaak een groot probleem, dus moet het opgelost worden. En oplossen van problemen gebeurt dan vaak weer (deels) onbetaald als je dat niet hebt afgedekt.

Bedrijven zijn geen filantropische instellingen.

Overigens zullen, na verloop van tijd, bedrijven het meerwerk niet meer in rekening (kunnen) brengen. Bijvoorbeeld omdat de markt intussen zo volwassen is geworden dat het gebruik van standaarden gemeengoed is geworden of omdat de "achterstand" op kennisgebied van het bedrijf is ingehaald.

Verwijderd schreef op 16 maart 2004 @ 17:36:
Als je wilt dan web standards door meer mensen gebruikt gaan worden moet je zelf ook wel even meewerken natuurlijk...

Dat meewerken gebeurt natuurlijk ook, alleen is het een geleidelijk proces.

[Blue-eagle]

Ach, we kunnen gerust zeggen dat wij de pioniers zijn van het standard-driven-web, straks. De standaarden worden ooit wel geaccepteerd, vooral als Microsoft en andere grote sites over stappen, en adviseren. Aangezien een internet standaard niet gebonden is aan directe risico's (zoals standaarden in airbags bijvoorbeeld, vul een airbag maar niet met kiezelstenen..) kan iedereen eigenlijk lekker freewheelen zonder al teveel consequenties.

Er moet een soort van "shame on you!" status ontstaan als je het op de oude manier doet. Je mag straks als webdeveloper eigenlijk niet meer aankomen met een tabellen-site, CV's moeten volstaan met hoe goed je wel niet de nieuwste standaarden beheerst, etc., etc.

[AkaXakA]

Verwijderd schreef op 13 maart 2004 @ 18:38:
En weer worden ondersteuning en CSS door elkaar gehaald.

Wat jij trouwens op je site beschrijft, in Mondriaan Magazine oid kan al lang ( http://steve.pugh.net/test/test57.html ). Er was laatst ook een artikel door een NL op A List Apart geschreven daarover (vind persoonlijk test57 een stukje mooier).

Wellicht is het handig om eerst is onderzoek te doen voordat je begint af te geven op een bepaalde techniek.

Goh, en het is misschien handiger om echt te kijken wat ik wil berijken voordat je dat zegt....
Want, als je kijkt wat ik wil berijken met MM, is niet alleen een balk aan de onderkant, maar ook een Nav balk die over de gehele hoogte van de content schaalt. Als je aan de Nav van test57 een achtergrondkleur geeft, zie je dat die niet verder komt dan de inhoud van de nav zelf. Als je de text goed gelezen had (en ik hem ook goed geschreven heb...) zie je dat ik het in 2003 geschreven heb en het article van A List Apart is van 2004 en gebruikt bovendien JavaScript....iets wat ik niet gek op ben, vooral als het punt zou moeten zijn dat het puur in css moet.

Verder, de conclusie van het stuk is dat het op dat moment niet goed mogelijk was, vanwege de implementatie onder browsers op dat moment. Het stuk is bedoelt om iets aan te hebben....niet om de mensen voor te schotelen hoe dingen in de perfecte wereld zouden kunnen waar iedereen Mozilla/Opera/Safari gebruikt....

[...]
Ik snap deze niet helemaal.

Het gaat erom dat een commerciele website gebouwd wordt om een doelgroep te bedienen. Als een site gebouwd wordt voor een intranet met IE 5 *huiver* dan zal het _eigenlijk_ alleen uitmaken of het onder IE5 eruit ziet zoals het moet en of dat kreng bruikbaar is. Zolang dat bedrijf geen blinde mensen in dienst heeft, zal niemand het opmerken of je het nou wel of niet toegankelijk (denkt) te maken.

Dit is natuurlijk een extreem voorbeeld om mijn punt goed te illustreren, maar dit is tenminste duidelijk.

Eigenlijk snap ik geen van de punten die je maakt echt, heb je misschien een aantal concrete voorbeelden oid?

Begrijp me niet verkeerd, ik heb graag pure css+div layouts voor mijn websites, maar als een design echt niet mogelijk (goed te krijgen cross browser zonder hele gekke dingen te doen) is zonder tables, dan moet dat maar.....daar ontkom je vandaag de dag niet aan.

Maar wees niet ongerust, toen html 3.2 uitkwam zaten we ook allemaal te wachten en te zuchten voordat iedereen eindelijk ene nieuwe Netscape zou hebben zodat we ook eindelijk *al die coole dingen konden implementeren*.

En nu, is er eigenlijk niet gek veel veranderd....CSS 2.1 is uit, en we zitten nog steeds te wachten totdat die goed ondersteund wordt bij het grootste percentage van de surfende menigte....zodat we eindelijk *al die coole dingen konden implementeren*.

Maar wees dus niet bang...de tijd zal zelfs komen dat iedereen CSS 3 ondersteund...alleen duurt dat nog een eeuwigheid

[b]
Van een professioneel webdesign bedrijf is te verwachten dat ze een hele sloot verschillende templates voor layouts al liggen hebben die aangepast worden voor elke klus.
yak! dat meen je niet serieus hoop ik?

Ik merk dat ik duidelijker moet zijn. Ik bedoel dat de basis layout...dus niet design ofzo...maar gewoon de form...dus header + nav (rechts/links/top) + footer (wel/niet) + subnav (wel/niet/links/rechts) en dan nog andere elementen....dus templates in de zin van http://www.thenoodleincid...als/box_lesson/boxes.html niet zoals in die CDroms vol met cheesy standard graphics...

Maar goed dat m'n sig zo verlichtend werkt

[Verwijderd]

Ik heb nooit begrepen waarom ze dat niet gedaan hebben.

CSS is niet aleen bestemd voor XML. Daarnaast:

• http://www.w3.org/TR/REC-CSS1-961217 ( http://www.w3.org/TR/1999/REC-CSS1-19990111 )
• http://www.w3.org/TR/1999/REC-xpath-19991116

Goh, en het is misschien handiger om echt te kijken wat ik wil berijken voordat je dat zegt....

Een backgroundplaatje doet wonderen ;-). Zie http://alistapart.com/articles/fauxcolumns/ . En dat ik een aantal referenties gebruik die nu populair zijn, betekend niet dat het vorig jaar niet mogelijk was.

Begrijp me niet verkeerd, ik heb graag pure css+div layouts voor mijn websites, maar als een design echt niet mogelijk (goed te krijgen cross browser zonder hele gekke dingen te doen) is zonder tables, dan moet dat maar.....daar ontkom je vandaag de dag niet aan.

Ik zou toch graag een concreet voorbeeld willen hebben. En over dat intranet, dat is absoluut niet te vergelijken met websites imo (denk aan voorafbepaalde resolutie, instellingen etc.).

[Woudloper]

De reacties tot zover zijn erg verhelderend al zeg ik hetzelf en het idee van zo'n W3C NL stichting zou opzich een goed idee zijn, hoewel deze dat wel vanuit de bedrijven (middels geld o.i.d.) gesupport moet worden aangezien je anders een beetje in het niets een stichting hebt of het wordt voor iemand (net zoals bij de anti-spam stichting) erg veel vrije tijd die erin gestoken moet worden.

Zelf zouden we overigens ook wat kunnen doen door zomaar eens te brainstormen over wat van punten klanten kunnen vermelden in een offerte (soort van offerte checklist op het gebruk van standaarden) aangaande het gebruik van standaarden en daarbij hoe zij dat zouden kunnen controleren. Wellicht is het niet geheel handig voor de branche (of branchegenoten), maar het zou wel het gebruik van standaarden in Nederland kunnen vergroten. Ook zou je een stuk kunnen opstellen waarin je de meerwaarde van het gebruik van standaarden (anne heeft het al meerdere malen herhaald) beschrijft opdat klanten ook écht het nut zien van standaardengebruik.

[X-Lars]

I'm with Woudloper. Als je een goed stuk kunt opstellen over de meerwaarde van het gebruik van standaarden en vervolgens de klant laat kiezen of deze daar (gedeeltelijk) gebruik van wil maken dan kan iedereen gewoon zelf zijn prijs daarvoor bepalen. Misschien zullen maar weinig klanten het nut ervan inzien (dus het moet echt een goed stuk zijn), maar het is zeker een stap in de goede richting denk ik.

[T-MOB]

De keuze voor het inzetten van standaards zou imo niet de keuze moeten zijn van 'de klant'. Simpelweg omdat je niet kunt verwachten dat die er verstand van heeft en/of wil hebben. Als het verstand er was had de klant zélf ook wel een webpagina kunnen maken, niet?

Een extra stichting voor voorlichting over standaards lijkt me dan ook onnodig, de richtlijnen van het W3C zijn helder, goed beargumenteerd en erg toegankelijk. Ik kan me niet voorstellen dat een professioneel designer de weg naar het W3C niet weet...

Waar het dus om gaat is professionaliteit van de webdesignbureaus (he ander topic ;-)). Als er iets nieuws zou moeten komen dat is dat wat mij betreft een keurmerk voor webdesigners, net zoals dat er is voor makelaars, installatiebedrijven, etc. Zonder dat ik precies weet wat een NVM-makelaar precies onderscheid van een normale zou ik kiezen voor zo'n makelaar omdat de kwaliteit gewaarborgd is. Als zo'n keurmerk ingeburgerd raakt worden non-standard bureaus vanzelf weggeconcurreerd.

[X-Lars]

T-MOB schreef op 17 maart 2004 @ 13:54:
De keuze voor het inzetten van standaards zou imo niet de keuze moeten zijn van 'de klant'. Simpelweg omdat je niet kunt verwachten dat die er verstand van heeft en/of wil hebben. Als het verstand er was had de klant zélf ook wel een webpagina kunnen maken, niet?

De klant heeft geen technische kennis, maar termen als kostenbesparing op termijn, toegankelijkheid, flexibiliteit, uitbreidbaarheid, etc., etc. zijn heus wel goed uit te leggen.

Voor onderstaande zou dan een oplossing bedacht moeten worden. De idee is er wel (een keurmerk o.i.d.), maar de uitwerking/vorm kan alle kanten op. Hier kan ik als newbie heel weinig zinnigs over zeggen eigenlijk.

Een extra stichting voor voorlichting over standaards lijkt me dan ook onnodig, de richtlijnen van het W3C zijn helder, goed beargumenteerd en erg toegankelijk. Ik kan me niet voorstellen dat een professioneel designer de weg naar het W3C niet weet...

Waar het dus om gaat is professionaliteit van de webdesignbureaus (he ander topic ;-)). Als er iets nieuws zou moeten komen dat is dat wat mij betreft een keurmerk voor webdesigners, net zoals dat er is voor makelaars, installatiebedrijven, etc. Zonder dat ik precies weet wat een NVM-makelaar precies onderscheid van een normale zou ik kiezen voor zo'n makelaar omdat de kwaliteit gewaarborgd is. Als zo'n keurmerk ingeburgerd raakt worden non-standard bureaus vanzelf weggeconcurreerd.

De reacties tot zover zijn erg verhelderend al zeg ik hetzelf en het idee van zo'n W3C NL stichting zou opzich een goed idee zijn, hoewel deze dat wel vanuit de bedrijven (middels geld o.i.d.) gesupport moet worden aangezien je anders een beetje in het niets een stichting hebt of het wordt voor iemand (net zoals bij de anti-spam stichting) erg veel vrije tijd die erin gestoken moet worden.

[Verwijderd]

Annie schreef op 16 maart 2004 @ 21:37:
Dat meewerken gebeurt natuurlijk ook, alleen is het een geleidelijk proces.

Ja, en er mag achter dat proces best een beetje vaart gezet worden

[Verwijderd]

Wat ik me ook afvraag, is als je toch meer geld vraagt voor een XHTML compliant en een semantisch correcte website, wat krijgt de client dan als hij/zij niet meer betaalt? Een een-en al-tabellen-layout die niet semantisch correct is en zeker niet valideert aan op zijn minst XHTML 1.0 Transitional?

[AkaXakA]

Verwijderd schreef op 17 maart 2004 @ 07:36:
Een backgroundplaatje doet wonderen ;-). Zie http://alistapart.com/articles/fauxcolumns/ . En dat ik een aantal referenties gebruik die nu populair zijn, betekend niet dat het vorig jaar niet mogelijk was.

Daar had ik ook al aan gedacht, maar dat schaalt niet. De oplossing die ik nu heb (hoogte en breedte in EMs) is de enige die wel schaalt.

Ik zat er vanwege deze discussie echter wel aan te denken...maar dan zou ik niet zozeer kiezen voor fauxcolumns zoals ze in het article zijn gebruikt, maar meer zoals Douglass Bowman ze heeft gebruikt (en hij had ze al ver voor het article, viel me op)

Ik zou toch graag een concreet voorbeeld willen hebben. En over dat intranet, dat is absoluut niet te vergelijken met websites imo (denk aan voorafbepaalde resolutie, instellingen etc.).

Zoals ik al erbij schreef: Dat Intranet is een extreem voorbeeld die ik alleen gebruikte omdat het helder mijn punt kon illustreren.

PS. Door al die engelse termen in de text slaat mijn tweetaligheid door, dus excusses voor enige engelse woorden die door mijn post heen zitten.

[Verwijderd]

@AkaXakA, volgens mij zitten we toch best op dezelfde golflengte

@XPath fans: http://lists.w3.org/Archi...w-style/2003Jun/0110.html

Het lijkt mij ook belangrijk dat klanten zelf begrijpen wat de meerwaarden zijn van webstandaarden, maar uiteindelijk zullen dergelijke dingen toch ook moeten aankomen wij webdesigners/developers. HTML ((en CSS)) wordt over het algemeen als makkelijk afschildert en even snel op het laatste moment gedaan (+ een lading JS om alles een beetje te laten werken...).

[blaat]Wat imo heel erg zou helpen is als het vanuit de overheid opgelegd wordt, is dat alle overheid sites valid HTML 4.01 Strict of XHTML 1.0 Strict moeten zijn, dat ze toegankelijk moeten zijn zonder style sheets. Dat er gecontroleerd wordt op semantiek etc.[/blaat]

Wat ikzelf altijd zo jammer vind is dat ik weet dat een site ook sneller en kleiner had kunnen zijn. Meer toegankelijk, als de ontwerper (HTML'er) al alleen meer verstand had gehad van HTML. Zelfs Drempelsweg heeft hele rare dingen in de broncode, vooral het verzinnen van een leuke alternatieve tekst schijnt erg moeilijk zijn. Meestal staan er hele volzinnen (als bedrijven zich er een beetje mee bezig houden, anders is het attribuut gewoon niet gespecificeerd) waar \alt=""\ volstaat .

[T-MOB]

[blaat]Wat imo heel erg zou helpen is als het vanuit de overheid opgelegd wordt, is dat alle overheid sites valid HTML 4.01 Strict of XHTML 1.0 Strict moeten zijn, dat ze toegankelijk moeten zijn zonder style sheets. Dat er gecontroleerd wordt op semantiek etc.[/blaat]

In principe zouden ze dat al moeten zijn Overheidsinformatie moet voor iedereen (inclusief blinden en anders gehandicapten) toegankelijk zijn. OSOSS zou daartoe moeten bijdragen - maar ook daar een "brakke" website.

Wat ikzelf altijd zo jammer vind is dat ik weet dat een site ook sneller en kleiner had kunnen zijn.

Hier ben ik het maar gedeeltelijk mee eens. Voor statische content geldt zonder meer dat het correct gebruik van HTML en CSS "weight" kan besparen. Wordt het grootste deel van je content echter dynamisch gegenereerd dan krijg je enorme overhead op je CSS. Het stylesheet moet immers álle mogelijke elementen stylen die je kunt hebben.... Inline stylen zorgt er dan voor dat alleen de opmaak wordt geladen die nodig is.
Daarnaast moet je vaak lege elementen toevoegen om je layout flexibel te houden, CSS-zengarden is daarvan een goed (en dan nog statisch) voorbeeld. Neem één van de designs en je kunt een hoop HTML schrappen. Wil je ze allemaal houden dan zit je vast aan HTML "redundancy". Wil je dus dat je site volledig kan veranderen door het stylesheet dan zul je overbodige tags moeten invoegen.


Om meer op het algemene onderwerp te komen. Wat mij betreft liggen de zaken ongeveer zo:
1. Het naleven van 'standaards' levert niet direkt correcte HTML. Je kunt enorme tagsoep door de validator krijgen.

2. Je moet altijd afwegingen maken, hetzij tussen "overhead" en flexibiliteit , hetzij tussen nifty design en toegankelijkheid, hetzij tussen "foo" en "bar".

3. Als je je bewust bent van de afwegingen die je maakt en deze zorgvuldig maakt dan komt het wel goed met de website.

4. Standaarden zijn er niet voor niets.....

[ Voor 3% gewijzigd door T-MOB op 18-03-2004 01:40 . Reden: "/quote" werkt beter ]

[Mx. Alba]

T-MOB schreef op 18 maart 2004 @ 01:39:
Hier ben ik het maar gedeeltelijk mee eens. Voor statische content geldt zonder meer dat het correct gebruik van HTML en CSS "weight" kan besparen. Wordt het grootste deel van je content echter dynamisch gegenereerd dan krijg je enorme overhead op je CSS. Het stylesheet moet immers álle mogelijke elementen stylen die je kunt hebben.... Inline stylen zorgt er dan voor dat alleen de opmaak wordt geladen die nodig is.
Daarnaast moet je vaak lege elementen toevoegen om je layout flexibel te houden, CSS-zengarden is daarvan een goed (en dan nog statisch) voorbeeld. Neem één van de designs en je kunt een hoop HTML schrappen. Wil je ze allemaal houden dan zit je vast aan HTML "redundancy". Wil je dus dat je site volledig kan veranderen door het stylesheet dan zul je overbodige tags moeten invoegen.

Als je een externe stylesheet gebruikt wordt die één keer geladen en gecached door de browser. Het maakt dus weinig uit of je CSS licht of zwaar is. Natuurlijk is lichte CSS beter, maar zware CSS, eventueel met zaken die op de huidige pagina helemaal niet nodig zijn, is geen ramp...

Desnoods kan je je externe CSS opdelen in meerdere bestanden en dan dynamisch verschillende <link> tags genereren om alleen de nodige CSS in te laden, maar dat lijkt mij ook een minder dan optimale oplossing

[Genoil]

Mx. Alba schreef op 18 maart 2004 @ 08:12:
[...]
Desnoods kan je je externe CSS opdelen in meerdere bestanden en dan dynamisch verschillende <link> tags genereren om alleen de nodige CSS in te laden, maar dat lijkt mij ook een minder dan optimale oplossing

Mja dat is functionaliteit die m'n CMS ook heeft, maar ik steeds minder gebruik. Een feature die zeker geschrapt gaat worden in een volgende versie .
Als je zulk soort dingen (CSS verdelen over meerdere files) toch wilt doen, kun je denk ik beter slim gebruik maken van @import.

[ Voor 14% gewijzigd door Genoil op 18-03-2004 09:32 ]

[Spider.007]

Genoil schreef op 18 maart 2004 @ 09:30:
[...]


Mja dat is functionaliteit die m'n CMS ook heeft, maar ik steeds minder gebruik. Een feature die zeker geschrapt gaat worden in een volgende versie .
Als je zulk soort dingen (CSS verdelen over meerdere files) toch wilt doen, kun je denk ik beter slim gebruik maken van @import.

offtopic:
je Homepage is dood

[Genoil]

offtopic:
[quote]Spider.007 schreef op 18 maart 2004 @ 09:55:
[...]

je [afbeelding]Homepage is dood[/][/quote]


d'r staat nog een restje op www.doeds.com maar dat project is ook al zo lang dood...

[Verwijderd]

Ik vindt dat iedereen hier maar een beetje blindelings achter die standaarden aanrent.. http://gathering.tweakers.net/forum/list_messages/777206/ mischien oude post maar ik kan me der wel in vinden... et idee van css is wel goed (is iedereen et hier wel over eens geloof ik) maar de implementatie zuigt nogal een beetje in veel gevallen. Als een compleet artikel nodig hebt om de simpelste dingen uit te leggen (maak een paar kolommen) dan klopt er iets niet..

Daarnaast zijn veel argumenten om css te gebruiken in heel veel sites helemaal niet van toepassing. Als ik een webshop maak voor auto-onderdelen oid, waarom zou heel de wereld dat moeten kunnen lezen? Wat heeft een blinde nou aan auto-onderdelen? Of wie wil er nou vanuit ze hutje op de hei met ze telefoon een bodykit bestellen? Heel veel sites hebben er helemaal geen meerwaarde bij als deze op allerlei exotische apparatuur bekeken kunnen worden.

Maar goed, et is toch wel vooruitgang, ipv de spacer gif hebben we nu de spacer div die ervoor moet zorgen dat niet heel je design door elkaar loopt, en die hoef je mooi niet extra in te laden!

[Mx. Alba]

Om uit die andere thread, waar FURY het over had, te quoten:

Clay schreef op 30 juni 2003 @ 20:29:
Dat klopt. Ik zei ook al dat het lang zo erg niet is als de ellende met b.v. Netscape 4 (Of IE4 wat dat betreft). Css werkend krijgen vind ik ook wel een leukere "uitdaging" dan toen met html. De floats heb je wel gelijk in. Maar het blijven lastige dingen, zeker omdat mensen iets verwachten wat dus alleen in IE gebeurt, maar niet zo hoort.

Cascading Stylesheet:

div {
    margin:100px 0;
    height:100%;
}
/* of */
div {
    top:100px;
    bottom:100px;
}
/* zou allebei moeten werken */

De eerste geeft helaas toch een scrollbar, omdat 100% plus 100px meer is dan de schermhoogte. Alleen met een aangepaste boxmodel, of zonder doctype in IE werkt dat. De 2e werkt op zich wel, maar die kan je alsnog geen hoogte geven van 100% - 200px, en (wat ik ff had moeten zeggen excuses) het is met een position:absolute, en dat wil ik juist niet.

Dat probleem is eigenlijk vrij simpel op te lossen:

Cascading Stylesheet:

body {
    margin: 100px;
    padding: 0;
}
div {
    width: 100%;
    height: 100%;
}

Ik gebruik zulke code ook op één van mijn sites, werkt perfect. Moet je idd wel IE6 in quirks mode schoppen, maar iedereen die een beetje mooie CSS wil maken doet dat toch wel

[faabman]

Mx. Alba schreef op 18 maart 2004 @ 13:38:
Om uit die andere thread, waar FURY het over had, te quoten:


[...]


Dat probleem is eigenlijk vrij simpel op te lossen:

Cascading Stylesheet:

body {
    margin: 100px;
    padding: 0;
}
div {
    width=100%;
    height=100%;
}

Ik gebruik zulke code ook op één van mijn sites, werkt perfect. Moet je idd wel IE6 in quirks mode schoppen, maar iedereen die een beetje mooie CSS wil maken doet dat toch wel

hele discutable opmerking die je hier maakt i.e. in quirks gooien... standard compliance lijkt me een stuk gepaster, dan kun je tenminste een goede inschatting maken van de fouten die i.e. maakt...

ik neem aan dat die width=xxx een foutje is... hacks zijn niet echt aan te raden....

[Mx. Alba]

faabman schreef op 18 maart 2004 @ 13:50:

hele discutable opmerking die je hier maakt i.e. in quirks gooien... standard compliance lijkt me een stuk gepaster, dan kun je tenminste een goede inschatting maken van de fouten die i.e. maakt...

ik neem aan dat die width=xxx een foutje is... hacks zijn niet echt aan te raden....

euh, ja, die =jes waren idd stomme foutjes

Kijk, IE in quirks mode gebruikt het zelfde box model als IE5. Het is heel makkelijk om een style sheet te maken dat het zelfde doet in het IE5-boxmodel als in het W3C-boxmodel: gewoon ervoor zorgen dat je een element met een gedefiniëerde height of width geen padding of border meegeeft.

IE6 in zogenaamde standards compliant mode is allesbehalve standards compliant, en is compleet bug-ridden (bijvoorbeeld: als een link of een italic element line-breakt, wordt de parent een paar pixels breder, en komt er een horizontale scrollbar op de pagina omdat die verbreding van een paar pixels aan alle parent-elementen tot aan het html element wordt doorgegeven ), kan je echt veel beter quirks mode gebruiken.

Kijk naar http://forum-integration.info, die heb ik eerst geprobeerd in IE6 standards compliant mode, maar uiteindelijk heb ik toch moeten uitwijken naar quirks mode vanwege die bovengenoemde stupide bug...

[Verwijderd]

faabman schreef op 18 maart 2004 @ 13:50:
hele discutable opmerking die je hier maakt i.e. in quirks gooien... standard compliance lijkt me een stuk gepaster, dan kun je tenminste een goede inschatting maken van de fouten die i.e. maakt...

Je kunt heel goed valid (X)HTML en CSS schrijven die toch IE in quirks mode gooit. Zet bijvoorbeeld maar eens een comment voor de DOCTYPE.

[T-MOB]

Verwijderd schreef op 18 maart 2004 @ 14:57:
[...]

Je kunt heel goed valid (X)HTML en CSS schrijven die toch IE in quirks mode gooit. Zet bijvoorbeeld maar eens een comment voor de DOCTYPE.

Dat kan idd, maar het grote voordeel van IE uit quirksmode is dat ie dan hetzelfde box-model hanteert als de rest van de browsers. Ik zie niet in wat het voordeel is van verschillende box-interpretaties in verschillende browsers (het gaat in dit topic toch om standaarden). Zet dan gewoon een loose doc-type en forceer (-moz-)box-sizing: border-box in je css. Werkt het in ieder geval weer overal hetzelfde, niet?

[Mx. Alba]

T-MOB schreef op 18 maart 2004 @ 15:17:
Dat kan idd, maar het grote voordeel van IE uit quirksmode is dat ie dan hetzelfde box-model hanteert als de rest van de browsers. Ik zie niet in wat het voordeel is van verschillende box-interpretaties in verschillende browsers (het gaat in dit topic toch om standaarden). Zet dan gewoon een loose doc-type en forceer (-moz-)box-sizing: border-box in je css. Werkt het in ieder geval weer overal hetzelfde, niet?

Twee nadelen aan IE "compliance mode" :

1) IE5 valt buiten de boot.
2) IE6 in compliance mode barst van de bugs, zoals de al eerder beschreven italic-linebreak-bug.

IE in quirks mode heeft deze nadelen niet. En zoals ik al zei is het écht niet moeilijk om een CSS layout te maken die zowel in het W3C-boxmodel als in het IE6 QuirksMode (= IE5) -boxmodel het zelfde resultaat oplevert.

[Verwijderd]

In principe zouden ze dat al moeten zijn Overheidsinformatie moet voor iedereen (inclusief blinden en anders gehandicapten) toegankelijk zijn. OSOSS zou daartoe moeten bijdragen - maar ook daar een "brakke" website.

Wie is er verantwoordelijk voor de overheid sites dan?

Hier ben ik het maar gedeeltelijk mee eens. Voor statische content geldt zonder meer dat het correct gebruik van HTML en CSS "weight" kan besparen. Wordt het grootste deel van je content echter dynamisch gegenereerd dan krijg je enorme overhead op je CSS. Het stylesheet moet immers álle mogelijke elementen stylen die je kunt hebben.... Inline stylen zorgt er dan voor dat alleen de opmaak wordt geladen die nodig is.

En dat kan niet met CSS? Daarnaast heb je bij gestructureerde documenten/websites nooit verschillende style sheets per pagina nodig. Dan lijkt het me dat er sowieso iets niet klopt in de opbouw van de pagina (andere kleuren per pagina en plaatjes kan natuurlijk altijd).

1. Het naleven van 'standaards' levert niet direkt correcte HTML. Je kunt enorme tagsoep door de validator krijgen.

Eens, maar valideren is toch altijd beter dan niet valideren.

2. Je moet altijd afwegingen maken, hetzij tussen "overhead" en flexibiliteit , hetzij tussen nifty design en toegankelijkheid, hetzij tussen "foo" en "bar".

Oneens, waarom zou je dat moeten doen?

4. Standaarden zijn er niet voor niets.....

Volgens mij heeft FURY die niet helemaal begrepen

[Verwijderd]

Over IE6. Dat is m.i. alleen interessant als je ook echt gebruik kunt maken van die leuke dingen zoals het BODY element wat meer flexibel stylen. Als je IE5.x ook nog moet ondersteunen is het niet zo relevant.

Veel belangrijker is het dat niet buggy browsers in standard-compliant renderen, zodat je een beetje normaal kunt testen zonder van rare quirks last te hebben.

[Verwijderd]

Tussendoor eventjes wat leesvoer, wordt er niet teveel gefocused op standards en te weinig op user experience.

http://www.37signals.com/svn/archives/000600.php

[T-MOB]

2. Je moet altijd afwegingen maken, hetzij tussen "overhead" en flexibiliteit , hetzij tussen nifty design en toegankelijkheid, hetzij tussen "foo" en "bar".

Oneens, waarom zou je dat moeten doen?

OK, een voorbeeldje. Ik gebruik een FIR techniek om een menu op te maken. In een "normale" browser ziet dat er ongeveer zo uit:


Een tekst browser rendert netjes de namen van de links (lynx iig). Een "normale" browser met image support uit rendert echter dit:

Niet erg toegankelijk, niet?

Een toegankelijke oplossing is een inline image (ipv css zoals nu), wat weer ten koste gaat van flexibiliteit in het aanpassen van het design. Of je moet gaan zitten vogelen om de tekst achter het plaatje te krijgen waarvoor je op zijn minst 1 extra element nodig hebt..... Dat zijn de afwegingen die ik bedoel.

en @fury:

Wat heeft een blinde nou aan auto-onderdelen?

Met een toegankelijke site kan een blinde iig zélf uit maken dat ie niets aan je heeft.

[CrashOne]

En als je een alt tekst gebruikt?

[T-MOB]

CrashOne schreef op 19 maart 2004 @ 12:00:
En als je een alt tekst gebruikt?

Een toegankelijke oplossing is een inline image (ipv css zoals nu),

rmc

[oh,when?]

Als de TS trouwens nog ff een samenvatting van het topic kan maken en misschien nog aan kan geven of onze input het gewenste resultaat heeft gehad, nu er toch wel genoeg professionals hier zijn of haar mening heeft kunnen geven. Ben eigenlijk wel benieuwd

[Verwijderd]

Ik denk dat uit dit en het andere topic (wie heeft de grootste, etc.) blijkt dat "professioneel" Nederland erg conservatief is. Juist van grotere bedrijven verwacht je dat zei nieuwe dingen toepassen en onderzoeken. Het tegenovergestelde blijkt echter, anno 2004 vinden de meeste het nog steeds moeilijk om met CSS om te gaan en blijven tabellen toch de standaard bij de wat grotere bedrijven.

Niet alleen de rede dat het te moeilijk is wordt gegeven, ook het feit dat het voor grote websites eigenlijk helemaal niet belangrijk is heb ik voorbij zien komen. Dingen als schaalbaarheid hebben veel meer prioriteit (ik vraag me af wat een client-side scripter(/designer?) met schaalbaarheid te maken heeft, maar dat kan aan mij liggen).

Elk groter bedrijf heeft gewoon een "troebele" kijk op het web. Ze zijn al 10 jaar bezig met tabellen ontwerpen en dat werkt, dus waarom zou je verder kijken. De meeste mensen die nu beginnen lijken niet zo heel veel moeite te hebben met de keuze. Alhoewel het gebruik van CSS ze in het begin wel wat moeite kost, zien de meeste mensen het voordeel er van in.

Hier komen de meeste tegenargumenten een beetje op neer:

Since the web standards movement began, people have been saying W3C specs were irrelevant, everybody uses Netscape 4 Internet Explorer 4 5 6, the browsers won’t change, the browsers haven’t changed, okay the browsers have changed I stand corrected but do you realize how much money we make from knowing the 17 proprietary ways to code a web page, you people are fools, you people are bullies, you people are Nazis, validation doesn’t matter, there are no benefits, my client won’t let me, nobody cares, users don’t view source, everybody has high-bandwidth connections, everybody has Flash, blind people don’t buy my client’s product, if they didn’t want us using tables for layout they shouldn’t have uh, okay never mind that one, CSS doesn’t work, XHTML doesn’t work, IE handles XHTML the wrong way and therefore there’s no point in using XHTML, there’s no point in using CSS until all browsers support CSS3, there’s no point in using CSS if you have to compensate for potholes in IE’s support, and so on.

Bron: http://www.zeldman.com/daily/0404b.shtml#metrics

[Verwijderd]

Verwijderd schreef op 08 april 2004 @ 07:52:

Nounounou, dat is allemaal wel weer heel zwart wit. Zoals ik al eerder vermelde, en tevens Crisp, en Oh when. Het komt toch vooral aan op kan ik het vertrouwen, kan ik er een groot publiek meer bereiken waar ik daadwerkelijk wat meer aan heb (lees bijv. NS4 ondersteuning). En kan ik erop vertrouwen dat alles wat ik volgens de specs code ook daadwerkelijk volgens de specs werken. Dat is momenteel nog een best groot probleem vind ik zelf.

Hier komen de meeste tegenargumenten een beetje op neer:
[...]
Bron: http://www.zeldman.com/daily/0404b.shtml#metrics

Je pakt nu ook direct een lijstje argumenten van iemand die is bevooroordeeld. Als hij echt zo om kwaliteit gaf, had die ervoor gezorgd dat zijn boek wat steviger in elkaar was gezet, zodat die niet direct uit elkaar flikkerde toen ik de doos van Amazon open maakte en met een big smile het boek eruit pakte waar direct de hele zooi uit elkaar donderde omdat het niet volgens de standaard manier was gebonden. *eventjes stukje frustratie*.

pst... het boek zuigt ook nog eens..

[ Voor 8% gewijzigd door Verwijderd op 08-04-2004 10:17 ]

[faabman]

Verwijderd schreef op 08 april 2004 @ 07:52:
Ik denk dat uit dit en het andere topic (wie heeft de grootste, etc.) blijkt dat "professioneel" Nederland erg conservatief is. Juist van grotere bedrijven verwacht je dat zei nieuwe dingen toepassen en onderzoeken. Het tegenovergestelde blijkt echter, anno 2004 vinden de meeste het nog steeds moeilijk om met CSS om te gaan en blijven tabellen toch de standaard bij de wat grotere bedrijven.

Alles leuk en aardig, maar wat je hier zegt is dus gewoon bull . Een van de verschijnselen wat zich standaard voordoet wanneer bedrijven groter worden is bureaucratisering... Dit is op zichzelf geen negatief verschijnsel, maar heeft wel tot gevolg dat de procesverbetering en de innovaties vertragen... Daarnaast heb je het over onderzoek; het lijkt mij dat het www op dit moment voor veel bedrijven een zogenaamde cash-cow is en daarom is er geen behoefte aan "onderzoek"...

[Verwijderd]

Verwijderd schreef op 08 april 2004 @ 07:52:

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!"