This is a solved problem. Use the SASS syntax. I don't know why it's even a question.
Help choose the syntax for CSS Nesting
101–110 of 170 posts
Re: Help choose the syntax for CSS Nesting
#102Earlier quoted context omitted.
Tbh, if this sort of "nesting" is possible in Sass, I don't think I've ever used it... Is it really necessary to support? I'd be cool with just simple nesting logic
It is definitely possible, just with a more complicated (and slow) parser than what browsers use now – there's been some discussion in this thread. As for whether it's necessary – eh, it's neat and might be useful sometimes but it's not a big deal I think. Personally, I remember a couple instances when I needed to override a few properties depending on context and it would be helpful, but `&:hover` is so much more us…
Right and now that we have (or will, soon enough) `:has`, I really don't think it's worth mucking up the potentially very simple and sweet nesting syntax to support something that's probably usually a bad practice anyways (though obviously I'm speaking from a place of little experience using this)
Re: Help choose the syntax for CSS Nesting
#103> 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 us…
> What is even the problem? People use preprocessors, poly-fills, hot-reloading, etc anyway. It isn't 1990s. All of this tooling is used because of missing CSS features for the most part. The web browser's ethos is to be a viewing and authoring environment; from Netscape Navigator on, browsers have enabled its users to write HTML and later, CSS. For that to continue, browsers we can't have web authoring that's depend…
Everything is still going to be tree-shaken, minified and mangled before being transferred to the client; no matter how much bells and whistles are added to web languages. Why not just make it decoupled and efficient? Compiling code isn't a radical idea.
Re: Help choose the syntax for CSS Nesting
#104Option 3 seems the most intuitive, but I can see the arguments for 5. It's 4 that I'm having a hard time understanding why anyone would want it that way. It's truly awful. I can't think of literally any other language (style, markup, programming, or otherwise) that does nesting with a second set of adjacent (not nested!) curly braces.
Same. I think that the only thing I don’t like about 3 is the need for `:is(aside)` and the like, and I can see that there might be some performance benefit to `@nest {…}` blocks (5). I think the only thing I don’t like about 5 is the required `& {}` block. I find 5 to be the most consistent and 3 to be mostly cleaner because of what becomes optional.
I find 5 least consistent because there are now two competing ways to define an unnested block: the normal way, and the `@nest { & { ... } }` way. Why would anyone do the second way, you ask? Because that rule used to have a nested rule, and when it was taken out the programmer was lazy or didn't notice that it was the last nested case. Having to completely reformat the base rule just to add or remove a nested case is a complete deal breaker for me.
I started liking option 4 when I started thinking of `} {` as a special "nested stuff here" sequence instead of a set of scope delimiters. True, it would be better if they had used basically any other sequence of bytes for that, but it still bothers me less then that goofy `:is()` requirement.
Re: Help choose the syntax for CSS Nesting
#105Earlier quoted context omitted.
Thanks for the thoughtful response. No. 3 is the knee jerk, in the heat of the moment response; but no. 5 makes the most sense long term.
The web has given me an amazing career and life (that I feel is still very much only getting started). I’m always happy to contribute when I can. That being said, I wish I could better articulate my opposition to No. 4. I think it’s because it immediately strikes me as a typo, like if someone was editing some CSS, deleted a selector and then forgot to write a new one back in before committing their work. Others seem…
>Others seem to suggest that formatting addresses this,
I feel the same way about python. To me, indentations and spaces are much more for human legibility than the parser's. Something in my brain says that symbols like curly/square braces designate code blocks much more succinctly than white spaces.
However, for someone that started in a language that used white spaces vs symbols, I get how they would feel the opposite.
Re: Help choose the syntax for CSS Nesting
#106I'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.
They don’t know what to do with options 1..5 neither.
Re: Help choose the syntax for CSS Nesting
#107Given the rules at where I work, we aren't allowed to use elements case rules anyways, so Option 3 has no downside for me haha.
If you're being micromanaged to the point of "allowed" CSS selectors, perhaps you should branch out a bit?
Re: Help choose the syntax for CSS Nesting
#108Am I the only one who prefers unnested? It seems to make more sense to me.
Re: Help choose the syntax for CSS Nesting
#109[deleted]
Re: Help choose the syntax for CSS Nesting
#110So 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…
You browser developers seem to already decided on it, so why asking at all. This “help us to choose but stay silent if you don’t like it” is pointless. I am well-informed on most of these nuances and don’t like any of these options. Will stick with sass unless forced to use some of that, I don’t care which you end up with.
My opinion is: provide a slow parser for my kilobytes of “style.kbcss” and do whatever you want with minified bootstrap megabytes and such. If you don’t feel like counting this opinion, fine. Build pipelines or makefile-likes or just a caching middleware is not a deal big enough to make drama out of it.
I see why you may find uninformed opinions irritating, but the only constructive thing here is to make your comment softer and put it into the header of that site. People may not visit links, may not understand what/why or may (surprise) not care about implications. If you care to make a poll that excludes some opinions in advance, prepare the auditory correctly.