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

WebKit Supports Nested CSS

webkit.org

Post reply on HN
Print view View original

91–100 of 183 posts

Re: WebKit Supports Nested CSS

#91

Post by iLoveOncall »

oliwarner wrote: post #89

It's great it's here, but isn't everyone and their dog who wants features like this using PostCSS, LESS or SASS? In a build environment that nearly makes this transparent. I use Vite and PostCSS and a bevy of linters, image processing tools, even for CSS-only projects because they're so fast and generally so good at what they do that it'd be silly not to. I used to hodge tools together with Makefiles but Vite in part…

This has benefits even if you use those pre-processors. One I have in mind is smaller CSS file sizes.

Re: WebKit Supports Nested CSS

#92

Post by [deleted] »

oliwarner wrote: post #89

It's great it's here, but isn't everyone and their dog who wants features like this using PostCSS, LESS or SASS? In a build environment that nearly makes this transparent. I use Vite and PostCSS and a bevy of linters, image processing tools, even for CSS-only projects because they're so fast and generally so good at what they do that it'd be silly not to. I used to hodge tools together with Makefiles but Vite in part…

[deleted]

Re: WebKit Supports Nested CSS

#94

Post by oliwarner »

iLoveOncall wrote: post #91
oliwarner wrote: post #89

It's great it's here, but isn't everyone and their dog who wants features like this using PostCSS, LESS or SASS? In a build environment that nearly makes this transparent. I use Vite and PostCSS and a bevy of linters, image processing tools, even for CSS-only projects because they're so fast and generally so good at what they do that it'd be silly not to. I used to hodge tools together with Makefiles but Vite in part…

This has benefits even if you use those pre-processors. One I have in mind is smaller CSS file sizes.

I can think of a very few, very extreme examples that I've worked on where that might be a registrable amount, but even then, you're only saving on duplicated parent classes/element which would have been taken care of by simple gzip compression.

There are [increasingly few] times when it's just nice to just write CSS and I guess unifying nesting will make that nicer, but I don't think there are tangible benefits over "flat" production output.

Re: WebKit Supports Nested CSS

#95

Post by lenkite »

esperent wrote: post #81
JimDabell wrote: post #65

Earlier quoted context omitted.

> When the number of nested selectors becomes too great it can become very difficult to reason about. This is a sign you need to decompose whatever design you are working on into smaller components. If you’re trying to write styles for a whole page at once, you’ll see this problem, but if you are working on small components, it’s very rare.

> decompose whatever design you are working on into smaller components I haven't followed modern CSS development much. Does it have a module system now?

Not precisely a module system, but you at-least get scoping if you use web-components where you can restrict CSS to the scope of the web component. (There are CSS module systems, but they are not covered by a standard and use JS libs)

The problem is that web-components need JS enabled, which really, really sucks. Why should a component that can perfectly render itself using plain HTML and CSS need to have associated JS declaring: "Hey! I am a web-component!". Declarative web components would have made adoption of web-components super-high , but alas, corporate interests are against this feature.

Re: WebKit Supports Nested CSS

#97

Post by dgb23 »

meerita wrote: post #96

That's a valuable addition, but it's unfortunate that it arrived late. These days, functional CSS http://minid.net/2019/04/07/the-css-utilitarian-methodology/ is gaining popularity due to its effectiveness in reducing the need for excessive nesting of classes and unwieldy CSS files.

Functional/atomic css is great. But there are many use cases for composing and refactoring them into aggregates. Nested css can help you for tgese cases.

Re: WebKit Supports Nested CSS

#98

Post by mock-possum »

emsixteen wrote: post #84
mock-possum wrote: post #51

man I can't wait to not need LESS/SCSS anymore. the less I need to compile/transpile before handing stuff off to the browser, the better in my book.

I don't understand this viewpoint, but I've seen it a lot so you're definitely not alone. A large part of what's useful about SASS are the mixins and functions, not just nesting - do you just not use those?

No no I do, I just don’t want to use a CSS pre processor to utilize them. I want them to be part of vanilla CSS, same as variables are now, same as nesting is now.

Re: WebKit Supports Nested CSS

#99

Post by Jaxan »

transfire wrote: post #55
culi wrote: post #21

Earlier quoted context omitted.

I generally agree and wince at anything deeply nested, but there's no question that the biggest benefit here by far will be pseudoclasses. Especially when you wanna do something to children elements based on a pseudoclass .page form border: 2px solid #223; border-radius: 0.15rem; & button { background-color: red; transition: background-color 0.15s ease; } &:hover button { background-color: blue; } } seems way cleaner…

Am I missing something… isn’t it just a simple substitution? .page form { border: 2px solid #223; border-radius: 0.15rem; } .page form button { background-color: red; transition: background-color 0.15s ease; } .page form:hover button { background-color: blue; }

That’s the point. Why should we be doing the trivial substitution if tools can do that for us!?

Re: WebKit Supports Nested CSS

#100

Post by bryanrasmussen »

ocimbote wrote: post #64
c-smile wrote: post #41

Nested rules is just a syntax sugar. In Sciter, 10 years ago, I came up with style sets: @set Main { :root { ... } // root element that has this set applied .bar { ... } article { ... } :root > article { ... } } main { style-set: Main; } // main element with the set applied This solution solves two problems: 1. Modular/componentized style definition - same goal as in nesting styles, but without introduction of new sy…

If syntactic sugar was really just sugar, JS would have sticked to callback functions, and we’d still be inventing abstractions to make our lives easier. Syntactic sugar, sometimes, is the promise of sunnier mornings and that matters.

unpopular opinion I'm sure from reading everyone here, but to me nesting css is syntactic poison - or maybe syntactic sucrose or something that gives you cancer you use too much of it?

Anyway programmers given nesting just do it all the time which ends up leading to stuff like

article.news section.preamble h1 and probably a few other selectors after that all nested giving you a wonderful high priority for your style and possible collisions.

Then the same guys who made the problem can't figure out the problem so they figure some highlevel nesting is the solution so there won't be any collisions and overriding of styles.

Post reply on HN