Semantische HTML, CSS en jij

Inmiddels begint het duidelijk te worden dat tables écht niet meer kunnen, en beginnen steeds meer developers over te schakelen op CSS-based websites. Helaas is het table gebruik diep genest in de genen van menig webdeveloper, en worden er nog steeds lelijke DIV/SPAN constructies bedacht om alles er maar uit te laten zien zoals de designer het wil.
Tuurlijk, het is niet echt een verbetering, maar het is een begin. De webdevelopers leren de wondere wereld van CSS en de bijbehorende mogelijkheden kennen, en ontdekken dat CSS verder gaat dan je plaatjes slicen om ze maar in een raster op je site te zetten. CSS biedt de mogelijkheid om een element dat je anders nooit gebruikt zou hebben vanwege de uiterlijke opmaak ervan, compleet naar jouw wensen te stylen.

En hiermee zijn we aangekomen bij een heel ander ontwerpen. Namelijk het ontwerpen van de opmaak van je inhoud, want dat is waar HTML (HyperText Markup Language) ooit voor bedoeld was! De titel van een stuk tekst ziet er met <span style="font-weight: bold">Titel</span> misschien voor jou goed uit, maar je hebt hiermee nog steeds niet omschreven dat het hier ook daadwerkelijk om een titel gaat. Hier zijn die lelijke H1 t/m H6 headers voor bedacht. Met een beetje CSS zien ze er precies hetzelfde uit als het voorgaande voorbeeld, maar nu weten ook zoekmachines, screenreaders en browsers zonder CSS ondersteuning (ja, die bestaan) dat het hier om de kop van een stuk tekst gaat. Introducing: semantische HTML.

Mocht je nu denken, leuk kerel, maar dit wist ik al, dan zul je ongetwijfeld weten dat je bij semantische HTML in combinatie met CSS soms nog voor interessante problemen komt te staan. Want waar je vroeger gewoon een table voor gebruikte blijk je het nu met een UL op te moeten lossen. En dat is lastig, want tables hadden als grote voordeel dat ze altijd precies deden wat jij wilde. Die tijden zijn nu voorbij. Om tegenwoordig een design semantisch correct en bovendien niet spuuglelijk te krijgen moet je als webdeveloper over een flink arsenaal aan kennis en truuks beschikken om je maar door alle bochten te wringen die opstandige elementen en koppige browsers met zich meebrengen.

En met die laatste zin ben ik dan eindelijk aangekomen bij de hele reden dat ik dit topic geopend heb. Er zijn op het internet talloze blogs te vinden waarop "self-proclaimed experts" hun mening spuien over wat nu toch de perfecte oplossing voor een specifiek probleem is. Die meningen komen vrijwel nooit overeen, en staan regelmatig lijnrecht op elkaar. Nu is het heel handig om vanaf je blog de wereld te verbeteren, maar in de praktijk werkt het vaak net even wat anders. Daarom wil ik hier, vanuit dit topic, discussies gaan starten waarin we veelvoorkomende HTML/CSS problemen inclusief de mogelijke oplossingen bespreken, om zo een overzicht te krijgen van bruikbare technieken inclusief valkuilen en bijkomstige problemen. Want geen oplossing is perfect, maar misschien wel precies wat jij zocht voor jouw situatie.

Om te voorkomen dat alle discussies door elkaar gaan lopen wordt er voor iedere discussie een nieuw topic geopend. Als je zo'n topic opent, meldt het dan hier zodat we vanuit dit topic een lijst van lopende discussies bij kunnen houden. Dit kan dan tevens als naslagwerk dienen.

Aangezien de TS altijd als eerste de klos is, zal ik het eerste topic openen over de opmaak van formulieren.

Topics
[Semantiek] Formulieren
[semantiek] klikpad in html


Links
Andere sites/documenten die bijdragen aan de semantiek discussie:
Uitleg over semantiek en de meerwaarde ervan: http://home.parse.nl/~michiel/semantiek.html

Mooie voorbeelden van scheiding van data en presentatie: http://www.csszengarden.com/ en http://www.mezzoblue.com/zengarden/alldesigns/official/

Webzine over webdevelopment: http://www.alistapart.com

Zeer uitgebreide site over CSS, JavaScript, overzichten van browsereigenaardigheden, noem maar op: http://www.quirksmode.org

