As someone who just implemented automatic table layout and is now intimately familiar with the details of how it works, I'd like to suggest that the problem with table-based layout is that it's excessively complex and largely undocumented and unspecified. The results will differ between browsers. Even the parts that have draft specs (which don't include, for example, percentage heights) are much more complex than CSS blocks and inlines: look at sections 4.1 through 4.4 of [1] for example.
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%.
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.
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.
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.
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.)
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.
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.
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.
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.
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.
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 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 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.
Yep, sorry I took a shortcut, I was referring to using table as a positioning method for the layout. Of course table are perfectly fine to display tabular data :)
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...
Sure, but IE 7 predated Chrome by 2 years. I'm not sure how IE 7 which has a global browser share roughly equivalent to Chrome 11, Firefox 3.6, Android 2.3 and Blackberry 7 has any relevance.
The biggest downside of display: table and friends is performance. Changing any CSS or DOM properties will basically cause a full page (!) relayout and repaint on a lot of browsers (especially mobile safari).
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.
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.
"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.
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).
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.
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.
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:
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.
> 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.
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).
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. :(
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.
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.
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!
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...
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/