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

CSS Grid – Table layout is back. Be there and be square

developers.google.com

Post reply on HN
Print view View original

221–230 of 280 posts

Re: CSS Grid – Table layout is back. Be there and be square

#221

Post by metamet »

yoz-y wrote: post #107
kagamine wrote: post #78

Earlier quoted context omitted.

That's a problem for sure but last week I looked into creating a family tree with the basics of HTML and CSS and the following nested lists seems to be the best solution according to forums. Now, try to add into these nested lists some siblings(the people kind) and some new branches as you discover people in census reports from 100 years ago. Now add in a newborn. Is this the best we can do? (apologies, but I haven't…

How could this be done better though? Unless using a DSL it seems to me that this problem is quite complex to begin with.

> How could this be done better though?

      
        
          Parent

Re: CSS Grid – Table layout is back. Be there and be square

#222

Post by scelerat »

Symbiote wrote: post #205
emodendroket wrote: post #167

Earlier quoted context omitted.

I mean, it is semantic, if you want a table. One of the most baffling things to me is people trying to use not-tables when they're literally trying to display tabular data.

I laughed when I had to make a minor change to an old web application, and found our tabular, scientific data was being displayed in a series of DIV and SPAN elements, with the CSS table styles applied to them. I changed it to a real TABLE, since that's far more accessible -- most users can cut and paste into their spreadsheet, and a screen reader might give options to avoid reading out all the data. Another time, a…

To be perfectly semantically correct (which he was no doubt attempting, as I is a purely visual/appearance tag, and EM connotes some meaning), he should have used

Re: CSS Grid – Table layout is back. Be there and be square

#223

Post by j_r_f »

emodendroket wrote: post #167
leppr wrote: post #48

Earlier quoted context omitted.

It's neither flexible nor semantic. Flexibility is what allowed webpages to be "responsive" before media-queries even existed, and semantics is what allows accessibility, search engines, and other html parsing tools ("readability" in Firefox and Safari, ...) to function better. The only advantage it has is that it's old and predictable. That's why it's still used to format emails for instance, it's reliable and works…

I mean, it is semantic, if you want a table. One of the most baffling things to me is people trying to use not-tables when they're literally trying to display tabular data.

Sometimes it's worth it. A real pain with tables is that you can't have it be positioned relatively. So if you want to display an absolutely positioned tooltip next to a row it becomes a gigantic pain and i'd argue impossible — or extremely hacky — without using JS.

Re: CSS Grid – Table layout is back. Be there and be square

#224

Post by SippinLean »

marcosdumay wrote: post #143
tbarbugli wrote: post #106

Earlier quoted context omitted.

? Edit: this is meant to be ironic

You meant it ironically, but people did write things like that. (And it was the only way to get the intended result by the time.)

Did and do, this very site uses nested

Re: CSS Grid – Table layout is back. Be there and be square

#225

Post by nitwit005 »

mullsork wrote: post #42
TurboHaskal wrote: post #31

I still use plain old tables in 2017. Number of unhappy customers: 0

Except anyone with accessibility requirements, no? As far as I know tables are horrible for anyone with a screen reader. Can you annotate tables somehow to work for accessibility purposes?

It looks like you can just mark it as being for presentation:

Although the screen readers seem to do a decent job of doing this automatically.

Re: CSS Grid – Table layout is back. Be there and be square

#226

Post by xaduha »

milesrout wrote: post #82
mhd wrote: post #58

Earlier quoted context omitted.

PostScript is a programming language.

I don't see how that's a benefit.

Exactly. Also happens when people talk about would-be DSL that they made on top of existing language and mention that you can always fallback to using it. But that's the whole point of the domain-specific language that it is not a generic purpose one!

Sometimes less is more and constraints are good, there are things that you shouldn't shoehorn.

Re: CSS Grid – Table layout is back. Be there and be square

#227

Post by xaduha »

swerner wrote: post #100
amiga-workbench wrote: post #51

Earlier quoted context omitted.

I don't know if developers even care about semantic markup anymore, just have your 5 meg of JavaScript squirt out a bundle of divs and to hell with accessibility.

Just render a png file, server side. The only way to ensure pixel perfect layout, and it's even going to use less bandwidth than most JS frameworks these days.

