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

Help choose the syntax for CSS Nesting

webkit.org

Post reply on HN
Print view View original

41–50 of 170 posts

Re: Help choose the syntax for CSS Nesting

#41

Post by philliphaydon »

spankalee wrote: post #10
gorkish wrote: post #9

We want it to work the way Sass works. FFS make it happen and stop it with all this pedantry.

Did you read the third paragraph in the article?

It does not matter if the browser can’t do it. Make it do it.

There’s no point in supporting nesting if the solution is worse than the options we have right now.

The vast majority of people would rather stick with preprocessors than deal with shit syntax.

If they implement a shitty syntax because of browser limitations they don’t want to fix. People will just use pre processors.

So it’s not about reading or not reading the article. It’s the fact that the options are shit and unless they do syntax similar to what we do now they should abandon trying to support nesting.

Re: Help choose the syntax for CSS Nesting

#42

Post by claytongulick »

Sesse__ wrote: post #32
claytongulick wrote: post #29

I like option 3 the best, but what I'd really prefer would be block-scoped css blocks that could optionally be scoped just to children of the parent tag. I know this is why we have shadow dom, but in practice I feel like the shadow dom has caused more problems than it solved. Now we have a bunch of ::part things being added to make up for the problems, but it's still very difficult to work with. I'd love to have the…

Have you looked into @scope?

I haven't!

I found this [1] which basically has everything I want, but apparently it's been deprecated, which makes me sad.

Searching, I found [2], is that what you're referring to? It looks like it'll do what I'm after, if a bit less gracefully. Exciting though!

[1] https://css-tricks.com/saving-the-day-with-scoped-css/

[2] https://drafts.csswg.org/css-cascade-6/#scope-atrule

Re: Help choose the syntax for CSS Nesting

#43

Post by TrianguloY »

toomanydoubts wrote: post #24
spankalee wrote: post #10

Earlier quoted context omitted.

Did you read the third paragraph in the article?

I think the question that's not answered clearly is: why can Sass parse it, but browsers can't? It says: "If they see a sequence like element:pseudo, they’ll parse the entire style rule as if it were a property: value declaration.", but why can't the parser be modified to work like Sass parser? Maybe it's obvious for someone who has deep parser knowledge, but for someone who only has a superficial knowledge, this is…

I may be wrong, but I think it's a matter of complexity and speed. An efficient parser knows exactly what it is reading just by checking the next following word (token) and can act before it even reads the whole thing. Sass uses an "infinite lookahead" algorithm that makes it way slower (maybe doesn't matter for 1 file, it does for hundreds). With sass the parsing is made only when compiling the app, so it can afford the extra processing. On browsers, specially mobile, it can become a problem if you need to do it on all css of all pages.

An example that I think it's easy to understand: suppose you are reading a csv string of numbers that can be in base 10 or base 2.

