4 ms·
Tables have a well(ish) defined semantics that you're breaking. Those semantics give rise to real practice benefits like navigating via column and row with scre
by ajanuary 13y ago
Tables have a well(ish) defined semantics that you're breaking. Those semantics give rise to real practice benefits like navigating via column and row with screen readers or hinting how best to split a table up into multiple pages when printing.
Practically, the way it's ended up, the semantics of a div is "some stuff". It's evolved into the go-to method to hide a multitude of styling sins. I don't think there's anything hugely hypocritical in limiting any ugly semanticless hacks to a single generic container like divs.
Put as much as you can into semantic markup, and then anything else you really can't fit into that, favour using div soup over breaking the semantics of another tag.
- Daniel_Newby 13y agoWhat about inline elements inside divs? Even the semantic correctness crusaders freely resort to abuse of <b> and <i>. HTML lacks extensibility. If you want to move beyond classical typography you have to make heinous compromises, and there is no reason <table> should be specially exempt.
- ajanuary 13y agoI agree we have to make compromises because HTML has huge shortcomings. My point, and the point of a lot of people advocating semantic markup, is that if you have to resort to hacks, prefer lots of uly generic containers like divs and spans to misusing things that have better defined semantics that are actually of use to people, like tables. I can't think of anything you can do with tables that you can't do with an ugly mess of divs and a little compromise in cross-browser consistency.