Semantische HTML, CSS en jij

[Victor]

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
[rml][ Semantiek] Formulieren[/rml]
[rml][ semantiek] klikpad in html[/rml]


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

[ Voor 11% gewijzigd door Victor op 25-01-2006 18:33 . Reden: Links toegevoegd ]

[Verwijderd]

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.

[ Voor 29% gewijzigd door Verwijderd op 23-01-2006 23:36 ]

[Victor]

Verwijderd 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

[Verwijderd]

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

[Copyman]

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/)

[:murb:]

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

[Verwijderd]

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.

[ Voor 2% gewijzigd door Verwijderd op 24-01-2006 00:16 . Reden: 4 zelfs alweer ]

[flashin]

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?

[ Voor 23% gewijzigd door flashin op 24-01-2006 00:30 ]

[Verwijderd]

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.

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.

[ Voor 32% gewijzigd door Verwijderd op 24-01-2006 00:35 ]

[flashin]

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.

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.

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) .

[ Voor 63% gewijzigd door flashin op 24-01-2006 00:39 ]

[Victor]

Verwijderd 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.

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.

[crisp]

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

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...

[ Voor 28% gewijzigd door crisp op 24-01-2006 00:50 ]

[Verwijderd]

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.

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

[crisp]

Verwijderd 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...

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

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

true

[Victor]

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?

[Xiqum]

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.

[ Voor 13% gewijzigd door Xiqum op 24-01-2006 09:20 ]

[BtM909]

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.

[Verwijderd]

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.

[Beekforel]

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!

[djluc]

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.

[Victor]

Beekforel 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?

[Clay]

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.

Verwijderd 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.

[Verwijderd]

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

[Sendy]

Verwijderd 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.

[ Voor 37% gewijzigd door Sendy op 24-01-2006 11:43 ]

[Sappie]

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

[Verwijderd]

Ik vind dat er wel voordelen aan CSS zitten. Je hebt meer controle over de opmaak en je kunt je opmaak centraal regelen. Dit levert schonere en lichtere HTML op die makkelijker site-wide aan te passen is. Een groot nadeel is de browsercompatibiliteit. Ik word daar af en toe behoorlijk gek van, ondanks dat ik al ruim 2 jaar CSS layouts gebruik. Ik heb verschillende keren rare hacks moeten gebruiken (zie bijvoorbeeld text selection bug). Dit zijn allemaal wel overkomelijke problemen, maar het zijn problemen die ik eigenlijk in eerste instantie al niet tegen wil komen.

Ik doe eigenlijk alles aan webontwerp: grafisch ontwerp, templates bouwen en de backend programmeren in Java of PHP. Als je net de backend hebt gebouwd is het enorm frustrerend als je vervolgens de templates gaat doen. Bij het bouwen van de backend gelden vaststaande regels waar je je aan kan vasthouden. Doe je iets fout, dan heb je vrijwel meteen een idee waar het aan kan liggen en wat de oplossing is. Als je er ook nog een foutmelding bij krijgt weet je helemaal snel waar de fout ligt. Ga je vervolgens aan de templates beginnen dan loop je tegen allerlei obscuur gedrag aan, waarvan het heel moeilijk na te gaan is waardoor het veroorzaakt wordt. En DAT is het grootste euvel. Op zich is CSS niet moeilijk, maar het kost jaren ervaring en proberen om de know how te verzamelen die je nodig hebt, omdat de CSS spec gewoon niet door alle browsers nageleefd worden en omdat er geen foutmeldingen gegenereerd worden.

[ Voor 5% gewijzigd door Verwijderd op 24-01-2006 11:52 ]

[Verwijderd]

Semantisch "correct" opmaken kost niet meer tijd dan een layout in tabellen opmaken. Dat is slechts een kwestie van gewenning. Op het moment dat SEO een issue is, kun je sowieso niets anders dan semantisch "correcte" documenten afleveren.

[BtM909]

Sendy schreef op dinsdag 24 januari 2006 @ 11:30:
[...]

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.

Het staat toch echt zo omschreven in de specs van W3

Remember: fontgrootte (en zelfs presentatie van strong of em) worden natuurlijk via CSS geregeld.

[Sendy]

BtM909 schreef op dinsdag 24 januari 2006 @ 11:59:

[...]

Het staat toch echt zo omschreven in de specs van W3

Remember: fontgrootte (en zelfs presentatie van strong of em) worden natuurlijk via CSS geregeld.

Je hebt gelijk. Ik lees in de XHTML 1.0 DTD dat strong is "strong emphasis". Nou ja, dit neemt niet weg dat ik geen voorstander ben van "strong emphasis", gewone benadrukking lijkt me meer dan voldoende

[Verwijderd]

Verwijderd schreef op dinsdag 24 januari 2006 @ 11:59:
Semantisch "correct" opmaken kost niet meer tijd dan een layout in tabellen opmaken. Dat is slechts een kwestie van gewenning. Op het moment dat SEO een issue is, kun je sowieso niets anders dan semantisch "correcte" documenten afleveren.

Dat hangt van meerdere factoren af, je kunt niet zomaar zeggen "het kost minder tijd". In de meest perfecte situatie wel, maar die zijn er niet. Vooralsnog zijn er nog heel veel vragen en klachten over de complexiteit van de standards, de slechte voorbeelden van implementatie van die standards (open een willekeurige rss feed eens in FeedDemon, 95% van de CSS layouts breekt), of onvolkomenheden in de standards die zorgen voor belemmeringen.

Nu ben ik zeker iemand die graag wil dat er volgens de nieuwe mogelijkheden wordt ontwikkeld, maar ik ben wel realistisch en zie in de daadwerkelijk resultaten dat het nog steeds meer tijd kost in de ontwikkeling dan een tabulaire layout tenzij je een highly skilled web developer hebt, waarvan er hier een aantal zitten, maar waarvan er maar bar weinig beschikbaar zijn in het bedrijfsleven.

Een bewezen techniek als tables, die vroeger juist is ontwikkeld uit het oogpunt om layouts op te maken en later pas door de evangelisme de semantische waarde van tabulaire data heeft gekregen, heeft die problemen niet. Dat was, en ik heb vroeger echt enorm veel van die layouts in elkaar gehangen, een kwestie van spacer.gifs, de juiste afmetingen pakken, en het resultaat was zelfs in IE op de Mac correct mits je goed je berekeningen had gedaan. Het voordeel is wel, dat layouts met tables gewoonweg niet breken op resoluties, schaalbaar zijn ze echter ook niet.

SEO en semantische documenten is een dooddoener. Elke persoon die zich bezighoudt met SEO kan je vertellen dat de score van semantiek zo laag is dat je beter je pijlen kunt richten op andere aspecten met een hoger rendement.

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.

[ Voor 14% gewijzigd door Verwijderd op 24-01-2006 13:15 ]

[Verwijderd]

Even een vraag om voor mezelf een duidelijk beeld te krijgen.

Wat is precies het verschil tussen dit semantishe HTML en hetgeen wat men bijv. behoord te doen met XHTML & CSS?

Want dit wat hier beschreven wordt heb toch eigenlijk maar weinig te maken met dat 'semantic web' verhaal voor zover als ik dat begrepen heb tijdens het onnodig leren voor mijn laatste tentamen. Het komt wel een beetje overeen maar dat is dan wel bar weinig.

[crisp]

Verwijderd schreef op dinsdag 24 januari 2006 @ 13:26:
Even een vraag om voor mezelf een duidelijk beeld te krijgen.

Wat is precies het verschil tussen dit semantishe HTML en hetgeen wat men bijv. behoord te doen met XHTML & CSS?

Niets; XHTML(1.x) is HTML maar dan als xml-application (met alle nadelen van dien).

[Verwijderd]

Verwijderd schreef op dinsdag 24 januari 2006 @ 13:26:

Het zgn. semantic web is niet anders dan het gebruik van de markup elementen binnen de context die daar aan hangt. Het voordeel daarvan is dat software die dergelijke documenten inleest, op basis van de waarde die aan die context hangt een actie kan uitvoeren.

