Tables voor layout elementen

[perpixel]

Nee schrik niet! ik wil geen tables gebruiken voor een hele layout, maar een op een bepaald gedeelte van een te bouwen website is er content als volgt geordend:

http://jsfiddle.net/J4dY3/

Nu is dit natuurlijk wel met div's op te lossen, maar in de basis is dit een table structuur.

Ik weet dat het geaccepteerd wordt om tables als opmaak voor formulieren te gebruiken, maar omdat het in dit geval over content gaat vroeg ik me af of het hier ook de betere oplossing was of dat jullie dit anders op zouden lossen?

[jurrie]

Je kunt CSS columns gebruiken, al hangt het van de precieze inhoud af of het allemaal lekker werkt of niet (is mijn ervaring ten minste). Bijvoorbeeld:

http://jsfiddle.net/XKSzK/1/

Vereist nog wel browser prefixes maar als je redelijk moderne browsers mag ondersteunen is het zeker mogelijk: http://caniuse.com/#feat=multicolumn

[TERW_DAN]

Als het gaat om tabulaire data kun je dat natuurlijk prima in tabellen zetten. Het is niet alsof ze helemaal niet meer mogen natuurlijk.

[perpixel]

IE8 en IE9 gaan sowieso ondersteund worden dus css columns gaat het helaas niet worden. Verder gaat het gewoon echt om content en niet om tabulaire data. Dat is ook waarom ik de vraag stel. De vorm is het makkelijkst te maken met een table, maar omdat screenreaders mogelijk problemen hebben met tables vroeg ik me af of het wel de meest geschikte oplossing was.

[Miyamoto]

Geen tabulaire data, dan geen tabel. Gewoon met CSS fixen.

[TERW_DAN]

Idd, als het niet gaat om tabulaire data zou ik 't gewoon positioneren in CSS als dat nodig is. Css columns maken het wat makkelijker, maar zijn niet noodzakelijk om zoiets te doen.

[perpixel]

Miyamoto schreef op vrijdag 07 maart 2014 @ 16:00:
Geen tabulaire data, dan geen tabel. Gewoon met CSS fixen.

Dat is redelijk kort door de bocht toch? Volgens mij is het redelijk algemeen geaccepteerd om formulieren op te maken met tabellen.

[Miyamoto]

Vroeger. Nu niet meer hoor.

Gebruik elementen waarvoor ze bedoeld zijn. Eigenlijk heel simpel.
Je layout is ook vrij eenvoudig op te lossen met CSS, dus zie geen reden om een tabel te misbruiken.

[ Voor 26% gewijzigd door Miyamoto op 07-03-2014 18:35 ]

[NMe]

perpixel schreef op vrijdag 07 maart 2014 @ 16:26:
[...]

Dat is redelijk kort door de bocht toch?

Nope. Er is doorgaans geen enkele reden om tables te gebruiken wanneer dat semantisch niet correct is. Je kan desnoods wél display: table/table-row/table-cell gebruiken als je die tabelstyling wel nodig hebt, maar zelfs dat is meestal niet eens nodig.

[Bosmonster]

perpixel schreef op vrijdag 07 maart 2014 @ 16:26:
[...]


Dat is redelijk kort door de bocht toch? Volgens mij is het redelijk algemeen geaccepteerd om formulieren op te maken met tabellen.

Dat is pas kort door de bocht.

Er zijn mensen die tabellen semantisch correct vinden voor de opmaak van formulieren. Ik ben er daar niet een van, maar er zijn argumenten voor te vinden.

Voornaamste issue is dat je semantiek toepast o.a. vanuit toegankelijkheidsperspectief. Er zijn 2 elementen die een drama zijn in dat opzicht: tabellen en formulieren. Die twee combineren maken formulieren dus alleen maar minder toegankelijk.

Formulieren bevatten genoeg semantiek uit zichzelf (zoals linking van labels aan velden e.d.). Extra is dus ook helemaal niet nodig en een eenvoudige lijst of zelfs gewoon div's zijn daar dus prima voor.

[ Voor 12% gewijzigd door Bosmonster op 10-03-2014 09:51 ]

[underrated]

Eens met Bosmonster.

Voorbeedl van TS is semantisch volgens mij een list; en moet dus ook zo opgemaakt worden.

[biglia]

Als je het geen probleem vindt dat elke titel op dezelfde hoogte staat, lijkt me dit niet verkeerd.

[_Thanatos_]