Victor wijzigde dit bericht 25-01-2006 18:33 (11%)
Reden: Links toegevoegd

Mooi topic! Ik zou graag een discussie zien over menu's. Naast formulieren een veelbesproken onderwerp. Ik heb tot nu toe platte menu's gezien, menu's in een (al dan niet geneste) ul-li structuur, en menu's gemaakt m.b.v. een definition list. (dl met daarin dt en dd elementen). Waarschijnlijk kan iemand anders hier beter een topic over starten dan ik, maar ik gooi vast een balletje op.

joostbastings wijzigde dit bericht 23-01-2006 23:36 (29%)

quote:

joostbastings schreef op maandag 23 januari 2006 @ 23:34:
Mooi topic! Ik zou graag een discussie zien over menu's. Naast formulieren een veelbesproken onderwerp. Ik heb tot nu toe platte menu's gezien, menu's in een (al dan niet geneste) ul-li structuur, en menu's gemaakt m.b.v. een definition list. (dl met daarin dt en dd elementen)

Ik zou zeggen, open een topic (verwijs even naar dit topic) en deel je ideeën

Meld het even hier als je een topic opent zodat ik het toe kan voegen aan de lijst van topics

quote:

King_Louie schreef op maandag 23 januari 2006 @ 23:36:
[...]

Ik zou zeggen, open een topic (verwijs even naar dit topic) en deel je ideeën

Meld het even hier als je een topic opent zodat ik het toe kan voegen aan de lijst van topics

Als niemand dat voor morgenavond heeft gedaan ga ik mijn best doen. Heb er nu even geen tijd voor, en wil het wel goed doen

Goed initiatief, ik ben de laatste tijd ook wat serieuzer bezig met semantiek, aangezien dit ook de broncode zelf leesbaarder maakt. Wellicht als ik tijd heb, dat ik ter aanvulling met een goed semantisch voorbeeld kan komen.

En misschien nog een link om toe te voegen:
http://www.csszengarden.com/ (met uiteraard de links naar alle stylesheets: http://www.mezzoblue.com/zengarden/alldesigns/official/)

Deze kun je er ook gelijk aan toevoegen: [semantiek] klikpad in html

Zen Garden is een absolute kutsite als je naar de markup gaat kijken. Erg kneedbaar, dat wel. Maar ook bomvol nutteloze elementen die daarvoor zijn toegevoegd. Leuk als geinige demonstratie, slecht als voorbeeld.

Dit topic begint met "Inmiddels". Nou sorry, maar je bent meer dan 4 jaar te laat met dit topic. Ik geloof dat het ook echt meer dan 2 jaar geleden is sinds ik hier voor het laatst écht over gediscussieerd heb.

Het is eigenlijk allemaal zo vreselijk simpel. De meesten van ons hebben een verkeerd beeld van HTML. Leer af wat je geleerd hebt, begin bij het begin, laat alles bezinken, en probeer te begrijpen waarom. Daarna is het niet meer moeilijk om te begrijpen dat elementen als i en b niet in HMTL thuishoren, maar vooral ook dat em en strong die twee elementen niet vervangen. Het is ook niet meer moeilijk om te begrijpen waarom een navigatiemenu wel in een lijst mag. En waarom het table element met zijn hele familie absoluut belangrijk zijn.

Maar als ik ergens ziek van word, is als mensen zeggen dat tabellen niet meer mogen, dat divjes de bom zijn, dat frames uit zijn, en dat iedereen het idee heeft dat dit allemaal nét bekend is geworden.

Cheatah wijzigde dit bericht 24-01-2006 00:16 (2%)
Reden: 4 zelfs alweer

Waar ik me gewoon aan erger zijn die hobbyistende fanboys die alleen maar kijken naar uberperfectie. Tuurlijk, als bedrijf moet je bij grote opdrachten een zekere semantische kwaliteit kunnen maken. Maar om continu je CSS compatible te maken in diverse browsers is imho op dit moment een te grote tijdvreter voor kleinere projecten.

Het is gewoonweg niet goed genoeg gestandariseerd. Iedere browser reageert er anders op. Je kunt wel zeggen "veel oefenen, dan leer je precies hoe je het binnen een aantal browsers gelijk eruit laat zien en gaat het sneller", maar voor niet-puristische bedrijven bij eenvoudige opdrachten is het dikke overkill.

