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 :)
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.