NMe schreef op vrijdag 07 maart 2014 @ 19:05:
[...]

Nope. Er is doorgaans geen enkele reden om tables te gebruiken wanneer dat semantisch niet correct is. Je kan desnoods wél display: table/table-row/table-cell gebruiken als je die tabelstyling wel nodig hebt, maar zelfs dat is meestal niet eens nodig.

Zie correctie

[incaz]

Ik ben nog steeds best benieuwd naar een concreet voorbeeld waarom tabellen zo ontoegankelijk zijn. Heb ze ooit met lynx en een seriele reader bekeken en daar was niks mee aan de hand.

That said: het voornaamste probleem dat wel optreedt met tabellen is dat ze beroerd schalen naar smalle schermen / mobiel. Daar zijn bepaalde trucs voor maar erg elegant is het allemaal niet. En het voordeel van een css-tabel over een html-tabel is dat je die css-tabel beneden een bepaalde breakpoint kunt loslaten.

Punt daarbij is overigens dat je binnen css-tabellen geen rowspan hebt, en je op die manier niet exact kunt krijgen wat je hier toont. Flex zou het geloof ik wel moeten kunnen maar dat blijft natuurlijk toekomstmuziek.

En dat zou mij dan op z'n minst brengen naar de volgende vraag: wat wil je weergeven en wat is het belangrijkste daarvan? Is de gelijke hoogte van de cellen belangrijk, is de rowspan belangrijk, is het belangrijk dat het goed reflowt op kleinere schermen en zo ja hoe? Zijn er andere layouts te verzinnen die dit aardig benaderen maar misschien niet helemaal hetzelfde zijn maar wel aan de voorwaarder voldoen?

[Herko_ter_Horst]

incaz schreef op dinsdag 18 maart 2014 @ 10:04:
Ik ben nog steeds best benieuwd naar een concreet voorbeeld waarom tabellen zo ontoegankelijk zijn. Heb ze ooit met lynx en een seriele reader bekeken en daar was niks mee aan de hand.

Het gaat bij semantische markup dan ook niet in eerste instantie om toegankelijkheid, maar veel algemener om het voor machines begrijpelijker maken van de structuur van de pagina. Dit heeft op allerlei vlakken voordelen: doorzoekbaarheid, indexeerbaarheid, toegankelijkheid, schaalbaarheid, etc.

[incaz]

Herko_ter_Horst schreef op dinsdag 18 maart 2014 @ 12:52:
[...]

Het gaat bij semantische markup dan ook niet in eerste instantie om toegankelijkheid, maar veel algemener om het voor machines begrijpelijker maken van de structuur van de pagina. Dit heeft op allerlei vlakken voordelen: doorzoekbaarheid, indexeerbaarheid, toegankelijkheid, schaalbaarheid, etc.

I know, het klinkt allemaal geweldig. Alleen werd dat 10 jaar geleden ook gezegd en is er sinds die tijd nog geen praktische implementatie verschenen.
Het maakt dus eigenlijk nog niets uit in de praktijk, vooral niet als het alternatief op zichzelf vrijwel niets semantisch interessanter is (divjes bv.)

Ik vind het op zich prima om er naar te streven om het zoveel mogelijk semantisch ok te houden hoor, doe ik zelf ook. Maar laten we het gewicht ervan niet overschatten

[MoietyMe]

Heel kort voorbeeld dan:

HTML:

<table class="table">
    <tr class="head">
        <td></td>
        <td></td>
    </tr>
    <tr class="body">
        <td class="page"></td>
        <td class="sidebar"></td>
    </tr>
    <tr class="footer">
        <td colspan="2">
            <span>&copy; 1999 Michiel</span>
            <p>Hoofdstraat 19<br />3902 KL<br />Veenendaal</p>
        </td>
    </tr>
</table>

HTML:

<header role="banner"></header>
<article class="body">
    <section class="page"></section>
    <aside class="sidebar"></aside>
</article>
<footer role="contentinfo">
    <p>&copy; 2014 Michiel</p>
    <address>Vestergade 19<br />1456<br />København</address>
</footer>

[NMe]

incaz schreef op dinsdag 18 maart 2014 @ 13:25:
[...]

I know, het klinkt allemaal geweldig. Alleen werd dat 10 jaar geleden ook gezegd en is er sinds die tijd nog geen praktische implementatie verschenen.