Dus: Als je je baas (of jezelf) deze alternatieven geeft:
- 5 uur semantisch correcte HTML en compatible in diverse browsers
- 1 uur aardig semantische HTML en compatible in diverse browsers
Dan weet ik wat mijn baas zou verkiezen.

"Maar ahh dat is zielig voor bijvoorbeeld braille en PDA gebruikers"
Ooit gehoord van P5 en P95?

flashin wijzigde dit bericht 24-01-2006 00:30 (23%)

quote:

flashin schreef op dinsdag 24 januari 2006 @ 00:26:

Het is gewoonweg niet goed genoeg gestandariseerd. Iedere browser reageert er anders op. Je kunt wel zeggen "veel oefenen, dan leer je precies hoe je het binnen een aantal browsers gelijk eruit laat zien en gaat het sneller", maar voor niet-purerende bedrijven bij eenvoudige opdrachten is het dikke overkill.

Als je er je werk van maakt, moet je gewoon zorgen dat je het beheerst. Bij 9 van de 10 websites heb ik geen grote problemen hoor. Alleen die 1e keer dat de grafisch ontwerper echt iets heel aparts in elkaar zet moet je extra goed opletten.
En ja, er mag ook best weleens gezegd worden dat bepaalde website ontwerpen niet deugen. Dat is ook weleens een reden om met je markup in de problemen te kunnen komen.

quote:

Dus: Als je je baas (of jezelf) deze alternatieven geeft:
- 5 uur semantisch correcte HTML en compatible in diverse browsers
- 1 uur aardig semantische HTML en compatible in diverse browsers
Dan weet ik wat mijn baas zou verkiezen.

Alsof je voor de gemiddelde website 5 uur aan HTML besteed. Ik heb natuurlijk geen idee wat jij voor werk doet, maar bij de meeste websites hoef ik niet meer dan een paar regels HTML te schrijven, en een stylesheet aanpassen. Véél dingen doe je 1 keer, en voor de rest kun je een hoop recyclen.
Je mag je best ergeren aan mensen die volgens jou mierenneuken, maar andersom mag je je ook weleens afvragen of je de boel zelf niet opblaast. De meeste HTML stelt echt niet veel voor, en schud je zo uit je mouw.

Cheatah wijzigde dit bericht 24-01-2006 00:35 (32%)

Ik geef even als voorbeeld, dit forum. Hartstikke goed dat het semantisch zo correct is, het is indrukwekkend zelfs. Maar volgens mij heeft het wel een poosje geduurt voordat het compleet compatible was. Dat is mijn grootste probleem.

quote:

Alsof je voor de gemiddelde website 5 uur aan HTML besteed. Ik heb natuurlijk geen idee wat jij voor werk doet, maar bij de meeste websites hoef ik niet meer dan een paar regels HTML te schrijven, en een stylesheet aanpassen. Véél dingen doe je 1 keer, en voor de rest kun je een hoop recyclen.

Nee gemiddeld niet. Maar de ontwerpen zijn vaak zo divers dat het niet altijd recyclebaar zou kunnen zijn.

quote:

Je mag je best ergeren aan mensen die volgens jou mierenneuken, maar andersom mag je je ook weleens afvragen of je de boel zelf niet opblaast. De meeste HTML stelt echt niet veel voor, en schud je zo uit je mouw.

Ik hou af en toe wel van overdrijven, zeker als er geen duidelijke tegenstander is (zeker hier kom je die niet veel tegen imho) .

flashin wijzigde dit bericht 24-01-2006 00:39 (63%)

quote:

Cheatah schreef op dinsdag 24 januari 2006 @ 00:14:
Dit topic begint met "Inmiddels". Nou sorry, maar je bent meer dan 4 jaar te laat met dit topic. Ik geloof dat het ook echt meer dan 2 jaar geleden is sinds ik hier voor het laatst écht over gediscussieerd heb.

Het leeft echter nog steeds, en dus leek me dit een nuttige bijdrage. Prima als je dit niet meer interessant genoeg vindt om over te discussieren, maar die mededeling op zich is compleet irrelevant.

quote:

Maar als ik ergens ziek van word, is als mensen zeggen dat tabellen niet meer mogen, dat divjes de bom zijn, dat frames uit zijn, en dat iedereen het idee heeft dat dit allemaal nét bekend is geworden.

Dat wordt in dit topic dan ook nergens gesuggereerd.

