The Anti-hero of CSS Layout – “display:table”(colintoh.com)
colintoh.com
The Anti-hero of CSS Layout – “display:table”
http://colintoh.com/blog/display-table-anti-hero
16 comments
Yes! I remember running into a really obscure bug that was caused by having an element nested into a parent with display: table. I don't remember the details, but I remember we were using the sticky footer technique described in the article.
I ran into a similar situation a while back while building an internal dashboard that had a fairly complex nested-table layout. It wouldn't render properly because of a bug in Firefox that had been open since 2000. I think this was the one (it seems they've fixed it): https://bugzilla.mozilla.org/show_bug.cgi?id=63895
>> E8 and IE9 still make up 32% of the browser market share and that is a lot to give up if I was to revert to the flex solution
Yes, if you have an even worldwide visitor share. Can I Use[0] puts USA IE9 usage at 3.86% and IE8 at 7.28% (11.14% in total). If your user base is different it would be wise to examine the data before discounting flex-box based on worldwide stats.
If anyone has access to netmarketshare's USA[1] (used in the article) data, it would be nice to see what it is.
EDIT: Also the article's stats[2] are for desktop only. It seems[2] that mobile support is relatively high with Can I Use[0] stating that total USA support = 86.46%.
[0] http://caniuse.com/#search=flexbox [1] http://www.netmarketshare.com/browser-market-share.aspx?qpri... [2] http://www.netmarketshare.com/browser-market-share.aspx?qpri...
Yes, if you have an even worldwide visitor share. Can I Use[0] puts USA IE9 usage at 3.86% and IE8 at 7.28% (11.14% in total). If your user base is different it would be wise to examine the data before discounting flex-box based on worldwide stats.
If anyone has access to netmarketshare's USA[1] (used in the article) data, it would be nice to see what it is.
EDIT: Also the article's stats[2] are for desktop only. It seems[2] that mobile support is relatively high with Can I Use[0] stating that total USA support = 86.46%.
[0] http://caniuse.com/#search=flexbox [1] http://www.netmarketshare.com/browser-market-share.aspx?qpri... [2] http://www.netmarketshare.com/browser-market-share.aspx?qpri...
netmarketshare also tracks users based purely on the user agent, regardless of how much browsing they do. As a result, it skews toward older browsers like IE8 and IE9 whose users typically don't surf very much at all. IF you track browser usage based purely on page views per browser IE8/9 represent a far lower percentage of all browser usage.
I was going to comment on that as well.
That depends on your target, my blog gets about 1% of traffic from IE8/9 so using flexbox would be ok if I wanted. If you're working on gaming/tech things for example, chances are most of your users will be on chrome/firefox and you can safely use it.
And flexbox is so nice.
That depends on your target, my blog gets about 1% of traffic from IE8/9 so using flexbox would be ok if I wanted. If you're working on gaming/tech things for example, chances are most of your users will be on chrome/firefox and you can safely use it.
And flexbox is so nice.
Agreed. A friend of mine suggested Flexbox for a web-app I was going to build him. I glanced over the requirements and then asked him his traffic for <IE10, and it was nearly 10%. (Website has 1m+ pageviews per month).
Not nearly as bad as 32%. And the number continues to drop.
Not nearly as bad as 32%. And the number continues to drop.
That said, if I told people on this site that I was offering a PaaS with only 1 nine of reliability, I'd be laughed out of the park. And yet that's exactly what I'd be saying if I were to advocate for ignoring <IE10.
Sure, wasn't making any comment as to whether it's okay to ignore 10%, just that 30% <IE10 is probably an overstatement.
As for whether it's okay to ignore... I guess it really depends. I actually ended up writing a mobile web-app with Cordova, so obviously my target market had no old IE in there. It might also be true that people on old IE are people on old hardware, the type like my dad who never does any ecommerce at all, and who may not be very lucrative visitors anyway.
Anyway I wonder if someone has some actual data on this, I can make up some assumptions but I really don't have a clue. I do often read that China and Russia are big IE markets (lots of windows XP and lots of websites that still use activex stuff). It'd be interesting to see which markets are high on <IE10 and what the average value (e.g. ad or ecommerce) per user from different browsers is.
Just checked on my own website, target audience are mostly 30-40 year old moms in OECD countries. <5% IE, and virtually all IE10/11. Just 5% IE9 and barely anything below. (mostly West-European audience.)
As for whether it's okay to ignore... I guess it really depends. I actually ended up writing a mobile web-app with Cordova, so obviously my target market had no old IE in there. It might also be true that people on old IE are people on old hardware, the type like my dad who never does any ecommerce at all, and who may not be very lucrative visitors anyway.
Anyway I wonder if someone has some actual data on this, I can make up some assumptions but I really don't have a clue. I do often read that China and Russia are big IE markets (lots of windows XP and lots of websites that still use activex stuff). It'd be interesting to see which markets are high on <IE10 and what the average value (e.g. ad or ecommerce) per user from different browsers is.
Just checked on my own website, target audience are mostly 30-40 year old moms in OECD countries. <5% IE, and virtually all IE10/11. Just 5% IE9 and barely anything below. (mostly West-European audience.)
I hardly think you're comparing anything meaningful. The hypothetical PaaS has a certain level of reliability regardless of the client your user choses to use to connect but your user's client doesn't support the server's feature set.
Anyways, I have no respect for anyone using <=IE9. I currently have to support IE8 (and 9 but that's not a big deal) because we deal with Australia and we deal with banks. At this point it's ludicrous that they haven't caught up. IE8 doesn't have the ActiveX lockin that IE6 had and current IE is immeasurably better in all conceivable ways from what's come before.
Anyways, I have no respect for anyone using <=IE9. I currently have to support IE8 (and 9 but that's not a big deal) because we deal with Australia and we deal with banks. At this point it's ludicrous that they haven't caught up. IE8 doesn't have the ActiveX lockin that IE6 had and current IE is immeasurably better in all conceivable ways from what's come before.
... something something inhouse-app on ie9 install base ...
I remember the anti-html table movement fondly. While everyone knew tables were bad for certain purposes, the hate movement brainwashed people into thinking that using tables for anything (including tabular data) was bad. And so, people started marking up tabular data using DIV's and CSS properties that suffered from a myriad of compatibility issues, convincing themselves that using floats was the right thing to do.
And we all bought into it, well most of us. Every time an overzealous developer would spot the use of a table tag, hell would reign down upon Earth lambasting the developer for using a table, even if it was being used for the right purpose. "how dare you use a table you noob, use floats and DIV's, they are so much better" - for a good while people were hating on using the table tag to the point where many were hating it, but could not really tell you why other than, "because tables are bad"
In many ways the web has gone full circle, Flexbox is merely a more powerful CSS version of tables, in-fact there are many similarities like the ability to have columns of content of varied size sitting alongside one another. We added in a new set of properties, changed the name and made them a little bit more powerful.
I am one of those developers who have been quietly using display table for non-tabular data for a while now to solve issues I have seen other developers resort to additional markup and CSS hacks for, that either makes me a lazy developer, an efficient developer or perhaps both.
Just recently I proved a remote developer wrong in regards to responsive tables. He tried telling me and the business responsive tables cannot be done without hacks. I implemented a solution using display table and DIV's. This is for part of an app that only logged in users see, not search engines, so while it was not a true proper use of the properties, it allowed me to implement a true responsive solution for tables that will not degrade SEO or performance, as it is not public.
Simply using media queries I was able to make my table DIV's collapse by setting them to display block, adding in some type and colour adjustments, and it just worked. No need to use before and after pseudo selectors to hack in support for titles and stacked tables. No hair pulling when the business asked me to support IE9 either.
As developers we all mostly want to do everything correctly and use the proper tags and CSS properties in the appropriate way, but sometimes when you have a deadline to meet and time is running out, you have to do what you have to do to get things done.
And we all bought into it, well most of us. Every time an overzealous developer would spot the use of a table tag, hell would reign down upon Earth lambasting the developer for using a table, even if it was being used for the right purpose. "how dare you use a table you noob, use floats and DIV's, they are so much better" - for a good while people were hating on using the table tag to the point where many were hating it, but could not really tell you why other than, "because tables are bad"
In many ways the web has gone full circle, Flexbox is merely a more powerful CSS version of tables, in-fact there are many similarities like the ability to have columns of content of varied size sitting alongside one another. We added in a new set of properties, changed the name and made them a little bit more powerful.
I am one of those developers who have been quietly using display table for non-tabular data for a while now to solve issues I have seen other developers resort to additional markup and CSS hacks for, that either makes me a lazy developer, an efficient developer or perhaps both.
Just recently I proved a remote developer wrong in regards to responsive tables. He tried telling me and the business responsive tables cannot be done without hacks. I implemented a solution using display table and DIV's. This is for part of an app that only logged in users see, not search engines, so while it was not a true proper use of the properties, it allowed me to implement a true responsive solution for tables that will not degrade SEO or performance, as it is not public.
Simply using media queries I was able to make my table DIV's collapse by setting them to display block, adding in some type and colour adjustments, and it just worked. No need to use before and after pseudo selectors to hack in support for titles and stacked tables. No hair pulling when the business asked me to support IE9 either.
As developers we all mostly want to do everything correctly and use the proper tags and CSS properties in the appropriate way, but sometimes when you have a deadline to meet and time is running out, you have to do what you have to do to get things done.
Yup. Same thing that happened to goto, basically. People got so up in arms about the overuse of the concept (and they had a wonderful catchphrase thanks to Dijkstra) that it became vilified to the point where any time it showed up in code you'd likely incite a mini holy war that would usually end in its removal (if for no other reason than to shut everyone the fuck up). This despite the fact that (in C in particular) goto is sometimes absolutely the clearest, most practical way to deal with a function localized many-to-one flow control situation.
Using tables is back? Sweet. Now my knowledge of HTML is relevant again.
Exactly, too many developers think that tables are always bad. Really it's about using the right tool for the right job, and there are times when display:table will save you tons of work. There was a time when tables were used for everything, so people started blaming the tool instead of the bad practice.
To be honest the css property display:table isn't bad itself.
What we were reproaching to the <table> tag was to be wrong on the semantic side.
If you use divs and style them with display:table I see absolutely nothing wrong here, semantic is right, you infer the display behaviour through css.
What we were reproaching to the <table> tag was to be wrong on the semantic side.
If you use divs and style them with display:table I see absolutely nothing wrong here, semantic is right, you infer the display behaviour through css.
I think you're still falling into the religious trap here. Quite often I will put inline css into the html page, or use a table tag. Normally I would never admit this, as I would be hounded by css zealots. Often I do this when I'm building a user interface in html/javascript, or for a single one-off layout in a single page. Using external css in these cases would make it much more difficult to understand/maintain.
I can understand the argument that "you should put styling into an external css so you can just change it in one place rather than throughout the code". However that argument doesn't apply to many use-cases.
I can understand the argument that "you should put styling into an external css so you can just change it in one place rather than throughout the code". However that argument doesn't apply to many use-cases.
It comes to knowing your tools and craft.
Part of the madness was due to tools that auto generated attributes and browser implementations when repainting/reflow occurred.
If the time, and potential knowledge was there, to better organize the structure vs. the layout thing may have been different. We would probably still be wrestling with browser issues.
I have worked in places where corporate sites had tables were littered with font tags for each cell, littered with a half dozen iframes(!?!)
The use for tables in layout was easy, but the long term debt was never paid.
Granted this is less of a case now; wading through this was not fun.
Part of the madness was due to tools that auto generated attributes and browser implementations when repainting/reflow occurred.
If the time, and potential knowledge was there, to better organize the structure vs. the layout thing may have been different. We would probably still be wrestling with browser issues.
I have worked in places where corporate sites had tables were littered with font tags for each cell, littered with a half dozen iframes(!?!)
The use for tables in layout was easy, but the long term debt was never paid.
Granted this is less of a case now; wading through this was not fun.
I definitely agree that in cases like that CSS is the much cleaner solution.
I can't imagine a situation when using external CSS could make something to be much more difficult to understand and maintain. And no, I am not trapped by any religion, I do use inline CSS and <table> from time to time (only way to handle styling for e-mails) - and it is always a very, very painful experience.
It's simple as that: if you don't have to (e-mails) do not use inline CSS. Never, ever. And the same goes for <table>. It will actually save you a lot of work.
It's simple as that: if you don't have to (e-mails) do not use inline CSS. Never, ever. And the same goes for <table>. It will actually save you a lot of work.
It's not that external CSS will make it much more difficult to understand and maintain, just a little bit.
For example, I have a page that uses html5 to draw a playback progress bar. The canvas tag has an inline style giving the width and height. If I put this in an external css it would mean I would have to either create a new css page, or put it into an existing page (and then put a comment in the css saying which file it was for). Thus the html is larger in total, possibly more files to download, more files to maintain, and if you want to tweak the layout you have to hunt in the css for it (rather than it being right there).
In cases like this where it is a single tag, using inline styles just simplifies development and maintenance with no downside.
For example, I have a page that uses html5 to draw a playback progress bar. The canvas tag has an inline style giving the width and height. If I put this in an external css it would mean I would have to either create a new css page, or put it into an existing page (and then put a comment in the css saying which file it was for). Thus the html is larger in total, possibly more files to download, more files to maintain, and if you want to tweak the layout you have to hunt in the css for it (rather than it being right there).
In cases like this where it is a single tag, using inline styles just simplifies development and maintenance with no downside.
Not sure that's a very good example to be honest. Why would you need to create an entirely new CSS file for this?
And adding a single comment line in addition to your style sheet isn't exactly going to break the bank.
What if your client comes back to you in a few weeks/months and says "I want another playback progress bar on another page"?
And adding a single comment line in addition to your style sheet isn't exactly going to break the bank.
What if your client comes back to you in a few weeks/months and says "I want another playback progress bar on another page"?
It still takes me a few beats from thinking "I need a flexible grid layout here" to remembering I can just use display:table, having spent so many years discounting it off-hand because of Internet Explorer.
As a fairly new web developer, who's doing it for fun, I'm so glad that I can just say "screw it, I'm using flexbox" for 99% of these sorts of problems!
What does IE have to do with this? Wasn't the whole anti-table movement a response to the abuse of <table>, <tr>, <td> HTML tags for layout? I can't think of any particular issue with Internet Explorer and display:table...
If you use table for layout, remember to also use
table-layout: fixed;It really depends why you are using the table layout. Quite often the reason for using tables is to lay out multiple items based on their content size, so you want the default automatica layout.
'I absolutely dissent HTML table-layout'. Don't you have to dissent from?
yeah, that makes no sense grammatically, I think maybe OP meant "detest".
We have come full circle. Tables to CSS grid based frameworks back to Tables?
Tables are generally for structured content. They work and are perfect - Excel for example. Hundreds of cells on a page? Rendering / performance would be a nightmare.
CSS grids for layout - perfect and may cause some pain. Once you get it right the performance is there.
With css/tags there can be abuse and we must think of how we plan to present our content to the user who ultimately judges our work.
They do not care about the how it was implemented, they just want it now and that it works consistently.
We need to ensure we keep our sanity the balance is in between the two.
On another note, the use of colgroups should be mentioned with the above. It does help with rendering performance. http://www.w3.org/TR/html5/single-page.html#the-colgroup-ele...
- Enjoy!
Tables are generally for structured content. They work and are perfect - Excel for example. Hundreds of cells on a page? Rendering / performance would be a nightmare.
CSS grids for layout - perfect and may cause some pain. Once you get it right the performance is there.
With css/tags there can be abuse and we must think of how we plan to present our content to the user who ultimately judges our work.
They do not care about the how it was implemented, they just want it now and that it works consistently.
We need to ensure we keep our sanity the balance is in between the two.
On another note, the use of colgroups should be mentioned with the above. It does help with rendering performance. http://www.w3.org/TR/html5/single-page.html#the-colgroup-ele...
- Enjoy!
My IE8+ grid is based on display: table and just works. http://natuive.net
>> the holy grail layout
gave me an instant smile, I remember 7 years back, wracking my brains out to get it done for a project!
gave me an instant smile, I remember 7 years back, wracking my brains out to get it done for a project!
What I didn't understand from this blog post is WHY display:table is really bad.
It's not. That's the point.
"Tables for layout are bad" applies only to use of <table> HTML markup for layout. `display:table` achieves the same layout, but without presentational markup and accessibility problems that html-tables-for-layout caused.
If it was called "display:stretchy-box", nobody would mind.
"Tables for layout are bad" applies only to use of <table> HTML markup for layout. `display:table` achieves the same layout, but without presentational markup and accessibility problems that html-tables-for-layout caused.
If it was called "display:stretchy-box", nobody would mind.
Are html-tables bad even for their intended purpose of laying out tabular data?
No.
And again, that's part of the point; "HTML table tags aren't good for layout" semantically collapsed[1] to "tables aren't good for layout" collapsed to "tables are bad" collapsed to "tables are EVIL". No, they aren't. The first collapse is easily explained by the fact that for a long time HTML table tags bidirectionally implied table layout (no way to have one without the other), but now that CSS has broken that in both directions it's not a valid simplification.
(Less well known aspect of CSS table support, I'm pretty sure it's possible to take a series of HTML table elements and "undo" their tableness if you're feeling feisty. But it's a weird way to do things.)
[1]: I seem to recall there's a term for what I'm reaching for. Much obliged if someone can remind me.
And again, that's part of the point; "HTML table tags aren't good for layout" semantically collapsed[1] to "tables aren't good for layout" collapsed to "tables are bad" collapsed to "tables are EVIL". No, they aren't. The first collapse is easily explained by the fact that for a long time HTML table tags bidirectionally implied table layout (no way to have one without the other), but now that CSS has broken that in both directions it's not a valid simplification.
(Less well known aspect of CSS table support, I'm pretty sure it's possible to take a series of HTML table elements and "undo" their tableness if you're feeling feisty. But it's a weird way to do things.)
[1]: I seem to recall there's a term for what I'm reaching for. Much obliged if someone can remind me.
>"for a long time HTML table tags bidirectionally implied table layout" //
You're right, tables are fine for tabular data. But it was always thus.
Perhaps if you were a html noob and hung out listening to people pissed off with table layouts you'd get confused and think all tables were bad (you definitely want a graphical layout helper app though as keeping track of them in code is a PITA).
It was
You're right, tables are fine for tabular data. But it was always thus.
Perhaps if you were a html noob and hung out listening to people pissed off with table layouts you'd get confused and think all tables were bad (you definitely want a graphical layout helper app though as keeping track of them in code is a PITA).
It was
table tage |- table layout V tabulated data
table tage |- table layoutI've worked on HTML that was written by someone who cargo culted all of the tables into rows of Bootstrap columns, for tabular data. It happens.
"I seem to recall there's a term for what I'm reaching for." Conflated?
Specifically, a complicated concept getting simplified to a simpler concept that is easier to spread around culturally. Complicated treatises on when tables are and are not valid are much harder to spread around than "Tables are EVIL!", so the latter has a significant memetic propagation advantage.
The fact that nobody has popped up so far suggests that I may be wrong about an existing term. I'd really have expected a LessWronger or something to speak up by now.
The fact that nobody has popped up so far suggests that I may be wrong about an existing term. I'd really have expected a LessWronger or something to speak up by now.
Well with the world moving towards mobile display compatibility people are generally depreciating tables in favor of grid-systems via CSS because they are more customizable for formatting tables intelligibly on smaller displays. Tables don't collapse or reformat properly on small screen and what you'll get is usually multiple columns with one letter on each line while grid-systems can stack columns making it both more legible and organized. CSS grid-systems of course require more work but you can generally find them already integrated into frameworks like bootstrap. Even still if you have complex table formats it'll require more customized situational grids than generalized grid-systems but in most cases bootstrap grids works fine. However I have had times when I have tables with minimum copy and mostly icons so we opted for tables because even on small displays it collapsed just fine as opposed to grids which left a lot of empty space.
Or "display:flexible-box", maybe even shortening that somehow. Hmm.
A flex-box container is pretty different than a table.
Flex-boxes have a major axis whereas tables are just rows and columns, as one specific difference.
Flex-boxes have a major axis whereas tables are just rows and columns, as one specific difference.
Yeah, fair point actually.
That's not what he's saying. He's saying they're good at times but he took ages to realize that because the old table based layout using <table> used to result in extreme tag soup.
If you are looking for reasons why they're actually not that great anyway, this succinct post on /r/webdev reminded me why I haven't unsubbed from that highly variable sub:
http://www.reddit.com/r/webdev/comments/2k8ud2/why_does_no_o...
In this case, the example the OP gave at the beginning, a dashboard, can't work with a responsive layout using display:table, which is a feature you'd kinda expect in this day and age.
So they finally release a half decent display:table and it's too late as we now need responsive designs.
Pretty much sums up how pants the W3C process is.
If you are looking for reasons why they're actually not that great anyway, this succinct post on /r/webdev reminded me why I haven't unsubbed from that highly variable sub:
http://www.reddit.com/r/webdev/comments/2k8ud2/why_does_no_o...
In this case, the example the OP gave at the beginning, a dashboard, can't work with a responsive layout using display:table, which is a feature you'd kinda expect in this day and age.
So they finally release a half decent display:table and it's too late as we now need responsive designs.
Pretty much sums up how pants the W3C process is.
> So they finally release a half decent display:table and it's too late as we now need responsive designs.
I'm not sure what you mean by "finally release." The display: table property was part of the CSS 2.1, which became a Candidate Recommendation in 2004 and an official Recommendation in 2011. It also works perfectly in IE8, which was released in 2009.
The term "Responsive Design," on the other hand, wasn't even coined until 2010, and didn't really become mainstream for another 2-3 years.
There were a couple of years when working with display: table was perfectly reasonable and the "Responsive Design" trend hadn't yet hit the tipping point.
I dislike overdone/late W3C processes as much as anyone, but this isn't a good example of that.
I'm not sure what you mean by "finally release." The display: table property was part of the CSS 2.1, which became a Candidate Recommendation in 2004 and an official Recommendation in 2011. It also works perfectly in IE8, which was released in 2009.
The term "Responsive Design," on the other hand, wasn't even coined until 2010, and didn't really become mainstream for another 2-3 years.
There were a couple of years when working with display: table was perfectly reasonable and the "Responsive Design" trend hadn't yet hit the tipping point.
I dislike overdone/late W3C processes as much as anyone, but this isn't a good example of that.
Even earlier, display: table was part of the original CSS Level 2 which became a REC in 1998 — twelve years before "responsive design" came into being. It largely followed what had been added to HTML 3.2 in January 1997 — based on what most browsers (with Netscape first) in 1996.
There's also a lot of unwillingness to do much around display: table — it remains largely unspecified (mostly because we basically know web compatibility requires you to do what IE6 does — and nobody knows quite what that is, and MS people have struggled to get permission to disclose the detail).
There's also a lot of unwillingness to do much around display: table — it remains largely unspecified (mostly because we basically know web compatibility requires you to do what IE6 does — and nobody knows quite what that is, and MS people have struggled to get permission to disclose the detail).
At least it was mostly copied from Netscape, and source for that is available as Mozilla Classic (from the cancelled Mariner project). I used it to figure out where HTML legacy color parsing come from.
Sadly, we know that what web compat relies on isn't quite what NN4(-ish) does, so the mere fact that that is available doesn't really help too much. :(
Actually, the same thing is true for HTML legacy color parsing too, but the only difference there is a few lines of code. I think it is these lines that was added (from http://mxr.mozilla.org/classic/source/lib/layout/layimage.c#...):
if (bytes_per_val > 4)
{
bytes_per_val = 4;
}Table parsing is nowhere near that similar. It's almost certain IE's algorithm is largely different — it just obtains similar results to NN's in most cases.
But yea, I have been thinking of the idea of a IE only shared source program for a while now.
It's not. But nobody ever got to use it, because IE6 and IE7 didn't support it, and now it's only useful for supporting IE8, IE9.
[deleted]
He mentions it in the article. People associated it with the HTML table element. Using the table element for page layout affected the document's structure which is why that's a bad thing but the CSS table property does not affect structure.
I've been using this in some of my latest projects. Works like a charm!
interesting! will look this up again when I have one of the described problems. In the meanwhile, I'll push an update to my brain: not everything related to tables is old / bad!
This is the most appropriately-named article, ever.
Most of the examples can be achieved with flex layouts, Stylus+nib even manages the browser prefixes for you. Just mentioning this, because last week I considered a {HTML|CSS} table layout. As it turned out, solving the problem with tables was more difficult than using other methods...
You can achieve the same results with absolute positioning, which I prefer.
I'm pretty sure you can't, except in the trivial case of a table with absolute-sized everything, or alternatively by reimplementing the table algorithms in JS.
Problem with absolute positioning is that you remove elements from the natural flow of the page, meaning that adjacent elements aren't aware of the dynamic height of a fixed footer for example.
[1]: http://dbaron.org/css/intrinsic/