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

41–50 of 183 posts

Re: WebKit Supports Nested CSS

#41

Post by c-smile »

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 syntax constructs.

2. Reduces CSS resolution load. Rules inside the set are scanned only for DOM children that have style set defined.

3. DOM element may have @styleset="url#name" attribute defined - used in components (Web alike components and React alike components)

Re: WebKit Supports Nested CSS

#42

Post by orbital223 »

kijin wrote: post #17

:is(article) & That looks hacky at best. The excuse of parsing performance is responsible for so much weird syntax in web standards today. The standards are literally being dragged around by browser vendors' priorities. I wish they would do it the other way around for once: come up with the cleanest, easiest-for-humans syntax as possible, and tell browser vendors to fix their damn engines. Perhaps this will lead to t…

> come up with the cleanest, easiest-for-humans syntax as possible, and tell browser vendors to fix their damn engines

W3C has zero leverage over the browser vendors. If they tried to do this the end result would be the same thing that happened to XHTML: the browser vendors would tell them to pound sand and announce that the de facto CSS standard would now be maintained by the WHATWG.

Re: WebKit Supports Nested CSS

#43

Post by jakelazaroff »

cphoover wrote: post #32

Maybe I am an outlier... but I really don't like nested style documents like those founds with SASS, LESS, PostCSS. When the number of nested selectors becomes too great it can become very difficult to reason about. I would never use this without some kind of lint rule enforcing a maximum depth of selector nesting. I agree with the other commenters ITT taking the position flat CSS looks cleaner than nested documents.

I agree: even when I use preprocessors, I rarely nest “normal” selectors. The real win is nesting pseudoselectors (:hover, :focus, etc) and media queries.

Re: WebKit Supports Nested CSS

#44

Post by pier25 »

rezonant wrote: post #36
cphoover wrote: post #32

Maybe I am an outlier... but I really don't like nested style documents like those founds with SASS, LESS, PostCSS. When the number of nested selectors becomes too great it can become very difficult to reason about. I would never use this without some kind of lint rule enforcing a maximum depth of selector nesting. I agree with the other commenters ITT taking the position flat CSS looks cleaner than nested documents.

The difficulty you mention is definitely an issue, but the insane repetition required for even a modestly complex piece of UI when using "flat" CSS is worse, in my opinion. I suppose there might even be a slight efficiency gain over the wire once Sass outputs nested CSS by default.

I wrote flat CSS for many years and yeah it's a lot of work but also I find it becomes more difficult to parse visually.

Like when writing HTML or regular code, I find indentation helps me parse and navigate the structure very easily.

There are cases with complex components where it can become a bit complex, but it's trivial to split the tree in multiple parts to reduce the indentation.

Re: WebKit Supports Nested CSS

#45

Post by mkhalil »

I am supportive of this. Ofc, parent selector would still be nice, but I understand the problems solving that performantly.

As a highlight, Nested CSS doesn't support nested selectors if they both begin with letters, so the "&" is used as divider.

I highly recommend web-dev's check out the last section of the article*: https://webkit.org/blog/13813/try-css-nesting-today-in-safar...

[*: even though, IMO, in this instance it seems like a hack; nesting CSS styles, while the HTML is nested in the opposite direction seems pretty counterintuitive. but having the tool in your toolbox could be useful for other things.]

Re: WebKit Supports Nested CSS

#47

Post by rofrol »

throwaway284534 wrote: post #29
frosted-flakes wrote: post #22

Earlier quoted context omitted.

What do you use now? I'm currently using Create-React-App for one of my projects and some parts of it are really frustrating. For example, you can't create a Web Worker script without ejecting, or using some tool that intercepts and alters the CRA Webpack configuration. Should I just bite the bullet and figure out Webpack (or another bundler) from the basics? I feel like that will be inevitable at some point anyway.

IMO, ESBuild is the best option these days. It’s not as magic or batteries included as Webpack, but there’s very little kept secret from you during the compilation process. It’s fast too! Another tricky alternative is to just use TypeScript’s compiler. Combined with the new import maps spec, you can target most modern browsers and skip bundling all together.

Safari supports import maps in TP https://caniuse.com/import-maps

Re: WebKit Supports Nested CSS

#49

Post by TekMol »

I'm losing track of what CSS can do.

Do we have inheritance already?

Pseudocode of what I mean:

    .info {
        font-size: 8px;
    }

    .news extends .info {
        color: black;
    }
So news are displayed in an 8px black font.

Re: WebKit Supports Nested CSS

#50

Post by kijin »

spankalee wrote: post #40
kijin wrote: post #17

:is(article) & That looks hacky at best. The excuse of parsing performance is responsible for so much weird syntax in web standards today. The standards are literally being dragged around by browser vendors' priorities. I wish they would do it the other way around for once: come up with the cleanest, easiest-for-humans syntax as possible, and tell browser vendors to fix their damn engines. Perhaps this will lead to t…

> tell browser vendors to fix their damn engines Parsing performance of the type they're talking about is an algorithmic fact, not an implementation problem. Your suggestion is like telling engineers to fix the laws of physics.

The fact that the article raises the possibility of this limitation being removed in the near future means that it's not a law of physics, only a matter of finding a better algorithm.

Even if it were a law of physics, engineers can often circumvent laws of physics using smart caching and other tricks.

We've been waiting for this feature for decades already. It would have been better if they'd just invested a couple of more years to come up with a better parsing algorithm before standardizing a halfway implementation.

Post reply on HN