quote:

flashin schreef op dinsdag 24 januari 2006 @ 00:26:
Waar ik me gewoon aan erger zijn die hobbyistende fanboys die alleen maar kijken naar uberperfectie. Tuurlijk, als bedrijf moet je bij grote opdrachten een zekere semantische kwaliteit kunnen maken. Maar om continu je CSS compatible te maken in diverse browsers is imho op dit moment een te grote tijdvreter voor kleinere projecten.

Aansluitend bij Cheatah; dat is gewoon een kwestie van ervaring, webdevelopment is niet voor niets een vak (en vervang "diverse browsers" maar door "Internet Explorer" )

Ik ben wat dat betreft eigenlijk best blij met de huidige ontwikkeling richting standards-based development. Het kaf wordt daardoor nu van het koren gescheiden; iemand als Frontpage/Dreamweaver expert, Photoshop-slizer en/of met enkel copy/paste skillz komt straks gewoon niet meer aan de bak, en daar ben ik niet rouwig om

quote:

flashin schreef op dinsdag 24 januari 2006 @ 00:37:
Ik geef even als voorbeeld, dit forum. Hartstikke goed dat het semantisch zo correct is, het is indrukwekkend zelfs. Maar volgens mij heeft het wel een poosje geduurt voordat het compleet compatible was.

Dat valt best mee kan ik je uit eigen ervaring vertellen. Uiteraard is en was IE een bitch, maar de meeste tijd is gaan zitten in het feit dat dit forum gewoon uit ontzettend veel templates bestaat (en dat ik het volledig in eigen vrije tijd heb moeten doen).
Ik kan niet ontkennen dat ik er veel van geleerd heb, maar van die ervaring heb ik nu weer ontzettend veel voordeel...

crisp wijzigde dit bericht 24-01-2006 00:50 (28%)

quote:

crisp schreef op dinsdag 24 januari 2006 @ 00:45:

Dat valt best mee kan ik je uit eigen ervaring vertellen. Uiteraard is en was IE een bitch, maar de meeste tijd is gaan zitten in het feit dat dit forum gewoon uit ontzettend veel templates bestaat (en dat ik het volledig in eigen vrije tijd heb moeten doen).
Ik kan niet ontkennen dat ik er veel van geleerd heb, maar van die ervaring heb ik nu weer ontzettend veel voordeel...

De basis zat natuurlijk in een paar uurtjes in elkaar, dat stelt ook nooit veel voor. Het is precies wat je zegt: de hoeveelheid verschillende templates.
Maar had dat met tabellen nou echt minder tijd gekost?
Helaas weet ik ook niet wat er uiteindelijk op het gebied van bandbreedte bespaard is.
Overigens zitten de huidige templates vast nog vol met compromissen, wat geen wonder is met zo'n groot, divers en vooral kritisch publiek.

quote:

Ik hou af en toe wel van overdrijven, zeker als er geen duidelijke tegenstander is (zeker hier kom je die niet veel tegen imho) .

Ah, dat mag ik zelfs wel. Maar in dit geval zou ik moeten beweren dat de meeste mensen hiet het licht al hebben gezien nadat een aantal fanatiekelingen er en lange, lange tijd op gehamerd hadden

quote:

Cheatah schreef op dinsdag 24 januari 2006 @ 00:58:
[...]

De basis zat natuurlijk in een paar uurtjes in elkaar, dat stelt ook nooit veel voor. Het is precies wat je zegt: de hoeveelheid verschillende templates.
Maar had dat met tabellen nou echt minder tijd gekost?

Nee, dat had juist meer tijd gekost. Het aanpassen en maken van templates voor React 1.9.4 was bijvoorbeeld voor de huidige markup zo gebeurd, maar backporten naar de oude paarse table-based template kostte minstens 2x zoveel tijd...

quote:

Helaas weet ik ook niet wat er uiteindelijk op het gebied van bandbreedte bespaard is.

Zo'n 20% gok ik, maar dat is inmiddels wel weer opgevuld met extra functionaliteit

quote:

Overigens zitten de huidige templates vast nog vol met compromissen, wat geen wonder is met zo'n groot, divers en vooral kritisch publiek.

true

quote:

crisp schreef op dinsdag 24 januari 2006 @ 00:45:
[...]

