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

231–240 of 280 posts

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

#231

Post by jdmichal »

debaserab2 wrote: post #211
diamondlovesyou wrote: post #189

Earlier quoted context omitted.

I agree. Most of the HTML I write is to create structure for CSS to use. For example, a `div` is a container, but we put it on the content side. What would have been better would be a flat map identifier -> binary (or string or whatever, your choice) as the content, and then "CSS" (quotes because it wouldn't be the CSS we know now) would declare the layout/look and would read the content map for insertion into placeh…

The content map is the dom, no? I can't see what you described ending up any less complex than what we have today.

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 certainly make a case for it being grouped with either.

There's also plenty of questions around what's content and what's structure and what's presentation. For instance, a section heading is potentially all three. I personally would probably go for grouping presentation with the content, and call structure "layout" to disambiguate it. A section heading is maybe structure, but it's definitely not layout.

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

#232

Post by [deleted] »

lenkite wrote: post #147
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…

CSS would have been so simple if it had just adopted a plain LISP syntax. It is so difficult to memorise all the special and inconsistent syntax for every new thingamajig that browser vendors choose to introduce. Need to painfully look up a CSS reference if you haven't used that special rule in more than a week as it just doesn't seem to get retained (at-least for me) into long term memory.

[deleted]

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

#233

Post by jdmichal »

kazinator wrote: post #213
lenkite wrote: post #147

Earlier quoted context omitted.

CSS would have been so simple if it had just adopted a plain LISP syntax. It is so difficult to memorise all the special and inconsistent syntax for every new thingamajig that browser vendors choose to introduce. Need to painfully look up a CSS reference if you haven't used that special rule in more than a week as it just doesn't seem to get retained (at-least for me) into long term memory.

Some sort of uniform, same syntax for representing all of HTML, CSS and the browser-side scripting language would have been a good start instead of this hodge podge of different notations clumsily embedded in each other. Lisp for just CSS with all else same: lukewarm idea.

CSS would be nothing more than built-in functions to traverse nodes and change attributes. The latter of which would have already existed by virtue of having a programmatic interface with the DOM structure, and the former would have been invented in some form to build on whatever primitives existed, a la jQuery.

Kinda makes me wish I lived in that alternate universe.

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

#234

Post by svachalek »

romaniv wrote: post #230
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.

This was the role that XSL tried to fill but it never caught on. Part of the reason is that it's still very dependent on what information is in the source document; if it's not there you can't lay it out, and if you don't need it then it was a big waste of database time. This ends up reversing the dependency, so the contents of your "pure information" layer end up depending on what your "layout" layer needs, and in the end the difference between the layers is only nominal.

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

#235

Post by svachalek »

laszlokorte wrote: post #26
nailer wrote: post #7

> Short of taking care of sizing the elements yourself, sadly, you can't have both a vertical and horizontal rhythm by just using flexbox alone. Accompanied by https://developers.google.com/web/updates/images/2017/01/css... I'm pretty familiar with Flex but I simply don't understand and the diagram doesn't help. What does 'rhythm' mean in terms of layout? Taking a guess (which I shouldn't be), I can make https://deve…

As I understand this image: https://developers.google.com/web/updates/images/2017/01/css... it shows that you can not use flexbox to force the both upper blocks being the same height.

Right. With flex you can create elements whose height is equivalent to the elements to the left and right, or whose width is equivalent to the elements above and below, but not both at the same time.

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

#236

Post by SimeVidas »

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…

What would make more sense?

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

#237

Post by at-fates-hands »

usaphp wrote: post #195
njharman wrote: post #191

Earlier quoted context omitted.

Dude! I had so forgot about making those 1px by however long/high images, over and over as size of things changed. CSS/HTML is a complicated mess. But anyone who thinks it used to be better needs to take off the rose tint glasses.

Remember back in the days you had to use rounded corners images and JS hacks to get a result that border-radius does today. Nightmares.

The ironic thing is now instead of having to load 40 images, you're loading 40 different JS libraries to get the job done.

I'm still not sure if we're better off yet. . . .

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

#238

Post by at-fates-hands »

GeneralMaximus wrote: post #85
mhd wrote: post #19

If we all had something like Display Postscript, this layout thingamajig would be delegated to libraries, and we wouldn't have to ask the browser deities to bestow new gifts upon us. Good adaptive layout would be closer to a new version of jquery and less Windows XP Service Pack 51.0.2b. (We also would have more sites that looked liked late 90s Flash, but then again, we're moving that direction anyway, just with more…

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.

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

#239

Post by random28345 »

T-hawk wrote: post #229
ender7 wrote: post #216

Earlier quoted context omitted.

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

> Right here on HN is an example, where the comment reply chain is indicated with indentation.

    
      T-hawk
      Right here on HN is an example, where the comment reply chain is indicated with indentation.
      
        
          random28345
          HTML is a tree of element nodes, the identity of the post being replied to can be determined by 
          the position of element in the tree
----------------------

    .replies {
      margin-left: 2em;
    }

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

#240

Post by astine »

T-hawk wrote: post #229
ender7 wrote: post #216

Earlier quoted context omitted.

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

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 being expressed. Blind people read the Web too. Having multiple layouts for different kinds and sizes of device is super useful. Being able to attach a caption to photo in HTML and express the exact spatial relationship later through CSS is much more versatile than hard baking layout into the document.

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

No you wouldn't and no it is not. It's dead simple:

    
        
        Caption goes here
Post reply on HN