
The Anti-Hero of CSS Layout – “display:table” (2014) - Tomte
http://colintoh.com/blog/display-table-anti-hero
======
olavk
It is fascinating how a perfectly sensible rule-of-thumb "you shouldn't use
html tables for something which is not semantically a table" gradually morphed
into various superstitions like "you shouldn't use html tables" or "you
shouldn't use tables for layout" or even "you shouldn't use tables".

I don't think people have a hard time understanding that you shouldn't use the
<blockquote>-element for something which is not a quote. But html tables had a
more troubled history because for a long time html tables were the only way to
achieve certain layout effects, which was not supported by pure CSS in
mainstream browsers, because they didn't implement "display:table".

This article is well-intentioned but I think it also contains some language
which muddies a pretty simple concept. Eg. it states _CSS Table has a key
differentiation over HTML Table. It can choose not to be a table by just
adjusting its CSS properties. Something that HTML Table is incapable of._ The
sentence seem to confuse semantics with presentation, which is what got us
into this mess in the first place.

~~~
achairapart
On the other hand, there are cases where HTML Tables put great challanges to
user experience.

First to come to mind: A table with many rows displayed on a tiny mobile
screen. The most common solution is to let the table overflow horizontally.
There are other complex solutions, most of them fall in the _CSS-Hack_
category.

In this case, to have a _CSS table_ that can be something else on a tiny
screen (via media queries) may lead to a successful UX solution.

~~~
olavk
But you don't choose between HTML tables and CSS tables - they are independent
concerns, HTML is semantics, CSS is presentation. HTML table elements just
have display:table as the _default_ style (in the default browser style
sheet). You can override this in a style sheet as with any other style. And
conversely, you can apply display:table to any element regardless of HTML
semantics.

It is true older browsers had partially hardcoded presentation so you couldn't
always override the default CSS of certain elements (table elments and form
controls were especially notorious for hardcoded presentation). But I believe
this is not an issue in modern browsers.

~~~
gsnedders
> But I believe this is not an issue in modern browsers.

I think the last browser that saw widespread use in any market with that issue
was NN4. In some markets, Opera [some version; 7?] with the same issue will
have been a problem much later than NN4. Really, this is to say: this hasn't
been a concern for well over a decade at this point even with fairly generous
browser support matrices.

------
bgrohman
For what it's worth, the author mentioned that CSS Flexbox would also work,
but the market share of IE 9 was too high at the time for him to use. That was
2014, and now the market share of IE (especially IE 9) is drastically lower.