Aansluitend bij Cheatah; dat is gewoon een kwestie van ervaring, webdevelopment is niet voor niets een vak (en vervang "diverse browsers" maar door "Internet Explorer" )

Internet Explorer 6 geeft voor mij meestal geen problemen die niet vrij eenvoudig op te lossen zijn, het zijn vaak oudere versies van IE maar ook Opera die echt lastig zijn. Nu kun je bij IE tot op zekere hoogte nog wel rekenen op conditional comments, maar daarbuiten kan het soms verdomd lastig zijn om het allemaal netjes te laten werken in "iedere" browser.
Daarmee ben ik eigenlijk benieuwd naar hoever anderen hier gaan in ondersteuning van de misschien wat minder vaak gebruikte browsers, hoe ver gaan jullie in compatibiliteit? Ikzelf streef altijd naar een qua functionaliteit en uiterlijk gelijke site in IE vanaf versie 5, Opera (meest recente versies), Firefox en Safari. Mocht ik voor een andere browser buiten deze 4 met een eenvoudige fix problemen kunnen verhelpen, dan zal ik dat zeker niet laten, maar ik zal me er niet voor in bochten gaan wringen om het werkend te krijgen. Hoe kijken jullie hier tegenaan?

quote:

King_Louie schreef op dinsdag 24 januari 2006 @ 07:23:
[...]
hoe ver gaan jullie in compatibiliteit? Ikzelf streef altijd naar een qua functionaliteit en uiterlijk gelijke site in IE vanaf versie 5, Opera (meest recente versies), Firefox en Safari. Mocht ik voor een andere browser buiten deze 4 met een eenvoudige fix problemen kunnen verhelpen, dan zal ik dat zeker niet laten, maar ik zal me er niet voor in bochten gaan wringen om het werkend te krijgen. Hoe kijken jullie hier tegenaan?

Ik denk dat je dit ook zeker als streven moet nemen, de andere vrij exotische browsers die eventueel kunnen worden gebruikt hebben zo'n klein marktaandeel dat het niet interessant is. Als je even naar de Browser Statistics van W3Schools kijkt dan zie je het volgende:

2006	IE6	IE5	Ffox	Moz	N7	O8	O7
January	61.3%	5.1%	24.8%	3.3%	0.4%	1.4%	0.2%

Als je dus IE6, IE5, FF, Mozilla, Opera 8 ondersteunt heb je 95,9% in die voorbeeld te pakken. (Netscape is nu Mozilla based dus dat lijkt me ook geen probleem) Verder zou ik Safari nog ondersteunen betreft de Mac. Wanneer je dit ondersteunt en test ben ik van mening dat je met correct gebruik van HTML/CSS goed bezig bent.

These facts indicate that the browser figures below are not 100% realistic. Other web sites have statistics showing that Internet Explorer is used by at least 80% of the users.

Xiqum wijzigde dit bericht 24-01-2006 09:20 (13%)

quote:

Als je dus IE6, IE5, FF, Mozilla, Opera 8 ondersteunt heb je 95,9% in die voorbeeld te pakken.

De vraag is of die paar dingetjes die je breekt (of beter gezegd: niet fixed voor IE5) dusdanig onwerkbaar zijn. Voor de webdingen die ik doe, hou ik niet eens meer rekening met IE5. Als ik zin en tijd heb, fix ik die layout dingen wel, maar bijna nooit.

Ik ben tegenwoordig wat meer bezig met uren en financiële situaties op dit vlak, en wat ons vooral opvalt is dat het heel erg moeilijk is om een ander uit te leggen wat semantiek inhoudt. Als je het niet weet zie je de context niet van een element.

Als organisatie zijn we bezig met een commercieel product waarbij implementation partners zelf een template in elkaar kunnen zetten, en waar vervolgens componenten in geplaatst kunnen worden. In de vorige versie van het product, zat elk component in zijn eigen table, en we hadden er schoon genoeg van om telkens niet een gedeelte te kunnen positioneren omdat deze binnen de boundaries van de cell zat. Vervolgens ga je een opdracht neerleggen om al deze componenten te refactoren naar een situatie waarin dit wel mogelijk wordt, en onze insteek was daarbij de semantische aanpak. Hoe leg je anders tabeless layouts uit, en op welk moment je welk element gebruikt.

