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

251–260 of 280 posts

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

#251

Post by jdmichal »

debaserab2 wrote: post #248
jdmichal wrote: post #231

Earlier quoted context omitted.

The DOM is more than the proposed content map, because it also creates structure. I think the proposed idea is to basically create a structure without any content, then apply the content into that structure. The current split is CSS is presentation while HTML is content + structure. Unless I'm misunderstanding, this proposal would separate content and structure. I'm not sure where presentation would go; you could cer…

I'd be curious if there are any existing example implementations that you think demonstrate this - I'm having a hard time wrapping my head around how flattening the structure would make things better. A tree node structure for mapping content seems like it'd be the most efficient in all the ways I can imagine it.

I suppose I'm thinking of something like ASP.NET `ContentPlaceHolder`, where you create some layout and identify holes into which the content will be placed. Except that, unlike ASP.NET and HTML, only layout elements would be permitted? This would likely be an entirely new language -- thinking of it like HTML except without text doesn't really work. Think of it more like defining panes on the screen, and the content (like HTML) is injected into those defined panes.

How the panes are laid out could be accomplished through any number of methods. Absolute, flow, flex, grid, constraint solving... Or even parent panes using different methods for their sub-panes!

The point isn't to flatten the layout. The layout can be as complex as desired. The point is to remove content from the layout; a named mapping is just an easy way to associate content to layout panes for injection.

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

#252

Post by astine »

T-hawk wrote: post #245
astine wrote: post #240

Earlier quoted context omitted.

Ugh, no. Layout is one way to express those relationships, but those relationships already exist in the HTML. This is important because different layouts can express the same relationship. I can put a caption below, above, beside, or over a photo and have viewers understand what is meant but which option is appropriate can depend on a number of factors that have nothing to do with the actual content or relationship b…

Sure, it's dead simple for one particular semantic case already with its own specific definition in HTML. But you cherry-picked that from my examples. HTML doesn't express semantics for comment-replies or sports scores or so on. It has a generic notion of a hierarchical tree, to which CSS can apply layout (like indentation for HN comments), but that's not quite the same thing. Nothing in the HTML-CSS stack expresses…

I'm going to cherry-pick your examples again and point out that sports scores actually an ideal use case for actual tables because they are generally actual tabular data. But frankly I just disagree when you say that a hierarchical tree isn't a mechanism for expressing general-purpose semantic relationships, when it's at least as good as spatial positioning on a page. In fact, I can use classes with semantic names which make my meaning perfectly clear to anyone reading the source. It might be invisible with a bad or default stylesheet, but that's a relatively easily resolved problem.

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

#253

Post by naasking »

monk_e_boy wrote: post #130
dom0 wrote: post #75

Earlier quoted context omitted.

Most divsoup-layouts are not semantic at all, either.

Exactly this. How are DIVs more semantic than TABLE? And who is reading the source? Your developers and a web spider. The web spider doesn't care (I wrote one and getting it to parse DIV content and TABLE content wasn't much effort) As far as I am aware no spider is looking at the DIV and gathering semantic information from it. Sure, it may look at the TABLE and initially assume it has tabular data in it, but a tiny…

Screen readers and spiders do look at tables as semantic content though. Tables are simply the wrong idea.

That said, CSS layout should have been based on tables/grids from the get go, ie. specify a set of blocks as rows and cells, with colspan and rowspan. It took way too long to get to this point.

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

#254

Post by kagamine »

shadowfiend wrote: post #124
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…

Lifted from there, but with broken indentation :) In fact with correct indentation, you see that this goes down 4 levels (instead of the seeming 14 the current rendering seems to indicate). That's significantly better, and once you get used to the structures of lists it's actually relatively straightforward to understand a list like that. Moreover, it's trivial for a computer to understand a list like that as nested…

Absolutely, but try researching a family tree and then implementing it using that model and see how quickly you get lost in the nested list structure. The, as I said in another comment, try adding a child born after you started the lists, ie, before the first UL. Then add a divorce and a new spouse and see how easy that is to logically display the relationship.

To illustrate how HTML so ill suited to this structure, I had another look at the problem and found Treant, because yes, the easiest to do this on the Web and maintain it is to write an entire API.

http://fperucic.github.io/treant-js/

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

#255

Post by swerner »

xaduha wrote: post #227
swerner wrote: post #100

Earlier quoted context omitted.

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?

This is a joke, albeit with many web pages I get the suspicion that they'd indeed be better off serving a PNG or PDF file instead. Not to mention that PNG renders much, much faster than javascript orgies.

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

#256

Post by xaduha »

paulddraper wrote: post #182
swerner wrote: post #100

Earlier quoted context omitted.

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.

Wrap that sucker in some HTML with tags and you're golden.

Can't name any site that uses still other than http://www.teamfortress.com

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

#257

Post by iamben »

School-Cotton wrote: post #132
iamben wrote: post #129

Earlier quoted context omitted.

Nothing. But tables are for tabular data. Laying out a page using a table to divide it up and make it look pretty (or in lots of cases, lay it out so it performs some kind of sales based task) doesn't make much sense. Hence the preferred CSS route, even if the markup is just as verbose (as mentioned in this thread). Web apps aside [sigh], if one was to disable CSS (and thus all the blocks making it look pretty), the…

But why is that beneficial?

Along with what the others have mentioned (connection, screen readers), it's good for your SEO as well.

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

#259

Post by GeneralMaximus »

at-fates-hands wrote: post #238
GeneralMaximus wrote: post #85

Earlier quoted context omitted.

If we're lucky, we might get exactly that with Houdini. It's a proposed spec that -- if implemented -- will allow programmatic control of the browser's styling and layout process. Check it: https://www.smashingmagazine.com/2016/03/houdini-maybe-the-m... Here's the GitHub repo: https://github.com/w3c/css-houdini-drafts

Are we finally at the tipping point where everything you build, will be built with JS from soup to nuts? Houdini looks like its trying to do just that.

> Are we finally at the tipping point where everything you build, will be built with JS from soup to nuts?

That doesn't sound implausible. In fact, it sounds like a great idea. As long as performance and security don't suffer, more and more browser internals should be opened up to JS developers so that we don't have to wait for all browsers vendors to implement specific features before we get to use them.

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

#260

Post by tannhaeuser »

jordanlev wrote: post #208
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…

You say "css fans" like we have a choice in the matter :) I am a fan of building websites, and css is the only way to achieve that. Yeah it sucks, but it's all we got. Grid spec solves a LOT of problems so even if the syntax is ugly, it's existence in the world is beautiful.

Sorry I didn't mean it to sound like that. I'm saying this to myself just as to everyone else (I'm using CSS all the time). The post was more an expression of dissatisfaction of CSS's ad-hoc nature, and in particular of how we've come to rationalize this HTML/CSS/JS trifecta after the fact as a sound and dogmatic edifice, when in reality it is just the result a 10 days code jam in 1996.
Post reply on HN