[https://www.w3counter.com/trends](https://www.w3counter.com/trends)

[http://caniuse.com/#feat=flexbox](http://caniuse.com/#feat=flexbox)

~~~
blueside
depending on your audience, most of the time you still can't use flexbox today
due to ie9/10.

it's really something that after all these years, in 2017, microsoft browsers
still find a way to hold back web features.

~~~
crocodileJS
What audience is that? Who are these people relevant to? Microsoft isn't
holding back anything, they can't force these people to update their software.
If everyone keeps supporting them, they never will have a reason to update.

~~~
enraged_camel
Government is one such audience. The K-12 system is another.

~~~
crocodileJS
Is that _really_ true? You'd think that the government has security provisions
that requires software updates.

As for K-12, is that really a _requirement_ in some places, or is it just the
case that some clients just happen to not be updated?

~~~
gsnedders
IE9 gets security updates on Vista SP2.

More generally IE9 and IE10 are both still supported by Microsoft (for Vista
SP2, Server 2008 SP, Server 2008 IA64; and for Server 2012, and Embedded 8
Standard), so it seems entirely plausible Microsoft would sell security
updates for other OSes to clients willing to pay for them; they definitely do
that for some clients (some still get security updates for XP!).

~~~
sljd
These outdated OSes have a tiny market share, and more importantly, an
organization that prevents sw installation doesn't use outdated OSes. Others
can install Firefox even on XP. Old Androids and IPhones are a bigger issue.

------
cletus
The anti-table hysteria has vexed me for years. From a purely practical POV
tables were simply the only way to achieve things in a broad browser base
until only the last few years.

But what really drove me nuts was when that hysteria extended to things that
were clearly tabular. I remember trying to copy paste a list of transactions
from the Morgan Stanley site and it just didn't work. Confused why I looked at
the source and the "table" was in fact just a series of divs with a lot of CSS
to make it look like a table. A table could be copied and pasted into a Google
spreadsheet trivially. Instead I had to manually reenter the data.

I feel like a lot of this could have been prevent d had we simply created HTML
elements called <grid> years ago.

------
c-smile
The only problem with display:table is that it still requires additional
markup to organize elements in tables. Consider this definition list:

    
    
       <dl>
          <dt>Term1</dt> 
             <dd>Term1 defintion</dd>
          <dt>Term2</dt> 
             <dd>Term2 defintion</dd>
       </dl>
    

and the task of organizing it into two columns table: dt's in first column and
dd's in second. Impossible either with display:table & co. or with display
flex.

At the same time in Sciter[1] I can define that layout as

    
    
       dl { 
          flow: row(dt,dd); 
       } 
    

\- replace dt/dd pairs in table rows. The table will have two columns. Pure
styling without changes of markup semantic and structure.

[1] CSS: Flow property and Flex units in Sciter:
[https://sciter.com/docs/flex-flow/flex-
layout.htm](https://sciter.com/docs/flex-flow/flex-layout.htm)

~~~
olavk
CSS only needs additional elements in case you need to apply structures which
is not already present in the HTML. To layout something as a grid you need two
levels of grouping: what delimits a cell and what delimits a row. Free-from
dt/dd sequences does not contain this information, since there may be multiple
dt per dd and vice versa. If dt/dd could only appear in pairs (like in your
example) you could say there is an implicit structure, but this is not
necessarily the case.

~~~
c-smile
> you need two levels of grouping

Not necessarily.

I can define

    
    
       form { flow:row(label, input select textarea); }
    

to have typical form's two columns layout with all <label>s go to first column
and input, select and textarea go to second. All non-matching elements are
replaced as if they span full rows (like <caption> in tables).

People at trying to simulate these things by using float and clear. Ugly, non-
reliable, etc.

------
gsnedders
table-layout is another CSS property that I think too often goes unmentioned
when talking about table based layouts; the default value (auto) is
essentially "do something the spec isn't even going to try and define because
implementations be crazy because they're essentially reverse-engineered copies
of IE6's behaviour which is itself a reverse-engineered copy of NN4's
behaviour".

The other value the property can take, fixed, makes table layout way more
predictable: with no width properties defined, an n column table will result
in each column having an equal width. If you define a width on some columns,
it will split the remaining space between the remaining columns. This is far
more often what you actually want when laying out non-tabular data using
display: table as a make-shift grid layout system.

------
arca_vorago
I never understood why people think the "holy grail layout" is a sticky
footer. Do they really have pages with so little content that it's an issue?

I have decided for me at least that a fixed footer and header is what I
consider my "holy grail layout" with just a center with no columns. Lately
I've been trying to play with css grid to port over my previous layouts, but
without much luck so far.

~~~
olavk
The _point_ of a footer is that it is at the bottom of the canvas regardless
of the size of other content. If it is not at the bottom of the canvas, then
you get something else at the bottom - like a colored box of unknown
dimensions. Which means the footer is not the footer anymore.

------
return0
I'm still waiting for "display:div" to roll out.

~~~
bromuro
It's called `display: block` - in sake of consistency :)

~~~
c-smile
`display:block` does not define layout model of element content so I suspect
it is not an intent of the author.

This

    
    
       div { display:block }
       div > * { display:block; }
    

is closer but still far from ideal: e.g. it will force all tables to lose
their display:table; or lists to lose display:list-item;

As far as I understand author is looking for

    
    
       div { flow:vertical; }
    

But that's available only in Sciter.

~~~
olavk
I'm not sure I understand what you are trying to achieve differently from
regular display:block?

~~~
c-smile
Consider following markup:

    
    
       <div>
         some text
         <foo>first</foo><bar>second</bar>
       </div>
    

There is no way in CSS at the moment to define __content __flow of the div
above. The only possible way is to define `display` on its children.

Say, you want that div to replace content vertically as if all children are
blocks and text runs are wrapped into anonymous paragraphs:

    
    
       <div>
         <p.anonymous>some text</p>
         <block.foo>first</block>
         <block.bar>second</block>
       </div>
    

That's impossible in modern CSS without redefining `display` in children. But
usually you cannot blindly say

    
    
       div > * { display:block;} 
    

What if some child uses `display:flex` ?

Problem is that `display` defines how element is replaced __among its siblings
__. But not how its children are laid out.

At some point it was a proposal to add `display-model` css property. So you
can have

    
    
       div { display: block; display-model:flex | table | etc }
    

Without it we have ugly semi-solution of combinatorial explosion:

    
    
       div { display: flex; }
       div { display: inline-flex; }
       div { display: table }
       div { display: inline-table; }
       div { display: grid; }
       div { display: inline-grid; }
       ...

~~~
olavk
Ah OK, I agree this would be useful. I think a newer CSS proposal factors the
display property into separate values to declare element flow and element
content flow independently.

~~~
c-smile
"a newer CSS proposal"

This is of 2002: [http://www.w3.org/TR/2002/WD-
css3-box-20021024/#L706](http://www.w3.org/TR/2002/WD-css3-box-20021024/#L706)

15 years ago, Carl!

~~~
olavk
Yeah, that draft was abandoned though, but some of the ideas have been
incorporated in the CSS3 display model.

------
draw_down
Hmm, I usually only want "display: table" for... tables.

~~~
ricardobeat
You missed the point. The CSS table display was created to decouple this
particular layout behaviour from the <table> element. The reasons for that are
clearly laid out in the examples. All of this was impossible to accomplish
before flexbox.