Je ziet direct dat je vragen krijgt als "waarom nu een div, en geen span" "waarom nu een h1 en geen h2" "waarom nu een list en geen div". Dat komt puur omdat het een stukje eigen interpretatie is van semantiek. Dat is echt een nadeel, het is zo subjectief als de pest.

Afgezien daarvan is het commerciele aspect nog steeds niet erg sterk, en blijft het voorlopig nog echt bij een aanpak die vooral is ontstaan uit een visie van developers. We gaan er echter wel mee door, het is voor het buitenland de manier om een element een context te geven, en om een opdracht neer te leggen zonder pagina's vol requirements.

Volgens mij is het niet bepaald nuttig om IE5 te ondersteunen nog. Maar als je niet al te absurde dingen doet dan werkt een site nog wel in IE5 toch? Ik heb er het laatste jaar eigenlijk niet meer naar omgekeken.
Ik kom wel bij mensen thuis die IE5 gebruiken. Maar dan ook direct 16 bits kleuren en 640x480 hebben. Nou kom op, je kunt bezig blijven toch?
Vind dit een interessant topic, ben benieuwd of er nog wat leuks uit komt!

Vergeet niet dat het publiek van W3schools meer exotische browsers gebruikt dan de gemiddelde Nederlander doet...

Wat mij eigenlijk vooral stoort aan het semantiek gebeuren is dat je er oeverloos over kunt ouwehoeren. Dat is tegelijkertijd ook wel weer iets waardoor je er ook echt beter in kunt worden, omdat er diverse mogelijkheden zijn, maar het is niet altijd even duidelijk wat nou gewoon dé oplossing is. Denk aan onderwerpen die hierboven genoemd zijn als: klikpaden/formulieren opmaken enzovoorts. Het zou heel fijn zijn als een organistatie als W3 nou eens zou guidelines zou maken waarin voorbeelden staan hoe je een formulier optimaal kan stylen.

Natuurlijk kan dit nooit 100% maar zo gebruikt wel iedereen dezelfde richtlijnen. Tevens hebben de browserbouwers dan ook meteen een goed voorbeeld wat het resultaat van bepaalde code moet zijn zonder die specs geheel uit moeten pluizen.

quote:

freakstar schreef op dinsdag 24 januari 2006 @ 09:53:
Volgens mij is het niet bepaald nuttig om IE5 te ondersteunen nog. Maar als je niet al te absurde dingen doet dan werkt een site nog wel in IE5 toch? Ik heb er het laatste jaar eigenlijk niet meer naar omgekeken.
Ik kom wel bij mensen thuis die IE5 gebruiken. Maar dan ook direct 16 bits kleuren en 640x480 hebben. Nou kom op, je kunt bezig blijven toch?
Vind dit een interessant topic, ben benieuwd of er nog wat leuks uit komt!

Windows 2000 werd nog met IE 5 geleverd, sommige mensen hebben nog nooit van updates gehoord en maken dus nog steeds het web onveilig met dat stuk schroot. Als je met een simpele fix (denk conditional comments) deze mensen van dienst kan zijn, waarom niet?

Uit veel topics die langskomen blijkt nog maar al te vaak dat mensen soms geen idee hebben van waar ze mee bezig zijn. Natuurlijk kan een welgeplaatste float:left; of display:inline; je probleem oplossen, maar dit is vaak eerder symptoombestrijding dan een echte oplossing. Zolang je niet echt snapt wat die properties horen te doen (nog afgezien van de bugs in die implementaties) zul je blijven vloeken op de verschillende uitkomsten van je css-brouwsels per browser.

Helaas zou alleen in Utopia alles perfect werken, en zoals de witty quote al zegt; het verschil tussen theorie en praktijk is dat er in theorie geen verschil is, dus je zal af en toe consessies moeten doen, maar over het algemeen heb je al die ranzige hacks eigenlijk helemaal niet nodig.

quote:

Gordijnstok schreef op dinsdag 24 januari 2006 @ 09:52:
Ik ben tegenwoordig wat meer bezig met uren en financiële situaties op dit vlak, en wat ons vooral opvalt is dat het heel erg moeilijk is om een ander uit te leggen wat semantiek inhoudt. Als je het niet weet zie je de context niet van een element.

[...]

Afgezien daarvan is het commerciele aspect nog steeds niet erg sterk, en blijft het voorlopig nog echt bij een aanpak die vooral is ontstaan uit een visie van developers. We gaan er echter wel mee door, het is voor het buitenland de manier om een element een context te geven, en om een opdracht neer te leggen zonder pagina's vol requirements.