Option a is something like "32, 101b, 101" (aka binary numbers have a "b" suffix, decimal numbers don't)

Option b is the same but the "b" is a prefix "32, b101, 101"

Now think that you can only "see" one character at a time, so you see "3", then "2", then "," and so on. Which of the two options is more efficient to parse?

The answer is option b. With option a you could read a sequence of millions of 1/0 digits but you don't know if it's binary or decimal until you read the final "b" or a "," (or end of file) so you can't do anything but remember all the digits until the end, when you can finally do something with the number. With option b you know in advance if it's going to be decimal or integer (whether you receive a "b" or directly a digit) so you can do all the optimizations right away before even start reading the number!

It's not a matter of whether it can be done or not (of course it can) but the complexity and slowness it can become.

Re: Help choose the syntax for CSS Nesting

#44

Post by gaganyaan »

alwillis wrote: post #33

So far, most of the responses are pretty underwhelming. It's like that exercise middle school teachers sometimes do. They had out a worksheet where the directions tells the students to put their pencil down and do nothing. The rest of the worksheet is a series of questions or whatever. 80% of the students don't read the directions and start filling out the worksheet while the 20% who did read them are just sitting th…

This is more vitriol than necessary. The comment you linked to says the bad syntax choices presented in the article would allow for an easier parser implementation, but doesn't really expand on that or give any numbers. If someone thinks that the better syntax is worth a likely imperceptible increase in parsing time, that's hardly worth this harsh comment.

Re: Help choose the syntax for CSS Nesting

#45

Post by LudwigNagasena »

> Everyone wishes CSS nesting could use the same kind of simple syntax that Sass does. That’s impossible, however, because of the way browser parsing engines work.

I may be in a minority, but I think that what-you-write-is-what-your-browser-parses should be ditched as a norm. There should simply be an efficient (binary) format that is treated as an irrelevant implementation detail.

What is even the problem? People use preprocessors, poly-fills, hot-reloading, etc anyway. It isn't 1990s.

Re: Help choose the syntax for CSS Nesting

#46

Post by alwillis »

philliphaydon wrote: post #37
alwillis wrote: post #33

So far, most of the responses are pretty underwhelming. It's like that exercise middle school teachers sometimes do. They had out a worksheet where the directions tells the students to put their pencil down and do nothing. The rest of the worksheet is a series of questions or whatever. 80% of the students don't read the directions and start filling out the worksheet while the 20% who did read them are just sitting th…

I read the whole thing. And I don’t care if it doesn’t work or what excuses they make. If it’s not gonna be similar to any existing implementation for doing css then don’t bother doing it. The last thing we need is a shit version of nesting. The syntax we have now is good, it’s what we know, it works. There’s no need for stupid filler syntax to work around scenarios. I.e prefixing with @nest.

> There’s no need for stupid filler syntax to work around scenarios. I.e prefixing with @nest.

Respectfully, we already have @supports, @keyframe, @font-face and several others. Is it really that big a deal?

Re: Help choose the syntax for CSS Nesting

#47

Post by joeydi »

Sesse__ wrote: post #11
slinger wrote: post #5

> Everyone wishes CSS nesting could use the same kind of simple syntax that Sass does. That’s impossible, however, because of the way browser parsing engines work. I wish browser vendors could work around this limitation and stick to Sass syntax. IMHO all of those options seems strange and make it difficult to read.

> I wish browser vendors could work around this limitation and stick to Sass syntax. FWIW, it is not a limitation, it's a conscious choice. If you want to accept arbitrary selectors in option 3, you'll need unlimited lookahead, which limits the types of parser algorithms you can use, which means that _all CSS_ (not just CSS using nesting, every single web page out there) will be slower to parse, which means the web w…

I agree that it's not really worth it, but the answer is not to choose a worse option. The answer is the just not implement it.

These options are bad, and CSS does not need this.

Re: Help choose the syntax for CSS Nesting

#48

Post by alwillis »

janitor61 wrote: post #28

I'd say they should avoid bloating CSS, keep Sass style and just use type='text/sass' or type='text/css-nested' in the style tag, but it seems that attribute is depreciated... why is that?

The type attribute is not deprecated… but of course, no browser supports anything like
And certainly it breaks compatibility with older browsers which won't know what to do with it.

Re: Help choose the syntax for CSS Nesting

#49

Post by rtsil »

somishere wrote: post #13
Sesse__ wrote: post #11

Earlier quoted context omitted.

> I wish browser vendors could work around this limitation and stick to Sass syntax. FWIW, it is not a limitation, it's a conscious choice. If you want to accept arbitrary selectors in option 3, you'll need unlimited lookahead, which limits the types of parser algorithms you can use, which means that _all CSS_ (not just CSS using nesting, every single web page out there) will be slower to parse, which means the web w…

Possibly a stupid question. But is there a reason you couldn't include 2 engines? And require e.g. a doctype assertion?

Option 5 already does this by prefixing the top-level selector with @nest.

It would be my choice of all 3, if SCSS-style nesting is not possible.

Re: Help choose the syntax for CSS Nesting

#50

Post by jasonhansel »

I prefer Option 3, but IMHO the "&" should be required in all cases. Having it present in some places and absent in others makes the resulting code less readable, more ambiguous, and generally harder to understand. I'd rather keep things simple and uniform, even if it costs extra keystrokes.

Also: it would allow things like ".a { &.b { x: y; } }" (which would be equivalent to ".a.b { x: y; }") to be clearly differentiated from ".a { & .b { x: y; } }" (which would be equivalent to ".a .b { x: y; }"). Just ".a { .b { x: y; } }" looks ambiguous between the two, since it doesn't "look like" a descendant selector.

Post reply on HN