> Just render a png file, server side.

Know of any examples of that in practice or is this just a joke?

Re: CSS Grid – Table layout is back. Be there and be square

#228

Post by tannhaeuser »

ender7 wrote: post #216
tannhaeuser wrote: post #119

I don't know how to say it politely but what has been achieved by using ad-hoc syntax such as this gem (and similar complex CSS syntax): display: grid; grid-template-rows: 150px [nav-start] auto 100px [nav-end]; grid-template-columns: [header-start] minmax(200px, 3fr) 9fr [header-end]; CSS fans for some reason seem to think that its somehow better to have rendering/presentational properties in an ad-hoc language. Ori…

It's very easy to declaim one or another layout system as verbose or inconsistent. Can you suggest a mainstream layout system that offers this feature in a better manner? I've used a lot of different layout frameworks over the years. Constraint systems are neat but hard to scale. All-code layout definitions are hard to read and reason about. Markup-level layout systems have their issues, but are easier for new progra…

Good points, and I definitely don't have an answer re: best layout engine. But my critique wasn't aiming that high and was merely about placing CSS syntax outside markup.

CSS design genesis seems to be "ok we have this and that HTML presentation attribute; let's put it in an entirely new item-value format and separate HTML attributes/CSS properties syntactically".

From this arbitrary decision in language design the idea developed that markup attributes are part of the "semantic" content of a document, and not for styling, when, to the contrary, markup attributes were specifically designed for styling and other properties.

As a consequence, CSS has numerous redundancies, asymmetries, and absurdities such as CSS shapes, SVG properties you can style with CSS, the "content:" property, dogmatic and implementation-driven limitations for using presentational attributes on elements, etc.

Re: CSS Grid – Table layout is back. Be there and be square

#229

Post by T-hawk »

ender7 wrote: post #216
tannhaeuser wrote: post #119

I don't know how to say it politely but what has been achieved by using ad-hoc syntax such as this gem (and similar complex CSS syntax): display: grid; grid-template-rows: 150px [nav-start] auto 100px [nav-end]; grid-template-columns: [header-start] minmax(200px, 3fr) 9fr [header-end]; CSS fans for some reason seem to think that its somehow better to have rendering/presentational properties in an ad-hoc language. Ori…

It's very easy to declaim one or another layout system as verbose or inconsistent. Can you suggest a mainstream layout system that offers this feature in a better manner? I've used a lot of different layout frameworks over the years. Constraint systems are neat but hard to scale. All-code layout definitions are hard to read and reason about. Markup-level layout systems have their issues, but are easier for new progra…

Here's the fundamental problem with separating styling from content: styling is content.

Layout matters. Layout carries semantics. Right here on HN is an example, where the comment reply chain is indicated with indentation. The meaning of a comment such as "I disagree" varies depending on what it is replying to and therefore where it is in the layout.

Other examples where layout is content: Captions for photos. An online store where each price describes the cost of whatever item it is next to. Sports box scores and other statistical presentations. Interviews in question-and-answer format where the layout indicates who is speaking.

That's why we've gotten our layout engines so mixed up with our content and markup, because layout is content. How would one devise an abstraction for layout for all of these? You would need to express the semantic relationships within the data, like "comment-replied-to" and "photo-with-caption" and so on. That sounds tantamount to a full implication of natural language processing.

Re: CSS Grid – Table layout is back. Be there and be square

#230

Post by romaniv »

tannhaeuser wrote: post #119

I don't know how to say it politely but what has been achieved by using ad-hoc syntax such as this gem (and similar complex CSS syntax): display: grid; grid-template-rows: 150px [nav-start] auto 100px [nav-end]; grid-template-columns: [header-start] minmax(200px, 3fr) 9fr [header-end]; CSS fans for some reason seem to think that its somehow better to have rendering/presentational properties in an ad-hoc language. Ori…

IMO, HTML/CSS have always been missing a middle layer. It really should be:

- HTML for pure information - Something else (template/view?) for layout and (possibly) forms - CSS for styling in terms of fonts, colors, etc.

This would easily handle layouts, but it would also have some NLS-like capabilities where you could switch from one way of presenting information to another without changing the actual docment.

Post reply on HN