Comment by recursivecaveat
4 days ago
Imagine you have something like `width /comment/: /comment2 /12px /comment3/,`. Now you want to load your css into some kind of structured representation, rearrange it, then spit it back out again with that comment intact. The requirement to represent such comments in your structured format so you can retain them is really obnoxious. In html you can just view comments as another node in a uniform tree.
> In html you can just view comments as another node in a uniform tree.
When you parse an AST with comments (or a CST), they do become "just another node in a uniform tree". Think about it - in HTML you have a tree of nodes but comments can be anywhere, which is exactly as obnoxious to deal with as a CST where comment nodes can be anywhere.
This is a terrible reason to not support comments. If it was really important, then probably you should support comments in only a couple of places, e.g. on attributes or on selectors.
But I don't think it is very important. I can't think of a single tool that loads CSS, rearranges it, and then spits it back out in a form that would benefit from comments.
> in HTML you have a tree of nodes but comments can be anywhere
Maybe I'm misunderstanding, but no they can't. For example the comment here is not a comment, but part of the URL:
And HTML like this is simply broken:
Maybe you meant "they can be anywhere that a Node can be in the DOM", but I think that's more or less what the CSS "mistake" is suggesting should be true about CSS (just replace "DOM" with "CSSOM").
Yes, anywhere in the node tree. Imagine if CSS was specified in HTML-style. We might write this selector:
Like this:
Which is pretty much exactly the same as what you'd get as a CST from parsing the CSS.
5 replies →