There was a time, a decade ago, where using <table> for layout was reviled as horrendously poor form (and obviously it's semantically messy, and puts too much display information in the html markup) but CSS and proper html couldn't yet simply do what was simple to do in tables. But: Tables were pretty good at letting you indicate how you wanted unknown sized content to sit relative to other content. Not until flexbox and css grid layout appeared, really.
In those days, doing something like - getting multiple column-y divs to be as tall as each other without knowing how tall their content was tricky, this GIF shows the challenge:
One solution was the Equal Height Columns Hack where you would - I'm not kidding - add 32767 pixels worth of padding at the bottom, but then undo that with the negative equal value of margin.
I was kind of bitter. This kind of thing wouldn't even register as an challenge for a table-based layout - and using a table seemed MUCH less horrifying than this 32767 pixel garbage. (Apparently the number was empirically derived as large but not too large for most browsers). And really, is having an endless pile of nested <div> that much worse than non-data <table>? But I'm a hopelessly out of touch caveman for thinking so? OK.
I'm over it now, and am delighted CSS provides solid options that are semantically good. But overall I will always err on the side of pragmatic simplicity over semantic purity.
(Here's a similar grumbling blog entry from 2012 - using floating divs was another solution for solving problems caused by abstaining from tables)
No comments:
Post a Comment