[Disc.] Tabellen vs. semantisch design (anno 2009)*

[curry684]

Hacku schreef op donderdag 06 augustus 2009 @ 00:02:
Met display: table; kan het, maar dan kan je evengoed tabellen gebruiken.

Ho, stop, deze uitspraak moet ik toch even pertinent tegen in het geweer schieten. Een semantisch correct non-table element dat zich rendertechnisch toevallig dient te gedragen als table kun je nooit evengoed vervangen door een table. In het eerste geval kies je ervoor een div, paragraph, header, blockquote, whatever te gebruiken, en die los in het CSS-bestand dat tenslotte over rendering besluit een specifieke vorm van renderinggedrag te geven, in het tweede geval verneuk je de semantiek van je HTML-document. Dat is me nogal geen verschil, en juist het hele fundamentele punt van deze discussie

[ Voor 3% gewijzigd door curry684 op 06-08-2009 00:18 ]

[Yoozer]

Soultaker schreef op woensdag 05 augustus 2009 @ 16:48:
Als ik code moet schrijven zoals die van Herko, dan beschouw ik CSS toch echt als een soort Postscript: leuk dat 't werkt, maar niet bedoeld om handmatig te schrijven.

Volstrekt onzinnige vergelijking. "Leuk dat het werkt", kom nou.

CSS laat je toe om over opmaak in termen van unieke en wederkerende elementen te denken. Inline styles zijn volslagen zot als je ze zelf neerkalkt. Als je in je tekst quotes hebt van iemand is het toepassen van een setje stijlen op een blockquote tag, desnoods met nog een classname oneindig maal eenvoudiger dan een stel p's vernaggelen.

CSS niet zelf schrijven? Het is juist auto-generated CSS die er een zooi van maakt met spannende namen als .donkerBlauwVetGedrukt1, donkerBlauwVetGedrukt2 etc. Het zelf schrijven laat je nu juist toe om het zodanig toe te passen dat het nut heeft. Alleen al wat een beetje JS erbij kan doen.

Nee, je stelt je een beetje aan met die opmerking en doet jezelf zwaar tekort door niet eens een poging te wagen.

[Cousin Boneless]

Na alles wat er over CSS-layout versus table-layout is geschreven gelezen te hebben (mijn laatste reactie in dit topic) kan ik vaststellen dat de opbouw van de discussies altijd hetzelfde verloopt: het begint met geschreeuw over en weer en eindigt in een genuanceerder beeld.

Vaak krijg ik de indruk dat moderne websites er allemaal het zelfde uitzien en dat het gebruik van CSS daar debet aan is:
- Stel dat er makkelijk verticaal gecentreerd kon worden, dan werd dat vast veel vaker gedaan.
- Stel dat max-width en max-height goed werden ondersteund, dan zou ook het liquid layouten zo weer in zwang raken.

Wat dat betreft zijn we er niet op vooruit gegaan. Ook de doctypes hebben voornamelijk beperkingen opgelegd. Stel je wilt een site met een header en een footer en een overflow:auto op de container die er tussenin zit. Met een transitional doctype en table-layout niet moeilijk. Met CSS en/of strict doctype alleen te doen als de header en footer een fixed height hebben (wie? kom maar met de code)

Bij het gebruik van tables moet je volgens mij pragmatisch denken. Wil je dat bij dynamische content de cellen in een "row" een gelijke hoogte hebben en de cellen in een "kolom" dezelfde breedte, dan is een table de juiste tool. En dan kan ik me er misschien nog wel uitlullen dat dit semantisch gezien een tabel is. Toch leg ik het liever technisch uit: Het heeft de dynamische karakteristieken van een grid/tabel. En aan dat concept is niets mis.

Websites die ik in mijn vrije tijd maak zijn over het algemeen vrij complex (semi liquid). De oorzaak: artistieke aanleveringen in PhotoShop, waardoor de background de viewport bepaalt. Er zitten dan twee mannetjes op mijn schouder. De ene roept: "semantisch! state-of-the-art!" en de ander fluistert: "doe toch een tabelletje, dat is zoveel beter voor je nachtrust en bloeddruk".

Dat zoekmachines moeite hebben met het indexeren van een table-layout heb ik nog nooit gemerkt. En dat stipt volgens mij ook wel aan waarom de discussies altijd zo mank gaan: table-layout sluit semantiek niet uit. Okee, de table is verkracht, maar de overige tags die veel meer semantische lading hebben (h1, h2, strong) kun je nog steeds naar hartelust gebruiken. En we schreven de site bovendien voor mensen en niet voor zoekmachines? De semantiek kun je ook misbruiken om hoger te scoren. Het semantische web is zodoende een utopie. De "keywords" meta tag wordt niet voor niets genegeerd.

Ligt het aan mij of is display:table-cell een goedmakertje voor wat ons is afgeleerd? Opeens doet vertical-align zoals het nog in de oude vertrouwde td doet. Is het logisch?

[ValHallASW]

Hacku schreef op donderdag 06 augustus 2009 @ 00:02:
[...]
Schoonheid, het vraagt wel wat ervaring als je hiermee nog nooit gewerkt hebt.

Dat is dus precies het probleem met CSS: het in contraintuitief en als je dat zegt dan krijg je te horen dat het komt doordat je er geen ervaring mee hebt. Nee, duh, als je ervaring opdoet met een auto die linksaf gaat als je rechts stuurt en rechtsaf als je links stuurt dan werkt dat op een gegeven moment óók wel, en het is dan óók 'logisch'. Handig en togankelijk is alleen iets heel anders. Tabellen, daarintegen, zijn beperkter, maar zijn in ieder geval intuitief

offtopic:
nog even los van het gebruik van termen als 'schoonheid' in zo'n topic...

Overigens: css-table layouts lossen niets op om de volgorde in je bestand logisch te houden: je moet dan nog steeds van links naar rechts werken...

