Live data from Hacker News

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

developers.google.com

211–220 of 280 posts

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

#211

Earlier quoted context omitted.

These things, while beneficial, don't owe their existence to CSS. Instead, introducing eg. CSS shapes or `content: ` (as two extreme examples) was the way of least resistance/guerilla tactics, as opposed to putting the functionality into SVG proper, or aligning the layout box model better with the DOM model, resp. Now what we're left with is a way overcomplicated mess for generations to clean up. There's a reason Moz…

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.

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

#212

Makes you wonder why HN won't budge with those tags in the source code. One day I hope to see "Table layouts are back with tags" and the HN programmers would have saved themselves so much work.

Does this affect your experience as a user?

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

#213

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.

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.

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

#214
post #173

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.

The syntax is pretty simple. The problem is all the available attributes and values. I don't see how lisp syntax would help.

[deleted]

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

#215

Earlier quoted context omitted.

Oh I do, I do... and I agree that many of the things CSS does for you today are vastly better than the ad-hoc solutions we had in the past (if you ever have to create an HTML email - and thankfully I am able to outsource all of that sort of work to someone who actually takes a perverse pleasure in it - that's always a nice reminder of how silly HTML and CSS were in the late '90s before CSS was actually broadly usable…

> But still... some of the syntax we have now, not to mention the sheer breadth of verbiage, is insane I had somehow missed that your gripe is with the syntax - I fully agree with you on that! CSS definitely feels kludgey, especially for larger/complex apps or sites. I now think of real CSS as a target that my build system generates as I mostly write in Sass or LESS. I find those superior to vanilla CSS in maintainab…

I couldn't go back to vanilla CSS. Even with just its basic nesting features, SCSS enables a much more modular, compartmentalized, and parsable format, with a clear view of the overall hierarchy via imports

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

#216

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 programmers to learn and are the most instantly powerful out of the box. Most dewey-eyed replacements for production layout systems that I've encountered quickly founder when they try to cover all the corner cases that a mature framework would need to support. It's shockingly common to just end up with a kind of crappy version of bespoke CSS. Maybe with better syntax. Definitely with fewer features.

Alternately, if you're really complaining about the fact that you define styles in one file and markup in the other...I dunno, seems fine to me. I've seen systems that try to do all of that in one file (you can do it in HTML if you want to). They're not very readable. Splitting the styling from the basic structure is not a "clean" split, but it does simplify things enough to make your files much easier to scan. Sure, it doesn't live up to the old, pure idea about separating content from styling, but...who cares?

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

#217

Earlier quoted context omitted.

> There's a reason Mozilla spent the better part of the decade to come up with a new web renderer. That had nothing to do with the fact that HTML and CSS are independent. Tables are way way more complicated than anything in CSS. In fact, tables are unspecified. This [1] is a work in progress draft and incomplete. You'll be forgiven if your eyes glaze over while reading it. [1]: https://dbaron.org/css/intrinsic/

This is not a tables-vs-CSS thing. Hey, I'm looking forward to servo and applaud Mozilla devs for it; but the reason they found it worthwile to invent an entire new programming language for implementing it certainly is telling about CSS's insane complexity.

GPU vendors invented an entirely new programming language for drawing triangles. Creating a new programming language to a solve a task doesn't mean that task is overly complex.

CSS has its problems (I'm the first to admit that), but on balance I think it's the best layout language that has been devised for documents.

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

#218
post #197

Earlier quoted context omitted.

Not the one you asked, and purely for historic reasons, but DSSSL, the precursor of XSLT and CSS, was Scheme: ; rule associated to document's element class (element (section header) (make paragraph font-family-name: "Helvetica" font-weight: 'bold font-posture: 'oblique (process-children) ) ) ; rule associated to a particular element uniquely identified with an id: (id ("ref34") (make paragraph font-family-name: "Helv…

And how is that making it better than CSS? It looks more complicated and still has to use all the same attributes.

For one thing, if the rest of the representation of the document (the HTML and script part) was in the same language, maybe the CSS could be condensed with macros, or otherwise procedurally generated on the client side, all in the same syntax.

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

#219
post #171

Earlier quoted context omitted.

Could you give an example of how such a Lisp-like syntax would look, to show the improvement?

Not the one you asked, and purely for historic reasons, but DSSSL, the precursor of XSLT and CSS, was Scheme: ; rule associated to document's element class (element (section header) (make paragraph font-family-name: "Helvetica" font-weight: 'bold font-posture: 'oblique (process-children) ) ) ; rule associated to a particular element uniquely identified with an id: (id ("ref34") (make paragraph font-family-name: "Helv…

Figures Schemers would put the colon on the wrong end just so that the property indicators wouldn't translate to Lisp keyword symbols.

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

#220

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.

I'm a fan on BEM and SASS, though. :)
Post reply on HN