De techniek zelf is idd moeilijk uit te leggen, ik denk ook dat dat de komende jaren alleen maar moeilijker wordt. De vraag is ook of je het wel helemaal wil uitleggen. Een systeem architect zal z'n implementatie ook niet gauw op code niveau met de klant gaan doornemen. De voor- en nadelen, en met name de mogelijkheden die de aanpak biedt zijn wel van belang, en op dat niveau kan je prima - en met iedereen - die discussie aangaan.

Het is de taak van de specialist om dit te doen. Onbegrip of gebrek aan kennis/inzicht doet niets af aan het belang van dat specialisme. Juist het in de wind slaan van zijn (of haar) advies leidt tot ellende op korte danwel lange termijn vraag dan niets.

quote:

Clay schreef op dinsdag 24 januari 2006 @ 10:36:
Het is de taak van de specialist om dit te doen. Onbegrip of gebrek aan kennis/inzicht doet niets af aan het belang van dat specialisme. Juist het in de wind slaan van zijn (of haar) advies leidt tot ellende op korte danwel lange termijn vraag dan niets.

Het is echter de taak van een persoon boven die specialist om uren en kosten in de gaten te houden. Op het moment dat er meerdere specialisten een hele papierfabriek op gang moeten brengen met requirements; en daarnaast een aanzienlijk deel van de tijd moeten besteden aan het uitleggen van concepten die zo subjectief zijn, dat je ze alleen kunt uitleggen met prototypes, is het een onderwerp wat je steeds moeilijker kunt gaan verkopen.

De voordelen zijn vooral nog een prestige voor een ontwikkelaar. Iets opleveren wat er netjes uit ziet, wat een bepaalde architectuur heeft, maar de echte voordelen zoals het gebruik van de semantiek door textreaders zijn vaak niet commercieel interessant voor organisaties. Ze worden alleen gedwongen tot die voordelen als er iets is wat ze verplicht om zich aan die voordelen te houden, en meestal is dat alleen bij de overheid het geval. Verder is de standaard en de support van textreaders nog niet dermate uitgekristaliseerd dat het een heel interessant gebied is. Het is nog niet volwassen genoeg.

Op het moment dat iets niet commercieel interessant is treed de harde kant van het bedrijfsleven op; de schoorsteen moet toch roken.

Ik denk ook niet dat het ooit anders zal worden. Bij hoeveel trappen in het centrum zie je een specifiek deel voor rolstoelen bijvoorbeeld, of hoeveel geldautomaten zitten op een lagere hoogte zodat ze toegankelijk zijn voor de mensen met een handicap. Alles draait om geld, en het enige wat je denk ik momenteel kunt doen, is semantiek als argument gebruik in kostenbesparingen en om iemand uit te leggen op welke manier jij een document opgebouwd wil hebben.

In het buitenland volgen maar weinig ontwikkelaars de gedachtengang van context in elementen. Echter we hebben echt uren gediscussieerd in meetings over hoe we in vredesnaam uitgelegd krijgen wat we verwachten van de eindkwaliteit. Door met semantiek te werken, en uit te leggen wat de waarde is van een H1 krijg we steeds meer vat op het denkproces. Het is bijna Jip en Janneke taal, een lijst, gebruik een lijst. Het hoofdonderwerp, gebruik een H1. Ergens nadruk op leggen, gebruik strong.

Dan hebben we het nog niet eens gehad over het uitleggen van block level elementen en inline elementen. Dat is al helemaal rocket science schijnbaar

quote:

Gordijnstok schreef op dinsdag 24 januari 2006 @ 11:06:
[...]
Ergens nadruk op leggen, gebruik strong.

Interessant, het lijkt me dat je daarvoor <em> van "emphasize" (benadrukken) voor gebruikt

edit:

sappie: twee niveau's van benadrukken lijkt me veelal onnodig. Bold tekst (dat je standaard krijgt met <strong>) wordt in de professionele wereld alleen gebruikt voor koppen. De tekst wordt er op kleinere fontgrooten namelijk niet leesbaarder op.

Sendy wijzigde dit bericht 24-01-2006 11:43 (37%)

offtopic:
@sendy: <strong> legt nóg meer nadruk op een zinsnede dan <em>