In het kader van text to speech voor visueel gehandicapten, van een H1 weet de software dat het een onderwerp betreft en kan het een korte pauze invoegen na het uitspreken zodat duidelijk is dat we een onderwerp hebben opgenoemd. Bij een strong zal het zijn stem iets verheffen, en bij een list zullen de listitems per stuk worden opgenoemd zodat het niet wordt opgevat als een collectie zinnen.

Zonder deze context zou de software alle elementen hetzelfde beschouwen. Semantische markup, is dus niets anders als het gebruik van elementen voor hun doel zodat software die niets weet van jouw document, het document alsnog kan begrijpen doordat je door middel van markup hebt beschreven wat elk stukje informatie nu precies voor soort informatie is.

[ Voor 6% gewijzigd door Verwijderd op 24-01-2006 13:57 ]

[Verwijderd]

Verwijderd schreef op dinsdag 24 januari 2006 @ 13:11:
SEO en semantische documenten is een dooddoener. Elke persoon die zich bezighoudt met SEO kan je vertellen dat de score van semantiek zo laag is dat je beter je pijlen kunt richten op andere aspecten met een hoger rendement.

Waar baseer je dit op? Ik heb zelf namelijk de indruk dat documenten die semantisch "correct" zijn opgemaakt vele malen beter geindexeerd worden bij bijvoorbeeld Google. Bij een gemiddelde MKB-klant kunnen we met correcte syntaxis de vindbaarheid binnen enkele weken enorm vergroten door enkel en alleen juist gebruik van tags en een goede structuur. Iets wat me met een tabel-based layout niet lukt.

Met semantisch correct bedoel ik overigens niet het gezeik in de marge waar de zelfbenoemde puristen zich mee bezig houden.

[Verwijderd]

Verwijderd schreef op dinsdag 24 januari 2006 @ 13:11:Een bewezen techniek als tables, die vroeger juist is ontwikkeld uit het oogpunt om layouts op te maken en later pas door de evangelisme de semantische waarde van tabulaire data heeft gekregen, heeft die problemen niet. Dat was, en ik heb vroeger echt enorm veel van die layouts in elkaar gehangen, een kwestie van spacer.gifs, de juiste afmetingen pakken, en het resultaat was zelfs in IE op de Mac correct mits je goed je berekeningen had gedaan. Het voordeel is wel, dat layouts met tables gewoonweg niet breken op resoluties, schaalbaar zijn ze echter ook niet.

Ik blijf er bij dat een layout opbouwen zonder tables niet meer tijd hoeft te kosten. Een layout opbouwen met tabellen kost me meer tijd en ik heb bovendien het gevoel met handen en voeten gebonden te zijn. Het blijft gewoon minder flexibel, tenzij je gebruik maakt van veel te ingewikkelde constructies.

Een kwestie van gewenning dus...

[Sappie]

Verwijderd schreef op dinsdag 24 januari 2006 @ 14:04:
Waar baseer je dit op? Ik heb zelf namelijk de indruk dat documenten die semantisch "correct" zijn opgemaakt vele malen beter geindexeerd worden bij bijvoorbeeld Google. Bij een gemiddelde MKB-klant kunnen we met correcte syntaxis de vindbaarheid binnen enkele weken enorm vergroten door enkel en alleen juist gebruik van tags en een goede structuur. Iets wat me met een tabel-based layout niet lukt.

Met semantisch correct bedoel ik overigens niet het gezeik in de marge waar de zelfbenoemde puristen zich mee bezig houden.

Een duidelijke structuur in je markup (en daarmee dus een enigszins semantisch verantwoorde site) draagt uiteraard in positieve zin bij aan de indexering door oa google. Echter zijn er andere factoren die veel belangrijker zijn, zoals bijvoorbeeld pagerank.

offtopic:
deze discussie zou verder beter in dit topic thuis horen: [rml][ SEO] Tips & Trucs[/rml]

[sjaakaq]

Semantiek, erg interessant

Hoewel ik tegenwoordig DIV's, headers etc. wel onder controle heb qua semantiek (waarvoor te gebruiken), zit ik nog altijd te struggelen over wanneer ik iets tussen <p> en </p> moet zetten. Als ik één regel heb met alleen een datum, moet dat dan ook in een <p>?

[Copyman]

@leokennis

Daar wordt hier ook over gediscussieerd:
http://www.simplebits.com...when_to_p_conclusion.html
http://www.simplebits.com...iz_part_iv_when_to_p.html

[ Voor 24% gewijzigd door Copyman op 24-01-2006 14:59 ]

[BtM909]

Verwijderd schreef op dinsdag 24 januari 2006 @ 14:04:
[...]

Waar baseer je dit op? Ik heb zelf namelijk de indruk dat documenten die semantisch "correct" zijn opgemaakt vele malen beter geindexeerd worden bij bijvoorbeeld Google. Bij een gemiddelde MKB-klant kunnen we met correcte syntaxis de vindbaarheid binnen enkele weken enorm vergroten door enkel en alleen juist gebruik van tags en een goede structuur. Iets wat me met een tabel-based layout niet lukt.

Zoek voor de gein eens op webdesign met google en bekijk de source van de eerste hit maar eens. Het is voor indexering een stuk makkelijker voor de spider om juiste HTML te gebruiken, maar echt geen noodzaak hoor

[SYQ]

wat is aan te raden voor iemand die altijd heeft gewerkt met tables en het hoogtijd vind om met divs te gaan werken.

gelijk een tweede vraag. waarom divs ipv tables ??

[crisp]

SYQ schreef op dinsdag 24 januari 2006 @ 15:19:
wat is aan te raden voor iemand die altijd heeft gewerkt met tables en het hoogtijd vind om met divs te gaan werken.

gelijk een tweede vraag. waarom divs ipv tables ??

Lees de startpost eens...

[ Voor 3% gewijzigd door crisp op 24-01-2006 15:22 ]

[Sappie]

foute vraag: div's zijn zo ongeveer betekenisloze elementen (ja ze kunnen een website 'opdelen') en dienen in mijn ogen slechts dan gebruikt te worden wanneer de semantisch meer verantwoorde elementen niet genoeg aanhaakpunten voor de CSS creëren.

Tables dienen ook nog gebruikt te worden wanneer je te maken hebt met tabulaire data.

Layouts bewerkstelligen doe je dus noch met div's noch met tabellen. Je gebruikt de juiste elementen op de juiste plaats. Ik zou me eens goed gaan verdiepen in CSS en alle mogelijkheden daarvan. Verder zou ik de link mbt semantiek in de eerste post bijvoorbeeld eens doorlezen.

_{Hier zijn btw al genoeg woorden aan vuil gemaakt als je het mij vraagt}

edit:
heb er dus zelf ook alweer te veel woorden aan vuil gemaakt zie startpost idd

[ Voor 9% gewijzigd door Sappie op 24-01-2006 15:26 ]

[Erkens]

SYQ schreef op dinsdag 24 januari 2006 @ 15:19:
wat is aan te raden voor iemand die altijd heeft gewerkt met tables en het hoogtijd vind om met divs te gaan werken.

gelijk een tweede vraag. waarom divs ipv tables ??

divs zijn geen alternatief voor tables, eigenlijk maak jij gewoon de verkeerde keuze.
lees dit maar eens door: http://home.parse.nl/~michiel/semantiek.html

[SYQ]

nou nou

tnx erkens heb doorgelezen. mijn "fout" is dus dat ik html paginas maak met tables, maar alle style elementen opneem in een css. ff vanavond mijn fp proberen om te zetten, die is nu 50kb

[Verwijderd]

Verkleining van bestanden is ook zo'n non-argument, alsof we nog met 4800 baud werken. Leg dan de prioriteiten op het verkleinen van latencies, een stuk belangrijker vandaag de dag

[SYQ]

jezus zeg, ik moet hier blijkbaar oppasen met wat ik tik tussen al jullie supa-dupa designers. mijn bovenstaande opmerking schreef ik nav deze artikel : http://www.stopdesign.com/articles/throwing_tables/

ow bijna vergeten

[Erkens]

