Live data from Hacker News

The Anti-Hero of CSS Layout – “display:table” (2014)

colintoh.com

11–20 of 60 posts

Re: The Anti-Hero of CSS Layout – “display:table” (2014)

#11
post #2

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 -element for something which is not a quote.…

That is because people who do HTML markup are usually not developers. They are either wannabe developers or just incompetent people hired to reduce costs. They would never waste their time on reading something complicated as W3C standards and understanding concepts like semantic markup.

My experience has been quite opposite. In fact, most of the HTML I've worked on was written by developers whose primary focus is server-side Java.

Re: The Anti-Hero of CSS Layout – “display:table” (2014)

#13
post #2

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 -element for something which is not a quote.…

Largely because I'm relatively new to all of this and probably don't know better, but I've found success just using divs for all layout and doing it myself.

Which is a smell to me, but I just can't help but find that every time I have consistent results and expected behaviour. Div and flexbox for everything.

It actually reminds me of another smell I have with django: write my own serializers and views rather than using any of the magical ones. I tried so hard to use the freebies but the moment you want something that isn't exactly as prescribed, it becomes a disaster. That's been my experience with CSS and HTML layouts.

Re: The Anti-Hero of CSS Layout – “display:table” (2014)

#15

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

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

Re: The Anti-Hero of CSS Layout – “display:table” (2014)

#16
post #2

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 -element for something which is not a quote.…

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)…

This makes sense to me.

In the MySQL monitor, you can terminate a statement with ; for tabular view, or with \G for a linear view that represents each row as a key-value list. This is super useful for reading wide rows in narrow terminals. I can very easily see the appeal of doing the same for wide tables on narrow displays.

Re: The Anti-Hero of CSS Layout – “display:table” (2014)

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

   
      Term1 
         Term1 defintion
      Term2 
         Term2 defintion
   
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

Re: The Anti-Hero of CSS Layout – “display:table” (2014)

#18
post #9

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 http://caniuse.com/#feat=flexbox

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.

Re: The Anti-Hero of CSS Layout – “display:table” (2014)

#19
post #14
post #12

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

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

`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.

Re: The Anti-Hero of CSS Layout – “display:table” (2014)

#20
post #2

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 -element for something which is not a quote.…

Largely because I'm relatively new to all of this and probably don't know better, but I've found success just using divs for all layout and doing it myself. Which is a smell to me, but I just can't help but find that every time I have consistent results and expected behaviour. Div and flexbox for everything. It actually reminds me of another smell I have with django: write my own serializers and views rather than usi…

In terms of results, responsiveness, and flexibility, doing it with a div (or some other block-level element) and flexbox is the best way to do it. In terms of standards and tabular data, doing it with a table is probably more correct, but I think the benefits of flexbox outweighs any concerns about that.
Post reply on HN