The Anti-hero of CSS Layout – “display:table”
colintoh.com
colintoh.com
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...
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.
Not nearly as bad as 32%. And the number continues to drop.
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.
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.)
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.
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 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'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.
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.
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"?
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.
table-layout: fixed; table-layout: fixed;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!
gave me an instant smile, I remember 7 years back, wracking my brains out to get it done for a project!
"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.
Flex-boxes have a major axis whereas tables are just rows and columns, as one specific difference.
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.
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 layoutThe 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.
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.
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.
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).
if (bytes_per_val > 4)
{
bytes_per_val = 4;
}