Overigens II: waarom staat het menu op GoT bovenaan? Is dat een bewuste ontwerpkeuze (in lynx is het namelijk nogal irritant: ik wil het topic, niet het menu, en ik moet (op 80x24) zeven pagina's naar beneden. Hoe zou dat zijn voor een braillelezer?) of is dat puur door zwakheden in css/css-implementaties?

[ Voor 2% gewijzigd door ValHallASW op 06-08-2009 01:07 . Reden: + opmerking over tabellen ]

[curry684]

Yoozer schreef op donderdag 06 augustus 2009 @ 00:22:
[...]

Het is juist auto-generated CSS die er een zooi van maakt met spannende namen als .donkerBlauwVetGedrukt1, donkerBlauwVetGedrukt2 etc.

Nog afgezien van spanning maakt het inderdaad weer het hele punt van CSS overbodig doordat je weer opmaak in je HTML terug laat komen. Wat nu als die blauwe tekst morgen rood moet zijn, pas je dan de element classes aan of de CSS file?

[Bosmonster]

Denk dat het voor sommige mensen soms ook lastig te bevatten is dat html/css (en javascript, want die hoort er tegenwoordig ook volledig bij) meer is dan een een beetje opmaak alleen. Het is niet meer alleen een beetje design implementatie. Voor een goede synergie tussen die 3 is volledige controle en gedegen technische kennis benodigd. Daarom is frontend developer tegenwoordig ook een losse discipline en niet meer iets dat de webdesigner er even naast doet (sommige reclamebureau's buiten beschouwing gelaten *kuch*).

Het is een vak waarbij je analytisch en technisch sterk moet zijn en je continu op de hoogte moet blijven van de laatste ontwikkelingen. Waar kort geleden html4 strict nog de de facto standaard was, begint dat nu al te verschuiven naar de simpele html5 doctype bijvoorbeeld. Wat zijn de voor- en nadelen en wanneer stap je over? Of iets als font-embedding dat sinds Firefox 3.5 in alle browsers mogelijk is, wat ga je daarmee doen? Ga je het al toepassen? Etc.

Stilstand is achteruitgang.

[ Voor 32% gewijzigd door Bosmonster op 06-08-2009 01:18 ]

[crisp]

Cousin Boneless schreef op donderdag 06 augustus 2009 @ 00:47:
[...]
Vaak krijg ik de indruk dat moderne websites er allemaal het zelfde uitzien en dat het gebruik van CSS daar debet aan is:
- Stel dat er makkelijk verticaal gecentreerd kon worden, dan werd dat vast veel vaker gedaan.

Dat betwijfel ik; voor normale websites zie ik geen reden om af te wijken van het principe dat content gewoon bovenin begint en doorloopt naar onder, eventueel bereikbaar met een scrollbar uiterst rechts over de volledige hoogte van het browserscherm. Daarvan afwijken is over het algemeen niet intuitief voor de gebruiker en zou dus enkel bij hoge uitzondering (als vorm boven functie gaat) gebruikt moeten worden.

- Stel dat max-width en max-height goed werden ondersteund, dan zou ook het liquid layouten zo weer in zwang raken.

Zelfs dan is liquid-within-margins nog erg lastig te doen met enkel CSS als hulpmiddel. Daarbij moet ook je content zich daar wel voor lenen...

[...]Met een transitional doctype en table-layout niet moeilijk. Met CSS en/of strict doctype alleen te doen als de header en footer een fixed height hebben

Er is wat browsers betreft geen verschil in rendering bij een transitional doctype of een strict doctype

[Patriot]

Hacku schreef op donderdag 06 augustus 2009 @ 00:02:En waar is het lijstje met voordelen?

Daar ging het toch niet over? Als je bij de fietsenmaker komt om te vragen of hij je band wil plakken omdat die lek is vraagt hij toch ook niet om een lijstje met dingen die níet stuk zijn?

Sowieso, als ik zaken als "CSS is a pain to work with" tegenkom hoef ik niet verder te lezen: je bent developer, geen mietje die ervandoor rent wanneer je voor een uitdaging staat.

Oh kom op, je weet zelf ook wel dat dat onzin is. Als blijkt dat er dingen aan CSS zijn die onhandig zijn dan is het in iedereen's voordeel om daar wat aan te doen. Je moet ook weten wat die dingen zijn dus is het niet vreemd om het daar over te hebben.

[Bosmonster]

crisp schreef op donderdag 06 augustus 2009 @ 01:29:
[...]
Er is wat browsers betreft geen verschil in rendering bij een transitional doctype of een strict doctype

Bedoel je dat voor een specifiek voorbeeld? Want in het algemeen is dit natuurlijk wel het geval, aangezien transitional doctypes in veel browsers quirksmode of almost-quirksmode activeren.

[crisp]

Bosmonster schreef op donderdag 06 augustus 2009 @ 08:57:
[...]


Bedoel je dat voor een specifiek voorbeeld? Want in het algemeen is dit natuurlijk wel het geval, aangezien transitional doctypes in veel browsers quirksmode of almost-quirksmode activeren.

https://developer.mozilla...illa%27s_DOCTYPE_sniffing

Transitional doctypes (volledige, dus met system identifier) triggeren 'Almost Standards Mode' (wat natuurlijk iets anders is dan 'almost-quirksmode' ). Het verschil met standards mode is minimaal, en de kans is groot dat dat verschil ooit nog eens weggewerkt gaat worden (het gaat ironisch gezien om sliced images in table layouts )

[XWB]

curry684 schreef op donderdag 06 augustus 2009 @ 00:17:
[...]

Ho, stop, deze uitspraak moet ik toch even pertinent tegen in het geweer schieten. Een semantisch correct non-table element dat zich rendertechnisch toevallig dient te gedragen als table kun je nooit evengoed vervangen door een table. In het eerste geval kies je ervoor een div, paragraph, header, blockquote, whatever te gebruiken, en die los in het CSS-bestand dat tenslotte over rendering besluit een specifieke vorm van renderinggedrag te geven, in het tweede geval verneuk je de semantiek van je HTML-document. Dat is me nogal geen verschil, en juist het hele fundamentele punt van deze discussie

Ho, stop, check het voorbeeld nog even waar het om ging.

Daar ging het toch niet over? Als je bij de fietsenmaker komt om te vragen of hij je band wil plakken omdat die lek is vraagt hij toch ook niet om een lijstje met dingen die níet stuk zijn?

Irrelevant, wat ik bedoel is dat iets afbreken veel makkelijker is dan de voordelen opsommen. En dat heb je overal, maar dat wil nog niet zeggen dat het ergens op slaat.

Oh kom op, je weet zelf ook wel dat dat onzin is. Als blijkt dat er dingen aan CSS zijn die onhandig zijn dan is het in iedereen's voordeel om daar wat aan te doen. Je moet ook weten wat die dingen zijn dus is het niet vreemd om het daar over te hebben.

Een paar zaken zijn inderdaad pain in the ass, maar niet het hele css gebeuren zoals hij dat wel laat overkomen.

Dat is dus precies het probleem met CSS: het in contraintuitief en als je dat zegt dan krijg je te horen dat het komt doordat je er geen ervaring mee hebt. Nee, duh, als je ervaring opdoet met een auto die linksaf gaat als je rechts stuurt en rechtsaf als je links stuurt dan werkt dat op een gegeven moment óók wel, en het is dan óók 'logisch'. Handig en togankelijk is alleen iets heel anders. Tabellen, daarintegen, zijn beperkter, maar zijn in ieder geval intuitief

Dat is toch geen correct voorbeeld? CSS vraagt ervaring, maar daarom hoeft het niet onhandig te zijn.

[ Voor 15% gewijzigd door XWB op 06-08-2009 09:23 ]

[Yoozer]

Cousin Boneless schreef op donderdag 06 augustus 2009 @ 00:47:
Vaak krijg ik de indruk dat moderne websites er allemaal het zelfde uitzien

Verrek. Zou het wellicht ook kunnen omdat het toevallig een goed ontwerp is? Zoekdoos midden of rechtsboven, titel links, want we lezen van links naar rechts, menu bovenin zodat er zoveel mogelijk content op een pagina kan, en eventuele features links of rechts in een smallere kolom.

Klagen over sites die er hetzelfde uitzien is klagen over het feit dat auto's de gaspedaal allemaal op ongeveer dezelfde plek hebben. Het is niet zo dat er geen experimenten meer mogelijk zijn, maar de interface van een site moet niet vreemd zijn maar vertrouwd; omdat je zo bezoekers kunt aanhouden in plaats van wegjagen. Als ik de zoekfunctie niet aantref op de plaats waar ik 'm verwacht betekent dat je niet genoeg inhoud hebt om te doorzoeken of wil je dat ik menu's ga doorjagen in Day Of The Tentacle-stijl.

Alle touchscreen telefoons zijn ook zo saai. Allemaal zwart (of wit) met een paar knoppen onderin of bovenin. Welkom bij het verschijnsel dat technologische convergentie heet.

en dat het gebruik van CSS daar debet aan is:

Daar heeft CSS geen moer mee te maken.

- Stel dat er makkelijk verticaal gecentreerd kon worden, dan werd dat vast veel vaker gedaan.

Stel dat er op mijn muis nou een scrollwiel zit dat van boven naar beneden gaat. Dan ben ik nogal getikt als ik horizontaal scrollen ga forceren.

Er zijn 5 plekken op je scherm die het makkelijkst bereikbaar zijn; de hoeken en waar je muis op dat moment zit. De browser maakt deze plekken al min of meer onbruikbaar door er chrome neer te zetten, en nou ga je met centreren deze plekken nog eens extra onbruikbaar maken omdat m'n muis niks doet als ik 'm er neer zet.

Op een mobiele telefoon met touchscreen heb je een paar grote, eenvoudige knoppen. Dat is omdat je lompe vingers niet goed zijn in mikken (die van mij overigens ook niet) en je tijdens lopen/eten/douchen/sex evengoed op "REJECT CALL" moet kunnen hengsten. Mensen zijn slecht in mikken.

Centreren is leuk. Betekent voor 1024 x 768 dat je een klein venstertje ergens in het midden van het scherm hebt waar je content in zit. Nou schrijf ik even 3 A4tjes vol. De scrollruimte is klein. De kans dat ik op het venster klik om het focus te geven is klein. Nu zit je hier op het forum, en je ziet maar 1 scrollbar en die zit rechts, en is bijna net zo groot als het hele scherm.

Waarom, in godesnaam, zou je die niet gebruiken?

- Stel dat max-width en max-height goed werden ondersteund, dan zou ook het liquid layouten zo weer in zwang raken.

Scrollen is goedkoop. Een boek heeft pagina's die dezelfde grootte zijn omdat je anders met losse lappen papier ligt te zeulen. Een website heeft die beperking niet en het is volstrekt achterlijk om real-world beperkingen toe te gaan passen op dingen die zich er niks van aan hoeven te trekken.

Websites die ik in mijn vrije tijd maak zijn over het algemeen vrij complex (semi liquid). De oorzaak: artistieke aanleveringen in PhotoShop, waardoor de background de viewport bepaalt.

Daarom laat je de klant zelf geen design doen, of ga je ze heel snel leren waarom hun ontwerp waardeloos is. Leer ze te ontwerpen voor het web, niet voor drukwerk, video of multimedia CD-roms.

[ Voor 10% gewijzigd door Yoozer op 06-08-2009 10:00 ]

[Bosmonster]

crisp schreef op donderdag 06 augustus 2009 @ 09:07:
[...]

https://developer.mozilla...illa%27s_DOCTYPE_sniffing

Transitional doctypes (volledige, dus met system identifier) triggeren 'Almost Standards Mode' (wat natuurlijk iets anders is dan 'almost-quirksmode' ). Het verschil met standards mode is minimaal, en de kans is groot dat dat verschil ooit nog eens weggewerkt gaat worden (het gaat ironisch gezien om sliced images in table layouts )

Ehm ja almost standards mode bedoelde ik natuurlijk, het was nog vroeg

Overigens verschilt het nogal per doctype wat het triggered. Veiligste keuze blijft gewoon een strict doctype of html 5 doctype. Ik zie geen reden om een transitional doctype te hanteren eerlijk gezegd anno 2009.

[ Voor 13% gewijzigd door Bosmonster op 06-08-2009 10:03 ]

[moozzuzz]

Booster schreef op woensdag 05 augustus 2009 @ 21:05:
IE8: Load:2591ms Table Start:2836ms Table End:2836ms
FF3.5: Table Start:12ms Table End:386ms Load:1294ms
Bij mij duurt het ook echt even voor de tabel uberhaubt in beeld komt in IE.

Dit kan een probleem zijn als je bv een tabel zou gebruiken om een groot gastenboek of forum weer te geven.

Mijn ervaring met FF3 vs. IE6 geeft aan dat voor (erg) grote data-tables IE beter scoort dan FF. Namelijk na rendering is IE nog handelbaar en FF niet (als in: reageert niet meer)

[crisp]

Bosmonster schreef op donderdag 06 augustus 2009 @ 10:00:
[...]


Ehm ja almost standards mode bedoelde ik natuurlijk, het was nog vroeg

Overigens is de "almost standards mode" behaviour van o.a. Gecko hetzelfde als de "standards mode" in IE7. IE8 lijkt wel de "almost standards mode" behaviour te hebben overgenomen. Jammer, want dat was een kans geweest om "almost standards mode" te droppen zoals al eens eerder is voorgesteld.

Overigens verschilt het nogal per doctype wat het triggered. Veiligste keuze blijft gewoon een strict doctype of html 5 doctype. Ik zie geen reden om een transitional doctype te hanteren eerlijk gezegd anno 2009.

Ik moest zelf zoeken naar de transitional DTD, die gebruik ik ook al jaren niet meer

[donderklik]

Leuk om te lezen wat de verschillen zijn tussen het gebruik van tables en divisions op technisch vlak.

Waarom semantic web (dus divisions) vooral zo belangrijk is, is dat deze wordt gebruikt door spraakbrowsers en screenreaders. Die hebben niets te doen met mooie opmaak en css, maar gebruiken de semantic web voor de 'spraak/voel'-opmaak van de pagina's.

W3C zegt hier het volgende over in Web Content Accessibility Guidelines 1.0 (Guideline 3)

quote: http://www.w3.org/TR/WAI-...gl-structure-presentation

Using markup improperly -- not according to specification -- hinders accessibility. Misusing markup for a presentation effect (e.g., using a table for layout or a header to change the font size) makes it difficult for users with specialized software to understand the organization of the page or to navigate through it.

Het is zeker niet gemakkelijk om aan deze toegankelijkheids richtlijnen te voldoen. Een "Triple-A"-status behalen is ver van gemakkelijk. Maar als al je pagina's aan de "A"-status voldoen, maak je je mensen met een functiebeperking wel gelukkiger.

edit:
Ik heb de hele topic niet gelezen, maar gezocht op een aantal steekwoorden (blind, braille), omdat ik deze argumenten mistte in het begin van de topic (pagina 1-5). Hierdoor heb ik het over hoofd gezien dat Booster al een heel stuk over toegankelijkheid heeft geschreven.

[ Voor 13% gewijzigd door donderklik op 06-08-2009 16:17 . Reden: Dubbel post (?) ]

[curry684]

Ik had het ook al genoteerd maar dan had je moeten zoeken op 'voorleesbrowser'

[Soultaker]

donderklik schreef op donderdag 06 augustus 2009 @ 16:02:
Waarom semantic web (dus divisions) vooral zo belangrijk is, is dat deze wordt gebruikt door spraakbrowsers en screenreaders. Die hebben niets te doen met mooie opmaak en css, maar gebruiken de semantic web voor de 'spraak/voel'-opmaak van de pagina's.

Nou heb ik hier persoonlijk niet heel veel ervaring mee, maar ik heb wel eens een slechtziende met een laptop zien werken, en die had dan gewoon een brailleregel met bijbehorende software die willekeurige tekst van het scherm kon kopiëren naar de brailleregel. Voor zover ik weet werkt voorleessoftware op dezelfde manier: als je tekst kunt selecteren, kan 't voorgelezen worden.

Die software doet dus helemaal niets op HTML niveau. Het werkt gewoon in combinatie met een normale browser, en als de tekst correct gerendert wordt en te selecteren is, dan kan 'ie voorgelezen worden. Niets semantisch web en W3C standaarden. Gelukkig ook maar, want als slechtzienden dáár van afhankelijk waren dan zou misschien 0,1% van het web voor ze beschikbaar zijn.

Ik denk dat usability dus voor een groot deel uit niet-technische aspecten bestaat: niet te kleine fontsizes gebruiken (of zorgen dat de browservoorkeur daarvoor gerespecteerd wordt), geen laag-contrast-kleuren bij elkaar, dat soort dingen.

[ Voor 9% gewijzigd door Soultaker op 06-08-2009 16:53 ]

[disjfa]

Soultaker schreef op donderdag 06 augustus 2009 @ 16:51:
[...]
Nou heb ik hier persoonlijk niet heel veel ervaring mee, maar ik heb wel eens een slechtziende met een laptop zien werken, en die had dan gewoon een brailleregel met bijbehorende software die willekeurige tekst van het scherm kon kopiëren naar de brailleregel. Voor zover ik weet werkt voorleessoftware op dezelfde manier: als je tekst kunt selecteren, kan 't voorgelezen worden.

Jij zou blinde mensen laten kloten om text te selecteren (let op, blinde mensen zien echt helemaal niets )

Dat is best onaardig van je

[Soultaker]

disjfa schreef op donderdag 06 augustus 2009 @ 16:56:
Jij zou blinde mensen laten kloten om text te selecteren (let op, blinde mensen zien echt helemaal niets )

Nee, dat was een voorbeeld van een slechtziende (die dus wel kan zien dat ergens iets staat, maar niet lezen wat precies); ik weet niet hoe volledig blinden werken. De echte vraag was of tools voor blinden überhaupt op HTML niveau werken, want dat is niet vanzelfsprekend. Als die tools gewoon werken met tekst zoals die in de browser weergegeven wordt, dan werken ze dus prima met table-based layouts.

[curry684]

Soultaker: brailleboeken, en dus ook braillebrowsers, voorzien braaf teksten van semantische decoratie om duidelijk te maken wanneer een nieuwe alinea of hoofdstuk begint. Daarvoor heb je toch echt hX headers nodig. Not to mention de organisatie van menu's e.d. die in een unordered list thuishoren en niet in een table cell waardoor de menu's onbruikbaar worden etc. etc.

[Bosmonster]

Sterker nog, een voorlees-browser gaat je gewoon netjes de hele tabel-structuur voorlezen, aangezien die verwacht dat de tabel voor data gebruikt wordt die gerelateerd is op regel- en kolomniveau. Zeker met geneste tabellen kun je daar echt geen kaas meer van maken.

[ Voor 10% gewijzigd door Bosmonster op 06-08-2009 17:37 ]

[Cartman!]

Juist niet, in een tabel is alle content immers gelijk aan elkaar terwijl met een semantische opmaak je met lijsten, koppen en paragraven (ik geef zo maar wat voorbeelden) onderdelen vrij makkelijk uit elkaar kunt halen en weet wat hun eigenschap is. Sites voor bijv. de overheid die aan een set usability eisen moeten voldoen hebben dan ook vrijwel altijd een hele logische opmaak qua code die voor blinden heel logisch is (hun screenreaders dan). Help me ff hoe die richtlijnen heten, laatst nog een site gemaakt ervoor maar ben t ff kwijt

edit: bedankt curry en bosmonster voor het snellere typwerk
edit2: ze heten natuurlijk gewoon Webrichtlijnen

[ Voor 11% gewijzigd door Cartman! op 06-08-2009 17:44 ]

[Bosmonster]

Precies.. als je als ondernemer nog in tabellen werkt kun je opdrachten voor de overheid in ieder geval wel vergeten.

[Cousin Boneless]

Precies.. als je als ondernemer nog in tabellen werkt kun je opdrachten voor de overheid in ieder geval wel vergeten.

En dat is dus precies wat ik vorig jaar beweerde. CSS-layout wordt min of meer opgelegd door de overheid.(waarop werd gereageerd met: "heb je de laatste tijd nog chemtrails gezien?")
En nog belangrijker is, of het zonder fouten door de validator van webrichtlijnen.nl komt. En als de validator brak is, door melding te geven van hidden fields zonder label, het ontbreken van een submit button in een form en dingen die ze niet kunnen controleren, dan heb je als ontwikkelaar toch wel zin om iemand te schoppen. En daarna voeg je alles braaf toe met display:none.

[ Voor 10% gewijzigd door Cousin Boneless op 06-08-2009 23:42 ]

[donderklik]

Cousin Boneless schreef op donderdag 06 augustus 2009 @ 23:00:
[...]

En dat is dus precies wat ik vorig jaar beweerde. CSS-layout wordt min of meer opgelegd door de overheid.(waarop werd gereageerd met: "heb je de laatste tijd nog chemtrails gezien?")
En nog belangrijker is, of het zonder fouten door de validator van webrichtlijnen.nl komt. En als de validator brak is, door melding te geven van hidden fields zonder label, het ontbreken van een submit button in een form en dingen die ze niet kunnen controleren, dan heb je als ontwikkelaar toch wel zin om iemand te schoppen. En daarna voeg je alles braaf toe met display:none.

Wat je ook kunt doen is het maken van verschillende versies van de pagina. Een visueel aantrekkelijke versie en een toegankelijk vriendelijke versie. Deze laatste kun je dan ook mooi aanbieden als print versie.

Bij een goede structuur van je data en wanneer de data, techniek en uiterlijk los van elkaar staan (MVC-patroon) is dat simpel te doen.

[Bosmonster]

Cousin Boneless schreef op donderdag 06 augustus 2009 @ 23:00:
[...]

En dat is dus precies wat ik vorig jaar beweerde. CSS-layout wordt min of meer opgelegd door de overheid.(waarop werd gereageerd met: "heb je de laatste tijd nog chemtrails gezien?")
En nog belangrijker is, of het zonder fouten door de validator van webrichtlijnen.nl komt. En als de validator brak is, door melding te geven van hidden fields zonder label, het ontbreken van een submit button in een form en dingen die ze niet kunnen controleren, dan heb je als ontwikkelaar toch wel zin om iemand te schoppen. En daarna voeg je alles braaf toe met display:none.

Voor zover ik weet is die validator (of QuickScan) alleen maar een snelle test en geen definitieve bepaling of je voldoet aan de webrichtlijnen. Dat gebeurt nog steeds door een persoonlijke evaluatie.

donderklik schreef op vrijdag 07 augustus 2009 @ 09:24:
[...]


Wat je ook kunt doen is het maken van verschillende versies van de pagina. Een visueel aantrekkelijke versie en een toegankelijk vriendelijke versie. Deze laatste kun je dan ook mooi aanbieden als print versie.

Bij een goede structuur van je data en wanneer de data, techniek en uiterlijk los van elkaar staan (MVC-patroon) is dat simpel te doen.

Dat is alleen compleet zinloos. Het hele idee van semantische opbouw en technieken als unobtrusive javascript is dat dezelfde pagina voor iedereen werkt. Je wilt de gebruiker namelijk niet laten kiezen, want in veel gevallen kan die dat niet.

[ Voor 38% gewijzigd door Bosmonster op 07-08-2009 10:42 ]

[Yoozer]

donderklik schreef op vrijdag 07 augustus 2009 @ 09:24:
Wat je ook kunt doen is het maken van verschillende versies van de pagina. Een visueel aantrekkelijke versie en een toegankelijk vriendelijke versie. Deze laatste kun je dan ook mooi aanbieden als print versie.

Waarom meerdere versies? Dit kan ook al met CSS; slechts 1 bestand met print.css definieren met de juiste @media is genoeg. Juist hier vallen table-based layouts op hun snufferd, of je mag elke cel een ID gaan geven.

[ Voor 9% gewijzigd door Yoozer op 07-08-2009 11:51 ]

[curry684]

Cousin Boneless schreef op donderdag 06 augustus 2009 @ 23:00:
[...]

En dat is dus precies wat ik vorig jaar beweerde. CSS-layout wordt min of meer opgelegd door de overheid.(waarop werd gereageerd met: "heb je de laatste tijd nog chemtrails gezien?")

Volgens mij was dat mijn reactie en daar sta ik nog steeds achter hoor Wat jij namelijk beweerde was dat de overheid het gebruik van CSS reguleerde en afdwong en afstraft als je het niet doet, wat niet het geval is. De overheid is een potentiele klant die potentieel opdrachten aan jou wil verstrekken. Als een klant van jou eist dat jij z'n website naakt ontwikkeld op een Pentium 1 met 128MB RAM en Windows 95, heb jij als leverancier de vrije keuze om aan die eisen te voldoen. Als je dat niet wil lever je ze niet, simpel, duizenden andere vissen in de zee.

En thank god heeft de overheid iig z'n kop uit z'n reet gehaald en dwingen ze voor hun leveranciers het gebruik van hedendaagse standaarden af. Maar dat betekent niet dat ze Mirabeau of Lost Boys gaan beboeten als die voor een andere klant een tabelletje gebruiken.

[Anoniem: 3431]

En daarbij: de richtlijn is er, de overheid mag m afdwingen, maar doet elk overheidsorgaan dat ook? Als ik heel snel door utrecht.nl kijk staan niet alle menu's in een unordered list en wordt er ook nog wel eens een tabel gebruikt om het e.e.a. op de juiste plek te krijgen. Kan zijn dat de site van voor 30 juni 2006 is natuurlijk, maar toch. Ze beboeten (of controleren) volgens mij ook zichzelf niet

Verder eens met de semantiek-fanboys. Afwijken is imo alleen goed te praten als je op een enorm besloten site zit waarbij je zelf controle hebt over de gebruikte browser en echt geen tijd hebt (intranet-omgevingen). En dan alleen nog tijdelijk, tot je wel tijd hebt

[isomis]

zijn jullie nog steeds bezig met discussieren?

[NMe]

isomis schreef op vrijdag 07 augustus 2009 @ 15:53:
zijn jullie nog steeds bezig met discussieren?

Hartelijk bedankt voor deze zeer nuttige bijdrage aan de discussie.

[Boelie-Boelie]

Soultaker schreef op donderdag 06 augustus 2009 @ 17:00:
De echte vraag was of tools voor blinden überhaupt op HTML niveau werken

In ieder geval maken screenreadergebruikers gretig gebruik van headings, volgens de WebAIM screenreader survey (onderzoek van begin dit jaar), dus zinnig headinggebruik is in ieder geval erg nuttig. (Er stond in het onderzoek niks over tabellen.)

[Clay]

Voor wat het op pagina 17 nog waard is over opmerkingen op pagina 2 ... maar ik werk dus bij Lost Boys, en front-end is daar een afdeling vol vaardige en vooral ook eigenwijze mensen; eigenlijk net als hier De eerst volgende collega die ik een tabel zie gebruiken waar dat niet nodig is gaat dan ook ritueel 10 hoog het raam uit en ik verwacht dat ze mij hetzelfde aandoen.

Wat veel belangrijker is, is dat wij als front-end developers een keer opstaan en samen met de grotere cms etc bouwers iets doen aan de koppeling tussen de schier poetische semantiek die we in onze ivoren torens produceren, en de soms rauwe werkelijkheid van de output na implementatie. Ik heb toch immers ook geen 3 doctypes in ns.nl getemplate

[IntToStr]

Voor de diverse 'uitdagingen' in dit topic over hoe je iets zonder tabellen maar in css wilt doen is dit misschien een interessant artikel: http://www.smashingmagazi...-styling-design-elements/.

Heb niet gecontroleerd of de oplossingen allemaal 100% cross-browser compatible zijn, maar het lijkt een leuke samenvatting van nuttige use cases.

[Anoniem: 26306]

Op zich grappig, maar ik denk dat de meeste "problemen" voortvloeien uit een basiskennis waar het een en ander aan mankeert. Of te weinig inzicht. Je moet nu eenmaal even op een bepaalde manier naar dingen kijken. Een jaar of 8 geleden was dat nog raar, tegenwoordig zou het "normaal" moeten zijn. Probleem is dat er nog zoveel gebrekkige "tutorials" op het internet te vinden zijn.

Om een of andere reden slaan mensen de basis (HTML) over en moet het meteen een bepaalde smoel krijgen. Het moet er zus of zo uitzien, dus mensen gaan vanuit de visuele kant beginnen met "designen".

[Castor385]

Anoniem: 3431 schreef op vrijdag 07 augustus 2009 @ 12:35:
En daarbij: de richtlijn is er, de overheid mag m afdwingen, maar doet elk overheidsorgaan dat ook? Als ik heel snel door utrecht.nl kijk staan niet alle menu's in een unordered list en wordt er ook nog wel eens een tabel gebruikt om het e.e.a. op de juiste plek te krijgen. Kan zijn dat de site van voor 30 juni 2006 is natuurlijk, maar toch. Ze beboeten (of controleren) volgens mij ook zichzelf niet

In ieder geval voldoen de websites van de diverse ministeries wel aan de webrichtlijnen. Het opleggen van de webrichtlijnen gebeurt van bovenaf. De functioneelbeheerders van die website geven dan bij de leverancier de opdracht op de website aan te passen, zodat deze minimaal het waarmerk drempelvrij kan krijgen.

Afgezien daarvan is de discussie tabellen vs semantisch design. Ik zelf ben van mening dat je dat moet bepalen aan de hand van de opdracht waarvoor je werkt. Als je voor een of andere hobby bob een site in elkaar moet klussen: be my guest, kies de kortste weg naar rome. Ga je echter een site bouwen met potentieel heel veel bezoekers: sluit dan niemand uit! Zorg ervoor dat iedereen je site kan lezen zoals de bedoeling is -> semantiek wordt belangrijk.

Mijn insteek is tegenwoordig dat de inhoud belangrijker is dan de layout. Daarom zorg ik ervoor dat de inhoud ook op een juiste manier in html tags wordt geplaatst. Ik gebruik de tags waarvoor ze bedoeld zijn. Daarna ga ik pas layouten.

[JKVA]

Castor385 schreef op vrijdag 21 augustus 2009 @ 14:46:
[...]
Afgezien daarvan is de discussie tabellen vs semantisch design. Ik zelf ben van mening dat je dat moet bepalen aan de hand van de opdracht waarvoor je werkt. Als je voor een of andere hobby bob een site in elkaar moet klussen: be my guest, kies de kortste weg naar rome. Ga je echter een site bouwen met potentieel heel veel bezoekers: sluit dan niemand uit! Zorg ervoor dat iedereen je site kan lezen zoals de bedoeling is -> semantiek wordt belangrijk.
[...]

Los daarvan is het altijd nog een kwestie van kosten/baten. Voor mijn huidige project (secure bankieren website) is de eis 16/16 (Accessibility.nl) gesteld. Het lastige is echter dat het om een vrij rijke interface gaat (portal layout met ajax, effecten, d&d, modal windows, etc...).

Door met dergelijke extra eisen te komen (support voor geen JS, support voor geen CSS, etc...), wordt alles veel complexer, duurder en gaat de opleverdatum naar achteren. Ik vind het prima, maar ik geef tegelijk wel de consequenties door aan de business, zodat zij mogen kiezen. In mijn geval bleek het geen keuze (het moest gebeuren, no matter the costs).

Uiteindelijk is het wikken en wegen. Kom je tegemoet aan een minderheid (<1% in mijn geval)? Dan kun je een "groen mannetje" krijgen en kweek je goodwill waarmee je jezelf kunt promoten als sympathiek bedrijf dat niet alleen aan winst denkt.
Of kom je voor een deel tegemoet aan de minderheid en maak je een schaduwsite van je (rijke) "echte" site? Wat betekent dat je het "groene mannetje" niet krijgt en dus niet het imago-voordeel hebt.
Of ga je voor een 14/16 score en krijg je het "oranje mannetje", waarmee je niet bijzonder goed, maar ook niet helemaal slecht oogt?

In mijn projecten ligt deze keuze helemaal bij de business. Ik denk met ze mee en probeer ze zo goed mogelijk te adviseren, want zij zijn geen techneuten, maar het eindoordeel ligt niet bij mij.

Bottom line: Semantisch design en alle andere web-gerelateerde technieken zijn een middel en geen doel. Door technische of maatschappelijke ontwikkelingen kunnen kosten-/batenanalyses anders uitvallen, maar je moet semantisch design niet als doel zien, hooguit een heel nuttig middel. Wat je hooguit kunt doen, is zorgen dat je best practices goed onder de knie hebt, zodat de balans eerder naar jouw ideale oplossing uitslaat.

[acemoo]

Good Fella schreef op maandag 03 augustus 2009 @ 17:23:
Achter de mensen aan lopen? Het is een betere en makkelijker aan te passen techniek, mensen neigen nog wel eens technieken te gebruiken die goed en makkelijk zijn. Als morgen een revolutionaire manier van typen wordt onthuld die echt makkelijker en sneller is dan wat ik nu doe dan ga ik daar in mee. Lijkt me vrij logisch. Zeker als bedrijf zou je innovatief moeten zijn en niet achter de feiten aanlopen. Tabellen voor het maken van een layout is namelijk achterhaald, en ja dat is een feit.

Dvorak gebruiker neem ik aan?

Als Cybie met tabellen mooie sites kan maken wat goede zoek resultaten hebben in zoek machines, welke makkelijk aan te passen zijn na 2-3 jaar, dan waarom niet?

[curry684]

Omdat je in een aardbevingsgebied ook geen huizen van piepschuim bouwt. Dat het morgen toevallig even goed resultaat oplevert staat los van wat je klant aan lange termijn aan kwaliteit levert.

[Saven]

Anoniem: 312741 schreef op maandag 03 augustus 2009 @ 17:25:
[...]

ONKUNDE, nu wordt-ie mooi

Ben erg benieuwd hoeveel van dit soort uitlatingen nog gaan komen Iedereen weet het namelijk zo veel beter dan ik!

Modbreak:

een maand later reageren met alleen maar trolls en flames... Wat denk je zelf?

[ Voor 56% gewijzigd door BtM909 op 28-08-2009 00:31 ]

[armageddon_2k1]

IntToStr schreef op maandag 10 augustus 2009 @ 10:32:
Voor de diverse 'uitdagingen' in dit topic over hoe je iets zonder tabellen maar in css wilt doen is dit misschien een interessant artikel: http://www.smashingmagazi...-styling-design-elements/.

Heb niet gecontroleerd of de oplossingen allemaal 100% cross-browser compatible zijn, maar het lijkt een leuke samenvatting van nuttige use cases.

Deze site heeft ook wel twijfelachtige links hoor. Voorbeeldje:
http://www.456bereastreet.com/lab/equal_height/

En dan de beschrijving is:

Here’s a basic example of creating equal-height boxes (faux columns) using CSS. It works similarly to cells in a table, but without the messy table bits.

Het zijn al geen faux columns en de messy table bits worden inderdaad voorkomen, maar nu maakt met 3 divs welke als display-style 'table','table-row' en 'table-cell' hebben. Hoe is dit in godsnaam anders dan <table><tr><td> gebruiken? Ja, leuk, het zijn divs, maar onder water maakt het geen barst uit. Dit is een typisch geval van 'Ik wil geen tables gebruiken en ga dus elke mogelijke manier proberen om te bereiken wat ik wil om dan maar een nog onduidelijker resultaat te krijgen'. Het leuke van deze oplossing is is dat ie niet werkt in IE7 en lager, terwijl tables dat wel doen.

[Anoniem: 26306]

Het voorbeeld is inderdaad niet zo heel best, maar wél beter dan tables. Bekijk de pagina eens zonder CSS.

Kortom: jij begrijpt het ook nog niet.

[curry684]

armageddon_2k1 schreef op maandag 07 september 2009 @ 08:18:
nu maakt met 3 divs welke als display-style 'table','table-row' en 'table-cell' hebben. Hoe is dit in godsnaam anders dan <table><tr><td> gebruiken? Ja, leuk, het zijn divs, maar onder water maakt het geen barst uit. Dit is een typisch geval van 'Ik wil geen tables gebruiken en ga dus elke mogelijke manier proberen om te bereiken wat ik wil om dan maar een nog onduidelijker resultaat te krijgen'.

En jij bent nu je dit zegt een typisch voorbeeld van iemand die het denkt te snappen maar er nog niet helemaal is Het is namelijk een wereld van verschil omdat er nu een semantisch correcte markup is, wat het hele idee is achter de scheiding van (X)HTML voor inhoud en CSS voor opmaak. De display properties zijn juist bedoeld om opmaak te beinvloeden, en dit is juist een perfect voorbeeld van hoe je iets dat semantisch geen table is wel als een table wilt laten renderen.

Denk er nog maar eens goed over na

edit:
* curry684 mept Cheatah

[armageddon_2k1]

Kortom: jij begrijpt het ook nog niet.

Nou nou, je hoeft niet zo uit de hoogte te doen hoor. curry684legt het nog netjes uit.
Ik ben gelukkig geen web-developer

@curry684: Ah, zo had ik het nog niet bekeken. Vanuit die optiek is het wel heel logisch. Thanks

Maar dan is mijn volgende vraag: Als je content hebt welke echt tabulair is, zeg een Prijslijst o.i.d., dan ga je die uiteraard wel in een table gooien, want anders schiet je je doel ook weer erg voorbij.

[ Voor 4% gewijzigd door armageddon_2k1 op 07-09-2009 09:11 ]

[Erkens]

armageddon_2k1 schreef op maandag 07 september 2009 @ 09:09:
Maar dan is mijn volgende vraag: Als je content hebt welke echt tabulair is, zeg een Prijslijst o.i.d., dan ga je die uiteraard wel in een table gooien, want anders schiet je je doel ook weer erg voorbij.

Dat moet je ook gewoon in een tabel laten staan, anders ben je ook de relatie kwijt tussen de diverse cellen.

[curry684]

armageddon_2k1 schreef op maandag 07 september 2009 @ 09:09:
[...]

Maar dan is mijn volgende vraag: Als je content hebt welke echt tabulair is, zeg een Prijslijst o.i.d., dan ga je die uiteraard wel in een table gooien, want anders schiet je je doel ook weer erg voorbij.

Tables zijn voor tabulaire data, dus idd zot als je die niet zou gebruiken, check ook de source van de Pricewatch hier

De tablehetze schiet vaak door, maar de kern is enkel dat je geen tables moet gebruiken voor dingen die semantisch geen tabulaire data zijn, oftewel zowel horizontale als verticale betekenisvolle relaties tussen cellen onderhouden. Aanwezigheidsroosters, topiclistings, prijslijsten etc vallen daar allemaal onder. En dat staat dus als gezegd los van dingen die geen tabulaire data zijn maar je wel als zodanig wil tonen, daar heb je dus CSS voor, net zoals je niet je hele webpage in <strong>-tags moet verstoppen als je alles bold wilt hebben maar een font-weight tag op je body moet rammen.

[Tjolk]

De discussie lijkt me behoorlijk eindeloos. Ik zou het allemaal niet te moeilijk zoeken. Gebruik gewoon datgene wat je het beste uitkomt voor de situatie. Zo heb ik voor Added Notes de basisstructuur van de site geregeld met "divs" maar gebruik ik voor het genereren van de notitielijst een tabel. Het is niet sec tabulaire data, maar het is wel een goed werkende en prettige oplossing. Is het dan "fout" om een tabel te gebruiken, of is het "niet ideaal"?

Punt is ook de ontwikkeling van bepaalde sites in de tijd. Om weer als voorbeeld Added Notes te gebruiken: dat is ontwikkeld uit een puur persoonlijke site die enkel en alleen voor mij beschikbaar was. Dan heb je niet te maken met semantiek whatsoever, het moet gewoon werken en overzicht geven, dat zijn de enige eisen. Dat uit dat persoonlijke kladblokje een generiek beschikbare site is geëvolueerd, heeft ook effect op hoe die is opgebouwd. Nu zou je natuurlijk kunnen kiezen om dat geheel opnieuw te schrijven, maar dat gebeurt vaak pas bij een complete rewrite van een site. En ook dan geldt: kies datgene wat het beste uitkomt voor de situatie.

[DNA_Saint]

Ook maar even in de "discussie" mengen.
Ik maak nu al een paar jaar sites "met" divs. Ik begon met een online editor, zoals volgens mij iedereen begon (geocities, expage oid). Daarna ben ik het iets beter gaan aanpakken en kwam op de generate html functie in photoshop. Uiteindelijk ben ik daardoor weer bij tables beland.
Ik heb een reeks van sites met tables gemaakt, alles werkte goed. Maar ik had toch een hekel als er iets veranderd moest worden of wanneer een pagina iets anders uitzag dan een andere pagina.
Uiteindelijk ben ik via csszengarden beland op css en divs.
Als je het vergelijkt, dan heb je met tables echt veel minder vrijheid.
Altijd nadenken hoe je de cellen gaat indelen. Dan weer een rowspan, dan weer rijen bij elkaar, dan weer dit en dan weer dat.

Eigenlijk is vind ik het meest erge aan zulke dingen, dat een klant dit niet weet. Ik werk als freelancer en heb echt al zoveel mensen gehoord, dat ik te duur ben.
Dat hij bedrijven kent die een site voor een paar honderd euro maken. Ik word dan ook altijd erg boos, als ik op een brakke site kom, waar ze "webdesign" aanbieden voor een schijntje.
Websites maken is volgens mij echt een uitstervend beroep. Iedereen kent tegenwoordig wel een buurjongen of zelfs buurvrouw die wel eventjes een site maakt.

Mijn zusje is net begonnen aan het vak informatica op de middelbare school. Ik ben dus echt benieuwd wat ze gaat leren. Haar eerste opdracht is om een site te maken en tijdens de eerste les, kregen ze de opdracht om frontpage op te starten en op internet te zoeken, hoe je een site maakt.
Ik ben benieuwd. Ik post hier wel mijn bevindingen

[Pkunk]

DNA_Saint schreef op maandag 07 september 2009 @ 21:21:
Websites maken is volgens mij echt een uitstervend beroep. Iedereen kent tegenwoordig wel een buurjongen of zelfs buurvrouw die wel eventjes een site maakt.

Denk je dat serieuze bedrijven ooit hun website door de buurjongen of buurvrouw laten maken? Misschien wat MKB bedrijven die alleen een website als visitekaartje ( = statische content) gebruiken, maar huisvrouwen en buurjongens zullen heus geen databases kunnen optimaliseren of een lekker custom CMS kunnen inbouwen. Gekkie

[curry684]

DNA_Saint schreef op maandag 07 september 2009 @ 21:21:
Websites maken is volgens mij echt een uitstervend beroep. Iedereen kent tegenwoordig wel een buurjongen of zelfs buurvrouw die wel eventjes een site maakt.

Nee de zolderkamerbedrijfjes sterven uit. Er is relatief weinig vraag meer naar de 'tussenklasse' van mensen die wel iets weten maar ook niet de structurele support en kwaliteit van een meermansbedrijf kunnen leveren, maar tegelijkertijd is de vraag naar profi bureaus absoluut niet afgenomen afgelopen jaren. Maar klanten kiezen inderdaad bewuster voor broddelwerk (het neefje voor 2 bakken bier) of een serieuze oplossing (de profi toko die 4 of 5 cijfers reken), en minder dus voor de tussenklasse van een paar honderdjes. En met het toegenomen belang van internet is er dus wel degelijk meer vraag naar structurele kwaliteit, ook bij kleine bedrijven.

[Kiphaas7]

curry684 schreef op maandag 07 september 2009 @ 23:54:
[...]

Nee de zolderkamerbedrijfjes sterven uit. Er is relatief weinig vraag meer naar de 'tussenklasse' van mensen die wel iets weten maar ook niet de structurele support en kwaliteit van een meermansbedrijf kunnen leveren, maar tegelijkertijd is de vraag naar profi bureaus absoluut niet afgenomen afgelopen jaren. Maar klanten kiezen inderdaad bewuster voor broddelwerk (het neefje voor 2 bakken bier) of een serieuze oplossing (de profi toko die 4 of 5 cijfers reken), en minder dus voor de tussenklasse van een paar honderdjes. En met het toegenomen belang van internet is er dus wel degelijk meer vraag naar structurele kwaliteit, ook bij kleine bedrijven.

Met dat gezegd.... Ik vraag me af of veel van die zolderkamerbedrijfjes tegenwoordig pretenderen profi toko te zijn. Immers, het is relatief makkelijk om een leuk design te regelen, dit netjes te laten uitzien met behulp van hippe html en css, maar dan toch nog de meest ranzige php produceren. En daar prik je niet zomaar doorheen als MKB bedrijfje.

[Rekcor]

curry684 schreef op maandag 07 september 2009 @ 23:54:
[...]

Nee de zolderkamerbedrijfjes sterven uit. Er is relatief weinig vraag meer naar de 'tussenklasse' van mensen die wel iets weten maar ook niet de structurele support en kwaliteit van een meermansbedrijf kunnen leveren, maar tegelijkertijd is de vraag naar profi bureaus absoluut niet afgenomen afgelopen jaren. Maar klanten kiezen inderdaad bewuster voor broddelwerk (het neefje voor 2 bakken bier) of een serieuze oplossing (de profi toko die 4 of 5 cijfers reken), en minder dus voor de tussenklasse van een paar honderdjes. En met het toegenomen belang van internet is er dus wel degelijk meer vraag naar structurele kwaliteit, ook bij kleine bedrijven.

Je doet interessante uitlatingen, maar waar zijn ze op gebaseerd? Heb je bronnen?

* Rekcor schrikt op zijn zolderkamert

[Sebazzz]

Zo, tweede dag, nieuwe dag. Multimedia en internet. We moeten met XHTML (waarom?) een website maken, maar dan wel XHTML transitional (niet strict, want dat is te moeilijk volgens de docent en je krijgt teveel fouten bij de validator). We worden aangeraden om frames of tabellen in combinatie met CSS te werken. Het doel is dat we passed bij de W3C validator krijgen. Onze bron is handleidinghtml.nl en w3schools(maar w3schools is wél goed). Note dat de website van de docent zelf niet eens valideert. Gelukkig mag ik mijn website laten zien, en mag ik dan de komende vijf lessen overslaan of ik moet een multiple choice toets over XHTML en CSS maken.

Ik ga straks met hem even een flinke discussie starten

[ Voor 3% gewijzigd door Sebazzz op 08-09-2009 09:25 ]

[Tjolk]

Bah, praat me er niet van. In het eerste jaar HTS was er ook een vak waarbij het maken van een website onderdeel was. Daar werden frames en frontpage ook gepromoot als "the best in town". Anno 2001....

Ging ik in discussie met de docent: "Euj, da's nie!" Heb vervolgens een half uur college gegeven aan de docent.

[XWB]

[b][message=32541049,noline]Ik ga straks met hem even een flinke discussie starten

Heb ik in het verleden ook gedaan, dat win je nooit en als de leerkracht een lul is kost het je alleen maar punten. Nouja, hij was dan ook > 50 jaar, en mensen van die leeftijd blijven gewoon steenvast bij hun standpunt

[ Voor 19% gewijzigd door XWB op 08-09-2009 09:37 ]

[DNA_Saint]

Sebazzz schreef op dinsdag 08 september 2009 @ 09:22:
Zo, tweede dag, nieuwe dag. Multimedia en internet. We moeten met XHTML (waarom?) een website maken, maar dan wel XHTML transitional (niet strict, want dat is te moeilijk volgens de docent en je krijgt teveel fouten bij de validator). We worden aangeraden om frames of tabellen in combinatie met CSS te werken. Het doel is dat we passed bij de W3C validator krijgen. Onze bron is handleidinghtml.nl en w3schools(maar w3schools is wél goed). Note dat de website van de docent zelf niet eens valideert. Gelukkig mag ik mijn website laten zien, en mag ik dan de komende vijf lessen overslaan of ik moet een multiple choice toets over XHTML en CSS maken.

Ik ga straks met hem even een flinke discussie starten

LOL, ik ken die docent. Geen les van hem gehad. Het is echt een informatica docent. Weet veel over electronica etc, maar over websites echt niks. Dan moet je echt naar de GMT/CMD afdeling gaan.

[moozzuzz]

offtopic:
psst Sebazzz: je moet es je site scrollen in IE6 voor je die aan je leraar toont.

[Sebazzz]

Ik denk dat die docent wel aardig is, het mag geen problemen opleveren.

moozzuzz schreef op dinsdag 08 september 2009 @ 09:43:

offtopic:
psst Sebazzz: je moet es je site scrollen in IE6 voor je die aan je leraar toont.

Wij zijn niet verplicht om het in IE6 werkend te krijgen omdat we op school al IE7 gebruiken. Alleen IE7 support is nodig. Overigens is het een bug in IE6, ga maar eens scrollen als de website niet volledig geladen is: Werkt prima. Daarna niet meer.

edit: Yes, ik heb het voor elkaar gekregen dat ik gewoon HTML4.01 Strict mag gebruiken en me eigen website mag gebruiken. De Hogeschool Rotterdam heeft op zijn servers alleen JSP support, en geen PHP maar mijn eigen website wel natuurlijk.

[ Voor 36% gewijzigd door Sebazzz op 08-09-2009 10:31 ]

[DNA_Saint]

Sebazzz schreef op dinsdag 08 september 2009 @ 09:47:

edit: Yes, ik heb het voor elkaar gekregen dat ik gewoon HTML4.01 Strict mag gebruiken en me eigen website mag gebruiken. De Hogeschool Rotterdam heeft op zijn servers alleen JSP support, en geen PHP maar mijn eigen website wel natuurlijk.

huh, ik kon altijd wel php gebruiken op de servers en als je vraagt krijg je zelfs een db erbij.

[Sebazztiaan]

en dan heb je een klant (overheid en semi-overheid) die EIST dat je volgens 'drempelvrij' (guide van overheid) een website ontwikkeld, heb hem zo niet bij de hand, maar een paar van de punten heeft de volgende strekking

* zorg voor een SEMANTISCHE weblay-out,
* gebruik <p>, <hx> en <div> tags waar nodig
* gebruik geen tabellen voor je hoofdlay-out

+200 andere punten

[armageddon_2k1]

200 punten zijn wat fors, maar wat is er mis met de andere eisen?

[pedorus]

Ik zou zeggen dat het met tabellen juist makkelijker wordt. Kijk maar, het moet zonder style-sheets kunnen werken

quote: http://www.drempelvrij.nl/richtlijnen#ijkpunt6_1

WCAG-ijkpunt 6.1: Organiseer documenten zo dat ze zonder style sheets gelezen kunnen worden

[Sebazztiaan]

armageddon_2k1 schreef op maandag 14 september 2009 @ 20:45:
200 punten zijn wat fors, maar wat is er mis met de andere eisen?

pleit voor correct div gebruik

[Gomez12]

Sebazzz schreef op dinsdag 08 september 2009 @ 09:22:
Zo, tweede dag, nieuwe dag. Multimedia en internet. We moeten met XHTML (waarom?) een website maken, maar dan wel XHTML transitional (niet strict, want dat is te moeilijk volgens de docent en je krijgt teveel fouten bij de validator). We worden aangeraden om frames of tabellen in combinatie met CSS te werken. Het doel is dat we passed bij de W3C validator krijgen. Onze bron is handleidinghtml.nl en w3schools(maar w3schools is wél goed). Note dat de website van de docent zelf niet eens valideert. Gelukkig mag ik mijn website laten zien, en mag ik dan de komende vijf lessen overslaan of ik moet een multiple choice toets over XHTML en CSS maken.

Ik ga straks met hem even een flinke discussie starten

Ach, gewoon een hello world site maken, compleet goede xhtml en serveren als : application/xhtml+xml
Dan per email vragen waarom je site niet goed getoond word in ie7,linkje in de email erbij naar : http://blogs.msdn.com/ie/archive/2005/09/15/467901.aspx en rustig achterover zitten...

Ik word echt zo moe van de mensen die xhtml willen gebruiken in een omgeving waar ook IE draait...

[MoietyMe]

pedorus schreef op maandag 14 september 2009 @ 20:55:
Ik zou zeggen dat het met tabellen juist makkelijker wordt. Kijk maar, het moet zonder style-sheets kunnen werken

[...]

Dat kan prima met semantische html hoor.

[Bosmonster]

pedorus schreef op maandag 14 september 2009 @ 20:55:
Ik zou zeggen dat het met tabellen juist makkelijker wordt. Kijk maar, het moet zonder style-sheets kunnen werken

[...]

Dat het gelezen moeten kunnen worden. Dat betekent dus juist dat zonder CSS duidelijk is wat alles is, m.a.w. dat je de juiste semantiek hanteert.

De richtlijn die jij aangeeft is juist een van de belangrijkste richtlijnen _tegen_ het gebruik van tabellen voor opmaak.

[jbdeiman]

Die stichting drempelvrij stelt overigens niet zo heel veel voor hoor, en die eisen die ze stellen zijn vaak ook maar half uitgewerkt. Daarnaast (kijk maar eens bij de aangesloten websites) zitten er nog best websites tussen die blijkbaar bij de 1e ontwikkeling voldeden, maar later niet.

Ik weet zo niet welke website (ik heb wel eens een onderzoekje gedaan naar internetgebruik op dit vlak) het was, maar er staat er 1 tussen waarbij je (iig met Firefox) moet zoeken naar een optie in een vrij klein menu waardoor je op een pagina komt om aan te geven dat je lettertype groter moet worden.
Lekker "drempelvrij" is dat dan, als je moet zoeken naar zo'n functie. Daar komt nog eens bij dat in FF (toen ik keek in elk geval) die instelling niet eens wordt bewaard. Ook zo lekker, ga je weer naar een andere pagina is het weg.
Maar "de optie zit er in, dus de site voldoet"..

Een ander voorbeeld is ZoZijn.nl (http://www.zozijn.nl) Daar heb je in het menu de instellingen staan, op die instellingspagina kan je aangeven dat je een groter (16 pt, nog niet erg groot, maargoed) lettertype wilt. De menu's blijven (tenzij je voor een alternatief menu kiest) klein van lettertype. En je moet dus zoeken naar de instellingen.

curry684 schreef op maandag 07 september 2009 @ 23:54:
[...]

Nee de zolderkamerbedrijfjes sterven uit. Er is relatief weinig vraag meer naar de 'tussenklasse' van mensen die wel iets weten maar ook niet de structurele support en kwaliteit van een meermansbedrijf kunnen leveren, maar tegelijkertijd is de vraag naar profi bureaus absoluut niet afgenomen afgelopen jaren. Maar klanten kiezen inderdaad bewuster voor broddelwerk (het neefje voor 2 bakken bier) of een serieuze oplossing (de profi toko die 4 of 5 cijfers reken), en minder dus voor de tussenklasse van een paar honderdjes. En met het toegenomen belang van internet is er dus wel degelijk meer vraag naar structurele kwaliteit, ook bij kleine bedrijven.

Ik denk (merk) als ZZP'er dat dat wel meevalt hoor. Misschien val ik voor sommigen wel onder de "profi" bureaus, maar dat ben ik toch zeker niet.
Wel merken klanten dat ik prima weet waar ik mee bezig ben, en ze kunnen het ook erg waarderen dat je ook de tijd hebt/ neemt voor ze en dat je niet overal gygantische bedragen voor rekent. Daarnaast is het ook wel zo dat ervaring zeker in dit werkgebied ook wel wat doet.

Het komt overigens wel door mond tot mond reclame dat klanten bij me komen, maar dat is ook de beste en goedkoopste manier van reclame maken.

[edit]
Een website opgebouwd met de semantische regels in ogenschouw is vaak ook gebruiksvriendelijker wanneer deze zonder opmaak wordt bekeken. Mits goed opgebouwd krijg je een header (staat vaak een logo van het bedrijf in die klikbaar is), dan het menu en dan de inhoud.
Een logische volgorde, waar niets mis mee is. In tabellen wanneer je bijvoorbeeld het menu rechts hebt geplaatst klopt die volgorde al niet meer. Dit is erg jammer, omdat je nu pas onderaan het menu krijgt zonder opmaak. Met Div/ CSS kan je het menu ook rechts plaatsen wanneer opmaak wel wordt weergegeven, terwijl die zonder opmaak gewoon voor je content staat.
Daarom zijn die semantische regeltjes zo belangrijk, we willen immers dat iedereen een website kan gebruiken.

[ Voor 12% gewijzigd door jbdeiman op 15-09-2009 10:46 ]

[Bosmonster]

jbdeiman schreef op dinsdag 15 september 2009 @ 10:40:
Die stichting drempelvrij stelt overigens niet zo heel veel voor hoor, en die eisen die ze stellen zijn vaak ook maar half uitgewerkt. Daarnaast (kijk maar eens bij de aangesloten websites) zitten er nog best websites tussen die blijkbaar bij de 1e ontwikkeling voldeden, maar later niet.

De stichting draaft iets te ver door soms in de richtlijnen. Op zich niet zo'n ramp, aangezien je normaliter niet verplicht bent om deze door te voeren. Het zijn slechts richtlijnen.

Probleem ligt vooral bij sommige klanten (lees: overheid), waarbij die richtlijnen volledig opgevolgd dienen te worden. Dan kun je hoog of laag springen, je zult je volledig aan die richtlijnen moeten houden.

[Sebazztiaan]

Als ik het goed begrepen heb van een semi-overheid klant zijn ze *verplicht* zich aan deze richtijnen te houden, soort van 'bindend advies'

[jbdeiman]

@Bosmonster en Sebazztiaan
Het is inderdaad voor (nieuwe) websites van overheden een soort van bindend advies. Natuurlijk vind ik ook dat voor overheidsorganisaties het heel belangrijk is om ervoor zorg te dragen dat verschillende doelgroepen ook allemaal gebruik kunnen maken van de website en dan wel op een prettige manier.
Ik vind dan alleen wel dat ze de websites ook echt moeten controleren, het wegstoppen van een "larger text-size" optie vind ik dan wel een beetje vreemd.
Daarbij hebben browsers zelf de mogelijkheid om in te zoomen en doen dit (mijns inziens) beter dan die "zoomknopjes" op de websites zelf.

spoiler:

Haha, drempelvrij slaat natuurlijk erop dat de drempel zo laag is om er in mee te kunnen doen.

[Bosmonster]

jbdeiman schreef op dinsdag 15 september 2009 @ 12:36:


Ik vind dan alleen wel dat ze de websites ook echt moeten controleren, het wegstoppen van een "larger text-size" optie vind ik dan wel een beetje vreemd.
Daarbij hebben browsers zelf de mogelijkheid om in te zoomen en doen dit (mijns inziens) beter dan die "zoomknopjes" op de websites zelf.

Die opties zijn imho sowieso tegen de richtlijnen, want het is een feature die alleen werkt met javascript.

[InZane]

jbdeiman schreef op dinsdag 15 september 2009 @ 10:40:
Ik weet zo niet welke website (ik heb wel eens een onderzoekje gedaan naar internetgebruik op dit vlak) het was, maar er staat er 1 tussen waarbij je (iig met Firefox) moet zoeken naar een optie in een vrij klein menu waardoor je op een pagina komt om aan te geven dat je lettertype groter moet worden.
Lekker "drempelvrij" is dat dan, als je moet zoeken naar zo'n functie. Daar komt nog eens bij dat in FF (toen ik keek in elk geval) die instelling niet eens wordt bewaard. Ook zo lekker, ga je weer naar een andere pagina is het weg.
Maar "de optie zit er in, dus de site voldoet"..

As far as I know hoef je die optie helemaal niet op je website op te nemen.
Wel wordt aangeraden om relatieve font-sizes te gebruiken, dus geen font-sizes in pixels bijvoorbeeld.

[jbdeiman]

Oké, maar "you get what I mean", ze zouden dit op dat soort websites toch beter anders kunnen aanpakken. Maargoed, de discussie gaat nu wel een beetje offtopic. Het belangrijkste was:

jbdeiman schreef op dinsdag 15 september 2009 @ 10:40:

Een website opgebouwd met de semantische regels in ogenschouw is vaak ook gebruiksvriendelijker wanneer deze zonder opmaak wordt bekeken. Mits goed opgebouwd krijg je een header (staat vaak een logo van het bedrijf in die klikbaar is), dan het menu en dan de inhoud.
Een logische volgorde, waar niets mis mee is. In tabellen wanneer je bijvoorbeeld het menu rechts hebt geplaatst klopt die volgorde al niet meer. Dit is erg jammer, omdat je nu pas onderaan het menu krijgt zonder opmaak. Met Div/ CSS kan je het menu ook rechts plaatsen wanneer opmaak wel wordt weergegeven, terwijl die zonder opmaak gewoon voor je content staat.
Daarom zijn die semantische regeltjes zo belangrijk, we willen immers dat iedereen een website kan gebruiken.

[pedorus]

Bosmonster schreef op dinsdag 15 september 2009 @ 09:52:
[...]


Dat het gelezen moeten kunnen worden. Dat betekent dus juist dat zonder CSS duidelijk is wat alles is, m.a.w. dat je de juiste semantiek hanteert.

De richtlijn die jij aangeeft is juist een van de belangrijkste richtlijnen _tegen_ het gebruik van tabellen voor opmaak.

Let ook op de -smiley

Maar ik denk dat je 6.1 nog wel kan halen met tabellen. 3.3 (Use style sheets to control layout and presentation.) is zeker niet haalbaar, maar die heeft de shortlist van 16 punten niet gehaald, omdat bijna iedereen dat toch altijd al doet.. Maar goed, het is dan ook prima mogelijk om een 'drempelvrije' website te maken die toch beroerd toegankelijk is. Zie dit filmpje over de UWV-website.

[Asphyxion]

Bosmonster schreef op dinsdag 15 september 2009 @ 13:12:
Die opties zijn imho sowieso tegen de richtlijnen, want het is een feature die alleen werkt met javascript.

De opties zijn niet tegen de richtlijnen, maar je moet de optie ook zonder Javascript kunnen aanbieden (zoals bv op www.interpolis.nl is gedaan).

Je kunt ook de optie weg laten indien javascript is uitgeschakeld.

Zoals beschreven in: http://www.webrichtlijnen...t-dom/optionele-karakter/

Een voorbeeld is een menu op de pagina om de bezoeker de lettergrootte te laten regelen. Het is mogelijk om dit op te vangen met een server-side script. De webontwikkelaar kan er echter ook van uitgaan dat browsers zelf een functie bevatten om de lettergrootte op pagina’s te schalen naar de voorkeur van de gebruiker. Bezoekers die client-side scripts missen, zijn dan op deze standaardfunctie aangewezen.

[Bosmonster]

interpolis.nl breekt alleen wel zo'n beetje iedere andere visuele handicap-richtlijn... Witte tekst op lichtblauwe achtergrond

edit:
Ow je hebt een heel klein verstopt knopje waarmee je zwart/wit kunt kiezen! Jammer dat mensen dat natuurlijk nooit gaan vinden

Met dit soort dingen heb ik altijd het idee dat iedereen zo'n feature maar overneemt van een anders site, maar er wordt nooit _echt_ over nagedacht of het wel zin heeft. Of dat er gemeten wordt hoe vaak de optie nu werkelijk gebruikt wordt.

[ Voor 59% gewijzigd door Bosmonster op 15-09-2009 14:06 ]

[geert1]

Misschien slim om dit topic te renamen naar "Semantiek op het web" of iets dergelijks, en het hele "vs. tabellen" idee achter ons te laten. Tabellen zijn voor tabulaire content (overzichten van gegevens waar rijen en kolommen verband met elkaar hebben). Daarmee is de kous af wat betreft tabellen. Geen speld tussen te krijgen, behalve met non-argumenten uit 1998.

Wat er verder in dit topic wordt besproken is vele malen interessanter: semantiek, toegankelijkheid, de kwaliteit / dekking van de huidige richtlijnen, enzovoort.

[Cartman!]

Helaas denkt nog steeds niet iedereen er zo over geert1...

[Matis]

Cartman! schreef op dinsdag 15 september 2009 @ 14:06:
Helaas denkt nog steeds niet iedereen er zo over geert1...

Klopt, opmaak dien je te maken met divjes/cvs en niet in een tabel-gedreven opmaak.

Echter vind ik dat je binnen een divje (bijvoorbeeld content) wel in een tabel mag plempen, dit omdat het velen malen eenvoudiger is die content uit te kunnen lijnen.

tables voor site design --> No Go

[Erkens]

Matis schreef op dinsdag 15 september 2009 @ 14:09:
[...]

Klopt, opmaak dien je te maken met divjes/cvs en niet in een tabel-gedreven opmaak.

Echter vind ik dat je binnen een divje (bijvoorbeeld content) wel in een tabel mag plempen, dit omdat het velen malen eenvoudiger is die content uit te kunnen lijnen.

tables voor site design --> No Go

Ik wil niet weer die hele discussie die in dit topic is geweest aanwakkeren, maar juist met deze reactie laat je precies zien waarom veel mensen niet snappen waarom semantiek belangrijk is en waarom het nog niet door velen goed wordt toegepast. Dus eigenlijk geef je Cartman! dubbel gelijk, want met jouw reactie laat je precies zien waarom hij gelijk hebt ook al denk je dat jij het "goed" doet (let wel, dit staat tussen aanhalingstekens, want "goed" is natuurlijk een rekbaar begrip)

[Bosmonster]

Matis schreef op dinsdag 15 september 2009 @ 14:09:
[...]

Klopt, opmaak dien je te maken met divjes/cvs en niet in een tabel-gedreven opmaak.

Echter vind ik dat je binnen een divje (bijvoorbeeld content) wel in een tabel mag plempen, dit omdat het velen malen eenvoudiger is die content uit te kunnen lijnen.

tables voor site design --> No Go

Dat jij dat vindt maakt het er gelukkig nog niet beter op.

[disjfa]

De smilie maakt het helemaal af toch

[geert1]

Matis schreef op dinsdag 15 september 2009 @ 14:09:
Klopt, opmaak dien je te maken met divjes/cvs en niet in een tabel-gedreven opmaak.

Echter vind ik dat je binnen een divje (bijvoorbeeld content) wel in een tabel mag plempen, dit omdat het velen malen eenvoudiger is die content uit te kunnen lijnen.

tables voor site design --> No Go

Jammer maar helaas. Als jij denkt dat uitlijning makkelijker is met tabellen, dan is dat omdat je onvoldoende ervaring hebt met html/css. Niets is namelijk minder waar, een tabel heeft in een moderne website nergens echt voordeel (behalve voor weergave van een tabulair overzicht). Het kost alleen wel moeite om de lastigere kneepjes van moderne, semantische opmaak echt door te krijgen, er daar scheelt het meestal.

[ Voor 3% gewijzigd door geert1 op 15-09-2009 14:22 ]

[Matis]

Ben ik even naar het toilet, escaleert het topic
Ik denk dat Erkens mijn bericht verkeerd geïnterpreteerd heeft en dat jullie daarop voortborduren.
Ik wilde het verhaal van geert1 kracht bij zetten door het te bevestigen, dat tables "alleen" gebruikt mogen worden voor het groeperen/ordenen van gerelateerde gegevens.

offtopic:
Jammer dat er zo HK gereageerd wordt...

Edit: Geert1

Ik denk helemaal niet dat uitlijning met tables eenvoudiger is, het tegendeel is momenteel in dit draadje bevestigd.
Daarnaast: http://stopdesign.com/arc...7/27/throwing-tables.html

[ Voor 25% gewijzigd door Matis op 15-09-2009 14:26 ]

[Erkens]

Matis schreef op dinsdag 15 september 2009 @ 14:24:
Ik denk dat Erkens mijn bericht verkeerd geïnterpreteerd heeft en dat jullie daarop voortborduren.

Verkeerd? Als jij het niet zo bedoeld had dan had je het anders moeten opschrijven...

offtopic:
Jammer dat er zo HK gereageerd wordt...

Mag ik zeggen dat ik jouw reactie eerder van "HK-niveau" vind? Want als je serieus een flamebait gaat gooien dan vraag je er gewoon zelf om.

[Asphyxion]

Bosmonster schreef op dinsdag 15 september 2009 @ 14:03:
interpolis.nl breekt alleen wel zo'n beetje iedere andere visuele handicap-richtlijn... Witte tekst op lichtblauwe achtergrond

edit:
Ow je hebt een heel klein verstopt knopje waarmee je zwart/wit kunt kiezen! Jammer dat mensen dat natuurlijk nooit gaan vinden

Met dit soort dingen heb ik altijd het idee dat iedereen zo'n feature maar overneemt van een anders site, maar er wordt nooit _echt_ over nagedacht of het wel zin heeft. Of dat er gemeten wordt hoe vaak de optie nu werkelijk gebruikt wordt.

Mee eens (zowel over Interpolis als nuttigheid (is dat een woord?) van dergelijke opties).

Ik zie wel een trend dat bv font grote keuze op websites (bv ministeries) worden weggelaten. De browser functie werkt toch beter en het scheelt gewoon weer CSS/programmeer tijd.

[Bosmonster]

Matis schreef op dinsdag 15 september 2009 @ 14:24:

Ik denk helemaal niet dat uitlijning met tables eenvoudiger is, het tegendeel is momenteel in dit draadje bevestigd.

Matis schreef op dinsdag 15 september 2009 @ 14:09:
[...]

Echter vind ik dat je binnen een divje (bijvoorbeeld content) wel in een tabel mag plempen, dit omdat het velen malen eenvoudiger is die content uit te kunnen lijnen.

Ehh.. je zegt het toch echt letterlijk hoor. Weinig interpretatie mogelijk.

[Matis]

Ik bedoelde dit aan te geven: nieuws: Upgraden van Vista naar Windows 7 kan 20 uur duren
Het tabelletje over hoeveel uur het gaat duren. Dan zit dit tabel toevallig in het divje genaamd article en niet content.
Dit tabel is toch praktisch niet uit te lijnen met css?

[ Voor 196% gewijzigd door Matis op 15-09-2009 14:35 ]

[jbdeiman]

Daarnaast passen die knopjes vaak niet op een goede/ mooie manier in de lay-out waardoor ze "weggestopt" worden (zoals dus op de website van interpolis). Dat vind ik gewoon jammer, bak die optie er dan niet in. Als je het doet, moet je het goed doen en niet zo "halfbakken" zodat het bijna niet terug te vinden is.

Maar nogmaals wil ik wel vragen om dit van richtlijnen nu even achterwege te laten en weer door te gaan op tabellen vs. semantisch (div) designen. Reageer bijvoorbeeld (voor diegenen die daarop kúnnen reageren op een zinnige manier) op de quote van mijzelf in mn vorige post?

Matis schreef op dinsdag 15 september 2009 @ 14:32:
Ik bedoelde dit aan te geven: nieuws: Upgraden van Vista naar Windows 7 kan 20 uur duren
Het tabelletje over hoeveel uur het gaat duren. Dan zit dit tabel toevallig in het divje genaamd article en niet content.
Dit tabel is toch praktisch niet uit te lijnen met css?

Hier heb je wel gelijk in, zo kwam het echter niet (ook niet na je uitleg) over in je vorige post. Het leek er meer op als jij een tekst in "newspaper style" (in kolommen dus) wilt indelen in je content div, dat je dat dan met een tabel doet, omdat dat gemakkelijker zou zijn.

[ Voor 39% gewijzigd door jbdeiman op 15-09-2009 14:37 ]

[disjfa]

Matis schreef op dinsdag 15 september 2009 @ 14:32:
Ik bedoelde dit aan te geven: nieuws: Upgraden van Vista naar Windows 7 kan 20 uur duren
Het tabelletje over hoeveel uur het gaat duren. Dan zit dit tabel toevallig in het divje genaamd article en niet content.

Je bedoelt tabulaire data

je bedoeling zal goed zijn, het komt er alleen zo rot uit

[Erkens]

Matis schreef op dinsdag 15 september 2009 @ 14:32:
Ik bedoelde dit aan te geven: nieuws: Upgraden van Vista naar Windows 7 kan 20 uur duren
Het tabelletje over hoeveel uur het gaat duren. Dan zit dit tabel toevallig in het divje genaamd article en niet content.
Dit tabel is toch praktisch niet uit te lijnen met css?

Ok, bij deze is het inderdaad bevestigd dat je nog niet exact weet wat semantiek inhoud Ik stel voor dat je dit topic eens helemaal doorleest, wellicht krijg je er dan een beter beeld van. Even voor de goede orde, die tabel is onderdeel van het artikel en is een tabel met tabulaire data, er is dus niks "fout".

[Matis]

jbdeiman schreef op dinsdag 15 september 2009 @ 14:35:
Hier heb je wel gelijk in, zo kwam het echter niet (ook niet na je uitleg) over in je vorige post. Het leek er meer op als jij een tekst in "newspaper style" (in kolommen dus) wilt indelen in je content div, dat je dat dan met een tabel doet, omdat dat gemakkelijker zou zijn.

Hehe, dan zitten we weer op een lijn.
Als ik kolommen wil, dan gebruik ik wel frames

@disjfa; misschien komt dat door mijn muisarm

@erkens: se·man·tiek (de ~ (v.))
1 leer van de betekenis van de woorden en woordgroepen => betekenisleer

Volgens mij is het de scheiding van inhoud en weergave. Het weergeven van je gegevens buiten je html houden.

[ Voor 18% gewijzigd door Matis op 15-09-2009 14:43 ]

[curry684]

Ik denk dat je Erkens niet hoeft uit te leggen wat semantiek is maar er zelf echt nog eens in moet verdiepen, want uit je laatste 5 reacties blijkt toch echt ondubbelzinnig dat je geen idee hebt waar de 'table-hetze' over gaat en wanneer het gebruik van tables nu wel of niet acceptabel is

[Matis]

curry684 schreef op dinsdag 15 september 2009 @ 14:47:
Ik denk dat je Erkens niet hoeft uit te leggen wat semantiek is maar er zelf echt nog eens in moet verdiepen, want uit je laatste 5 reacties blijkt toch echt ondubbelzinnig dat je geen idee hebt waar de 'table-hetze' over gaat en wanneer het gebruik van tables nu wel of niet acceptabel is

Okee, prima...

@hieronder

[Bosmonster]

Ok excuses voor mn reactie eerder, je hebt het blijkbaar gewoon over tabulaire data

[M0nkeymen]

Volgens mijn is semantisch gewoon dat je de tags gebruikt waarvoor ze zijn. h1 t/m h6 gewoon voor titels gebruik, p voor paragraaf, br voor lijnbreaks, en tabellen voor tabulaire data(prijslijsten e.d.) divs voor divisions(delen van een site). De tabel in het artikel is volgens mij gewoon terecht omdat het data is die in een tabel thuis hoort.

[Tjolk]

Dat het in dat artikel om tabulaire data gaat is inmiddels zo'n *natte vinger* 20x gezegd. Zal we duidelijk zijn inmiddels.

Semantiek is gewoon het sleutelwoord in deze discussie; tags gebruiken waarvoor ze zijn. Dat is om diverse redenen nuttig. Ten eerste voor jezelf (maakt het ontwerpen en met name aanpassen van de site makkelijker), ten tweede voor de zoekmachines (die weten waar het om gaat) en ten derde voor de screenreaders (heel belangrijk voor ze, maar doelgroep is beperkt). De enige reden om het niet te doen is een gebrek aan kennis.

Volgens mij valt daarmee zo'n 20 pagina's aan discussie samen te vatten.

[Matis]

M0nkeymen schreef op dinsdag 15 september 2009 @ 15:05:
Volgens mijn is semantisch gewoon dat je de tags gebruikt waarvoor ze zijn. h1 t/m h6 gewoon voor titels gebruik, p voor paragraaf, br voor lijnbreaks, en tabellen voor tabulaire data(prijslijsten e.d.) divs voor divisions(delen van een site). De tabel in het artikel is volgens mij gewoon terecht omdat het data is die in een tabel thuis hoort.

Dat is hoop ik nu toch wel duidelijk(, of ben ik weer niet duidelijk)? In jouw voorbeeld scheid je toch ook de inhoud van de opmaak.
Immers kun je met eenzelfde html pagina een compleet andere smoel geven aan je site door alleen je css aan te passen?

[jbdeiman]

De tabel in het artikel is ook tabulaire data, dus dat klopt helemaal. En je hebt helemaal gelijk met wat semantisch volgens jou is. Echter gaat dat niet altijd helemaal op, maar dat heeft meer met de voorkant te maken.
Je gebruikt bijvoorbeeld een <em> of <strong> om bepaalde delen in je tekst te benadrukken. Dit is echter niet altijd het geval als je naar de website zelf kijkt (als bezoeker). Deze dingen worden vaak semantisch correct gebruikt en wel voor de zoekmachine.
Voor mij is semantisch gebruik ook zichtbaar: Dus je ziet ook dat tekst in een <em> anders is dan de gewone tekst. Je benadrukt het niet alleen voor Google, maar ook voor je bezoekers.

offtopic:
Een spijker sla je toch met een hamer in het hout, niet met de achterkant van een schroevendraaier, tenzij je geen andere mogelijkheid hebt. Hoewel het best mogelijk zal zijn is het niet gebruikelijk om dat ook maar te doen.