Het maakt wel degelijk uit in de praktijk. Screen readers en search engines kunnen veel beter bepalen wat er voorgelezen of geïndexeerd moet worden als jouw pagina betekenis krijgt door het gebruik van de juiste elementen. Tables en zélfs display: table-cell zijn eigenlijk vrijwel altijd overbodig als het op layout aankomt.

Ik vind het op zich prima om er naar te streven om het zoveel mogelijk semantisch ok te houden hoor, doe ik zelf ook. Maar laten we het gewicht ervan niet overschatten

Divs zijn echter allang niet meer het enige alternatief. Nav-elementen zijn bijvoorbeeld heel slecht te combineren met een table-layout terwijl ze wel aardig wat toevoegen. En dan heb ik het niet eens over articles, sections en asides die handig kunnen zijn, naast natuurlijk headers en footers.

[incaz]

Good Fella: heel mooi, zo zien mijn pagina's er ook ongeveer uit hoor (behalve dan dat ik niet snel een header role=banner zou geven.)

Maar wat gebeurt ermee? Welke indexering en welke assistive technology gebruikt die info?

NMe: heb je een bron? Heb laatst gezocht naar info over screenreaders (en zelfs een poging gedaan die krengen te installeren) maar ik las overal dat roles nog grotendeels genegeerd worden, en dat zelfs headers binnen sections nog niet behoorlijk genest kunnen worden.

Verder: ik zeg niks over headers en footers. Die zijn eenvoudig toe te passen en zou ik ook beslist aanraden. Alleen ging het daar niet echt over volgens mij. Als de TS gegronde redenen hebt om de 8 tekstfragmenten op exact deze manier weer te geven, zijn er niet zo gek veel interessante alternatieven. Het zijn immers gelijkwaardige elementen. Die kun je in divs stoppen, al iets beter is ze in aparte articles stoppen die je vervolgens in divs plaatst om je tabelstructuur te zetten, maar dan houdt het *bij dit voorbeeld* wel zo ongeveer op.

[MoietyMe]

incaz schreef op dinsdag 18 maart 2014 @ 14:31:
Good Fella: heel mooi, zo zien mijn pagina's er ook ongeveer uit hoor (behalve dan dat ik niet snel een header role=banner zou geven.)

Waarom niet? Lijkt me goed aansluiten bij de ARIA guidelines: WAI-ARIA Roles.

[NMe]

incaz schreef op dinsdag 18 maart 2014 @ 14:31:
NMe: heb je een bron? Heb laatst gezocht naar info over screenreaders (en zelfs een poging gedaan die krengen te installeren) maar ik las overal dat roles nog grotendeels genegeerd worden, en dat zelfs headers binnen sections nog niet behoorlijk genest kunnen worden.

Roles heb ik zelf nog nooit gebruikt dus dat weet ik zo niet. Afgezien van dat kunnen screenreaders pas beter worden als sites semantisch goed in elkaar zitten, dus zelfs als ze nog niet goed genoeg zijn om perfect met nieuwere elementen overweg te kunnen is het een goed idee om ze toch te verkiezen boven slechtere ideeën omdat de nieuwe generatie screenreaders daar beter gebruik van kan maken.

Als de TS gegronde redenen hebt om de 8 tekstfragmenten op exact deze manier weer te geven, zijn er niet zo gek veel interessante alternatieven. Het zijn immers gelijkwaardige elementen.

Juist omdat het gelijkwaardige elementen zijn zou ik het een ul/li-combinatie van maken. Het is feitelijk gewoon een lijstje met items. De ul groepeert de items samen omdat ze bij elkaar horen, screenreaders kunnen er netjes een opsomming van maken (want de layout interesseert niet, het feit dat het een lijstje is wel ) en ook Google kan zien dat bepaalde teksten bij elkaar horen en gelijkwaardig zijn.

Good Fella schreef op dinsdag 18 maart 2014 @ 14:36:
[...]

Waarom niet? Lijkt me goed aansluiten bij de ARIA guidelines: WAI-ARIA Roles.

Persoonlijk vermijd ik altijd het woord "banner" in mijn code vanwege adblockers.

[ Voor 10% gewijzigd door NMe op 18-03-2014 14:38 ]

[Bosmonster]

Persoonlijk vermijd ik altijd het woord "banner" in mijn code vanwege adblockers.

Als een adblocker content blocked door een role=banner dan heeft er iemand niet goed opgelet in de adblock-schrijf-les..

[NMe]

Niet geheel ondenkbaar, en dus hou ik er rekening mee aangezien dat toch geen moeite kost.