Semantische HTML, CSS en jij

quote:

King_Louie schreef op donderdag 26 januari 2006 @ 23:33:
Tag is in het artikel cursief geschreven, het gaat hier immers om een attribuut, niet om een tag.

ah, mja, als je iemand meteen "veroordeeld" om het feit dat hij/zij een verkeerde term gebruikt, het gaat erom dat je de ander begrijpt, blijkbaar wist jij ook meteen dat het om het attribuut ging en niet om een element

quote:

King_Louie schreef op donderdag 26 januari 2006 @ 23:33:
[...]

Tag is in het artikel cursief geschreven, ..

offtopic:
En dat doet hij met em ipv i.

quote:

King_Louie schreef op maandag 23 januari 2006 @ 22:49:
Inmiddels begint het duidelijk te worden dat tables écht niet meer kunnen

Persoonlijk vind ik dit een fout statement, dat je mee moet gaan met je tijd daar kan ik inkomen, maar er is volgens mij nog altijd niets verkeerds om je website mooi met tables op te bouwen, wel rekening houdend met de nieuwigheden.

Want om dan even terug te vallen op je eerste zin, 'k weet niet of je het gemerkt hebt maar zelfs Tweakers.net maakt zelfs nog gebruik van tables, misschien zijn ze dit gelijdelijk aan aan't veranderen, ik weet het niet, maar wat maakt het veel uit, persoonlijk vind ik het belangrijker dat de website goed werkt en hij in de meeste browsers volledig goed werkt en hoe in qua code is opgebouwd, don't really care, zolang het maar vlot & logisch werkt.

quote:

Quist schreef op donderdag 26 januari 2006 @ 22:21:

Degene die beweerde in dit topic dat b en i overbodig zijn, is trouwens aanzienlijk in mijn aanzien gedaald.

Dat was ik. Er is altijd een reden om iets in bold of italics te zetten. En die reden moet je "beschrijven" met welk element dan ook. Of dat nu em is, of label, of blockquote.

En je maakt je zelf schuldig aan waar die meneer achter dat linkje voor waarschuwt. Dom een ander achterna lullen zonder te begrijpen waarom iets gezegd wordt, en alles blindelings geloven.

Cheatah wijzigde dit bericht 27-01-2006 11:49 (2%)
Reden: typo

quote:

imp4ct schreef op vrijdag 27 januari 2006 @ 02:29:
Persoonlijk vind ik dit een fout statement, dat je mee moet gaan met je tijd daar kan ik inkomen, maar er is volgens mij nog altijd niets verkeerds om je website mooi met tables op te bouwen, wel rekening houdend met de nieuwigheden.

En volgens mij is er niets verkeerds aan om een tekst document in een spreadsheet programma te maken

quote:

Want om dan even terug te vallen op je eerste zin, 'k weet niet of je het gemerkt hebt maar zelfs Tweakers.net maakt zelfs nog gebruik van tables, misschien zijn ze dit gelijdelijk aan aan't veranderen, ik weet het niet, maar wat maakt het veel uit,

het forum gebruikt alleen tables waar dit logisch is om een table te gebruiken, bekijk de source maar eens
de frontpage is een ander verhaal, maar ach het is altijd makkelijk om naar een ander te wijzen "kijk hun doen het ook fout!"

quote:

persoonlijk vind ik het belangrijker dat de website goed werkt en hij in de meeste browsers volledig goed werkt

ligt dat dan niet meer aan de kennis van de developer dat het al dan niet goed werkt? juist met tables krijg je vaak problemen als je iets ergens anders wilt hebben staan.

quote:

en hoe in qua code is opgebouwd, don't really care, zolang het maar vlot & logisch werkt.

ik vind onderhoud van de code belangrijker

Zie trouwens ook http://code.google.com/webstats/index.html waar het gebruik van tags (en dus enigzins de semantiek) is bepaald van 1 miljard webpagina's.

quote:

Quist schreef op donderdag 26 januari 2006 @ 22:21:
Geweldig dat Gordijnstok zo heerlijk die conservatieve houding aanhoudt. Ik ben het volledig met je eens dat die bandbreedte geen ene fluit scheelt en geen argument is voor semantiek. Het enige juiste en correcte argument is onderhoudbaarheid.

Ik vind dit nog steeds gelul. De bestandsgrootte heeft wel degelijk effect op de beleving van de gebruiker en je bandbreedte verbruik.

Dat je er geen exorbitant veel tijd aan moet besteden: ja, maar een beetje tijd lijkt me niet verkeerd. Je besteed toch ook tijd aan het compressen van afbeeldingen?

quote:

chem schreef op vrijdag 27 januari 2006 @ 09:55:
Zie trouwens ook http://code.google.com/webstats/index.html waar het gebruik van tags (en dus enigzins de semantiek) is bepaald van 1 miljard webpagina's.

Leuke aan deze analyse is dat ze ook aandacht hebben besteed aan de impact van de gevonden resultaten op HTML 5. zeker omdat hieruit heel duidelijk dat een aantal van de meest populaire classes hun weg terug gaan vinden naar de specs. (http://code.google.com/webstats/2005-12/classes.html)
Wat ze wel zelf aangeven is dat ze niet zien waarom een tag de class "button" of "link" toegewezen krijgt. vind ik raar, als je namelijk een css-based navigatiemenu ontwerpt zit deze er nog best vaak in.

quote:

Ik vind dit nog steeds gelul. De bestandsgrootte heeft wel degelijk effect op de beleving van de gebruiker en je bandbreedte verbruik.

Dat je er geen exorbitant veel tijd aan moet besteden: ja, maar een beetje tijd lijkt me niet verkeerd. Je besteed toch ook tijd aan het compressen van afbeeldingen?

Belangrijkste bij dit punt is dat het semantiek misschien wel een middel is om bestandsgrootte te verkleinen, maar dat het geen /doel opzich moet worden om middels semantiek je bestandsgrootte aan te pakken, dan zijn er simpelweg betere manieren.

Chem heeft ook geen ongelijk, het is onweerlegbaar dat een kleiner bestand sneller kan zijn.

Er zijn echter ook situaties te bedenken dat een groter bestand sneller kan zijn, of gevoelsmatig sneller aanvoelt omdat de browser het makkelijker kan renderen. Echter blijft het wel zo, de grootste vertragingen komen door het maken van verbindingen met een server, niet door transfersnelheden. Als je dus zoals Chem al aangaf een sprite model kunt gebruiken, dan win je al een hele hoop doordat je maar een enkele request nodig hebt.

Als je echter 30 resources moet downloaden, dan is het vooral de latency die hier de boventoon gaat voeren, kortom, verbinding maken, resultaat verkrijgen, verbinding sluiten. Niet alleen omdat je die verbinding al moet maken, maar ook omdat een browser maar simultaan twee connecties geopend kan hebben, dit is namelijk beschreven in de HTTP specificaties. Of er dan 10 of 20 kb binnengehaald moet worden is dan al een stuk minder belangrijk.

Dit is ook de reden dat een drukbezochte site als die van Microsoft Office, meerdere servers gebruikt om resources te leveren. Die connection limit is namelijk vastgesteld per domein, als je dus een www1, een www2, en een www3 gebruikt om je resources te leveren beschik je direct al over 8 simultane connecties.

Gordijnstok wijzigde dit bericht 27-01-2006 11:36 (4%)

quote:

Quist schreef op donderdag 26 januari 2006 @ 22:21:
Geweldig dat Gordijnstok zo heerlijk die conservatieve houding aanhoudt.
[...]

quote:

Gordijnstok schreef op donderdag 26 januari 2006 @ 22:55:
Ik kan natuurlijk ook heel makkelijk roepen, wat heb jij behalve je editor aan commerciele projecten door de jaren heen opgeleverd, maar ik ga proberen een constructieve reply te geven op je troll.
[...]

Ik moet Gordijstok hier toch gelijk geven

Inderdaad is het zo dat mensen met een dergelijk kennis-niveau moeilijk te vinden zijn, en daarbij is webdevelopment voor veel mensen ook gewoon 'just a job' en die zullen dus ook niet zo de drive hebben om nog in hun eigen vrije tijd zoveel mogelijk van die extra kennis te vergaren.
Voordat je echt alle ins en outs kent, alle browserquirks en bugs en ook nog op de hoogte bent (en blijft) van alle verdere ontwikkelingen ben je jaren bezig, ook buiten de 40 uur van je werk...

Als je eenmaal op dat niveau zit is het makkelijk om anderen af te vallen, maar dan vergeet je hoeveel tijd en moeite het je zelf heeft gekost om op dat niveau te komen.

Verder denk ik dat veel mensen die op zo'n manier met webdevelopment bezig zijn helemaal niet goed zullen presteren in een commerciele omgeving. Vaak zijn het puristen en perfectionisten terwijl in een commerciele omgeving juist het kunnen maken van concessies en overzicht kunnen houden op het grote geheel een belangrijke rol speelt.

quote:

crisp schreef op vrijdag 27 januari 2006 @ 11:34:
[...]


[...]

Ik moet Gordijstok hier toch gelijk geven

Inderdaad is het zo dat mensen met een dergelijk kennis-niveau moeilijk te vinden zijn, en daarbij is webdevelopment voor veel mensen ook gewoon 'just a job' en die zullen dus ook niet zo de drive hebben om nog in hun eigen vrije tijd zoveel mogelijk van die extra kennis te vergaren.
Voordat je echt alle ins en outs kent, alle browserquirks en bugs en ook nog op de hoogte bent (en blijft) van alle verdere ontwikkelingen ben je jaren bezig, ook buiten de 40 uur van je werk...

Als je eenmaal op dat niveau zit is het makkelijk om anderen af te vallen, maar dan vergeet je hoeveel tijd en moeite het je zelf heeft gekost om op dat niveau te komen.

Verder denk ik dat veel mensen die op zo'n manier met webdevelopment bezig zijn helemaal niet goed zullen presteren in een commerciele omgeving. Vaak zijn het puristen en perfectionisten terwijl in een commerciele omgeving juist het kunnen maken van concessies en overzicht kunnen houden op het grote geheel een belangrijke rol speelt.

Crisp, dat ligt er maar net aan in wat voor commerciele omgeving je werkt. Ik heb tot nu toe altijd nog in de luxe positie gezeten om te kunnen werken voor bedrijven die klein zijn en alleen werken met mensen die wel op dat niveau of er tegenaan zitten. Ik geef toe dat ik waarschijnlijk niet goed zal functioneren in een bedrijf als Lost Boys, gewoonweg omdat ik niet geloof in rampe-stampen en snel-snel iets uit de grond te stampen.

Gordijnstok, dat ik hier lang niet actief ben geweest wil niet zeggen dat ik stil gezeten heb. Ik heb in die tijd juist ontzettend veel extra geleerd. Misschien ben ik een beetje cru, maar ik bedoel het allemaal niet zo. Soms druk ik me nogal zwart-wit uit om het vuurtje aan te wakkeren; een van mijn vele gebreken. Ik ben er van overtuigd dat je goed bent in je werk en heb je nooit persoonlijk willen aanvallen. Wij twee werken nou eenmaal in twee verschillende werelden. Vanuit jou oogpunt kan ik best begrijpen dat je semantiek af en toe van ondergeschikt belang vindt.

chem: ja de bandbreedte scheelt wel een fluit, maar het ging me er om dat het niet het sterkste argument is.

Ik vind semantiek niet ondergeschikt. Dat heb ik ook in mijn betogen uiteen gezet, ik vind het juist belangrijk, sterker nog, zonder kun je geen referentiekader neerzetten om samen te werken.

Het enige wat ik constateer, is dat men er soms te makkelijk denkt dat het in organisaties wel even te gebruiken is, dat het zo te leren is, dat het een kwestie is van een paar weken praktijkervaring, en dat het per definitie een kostenbesparing oplevert die zijn weerga niet kent.

Vergeet niet, vroeger werd er ad hoc gewerkt. Je had een intake, er werden PSD's ontwikkeld, PSD's werden bij de ontwikkelafdeling neergemikt, en er waren geen eisen behalve dat het er exact hetzelfde uit moest zien. De tarieven zijn vaak nog gebaseerd op deze eenvoudige snelle adhoc aanpak.

Wat je nu hebt, is niet alleen die intake, maar ook het uiteenzetten van requirements. Wat verwacht ik van de code, wat verwacht ik van de css, wat verwacht ik van de onderhoudbaarheid, wat verwacht ik van de validatie, wat verwacht ik van coding standards, wat verwacht ik van benamingen, wat verwacht ik aan semantiek, etc. Dat zijn allemaal zaken die ik momenteel in een project briefing oplever, zodat de personen die ontwikkelen op papier hebben staan wat er van ze verwacht wordt.

Het heeft zijn voordelen, er is duidelijk een professionalisering gaande. Ik ben zelf 5 a 6 jaar geleden bezig geweest met onderzoek en onderhandelingen om een keiharde ISO certificering los te krijgen voor web ontwikkeling, en toen bleek al heel snel in gesprekken met de heren die daarover gingen, dat de eisen die worden gesteld ontzettend subjectief zijn.

Door al deze eisen die men tegenwoordig stelt, is het een stuk kostbaarder om een coachingstraject in te gaan. Het kost veel meer tijd om alleen al de theorie onder de knie te krijgen. Dan komt daar inderdaad nog een hele klap aan praktijkervaring om de hoek kijken, omgaan met browser bugs, omgaan met eventuele hacks, ... de routine. Hoe complexer de technologie wordt - en het wordt tegenwoordig al gezien als een vak op zich, vroeger kon iedereen wat in elkaar stampen - hoe hoger de learning curve wordt, en hoe hoger de aanloopkosten zijn.

Ik zie dat in het buitenland 2 personen 40 uur nodig hebben om iets te implementeren waar ik in 12 uur mee klaar was. Dat is gewoon een stuk communicatie, ervaring, en routine. Als ik ze had gevraagd om gewoon te zorgen dat het resultaat eruit moest zien als de PSD, dan waren ze ook maar 12 uur bezig geweest, daar neem ik echter geen genoegen mee omdat er kwaliteit moet worden geleverd.

Nu zijn die personen bijvoorbeeld pak hem beet 20 euro de uur, en een developer in Nederland zet je weg voor een euro of 80 a 90 de uur (dan praat ik hier puur over uurtarief). Die 40 uur, kost mij dus 800 euro. Als ik hier in Nederland een developer had neergezet koste me dat voor hetzelfde aantal uren minimaal 3600 euro. Als ik het voor elkaar kan krijgen dat de onervaren personen groeien in hun ervaring en er wellicht +/- 15 uur over gaan doen, dan kost mij dat nog maar 300 euro, voor een complete implementatie.

De enige manier om een referentiekader neer te leggen, is door een benadering van een coding standard te gebruiken; semantiek. Elke persoon kan schijnbaar zien dat een afbeelding een afbeelding is, en een artikel een artikel is, en een lijst een lijst is. Belangrijk is wel dat de voorbeelden (PSD's) kunnen worden begrepen op context. Men moet weten wat de content is, anders kan men er geen semantiek aan vast hangen. Bij een lijst moet dus duidelijk zijn, voor de ontwikkelaar dat alle elementen een relatie met een onderwerp hebben.

Ik haal nog een stukje aan:

quote:

Desondanks gebruiken wij het toch, we geloven in het brengen van de structuur, in de kostenbesparingen vanwege het overzicht, de bereikbaarheid van markup paden, en hopen op uiteindelijk meer ervaring. We zien semantisch gebruik niet zozeer als het gebruik van markup om zijn context, maar meer als gebruik van markup om zijn code standards. Wij moeten een kader hebben waarin we andermans werk eenduidig kunnen auditten, of een bepaalde stempel van kwaliteit kunnen drukken. Daarvoor hebben we richtlijnen nodig, en daarbij is semantiek ons middel om tot regels te komen voor die validatie.

Gordijnstok wijzigde dit bericht 27-01-2006 18:51 (38%)

Hmm, hoe staat het eigenlijk met de semantische html ondersteuning in de screenreaders zoals Jaws? De laatste keer dat ik daar naar keek was het nog niet echt fantastisch.

quote:

Quist schreef op vrijdag 27 januari 2006 @ 15:05:
[...]

Ik geef toe dat ik waarschijnlijk niet goed zal functioneren in een bedrijf als Lost Boys, gewoonweg omdat ik niet geloof in rampe-stampen en snel-snel iets uit de grond te stampen.

In elk project moet je consessies doen; de klant z'n wens, z'n budget, de planning & beschibare resources ... Ik geloof niet zo dat het het ideaal van welk bedrijf dan ook is om hatseflats dingen uit de grond te stampen, maar soms loopt het gewoon daar op uit. In die zgn professionele omgevingen (of dat nou Lost Boys, Clockwork, Backbase, of een kleiner bedrijf is) heb je gewoon je resources en je projecten. Je wil niet teveel resources overhebben (verspilde uren), en je wil er ook niet teveel tekort komen (dure freelancers), de ideale mix vinden is moeilijk. Als werknemer heb ik liever wat tijd over, dan kan ik ook nog eens wat studie doen etc. Als werkgever heb je uiteraard liever net ietsje teveel werk

En dit zegt nog niets over de technische inhoud van dat werk noch over de visie van het bedrijf in kwestie.

offtopic:
Het valt me wel op dat de meningen binnen het vak 'webdesign' zelfs op professioneel niveau wel erg ver uiteen lopen. Ik ben zelf maar een hobbyist. maar raak door alle uiteenlopende adviezen vaak de weg kwijt

Ik maak zelf alleen simpele dingen, maar probeer me wel aan semantische HTML en CSS te houden. Het enige echte argument hiervoor is dat het een hobby is en dat ik er iets van wil leren.

Om ff het verhaal 'tables zijn niet voor opmaak bedoeld' (hoe ik uiteraard ook ben begonnen) over te slaan, mijn aanloop tot waar ik nu ben:

Toen ik hoorde dat ik CSS moest gebruiken ipv het stylen in HTML, gebruikte ik vaak constructie's als:


HTML:

1	<element style="style">tekst/whatever</element>

Ik heb mij vaak afgevraagd waarom dit nuttig was totdat ik erachter kwam dat dit totaal niet nuttig is. Immers bepaald de HTML nog steeds hoe de pagina eruit ziet. Toen ben ik begonnen om classes te gebruiken en kreeg ik constructie's als:


Cascading Stylesheet:

1 2 3

body { font-size: 9pt; }

HTML:

1 2	tralalala<br> tralalala

En later:


HTML:

1 2	<span class="maintext">tralalala<br> tralalala</span>

Ook hierbij kreeg ik het gevoel dat ik niet goed bezig was, maar ja - veel pagina's deden het op deze manier. Op dit moment gebruik ik:


HTML:

1 2 3 4 5 6 7 8

<h1>Pagina titel</h1> <h2>Categorie titel</h2> <h3>Item 1 titel</h3> <p>Item 1 tekst 1</p> <p>Item 1 tekst 2</p> <h3>Item 2 titel</h3> <p>Item 2 tekst 1</p> <p>Item 2 tekst 2</p>

Ook gebruik ik standaard iets als:


HTML:

1 2 3 4 5 6 7 8 9 10

<div class="container">   <div class="header">   </div>   <div class="menu">   </div>   <div class="content">   </div>   <div class="footer">   </div> </div>

Nu vraag ik me af of ik een beetje op de goede weg ben, want ik zie nog 1000 andere mogelijkheden die misschien wel veel beter / semantischer kunnen zijn.

AlainS wijzigde dit bericht 29-01-2006 05:14 (12%)

Vreemd dat ik deze pagina hier nog nergens ben tegengekomen:
http://css-discuss.incutio.com/

De wiki van Css-discuss:

quote: css-discuss.org

css-discuss is a mailing list devoted to talking about CSS and ways to use it in the real world; in other words, practical uses and applications. While theory and ideas for the future are interesting, they do interfere with our mission to help people get the most out of CSS today, so we tend not to spend a lot of time on theory. There are other lists and groups for that sort of thing anyway.

quote:

AlainS schreef op zondag 29 januari 2006 @ 05:14:
Ook gebruik ik standaard iets als:


HTML:

1 2 3 4 5 6 7 8 9 10

<div class="container">   <div class="header">   </div>   <div class="menu">   </div>   <div class="content">   </div>   <div class="footer">   </div> </div>

Nu vraag ik me af of ik een beetje op de goede weg ben, want ik zie nog 1000 andere mogelijkheden die misschien wel veel beter / semantischer kunnen zijn.

Bij semantische HTML hoort ook de kunst van het weglaten. Zo is een menu meestal een UL (Unordered List). Dit is van zichzelf al een blockelement, waarom er dan nog een DIV omheen zetten? Je hebt het niet nodig, dus weg ermee!

Zelfde geldt voor de header. Meestal is dit alleen een logo, dit kun je in mijn ogen het beste oplossen door daar je H1 neer zetten met de naam van je website/bedrijf/etc. en deze met een image replacement techniek zoals FIR vervangen door de afbeelding. Weer een onnodige DIV weg. *

En misschien is zelfs die footer ook niet nodig. Want als je daar alleen een paragraph in zou zetten, wat dus ook al een blockelement is, waarom er dan nog een DIV omheen gooien?

Het is dus belangrijk dat je goed naar een design kijkt om te bepalen hoe je het op gaat bouwen, in plaats van dat je weer het bekende raster maakt waar je je plaatjes in plakt. Op deze manier zul je zien dat de opmaak van je pagina een stuk efficienter in elkaar steekt.

* FIR maakt gebruik van het SPAN element binnen de H1 om de tekst onzichtbaar te maken. Hier voeg je dus weer een element toe dat eigenlijk alleen voor opmaak dient. Je zou hier dus wat mij betreft beide kunnen doen: de DIV laten staan, daar een achtergrondafbeelding op instellen en de H1 met daarin de tekst onzichtbaar maken. Of de DIV weghalen, op de H1 de achtergrond afbeelding instellen en met de SPAN de tekst onzichtbaar maken.

quote:

King_Louie schreef op zondag 29 januari 2006 @ 10:15:
[...]

waarom er dan nog een DIV omheen zetten? Je hebt het niet nodig, dus weg ermee!

Hmm, zo had ik het nog niet bekeken. Aan de andere kant: Is het niet eenduidiger als je div's gebruikt om te positioneren? Als ik <ul> of <p> tegen kom moet ik niet denken aan de positie terwijl dit bij een div wel zo is. Of is dit een rare gedachtenkronkel?

quote:

AlainS schreef op zondag 29 januari 2006 @ 13:01:
[...]


Hmm, zo had ik het nog niet bekeken. Aan de andere kant: Is het niet eenduidiger als je div's gebruikt om te positioneren? Als ik <ul> of <p> tegen kom moet ik niet denken aan de positie terwijl dit bij een div wel zo is. Of is dit een rare gedachtenkronkel?

Voor een machine maakt een element als DIV niet uit, het heeft geen speciale waarde. Het is er enkel om andere elementen te bevatten. Dat laat dus enkel jou als developer of een nieuwsgierige bezoeker over. Als jij voor jouw eigen gemak bij het developen een DIV wilt gebruiken, dan is daar geen enkel bezwaar (op bestandsgrootte na) tegen. Als je zelf prima zonder de extra elementen kan werken, dan moet je dat zeker doen. Dat iemand anders die jouw werk bekijkt en niet begrijpt hoe je die UL daar zo netjes op z'n plek hebt gekregen is niet iets waar je mee moet zitten

quote:

King_Louie schreef op zondag 29 januari 2006 @ 10:15:
[...]
Bij semantische HTML hoort ook de kunst van het weglaten. Zo is een menu meestal een UL (Unordered List). Dit is van zichzelf al een blockelement, waarom er dan nog een DIV omheen zetten? Je hebt het niet nodig, dus weg ermee!

Aan de andere kant hebben div's wel een semantische waarde, hoewel gering. Ze geven immers divisies aan (een zeer rekbaar begrip, waardoor div's vaak gebruikt worden om aanhangpunten voor je CSS te maken). In dat opzicht vind ik een menu toch een compleet andere 'divisie' dan de eigenlijke inhoud, waardoor het een en ander te zeggen valt voor het gebruik van een div in de situatie die jij aanhaalt.

Dat soort discussies zijn wat mij betreft echter "gerommel in de marge". Het is al mooi als er uberhaupt op semantiek wordt gelet. Mierenneuken over semantiek is natuurlijk zonde van tijd en geld voor bedrijven (iets waar Gordijnstok denk ik ook deels op doelt) en ook zal de gemiddelde kijk-ik-heb-een-website-hobbyist niet gillend in de nacht wakker worden, druipend van het angstzweet, omdat hij wellicht beter voor een extra div had kunnen kiezen in plaats van een serie CSS-hacks.

Ik zien mijn collega's af en toe constructies als
code:

<p class="normal">tekst</p>

gebruiken en dat dan dus op ELKE <p> die er langs komt en uiteraard als je dan een normale <p> er tussendoor laat gaan dan krijgt die standaard Times in zwart op witte achtergrond... dan lopen de rillingen over m'n rug en het is ze ook niet uit te leggen dat het idee van CSS is dat je default dingen juist al zo mooi kunt vast leggen.
Daarnaast krijg je dan in dat er in door loopjes gegenereerde tabellen (ja, met echte tabulaire data ) waarin dit soort dingen wordt gedaan:

code:

<tr style="background: #CFCFCF; color: #747474; text-align: left; font-size: 8pt;"><td style="padding: 0px 0px 0px 5px;">Cell 1A</td><td align="center">Cell 1B</td><td align="right" style="padding: 0px 5px 0px 0px;">Cell 1C</td><td align="right" style="padding: 0px 5px 0px 0px;">Cell 1D</td></tr>
<tr style="color: #747474; text-align: left; font-size: 8pt;"><td style="padding: 0px 0px 0px 5px;">Cell 2A  <span style="font-weight: bold; font-size: 10; color : red; background: transparent; font-style: italic;"> 2Aextra</span></td><td align="center">Cell 2B</td><td align="right" style="padding: 0px 5px 0px 0px;">Cell 2C</td><td align="right" style="padding: 0px 5px 0px 0px;">Cell 2D</td></tr>

(Even de echte waardes vervangen door 'Cell xy')
Heb niet zoveel nekharen, maar die staan wel allen paraat dan.
Aan de andere kant, zo gauw ik er dan even wat classjes bij maak dan besparen we meteen op zo'n pagina 40KB en kan ik weer even trots op mezelf zijn
Zou er zoiets van maken:

code:

<tr class="alt"><td class="colA">Cell 1A</td><td class="colB">Cell 1B</td><td class="colC">Cell 1C</td><td class="colD">Cell 1D</td></tr>
<tr><td class="colA">Cell 2A  <span class="extra">2Aextra</span></td><td class="colB">Cell 2B</td><td class="colC">Cell 2C</td><td class="colD">Cell 2D</td></tr>

(waarbij colA en dergelijke uiteraard nuttigere namen zijn in de praktijk, helaas is voor elke kolom wel weer een opmaak nodig, jammer dat <col> en <colgroup> zo goed als niet werken - opdrachtgevers uitleggen dat dat wat zij vragen aan uiterlijk niet nuttig is is helaas ondoenlijk)

Daarnaast zit iedereen uiteraard wel eens vast met zaken die je alleen via omwegen voor elkaar krijgt. Bijvoorbeeld een drie koloms layout... meestal kiezen we dan toch voor een tabel dan voor de bekende faux-columns oplossingen. Daarbij komt dat de ontwerpen die wij aangeleverd krijgen (wij bouwen ook alleen maar) over het algemene op een grid uitgelijnd zijn en je 't wel te horen krijgt als zaken niet met elkaar lijnen. Ik ben zelf erg pro-goed-gebruik-van-html en de meeste zaken die ik zelf maak lukt dat ook wel goed. Maar zoals al eens genoemd: als je moet kiezen tussen uren divjes uitlijnen en een paar minuten table bouwen en dan in de baas z'n tijd.

quote:

leipie schreef op zondag 29 januari 2006 @ 18:01:
code:

<tr class="alt"><td class="colA">Cell 1A</td><td class="colB">Cell 1B</td><td class="colC">Cell 1C</td><td class="colD">Cell 1D</td></tr>
<tr><td class="colA">Cell 2A  <span class="extra">2Aextra</span></td><td class="colB">Cell 2B</td><td class="colC">Cell 2C</td><td class="colD">Cell 2D</td></tr>

Het zal misschien te maken hebben met de keuze van de namen die - zoals je zelf aangeeft - nuttig zouden moeten zijn. Het kan ook te maken hebben met mijn onervarendheid. Maar ik snap _echt_ niet wat dit stukje code moet doen. En dat is imho wat semantiek betekent.

quote:

AlainS schreef op zondag 29 januari 2006 @ 20:33:
[...]


Het zal misschien te maken hebben met de keuze van de namen die - zoals je zelf aangeeft - nuttig zouden moeten zijn. Het kan ook te maken hebben met mijn onervarendheid. Maar ik snap _echt_ niet wat dit stukje code moet doen. En dat is imho wat semantiek betekent.

Dit zijn twee rijen met een aantal kolommen uit een tabel, met daarop gruwelijk veel classes toegepast.

quote:

King_Louie schreef op zondag 29 januari 2006 @ 21:26:
[...]

Dit zijn twee rijen met een aantal kolommen uit een tabel, met daarop gruwelijk veel classes toegepast.

De tr en td's had ik idd ook herkend.

quote:

King_Louie schreef op zondag 29 januari 2006 @ 21:26:
[...]

Dit zijn twee rijen met een aantal kolommen uit een tabel, met daarop gruwelijk veel classes toegepast.

Het zou idd een stuk minder kunnen; zelf gebruik ik liever een stukje eenvoudige javascript (icm cssQuery) die voor domme browsers (lees: IE) het eea. via JS emuleert. Omdat IE7 die selectors zelf al snapt.

Ik zet liever alles kaal op (de HTML dus), doe de opmaak met bv. firefox, of safari/opera, met css2.1 en css3 selectors. Eerst uitzoeken wat je allemaal nodig hebt. Daarna pragmatisch kijken of je de tekortkomingen in sommige browsers met JS oplost, met een col-class, of wellicht met een class in de HTML zelf.

Ik heb het gevoel, en meer is het ook niet, dat de HTML daarmee langer meegaat; zodra browsers (behalve IE, i know) de CSS3 technieken bv. gaan ondersteunen hebben ze de JS niet meer nodig; dan hoef ik enkel aan te geven, wanneer het mij dunkt, dat een bepaalde versie bepaalde fixjes niet meer nodig heeft.

Hmm, je vermelding van cssQuery is erg interessant. Binnenkort maar eens naar kijken