Verwijderd schreef op dinsdag 24 januari 2006 @ 15:42:
Verkleining van bestanden is ook zo'n non-argument, alsof we nog met 4800 baud werken. Leg dan de prioriteiten op het verkleinen van latencies, een stuk belangrijker vandaag de dag

Op drukke sites kan een paar KB toch veel uitmaken, als je bijvoorbeeld je frontpage kan reduceren met 1KB totaal (incl de nieuwe CSS file welke tevens gecached wordt) dan is dat met 10.000 bezoekers al 10MB. Niet onder de indruk?
Als ik bijvoorbeeld hier naar de t.net frontpage kijk, daar staat dat ze ruim 1600 pageviews per minuut hebben. 1600*60*24*30 = 69120000 page views per maand. Dat zou neerkomen op een besparing van 69GB per maand!

Daarnaast zijn kleine bestanden natuurlijk makkelijker te onderhouden.

[Verwijderd]

Verwijderd schreef op dinsdag 24 januari 2006 @ 13:56:
[...]


Het zgn. semantic web is niet anders dan het gebruik van de markup elementen binnen de context die daar aan hangt. Het voordeel daarvan is dat software die dergelijke documenten inleest, op basis van de waarde die aan die context hangt een actie kan uitvoeren.

In het kader van text to speech voor visueel gehandicapten, van een H1 weet de software dat het een onderwerp betreft en kan het een korte pauze invoegen na het uitspreken zodat duidelijk is dat we een onderwerp hebben opgenoemd. Bij een strong zal het zijn stem iets verheffen, en bij een list zullen de listitems per stuk worden opgenoemd zodat het niet wordt opgevat als een collectie zinnen.

Zonder deze context zou de software alle elementen hetzelfde beschouwen. Semantische markup, is dus niets anders als het gebruik van elementen voor hun doel zodat software die niets weet van jouw document, het document alsnog kan begrijpen doordat je door middel van markup hebt beschreven wat elk stukje informatie nu precies voor soort informatie is.

Ah, ik had begrepen dat het doel van het sematic web relaties leggen tussen dingen was. Zodat de computer uit kan vogelen dat als er 1 document bestaat uit de gegevens "John Lennon lid was van de band de Beatles" en een tweede document bestaat uit de gegevens "de Beatles een populaire band was uit Engeland". Dat naast de lezer van het document ook de computer er wat van zou kunnen begrijpen. Deze kan nu aangeven dat Jonh Lennon lid was van de band de Beatles, wat een popularie band uit engeland was.
Wat niet zozeer het geval is bij bijv. het gebruik van h1, etc. Het enige wat de computer dan van dat document weet is dat het de titel is van een hoofdstuk, maar niet of deze titel mogelijk overeenkomsten heeft met de titel uit document 2.

Maargoed dit semantische HTML zal wel in het begin van dat boek hebben gestaan wat ik gewoon geskipt had omdat ik het zo snel mogelijk wou weten wat ik op me tentamen zou kunnen krijgen Ik moet gewoon dat boek even weer ophalen en het een keer goed lezen, want dit is best interresant spul. Bedankt voor de uitleg.

[chem]

Verwijderd schreef op dinsdag 24 januari 2006 @ 15:42:
Verkleining van bestanden is ook zo'n non-argument, alsof we nog met 4800 baud werken. Leg dan de prioriteiten op het verkleinen van latencies, een stuk belangrijker vandaag de dag

Wat een gelul.

Als ik met m'n 4 mbit een 6kb of een 50kb file binnenhaal; dat merk je wel. Je CPU moet het hele zooitje ook nog parsen, tree bouwen, en op je scherm renderen.

Wat ik zelf de laatste tijd probeer is om het aantal requests per pageview omlaag te krijgen. Hiervoor gebruik ik bv tilemaps (dus 1 afbeelding, en dan de juiste icon eruithalen dmv background-positioning), retrieve-multiple.php waar je 1 "screen.css" aan opvraagt en vv alle @imports (lokale) afhandelt (ook zo met JS). Het wordt er wel degelijke (voor de gebruiker) sneller van - 5x 304 opvragen of 35x 304's opvragen, dat scheelt gewoon. Ook een :hover gaat er sneller door (geen extra request nodig, IE anyone?)

Daarbij is bandbreedte niet voor iedereen in overdaad aanwezig; denk aan mobiele telefoons met GPRS, < 1 mbit adsl verbindingen en de groep gebruikers die, jaja, nog steeds met modems inbellen.

Het semantiek-document wat ik geschreven heb zou ik nu al wat beter/constructiever oppakken.
Ik ben nog steeds van de aanpak van het eerst geheel semantisch taggen van de content, het daarna met CSS selectors (CSS3, als dat zo uitkomt) opmaken en daarna bekijken wat er nog voor oudere niet-css3, niet-css2 en niet-css browsers nodig is. Daar kies ik dan voor extra classes, JS (cssQuery) en andere oplossingen - wat er op dat moment maar het beste uitkomt.
Een aanpak waarbij ik dus begin met een "principiele" aanpak, om te eindigen met een pragmatische oplossing.

[-Lars-]

King_Louie schreef op maandag 23 januari 2006 @ 22:49:
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.

Helaas gaat dit niet altijd op, in ieder geval niet zonder allerlei hacks in je HTML en je CSS. Stel dat ik een blockquote-element wil stylen, met quotes als achtergrond zoals hier wordt gedaan en ook nog ronde hoeken (waarvoor veel technieken bestaan). Dan moet ik, zover ik tot nu toe heb kunnen vinden, in het minst semantisch oncorrecte geval in ieder geval 3 divs toevoegen:

• 1 div om linksonder de hoek rond te krijgen
• 1 div om rechtsboven de hoek rond te krijgen
• 1 div om rechtsonder de hoek rond te krijgen en de afsluitende aanhalingstekens te positioneren (samen te voegen tot een achtergrondafbeelding)
• (de achtergrondafbeelding met ronde linkerbovenhoek en aanhalingstekens-open kan op het blockquote-element zelf worden geplaatst)

Nu worden div's vaak gebruikt als lapmiddel, maar netjes is het natuurlijk niet. Volgens mij is het niet mogelijk om bovenstaande effect te krijgen zonder ongewilde, non-semantische div's toe te voegen.

Ik verwacht dat ronde hoeken uiteindelijk los in te stellen zijn via CSS (wellicht bestaat het al ergens in de diepe grotten van het W3C?), maar voordat onze grote vriend Internet Explorer dat ook ondersteunt kunnen we waarschijnlijk nog enkele elfstedentochten houden, en dat zegt wat.

[Verwijderd]

-Larz- schreef op dinsdag 24 januari 2006 @ 17:58:

Nu worden div's vaak gebruikt als lapmiddel, maar netjes is het natuurlijk niet. Volgens mij is het niet mogelijk om bovenstaande effect te krijgen zonder ongewilde, non-semantische div's toe te voegen.

Klopt. Dat is een tekortkoming van CSS2 en de specificaties. Er zijn tal van voorbeelden te bedenken die niet uitvoerbaar zijn. Dat geldt voor table layouts overigens net zo goed.

Ik verwacht dat ronde hoeken uiteindelijk los in te stellen zijn via CSS (wellicht bestaat het al ergens in de diepe grotten van het W3C?), maar voordat onze grote vriend Internet Explorer dat ook ondersteunt kunnen we waarschijnlijk nog enkele elfstedentochten houden, en dat zegt wat.

Dat klopt.

[Victor]

-Larz- schreef op dinsdag 24 januari 2006 @ 17:58:
Helaas gaat dit niet altijd op, in ieder geval niet zonder allerlei hacks in je HTML en je CSS.

De uitspraak moet je ook niet al te letterlijk nemen. Dan zou je een lapje tekst door middel van CSS ook in volle HD kwaliteit met THX geluid in 3D kunnen presenteren. Dat gaat (of ik moet wat gemist hebben) ook niet

Het gaat er natuurlijk om dat je al veel vrijer bent in je grafische opmaak, wat als gevolg heeft dat je ook vrijer bent in je element keuze. Uiteindelijk worden de "looks" van een website toch belangrijker gevonden door menig opdrachtgever, en als jij daar netjes aan kan voldoen en toch een fraai stukje semantische HTML kan gebruiken, is dat wel zo mooi.

