Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

colintoh.com

Post reply on HN
Print view View original

41–50 of 60 posts

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

#41

Post by c-smile »

robin_reala wrote: post #39
c-smile wrote: post #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(…

Not that I diagree with your premise, but in this particular example the WHATWG HTML Living Standard now allows containing divs around dt/dd pairings[1] and browers support this fine. [1] https://html.spec.whatwg.org/multipage/semantics.html#the-dl...

That requires change of existing markup and somehow its semantic changes too, right?

Yet this is not "resolution friendly".

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

#42

Post by c-smile »

olavk wrote: post #33
c-smile wrote: post #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(…

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…

> 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 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 in tables).

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

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

#43

Post by 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 years ago.

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

#44

Post by olavk »

c-smile wrote: post #40
olavk wrote: post #35

Earlier quoted context omitted.

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

Consider following markup: some text first second 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: some text first second That's impossible in modern CSS without redefining `display` in childre…

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.

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

#45

Post by c-smile »

twhb wrote: post #22
c-smile wrote: post #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(…

It's already a good idea to add elements where logical, even when unnecessary, to aid styling, scripts, coder comprehension, and sometimes automated comprehension, and to reduce likelihood it must be edited later. One could argue that rows always form logical units - certainly in the above example - and thus should always be wrapped. WHATWG does permit wrapping dt-dd groups in divs.

That "good idea" has a name "tag soup".

But even you can add some non-semantic DOM elements...

What if you have

    
      first
      second
      third
And you want to replace them in two,three,etc. aligned columns (depending on view size), like these:

   @media handheld {
      ul { flow:vertical; }
   } 

   @media ... {
      ul { flow:row(li,li); } // two columns
   } 

   @media ... {
      ul { flow:row(li,li,li); } // three columns
   }

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

#46

Post by robin_reala »

c-smile wrote: post #41
robin_reala wrote: post #39

Earlier quoted context omitted.

Not that I diagree with your premise, but in this particular example the WHATWG HTML Living Standard now allows containing divs around dt/dd pairings[1] and browers support this fine. [1] https://html.spec.whatwg.org/multipage/semantics.html#the-dl...

That requires change of existing markup and somehow its semantic changes too, right? Yet this is not "resolution friendly".

Semantics is defined by the specification, so in this case no. But yes, a change of the markup.

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

#47

Post by c-smile »

robin_reala wrote: post #46
c-smile wrote: post #41

Earlier quoted context omitted.

That requires change of existing markup and somehow its semantic changes too, right? Yet this is not "resolution friendly".

Semantics is defined by the specification, so in this case no. But yes, a change of the markup.

What if space allows and I will want to have four columns table:

    dl { flow: row(dt,dd,dt,dd); }
Changing markup structure is not a good idea if to consider that the same markup shall be used on different medias.

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

#48

Post by c-smile »

olavk wrote: post #44
c-smile wrote: post #40

Earlier quoted context omitted.

Consider following markup: some text first second 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: some text first second That's impossible in modern CSS without redefining `display` in childre…

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.

"a newer CSS proposal"

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

15 years ago, Carl!

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

#49

Post by luhn »

olavk wrote: 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.…

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

It's always bugged me to see the great lengths people will go to to avoid using an HTML table to create things like a calendar. A calendar is a table! Save yourself the effort and use . It's not only easier, it's semantically correct as well.

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

#50

Post by 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.

Post reply on HN