3 ms·

This should not be done on browser level, this should be done as a pre-processor, because any nested syntax is going to make older browsers faint, and to lessen

This should not be done on browser level, this should be done as a pre-processor, because any nested syntax is going to make older browsers faint, and to lessen the complexity of CSS, especially for beginners. That being said, if people really want this, then it definitely should not be something where the css file is going to be filled with "@nest" definitions. What about allowing SCSS-like syntax through something like `<link rel="stylesheet" href="styles.css" allow="nest,foo,bar" />` which then tells the parser to react in certain ways - for example if there is a rule "color:hover", then do the usual CSS parsing, while "color:hover {" means that there is a nested rule. That way the developer can opt-in to certain features, and you could even have it in the style tag with something like `<style allow="nest,foo,bar">...</style>` But then you have an issue of custom features allowed through the tag definition, where chrome can force their way with things even more.

LocalPCGuy 4y ago
Old browsers will just ignore it, just like if you give them nested SCSS without pre-processing it first. And for those that need to support older browsers, it'd probably still run through some sort of processor to output CSS for the older browsers. I see no reason to need to tell the parser what rules to parse for given how CSS works. As far as having numerous `@nest` definitions, I don't know if your concern is file size, but if so, that really isn't an issue - assuming use of gzip (or some similar compression), there is almost zero difference in file size for repeated use of `@nest`. I did a bunch of testing related to multiple @media blocks versus a single one (a long time ago) and found it didn't make any significant difference in file size - and that adds significantly more characters in the uncompressed version than @nest does.

LocalPCGuy 4y ago

Old browsers will just ignore it, just like if you give them nested SCSS without pre-processing it first. And for those that need to support older browsers, it'd probably still run through some sort of processor to output CSS for the older browsers. I see no reason to need to tell the parser what rules to parse for given how CSS works. As far as having numerous `@nest` definitions, I don't know if your concern is file size, but if so, that really isn't an issue - assuming use of gzip (or some similar compression), there is almost zero difference in file size for repeated use of `@nest`. I did a bunch of testing related to multiple @media blocks versus a single one (a long time ago) and found it didn't make any significant difference in file size - and that adds significantly more characters in the uncompressed version than @nest does.