[Clay]

Verwijderd schreef op dinsdag 24 januari 2006 @ 13:11:
[...]

Een bewezen techniek als tables, die vroeger juist is ontwikkeld uit het oogpunt om layouts op te maken en later pas door de evangelisme de semantische waarde van tabulaire data heeft gekregen, heeft die problemen niet.

[...]

Ho ho! de table is zeker niet bedacht om pixelpreciese designs te realiseren, dat was een bijkomstigheid. Dat dit mede de populariteit van internet ('t oog wil ook wat) heeft geholpen is tof, maar de semantische waarde had het altijd al; een td is nooit wat anders geweest dan "table data", noch was de th ooit geen "table header". Na een paar jaar wist niemand meer van het bestaan van dingen als thead, tbody of tfoot, zelfs de th was een stille dood gestorven, juist omdat je al die muk niet nodig had voor layouten.

King_Louie schreef op maandag 23 januari 2006 @ 22:49:
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.

Mwah, die elementen die je "anders nooit zou gebruiken" hebben niet voor niets een default layout. Als ik een h1, p, ul en table neerzet ben ik wel blij dat ik het niet helemaal hoef te stylen tot respectievelijk een titel, paragraaf, lijst en tabel.

@algemeen
Graceful degraden zou eens beter uitgelegd moeten worden. Op zich zijn het besef van belang van standaarden en de voordelen van de nette aanpak wel aanwezig. Je doel moet echter zijn om zoveel mogelijk mensen te bereiken, niet om op zoveel mogelijk browsers op de pixel hetzelfde te laten zien en daarbij oudere browsers te vergeten. Degraden is bijna inherent aan de techniek je kan het eigenlijk alleen maar opzettelijk slopen.

[Verwijderd]

Erkens schreef op dinsdag 24 januari 2006 @ 15:51:
[...]


Op drukke sites kan een paar KB toch veel uitmaken, als je bijvoorbeeld je frontpage kan reduceren met 1KB totaal (incl de nieuwe CSS file welke tevens gecached wordt) dan is dat met 10.000 bezoekers al 10MB. Niet onder de indruk?
Als ik bijvoorbeeld hier naar de t.net frontpage kijk, daar staat dat ze ruim 1600 pageviews per minuut hebben. 1600*60*24*30 = 69120000 page views per maand. Dat zou neerkomen op een besparing van 69GB per maand!

Daarnaast zijn kleine bestanden natuurlijk makkelijker te onderhouden.

Voor jou als persoon misschien veel, voor een organisatie met een heel serverpark en een maandelijkse omzet waar die 69GB gelijk staat aan een pak a4 papier niet, dan hebben we het nog niets eens gehad of compressietechnieken. Bandbreedte kost tegenwoordig praktisch niets. Dus als je voor specifiek het verkleinen van je code gaat doen ben je gewoon geld over de balk aan het gooien, voor andere zaken zoals onderhoud kan ik het me goed voorstellen.

[chem]

Verwijderd schreef op dinsdag 24 januari 2006 @ 13:11:
[...]

Nu ben ik zeker iemand die graag wil dat er volgens de nieuwe mogelijkheden wordt ontwikkeld, maar ik ben wel realistisch en zie in de daadwerkelijk resultaten dat het nog steeds meer tijd kost in de ontwikkeling dan een tabulaire layout tenzij je een highly skilled web developer hebt, waarvan er hier een aantal zitten, maar waarvan er maar bar weinig beschikbaar zijn in het bedrijfsleven.

offtopic:
ik hak even schaamteloos in op 1 zinsnede; ik heb de rest van je relaas wel gelezen

Wat is er mis met een highly skilled webdeveloper moeten zijn voordat je je met websites mag bemoeien? Ik zie dat eerder als een zege dan een nadeel.

Als we kijken naar een ander aspect van (u hoort nu een hype-geluidje op de achtergrond) Web 2.0 (einde geluidje) is het taggen van informatie. Of dit strict bij Web 2.0 hoort weet ik niet, het interesseert me ook niet. Wat ik wel van belang vind is dat het een onderdeel uitmaakt van het hele semantische en gestructureerde idee: het niet alleen semantisch markeren van de tekst, maar ook het gehele document en/of delen daarvan classificeren in categorieën en op die manier de uitwisseling en indexering etc. door verbeteren. In dezelfde lijn liggen bv. de microformats voor interpersoonlijke relaties.

Dergelijke classificaties en relaties maken en aanleggen eisen behoorlijk wat van de invoerder van de informatie; nog even en een site moet beheerd worden door iemand met een bibliothecaris-opleiding. Als de ideeën tenminste het weblog-niveau ontstijgen.

Al met al heeft het ons als bedrijf de nodige scheldpartijen en frustraties gekost om de nieuwe HTML-stijl eigen te krijgen. Niet alleen het voor de zoveelste keer om IE-bugs heen werken, maar ook gemaakte keuzes achteraf weer terugrollen en aanpassen.
Desalniettemin besparen we ons inmiddels zeeën van tijd; we hebben 1 templateset waarom we enkel een andere omlijsting gieten. De rest kan en gaat allemaal door CSS en JS; de onderhoud neemt er merkbaar door af (de kennis is nu eenmaal in het bedrijf en hoeft dus niet meer (!) opgedaan te worden), en de semantische (gestructureerde) HTML maakt het ook mogelijk met unobtrusive javascript kleine behaviours aan elementen te koppelen, per site en implementatie. 'Tis geen spam, maar een voorbeeld: zie bv vrouw.nl, nosheadlines.nl en forum.funx.nl - dezelfde templateset, dezelfde 'kern' qua onderhoud - alleen de weergave verschilt. Zonder semantische, tableless HTML was dat nooit gelukt en hadden we veel, veel meer te onderhouden.

[Erkens]

Verwijderd schreef op dinsdag 24 januari 2006 @ 20:32:
Voor jou als persoon misschien veel, voor een organisatie met een heel serverpark en een maandelijkse omzet waar die 69GB gelijk staat aan een pak a4 papier niet, dan hebben we het nog niets eens gehad of compressietechnieken. Bandbreedte kost tegenwoordig praktisch niets.

en daarom moet je er maar laks mee omgaan lekkere instelling heb je dan, ach het kost toch niks, dus wat boeit het?

Dus als je voor specifiek het verkleinen van je code gaat doen ben je gewoon geld over de balk aan het gooien

hoezo gooi je dan geld over de balk? je moet minder code kloppen dus in theorie ben je sneller klaar met een opdracht

[Verwijderd]

chem schreef op dinsdag 24 januari 2006 @ 17:38:
Wat een gelul.

Als ik met m'n 4 mbit een 6kb of een 50kb file binnenhaal; dat merk je wel. Je CPU moet het hele zooitje ook nog parsen, tree bouwen, en op je scherm renderen.

6kb of 50kb is nogal een verschil en zelfs dan denk ik dat je nog beter je prioriteiten kunt richten op latencies. Ik meen dat ik hiet ook wat van Backbase over heb gelezen, die daar onderzoek naar heeft gedaan.

Micro optimalisaties zijn echt in mijn ogen niet rendabel, tenzij de besparing echt zo enorm is dat het origineel gewoon echt slecht was.

Wat ik zelf de laatste tijd probeer is om het aantal requests per pageview omlaag te krijgen. Hiervoor gebruik ik bv tilemaps (dus 1 afbeelding, en dan de juiste icon eruithalen dmv background-positioning), retrieve-multiple.php waar je 1 "screen.css" aan opvraagt en vv alle @imports (lokale) afhandelt (ook zo met JS). Het wordt er wel degelijke (voor de gebruiker) sneller van - 5x 304 opvragen of 35x 304's opvragen, dat scheelt gewoon. Ook een :hover gaat er sneller door (geen extra request nodig, IE anyone?)

Kijk en hier ben ik het dan mee eens. Door deze aanpak richt je je op de grootste vertraging van websites, en dat zijn latencies die per request aan de orde zijn. Dit zijn optimalisaties die er toe doen.

Daarbij is bandbreedte niet voor iedereen in overdaad aanwezig; denk aan mobiele telefoons met GPRS, < 1 mbit adsl verbindingen en de groep gebruikers die, jaja, nog steeds met modems inbellen.

Dan ga je zowiezo kijken naar een lightweight templates, specifiek voor die toepassing. Je gaat geen complete layouts over je GPRS verbinding sturen. Wat ik aan GPRS sites bezoek zijn stuk voor stuk gespecialiseerde templates, geoptimaliseerd voor dat specifieke doel.

Dat je modem gebruikers nog wilt ondersteunen, tja daar zijn de meningen over verdeeld. Ik denk dat ik niet ver naast de pot pies als ik stel dat het aantal ontwikkelaars dat hun sites test tegen een 56k6 verbinding praktisch nihil is, ik kom ze behalve specifieke toepassingen echt niet meer tegen.

[Verwijderd]

Erkens schreef op dinsdag 24 januari 2006 @ 20:43:

en daarom moet je er maar laks mee omgaan lekkere instelling heb je dan, ach het kost toch niks, dus wat boeit het?

hoezo gooi je dan geld over de balk? je moet minder code kloppen dus in theorie ben je sneller klaar met een opdracht

Ik zou zeggen, vraag eens aan t.net of ze geld en tijd willen investeren in verkleinen van de code zodat ze op maandbasis van die terabytes aan dataverkeer 64GB afsnoepen. Ik denk dat ik het antwoord op commerciele basis wel weet

[Erkens]

Verwijderd schreef op dinsdag 24 januari 2006 @ 20:45:
Dan ga je zowiezo kijken naar een lightweight templates, specifiek voor die toepassing. Je gaat geen complete layouts over je GPRS verbinding sturen. Wat ik aan GPRS sites bezoek zijn stuk voor stuk gespecialiseerde templates, geoptimaliseerd voor dat specifieke doel.

als je templates al lightweight zijn hoef je niet extra kosten te maken om _nog_ een templateset te maken

Dat je modem gebruikers nog wilt ondersteunen, tja daar zijn de meningen over verdeeld. Ik denk dat ik niet ver naast de pot pies als ik stel dat het aantal ontwikkelaars dat hun sites test tegen een 56k6 verbinding praktisch nihil is, ik kom ze behalve specifieke toepassingen echt niet meer tegen.

ligt aan de doelgroep, en zodra je doelgroep "de gemiddelde nederlander" is dan zou je toch echt met 56k'er rekening moeten houden anders ben je gewoon niet professioneel bezig imo.

Verwijderd schreef op dinsdag 24 januari 2006 @ 20:48:
Ik zou zeggen, vraag eens aan t.net of ze geld en tijd willen investeren in verkleinen van de code zodat ze op maandbasis van die terabytes aan dataverkeer 64GB afsnoepen. Ik denk dat ik het antwoord op commerciele basis wel weet

je moet het natuurlijk ook niet als hoofddoel zien

offtopic:
overigens liet ik in mijn berekening 69GB zien, nu maak jij daar weer minder van, verder ging ik enkel uit van de frontpagina en van slechts een winst van 1KB, in de praktijk zal dit dus veel meer dan die kleine 70GB zijn, ik denk dat je eerder in de buurt van de 200GB zou zitten voor een site als de frontpage van t.net

[ Voor 28% gewijzigd door Erkens op 24-01-2006 20:51 ]

[Verwijderd]

chem schreef op dinsdag 24 januari 2006 @ 20:41:

offtopic:
ik hak even schaamteloos in op 1 zinsnede; ik heb de rest van je relaas wel gelezen

Wat is er mis met een highly skilled webdeveloper moeten zijn voordat je je met websites mag bemoeien? Ik zie dat eerder als een zege dan een nadeel.

Als developer is dat feest, ik wil echter als persoon die deze jongens stuurt wel die kwaliteit ontvangen; dus correcte markup, dus markup en layout gescheiden. En dan merk je dat het toch allemaal niet zo vanzelfsprekend is. Dat is het voordeel van werken met die skilled developer. Die kan zonder vragen het idee naar eindresultaat omzetten, zonder te vragen wanneer die nu wel of niet een tag moet toepassen, en weet vaak op basis van ervaring wat wel en wat niet goed werkt in de praktijk op verschillende browsers.

Vraag je ze om een layout met tables op te zetten, dan zijn ze echter zo klaar. In het buitenland is men nog niet zo in het semantiek en css verhaal. En totdat die kennis op een bepaald niveau is zijn dergelijke projecten nog steeds duurder. Dat is een beetje wat ik hier uiteen zet.

Web 2.0

Tagging is vooral een behoefte die ontstaat uit wat men information overload noemt, de basis waarom WinFS door Bill Gates werd geintroduceerd. Het is niet alleen iets wat je op het web tegenkomt, het was al heel lang gemeengoed in industriele document management systemen.

Dergelijke classificaties en relaties maken en aanleggen eisen behoorlijk wat van de invoerder van de informatie; nog even en een site moet beheerd worden door iemand met een bibliothecaris-opleiding. Als de ideeën tenminste het weblog-niveau ontstijgen.

In dergelijke situaties komt een workflow om de deur kijken, absoluut belangrijk om te voorkomen dat het een onoverzichtelijke bak met informatie wordt.

Al .... onderhouden.

Een forum is dan ook een layout die uitermate geschikt is voor dit soort aanpakken. Ik denk ook dat je nu wel een layout te pakken hebt die vaak een zelfde opbouw van informatie heeft en daardoor bijzonder rendabel is. Er zijn niet zo bizar veel uitgebreide layouts, die zo ideaal zijn voor deze aanpak en ook nog direct te hergebruiken zijn. Maar een layout zoals T.net is niet zo makkelijk toe te passen in een andere vorm, omdat er een bepaalde identiteit aan vast zit. Een forum heeft een algemeen aanvaard format wat dat betreft

[Verwijderd]

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

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

Ja, zeker van gehoord, maar dan meer als het "P5 P95 Syndroom".

[Verwijderd]

Erkens schreef op dinsdag 24 januari 2006 @ 20:49:
als je templates al lightweight zijn hoef je niet extra kosten te maken om _nog_ een templateset te maken

Ik snap je gedachtengang wel, maar toch worden voor dit soort zaken templatesets gemaakt, omdat voor die toepassingen heel andere combinaties van informatie worden gebruikt. Alleen headers bijvoorbeeld. Dan wil je niet alle overbodige markup die voor een web browser wel wordt getoond alsnog meeverzenden en vervolgens niet gebruiken.

ligt aan de doelgroep, en zodra je doelgroep "de gemiddelde nederlander" is dan zou je toch echt met 56k'er rekening moeten houden anders ben je gewoon niet professioneel bezig imo.

Dan ben ik een prutser Guilty!

je moet het natuurlijk ook niet als hoofddoel zien

offtopic:
overigens liet ik in mijn berekening 69GB zien, nu maak jij daar weer minder van, verder ging ik enkel uit van de frontpagina en van slechts een winst van 1KB, in de praktijk zal dit dus veel meer dan die kleine 70GB zijn, ik denk dat je eerder in de buurt van de 200GB zou zitten voor een site als de frontpage van t.net

Per ongeluk 4GB vergist .. lekker belangrijk We praten hier nog steeds over een voor mij, lousy 200GB. Weet je wat bandbreedte kost voor een organisatie die maandelijks grote hoeveelheden dataverkeer verplaatst? Je moet het bekijken op basis van kosten, niet op basis van wat je als developer vind dat er moet gebeuren

[crisp]

Verwijderd schreef op dinsdag 24 januari 2006 @ 21:51:
[...]
Per ongeluk 4GB vergist .. lekker belangrijk We praten hier nog steeds over een voor mij, lousy 200GB. Weet je wat bandbreedte kost voor een organisatie die maandelijks grote hoeveelheden dataverkeer verplaatst? Je moet het bekijken op basis van kosten, niet op basis van wat je als developer vind dat er moet gebeuren

Daar kan ik wel op inhaken
Kleinere code is absoluut geen streven, en de 200GB zal ook geen 200GB zijn aangezien we gebruik maken van HTTP compressie Wat uiteraard wel belangrijk is is onderhoudbare en flexibele code; dat goed gebruik van HTML en CSS in veel gevallen ook besparing op grootte opleverd is dan mooi meegenomen

[Erkens]

Verwijderd schreef op dinsdag 24 januari 2006 @ 21:51:
Ik snap je gedachtengang wel, maar toch worden voor dit soort zaken templatesets gemaakt, omdat voor die toepassingen heel andere combinaties van informatie worden gebruikt. Alleen headers bijvoorbeeld. Dan wil je niet alle overbodige markup die voor een web browser wel wordt getoond alsnog meeverzenden en vervolgens niet gebruiken.

een beetje template systeem kan je aangeven of je wel of niet bepaalde code wilt hebben zoals dus die "overbodige" headers. Met als gevolg dat je nog steeds maar 1 template hebt voor alle soorten html output.

Per ongeluk 4GB vergist .. lekker belangrijk We praten hier nog steeds over een voor mij, lousy 200GB. Weet je wat bandbreedte kost voor een organisatie die maandelijks grote hoeveelheden dataverkeer verplaatst? Je moet het bekijken op basis van kosten, niet op basis van wat je als developer vind dat er moet gebeuren

en weer lees je niet, anyway, niet alle websites zijn van grote bedrijven. overigens boeien mij als developer deze kosten ook niet, maar wel de snelheid waarmee een pagina binnenkomt en door de browser wordt gerenderd.

[OzBoz]

Erkens schreef op dinsdag 24 januari 2006 @ 20:49:
ligt aan de doelgroep, en zodra je doelgroep "de gemiddelde nederlander" is dan zou je toch echt met 56k'er rekening moeten houden anders ben je gewoon niet professioneel bezig imo.

De gemiddelde NLer heeft volgens mij geen 56k meer als ik de onderzoeken moet geloven en we zo ongeveer aan de top van het relatieve breedband internet staan worldwide. Ik moet zeggen dat ik vrij vroeg begonnen ben en nog van 'max. 30k voor een pagina' generatie, waar ik me ook graag aan hou. Ik word er wel steeds makkelijker in. Kranten worden niet gedrukt voor blinden en wanneer mensen zichzelf graag een handicap aanmeten in de vorm van een 56k modem dan is dat een keuze. Ben vrij praktisch, maar voor ook snellere verbindingen is het fijn een beetje een optimale pagina te fixen. Soms kun je door beeldmateriaal niet anders, het zij zo.

Wat betreft de semantische HTML, ik probeer netjes te programmeren maar ben geen codeklopper (zoek er nog één). Maar ben ooit begonnen met notepad in een erg ver verleden, toen tijd dreamweaver gebruikt (vooral omdat het lekker snel is) dat dan vervolgens wel met de hand aanpassen. En nu is het weer veel UltraEdit. En ik vind het altijd wel een uitdaging om het netjes te doen. Een eindgebruiker interesseert het meestal geen hol en bij klussen met krappe deadline word ik ook minder kieskeurig. Ik kreeg laatst een nieuwsbrief aangeleverd als 1 complete JPG en dat gaat mij bv te ver. Maar soms moet je praktisch zijn ten koste van netheid. En als dan Safari niet begrijpt hoe ie een validated pagina moet renderen terwijl in IE en FireFox het prima gaat, prima, Safari is ook jezelf een handicap aanmeten. Parkeerkaart af te halen op gemeentehuis.

Het is vooral eigenbelang dat ik probeer netjes te werken, net zo makkelijk met het aanpassen. Nu wil ik mezelf nog weleens in de vingers snijden door een wat vage layout maar dan is er ook vaak wel een quick'n dirty oplossing. Het hypen van dingen roept bij mij sowieso weerstand op dus doe ik het 'netjes' vooral voor mezelf. Is de tijd er niet, dan niet.

[Pkunk]

offtopic:
Even een dankwoord aan de TS want de links die je hebt gegeven zijn helemaal wat ik altijd zocht en nooit heb kunnen vinden. Je bent mijn held voor vandaag.

[R2D2]

Erkens schreef op dinsdag 24 januari 2006 @ 15:51:
[...]


Op drukke sites kan een paar KB toch veel uitmaken, als je bijvoorbeeld je frontpage kan reduceren met 1KB totaal (incl de nieuwe CSS file welke tevens gecached wordt) dan is dat met 10.000 bezoekers al 10MB. Niet onder de indruk?
Als ik bijvoorbeeld hier naar de t.net frontpage kijk, daar staat dat ze ruim 1600 pageviews per minuut hebben. 1600*60*24*30 = 69120000 page views per maand. Dat zou neerkomen op een besparing van 69GB per maand!

Daarnaast zijn kleine bestanden natuurlijk makkelijker te onderhouden.

En waarschijnlijk is dat getal X een getal waar je niet wakker van ligt als je kijkt naar het totale traffic cijfer.

edit:
ik lig weer te slapen.... is al lang gezegt

Ik ben zelf geen webdesigner maar kloot een beetje aan en ik kan zowel met div's prima uit de voeten als met tabellen. Div's gebruik ik wanneer het simpel blijft (skills om complexe dingen te gaan bouwen heb ik simpelweg niet) en wanneer het allemaal wat lastiger word pak ik mooi tabellen.

Ik houd voor mezelf de regel vast dat er behalve een class verder niets in de <td> regel mag staan aan info die niet weg gewerkt kan worden in een CSS. Natuurlijk kan alles via de CSS maar ik snap het probleem met tabellen soms niet helemaal als ik zie wat voor fratsen ik allemaal uit moet halen om de zaak cross browser proof te krijgen als ik alles CSS wil stijlen en wat voor tijd dat vreet. Daarnaast gooi ik mijn website nooit dusdanig om dat ineens alles anders moet.... ik kan dat voor een groot deel nu ook in de CSS en als ik echt wat anders wil dan maak ik wel een compleet nieuwe template voor mijn site.

Naar mijn (en erbij vermeldend dat ik er amper kaas van heb gegeten) mening heb je een verantwoord gebruik van tabellen en een onverantwoord gebruik, ik denk dat ik nog redelijk aan de goede kant zit, echter ben ik ook van mening dat het hele <div> verhaal soms een beetje overhyped word en sommigen een beetje door slaan op dit vlak.

Overigens is mijn cms ook grotendeels op tabellen gebaseerd (Joomla) en die zijn er volgens de roadmap pas eind 2007 uit dus mocht ik het tegen die tijd snappen en kan ik de zaak met css zonder al teveel gekontendraai cross browser proof krijgen en heb ik tijd over..... dan zal ik me er eens een keer echt druk om gaan maken (ik ben me er inmiddels wel in aan het verdiepen....echter zal ik nooit een goeroe worden op dit gebied )

[ Voor 6% gewijzigd door R2D2 op 25-01-2006 01:03 ]

[Verwijderd]

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.

Hehe, ik ben zo'n hobbyist en fanboy
Maar goed, ik ben dus webdesigner en developer. Persoonlijk vind ik CSS erg mooi, en als ik voor mezelf aan het hobbyen ben, dan ben ik uberperfectionist...

- Beter! weer een regel uit mijn html kunnen halen, waardoor de site nog sneller ingeladen wordt!
- Kant en klare javascript componenten en cms systemen ? Nah, zelf kan ik dat beter
- Hmmz, deze gif ziet er ook goed uit met 8 kleuren in plaats van 16
- Rendert mijn site eigenlijk wel in Netschaap 4?
- Die broncode lijnt niet netjes uit. Beetje tweaken nog
- Kant en klare componenten om sql queries uit te voeren? Als ik ze met de hand schrijf zijn ze net wat sneller
- Postback en viewstate? Dat vertraagt alleen maar...
- Enz..

Maar nee, mijn baas snapt niks van beauty, hij wil ook nog wat verdienen...

Tuurlijk kan je css-only (vooral div elementen voor mij) sites best snel opbouwen, zeker met wat ervaring. Maar het blijft kutten met sommige dingen, zoals footers, of bijvoorbeeld plaatjes alignen naar bottom (en dat compatible maken voor safari, ie, firefox en opera). Dan werk ik met visual studio 2003; microsoft heeft nog niet veel kaas gegeten van doctype's en snelle rendering van pagina's (om over mijn collega's maar te zwijgen). Ook hebben we een heel arsenaal aan componenten voor bijvoorbeeld menu's en grids, die best snel te bouwen zijn, maar in mijn ogen nodeloos vetragen (door grote blokken aan javascript / html, en 50 regels aan viewstate etc).

Afijn, ik heb een tijdje alleen maar css sites gebouwd, maar ben nu toch maar weer teruggestapt op tables. En daarmee kan ik nagenoeg alles bereiken wat ik wil. Toch vind ik het toch ergens pijnlijk als ik een site aflever waarvan ik zelf vind dat het veel beter had gekund, maar goed het went.


En mijn baas heeft liever dat de site snel af is en redelijk werkt.

[Verwijderd]

crisp schreef op dinsdag 24 januari 2006 @ 23:42:
Daar kan ik wel op inhaken
Kleinere code is absoluut geen streven, en de 200GB zal ook geen 200GB zijn aangezien we gebruik maken van HTTP compressie Wat uiteraard wel belangrijk is is onderhoudbare en flexibele code; dat goed gebruik van HTML en CSS in veel gevallen ook besparing op grootte opleverd is dan mooi meegenomen

Precies, dat is het hele punt, maar waar het naartoe ging was het aanpassen van de code met als doel een besparing te krijgen van bestandsgrootte, op die opmerking haakte ik in.

[ Voor 5% gewijzigd door Verwijderd op 25-01-2006 08:49 ]

[Erkens]

Verwijderd schreef op woensdag 25 januari 2006 @ 08:45:
Precies, dat is het hele punt, maar waar het naartoe ging was het aanpassen van de code met als doel een besparing te krijgen van bestandsgrootte, op die opmerking haakte ik in.

afaik was jij juist de eerste die dat aanhaalde en dat was dus de opmerking waar _ik_ op in haakte...
Maargoed, dan nog lees je niet, want ook ik heb al diverse keren gezegt dat dat niet het hoofddoel is, het is mooi meegenomen.

[chem]

Verwijderd schreef op dinsdag 24 januari 2006 @ 21:39:
[...]
En totdat die kennis op een bepaald niveau is zijn dergelijke projecten nog steeds duurder. Dat is een beetje wat ik hier uiteen zet.

Maar dat is toch op zich geen probleem? Kennisverhoging binnen het bedrijf kost altijd geld, en levert uiteindelijk, hopelijk, meer geld op.

[...]

Tagging is vooral een behoefte die ontstaat uit wat men information overload noemt, de basis waarom WinFS door Bill Gates werd geintroduceerd. Het is niet alleen iets wat je op het web tegenkomt, het was al heel lang gemeengoed in industriele document management systemen.

True, het is ook niet iets nieuws; maar het juist en consistent taggen is lastig; het is nog vele malen subjectiever dan de semantiek van HTML en het wordt al snel "je doet maar wat". Achteraf hertaggen bij een flinke DB is bv. waanzin.

Maar het toont voor mijn gevoel juist aan dat webdevven meer een vak aan het worden is, en steeds meer gericht op informatie-techniek (komt dat naampje ICT toch weer eens van pas); en minder op het omzetten van een ontwerp naar de code die daarvoor nodig is.

[...]

Een forum is dan ook een layout die uitermate geschikt is voor dit soort aanpakken. Ik denk ook dat je nu wel een layout te pakken hebt die vaak een zelfde opbouw van informatie heeft en daardoor bijzonder rendabel is. Er zijn niet zo bizar veel uitgebreide layouts, die zo ideaal zijn voor deze aanpak en ook nog direct te hergebruiken zijn. Maar een layout zoals T.net is niet zo makkelijk toe te passen in een andere vorm, omdat er een bepaalde identiteit aan vast zit. Een forum heeft een algemeen aanvaard format wat dat betreft

Dat is niet helemaal waar; kijk dan toch eens naar bv. vrouw.nl vs nosheadlines.nl vs. de base_grey template die je als abo hier ook kunt kiezen; er zijn welliswaar voor sommige onderdelen toch custom templates gebruikt maar dat is vooral om extra informatie weer te geven of de informatie te herstructureren (bv. dl ipv ul) omdat er een andere betekenis/relatie is gekomen. Desalniettemin is toch > 90% van de templates gelijk (zo niet meer), met toch een eigen layout.

[Verwijderd]

chem schreef op woensdag 25 januari 2006 @ 09:49:
Maar dat is toch op zich geen probleem? Kennisverhoging binnen het bedrijf kost altijd geld, en levert uiteindelijk, hopelijk, meer geld op.

Laten we het hopen Het punt met de hogere kosten tot nu toe, is dat je in de "oude" situatie alleen maar aan hoeft te geven "maak deze layout". Tegenwoordig komt er een eisenpakket bij, qua markup, css, standaarden, etc. Dat was er vroeger nooit, en dat is een verplaatsing van de kosten van tijd die aan het coden wordt besteed naar tijd die aan het valideren en specificeren wordt besteed. Er zijn vandaag de dag veel meer eisen.

Maar het toont voor mijn gevoel juist aan dat webdevven meer een vak aan het worden is, en steeds meer gericht op informatie-techniek (komt dat naampje ICT toch weer eens van pas); en minder op het omzetten van een ontwerp naar de code die daarvoor nodig is.

Dat was het eigenlijk altijd al. Vroeger al toen men door ervaring kon aantonen dat ze hun ontwerpen in zowel netscape, mac en internet explorer exact hetzelfde eruit konden laten zien. Ik denk meer dat het puur een verschuiving is van de technieken, en niet zozeer iets extras heeft gekregen. Misschien kijk ik er wel te nuchter tegenaan

Dat is niet helemaal waar; kijk dan toch eens naar bv. vrouw.nl vs nosheadlines.nl vs. de base_grey template die je als abo hier ook kunt kiezen; er zijn welliswaar voor sommige onderdelen toch custom templates gebruikt maar dat is vooral om extra informatie weer te geven of de informatie te herstructureren (bv. dl ipv ul) omdat er een andere betekenis/relatie is gekomen. Desalniettemin is toch > 90% van de templates gelijk (zo niet meer), met toch een eigen layout.

Je hebt helemaal gelijk, maar het is denk ik wel om goed in je achterhoofd te houden dat deze voordelen niet gegarandeerd zijn

[ Voor 13% gewijzigd door Verwijderd op 25-01-2006 20:48 ]

[Roa]

Okay, vraagje van mij, ik weet niet of dat echt de bedoeling is, maar goed.

Ik ben bezig aan een website en daar wil ik horizontaal een menu maken. Dus ik heb een <h5> gebruikt als 'container' (het is immers een header, bovenaan de site..?) en hierin staat een span en verschillende links (<a>). Echter, span en links zijn inline elementen en kan je geen hoogt/breedte meegeven zonder ze block te maken. Maar als ze block zijn willen ze weer niet naast elkaar zonder floats. Is het in dit geval dan geoorloofd om tabellen te gebruiken? Het is immers een soort van tabel, het is slechts 1 rij, maar het is in princiepe wel een tabel, of is het nu de bedoeling om dus met floats e.d. te gaan werken?

Overigens gebruikte ik altijd de tabellen aanpak, dus het is even wennen om daar vanaf te stappen en te pogen om semantisch correct te doen alsmede me ook nog eens aan alle regeltjes te houden voor de W3c enzo (alhoewel dat niet het moeilijkste is).

[ Voor 5% gewijzigd door Roa op 26-01-2006 01:35 ]

[Verwijderd]

Roa schreef op donderdag 26 januari 2006 @ 01:34:
Ik ben bezig aan een website en daar wil ik horizontaal een menu maken. Dus ik heb een <h5> gebruikt als 'container' (het is immers een header, bovenaan de site..?)

Dat is net zomin een header als dat de inhoudsopgave bovenaan de voorpagina van een krant een kop is. De algemene opvatting is dat het een lijst met links is, dus:

HTML:

<ul>
    <li><a ...>Item</a></li>
    <li><a ...>Item</a></li>
    ...etc
</ul>

[...]of is het nu de bedoeling om dus met floats e.d. te gaan werken?

Ja.

[Verwijderd]

Een hn is een heading, geen header. Een heading is een kop of een titel.

[chem]

Verwijderd schreef op donderdag 26 januari 2006 @ 08:12:
[...]

Dat is net zomin een header als dat de inhoudsopgave bovenaan de voorpagina van een krant een kop is. De algemene opvatting is dat het een lijst met links is, dus:

HTML:

<ul>
    <li><a ...>Item</a></li>
    <li><a ...>Item</a></li>
    ...etc
</ul>

En als het een geordend/hierarchisch menu is kan je OL gebruiken, mits dat uiteraard klopt.

[Roa]

Okay, bedankt allemaal. Toen ik vanochtend wakker werd had ik eigenlijk ook het idee dat een H5 daar niet helemaal correct was en dat een lijst gebruiken waarschijnlijk beter werkte. Dit vermoedden wordt nu dus bevestigd.

Well then, ik ga weer even verder ploeteren

[Verwijderd]

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. Dat is ook meermalen genoemd in dit topic.
Wanneer een template is opgemaakt volgens de standaarden en impliciete afspraken qua gebruik van semantiek, dan is het wijzigen van een design appeltje-eitje. Ik snap dan ook niet waarom Gordijnstok zeurt over zijn personeel. Blijkbaar heb je prutsers in dienst en moet je ze of een training geven of de tent uit schoppen en beter personeel uitkiezen.
Wanneer je te maken hebt met een professional dan zal ontwikkeling in standaarden niet meer tijd kosten (tering zeg, weer een dejavu). Als je zorgt dat je personeel deskundig is, kan je gewoon op de uren en kosten blijven letten en glimlachend een virtueel schouderklopje geven wanneer een project succesvol afgerond is. Die grote productiefabrieken zouden eens wat meer tijd en energie moeten steken in training van hun personeel. Niet in de laatste plaats omdat webstandaarden nou eenmaal goed verkopen (mits je benadrukt dat het niets meer kost, maar ze wel meer krijgen).
Degene die beweerde in dit topic dat b en i overbodig zijn, is trouwens aanzienlijk in mijn aanzien gedaald.

[Verwijderd]

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.

Verwijderd 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. Dat is ook meermalen genoemd in dit topic.
Wanneer een template is opgemaakt volgens de standaarden en impliciete afspraken qua gebruik van semantiek, dan is het wijzigen van een design appeltje-eitje. Ik snap dan ook niet waarom Gordijnstok zeurt over zijn personeel.

Ter informatie, allereerst zeur ik niet; ik constateer ... naast dat we onshore met ervaren ontwikkelaars werken stuur ik ook teams aan in het buitenland. Zodoende krijg ik ook accurate gegevens over voortgang, uren die worden besteed, bottlenecks etc. immers moet ik rapportages uitbrengen. Op basis van deze rapportages en de hoeveelheid coaching die er overall nodig is, kan ik stellen dat semantisch werken en css layouting nog steeds niet zo makkelijk op te pakken is als men het probeert te schetsen, en de complexiteit van dit alles de voorgestelde besparingen niet altijd per definitie waarmaakt. Dat is ook het enige punt wat ik maak. Het is niet een kwestie van eventjes..

Mensen moeten samenwerken, het zijn geen one men armies. Er zijn niet veel developers met het kennisniveau van een en ik noem maar even wat Crisp, Blues, Anne, Andre, of een Clay. Daar moet je mee rekening houden, en dan komen zaken als de visie op semantiek om de hoek kijken, die behoorlijk subjectief kunnen zijn. Kijk naar het aantal vragen op het web over, moet ik nu dit doen, of moet ik nu dat doen. Stel je dat voor in een groep van 40 personen, en krijg ze allemaal op dezelfde lijn.

Nu is het ook geen probleem, daar de kosten in het buitenland voor pure produktie lager zijn dan in ons eigen land. Echter, ik weet dat ze lager kunnen als de techniek volledig onder controle is.

Vanaf de zijlijn is het altijd zo makkelijk roepen totdat je te maken krijgt met cultuur verschillen, het werken in teamverband aan een enkel project, kennisoverdracht, etc.. je kunt je geen voorstelling maken wat er allemaal omheen aan parameters meespeelt.

Blijkbaar heb je prutsers in dienst en moet je ze of een training geven of de tent uit schoppen en beter personeel uitkiezen.

Dat zou zeker de makkelijkste weg zijn, de tent uitschoppen en wachten totdat die paar developers zich aanmelden met de ervaringen die we zoeken. Vind je het erg dat ik gewoon die kosten voorlopig voor lief neem, en die minder ervaren mensen liever op een constructieve wijze coach zodat ze zich alsnog gaan terugbetalen, en nieuwe resources zelf gaan coachen?

Ik zou zeggen, stuur me je CV, jij bent schijnbaar zo goed dat je mij de les kunt leren over hoe het wel zou moeten, misschien zit ik al wel te lang in de wereld van web development. We hebben universitair geschoold personeel wat zich bezig houdt met requirements, trainingsmateriaal, etc. schijnbaar kun jij het beter?

Wanneer ...Die grote productiefabrieken zouden eens wat meer tijd en energie moeten steken in training van hun personeel. Niet in de laatste plaats omdat webstandaarden nou eenmaal goed verkopen ...

Waarom verkopen webstandaarden dan goed, ... het is een leuk marketing instrument, maar voor het sales process van ondergeschikt belang aan andere aspecten.

Verder ben ik benieuwd, waarop bazeer je al deze wijsheid met trainingen? Ik begin ondertussen echt razend benieuwd te worden. Ik wil best een discussie met je aangaan, maar dan wel graag op de normale manier van communiceren. Ik kan niet zomaar met cijfers gaan strooien, ik kan je wel zeggen dat de theorie niet gelijk is aan de praktijk.

[ Voor 39% gewijzigd door Verwijderd op 26-01-2006 23:46 ]

[Erkens]

Verwijderd 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.

http://www.w3.org/TR/html4/present/graphics.html#h-15.2
http://www.w3.org/TR/html4/struct/text.html#h-9.2

overigens:

Talks about the importance of the alt tag.

als je dat niet belangrijk vind moet je maar een ander beroep zoeken imo

[ Voor 6% gewijzigd door Erkens op 26-01-2006 23:37 ]

[Victor]

Erkens schreef op donderdag 26 januari 2006 @ 23:01:
overigens:

[...]

als je dat niet belangrijk vind moet je maar een ander beroep zoeken imo

Tag is in het artikel cursief geschreven, het gaat hier immers om een attribuut, niet om een tag.

[Erkens]

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

[Voutloos]

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.

[imp4ct]

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.

[Verwijderd]

Verwijderd 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.

[ Voor 2% gewijzigd door Verwijderd op 27-01-2006 11:49 . Reden: typo ]

[Erkens]

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

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

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.

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

ik vind onderhoud van de code belangrijker

[chem]

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.

Verwijderd 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?

[RagaBaSH]

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.

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.

[Verwijderd]

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.

[ Voor 4% gewijzigd door Verwijderd op 27-01-2006 11:36 ]

[crisp]

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

Verwijderd 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.

[Verwijderd]

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.

[Verwijderd]

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:

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.

[ Voor 38% gewijzigd door Verwijderd op 27-01-2006 18:51 ]

[alienfruit]

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.

[Clay]

Verwijderd 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.

[Alain]

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:

<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:

body {
font-size: 9pt;
}

HTML:

tralalala<br>
tralalala

En later:

HTML:

<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:

<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:

<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.

[ Voor 12% gewijzigd door Alain op 29-01-2006 05:14 ]

[Dextro]

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

De wiki van Css-discuss:

quote: http://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.

[Victor]

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

HTML:

<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.

[Alain]

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?

[Victor]

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

[-Lars-]

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.