←back to thread

Incomplete list of mistakes in the design of CSS

(wiki.csswg.org)
197 points OuterVale | 8 comments | 11 Dec 25 04:20 UTC | HN request time: 0.001s | source | bottom
Show context
yread ◴[11 Dec 25 09:23 UTC] No.46229304[source]▶
I don't understand the point about comments. Why shouldn't they be allowed? What object model?

>Comments shouldn't have been allowed basically everywhere in CSS (compare to HTML, which basically only allows them where content goes), because it makes them basically unrepresentable in the object model, which in turn makes building editing directly on top of the object model impossible

replies(5): >>46229365 #>>46229381 #>>46229430 #>>46229509 #>>46231920 #
recursivecaveat ◴[11 Dec 25 09:44 UTC] No.46229430[source]▶
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.
replies(1): >>46230187 #
1. IshKebab ◴[11 Dec 25 11:43 UTC] No.46230187[source]▶
> 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.

replies(1): >>46234026 #
2. matt_kantor ◴[11 Dec 25 17:08 UTC] No.46234026[source]▶
> 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:

    <a href="https://example.com<!-- comment -->">click me</a>
And HTML like this is simply broken:

    <div<!-- comment -->>content</div>
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").
replies(1): >>46234814 #
3. IshKebab ◴[11 Dec 25 18:07 UTC] No.46234814[source]▶
Yes, anywhere in the node tree. Imagine if CSS was specified in HTML-style. We might write this selector:

  h1,
  /* don't forget h2! */
  h2 {
    color: /* I love red */ "red";
  }
Like this:

  <rule>
    <selector>
      <alternative>
         h1
      </alternative> <!-- don't forget h2 -->
      <alternative>
         h2
      </alternative>
    <selector>
    <attributes>
      <color><!-- I love red --> red</color>
    </attributes>
  </rule>
Which is pretty much exactly the same as what you'd get as a CST from parsing the CSS.
replies(1): >>46235565 #
4. matt_kantor ◴[11 Dec 25 19:01 UTC] No.46235565{3}[source]▶
Problem is, the CSSOM models that more like this:

    <rule selector="h1, h2">
      <style>
        <property name="color" value="red" />
      </style>
    </rule>
Perhaps your takeaway from this is "the CSSOM is bad" (and I don't necessarily disagree), but it's what the "mistake" is talking about.
replies(1): >>46238877 #
5. IshKebab ◴[11 Dec 25 23:33 UTC] No.46238877{4}[source]▶
I wouldn't say that, it's more that the CSSOM doesn't try to preserve comments, which is a perfectly reasonable thing to do. I think most uses cases for modifying CSS that care about comments (e.g. auto-formatters?) would need parsers that return the full CST anyway.
replies(1): >>46239479 #
6. matt_kantor ◴[12 Dec 25 00:42 UTC] No.46239479{5}[source]▶
I see. I was under the impression that you were saying the "mistake" from the post was wrong in its premise. But I guess that's incorrect, rather you think that people shouldn't use the CSSOM for use cases when comments matter, and instead they ought to design their own parsers/representations.

Just curious: do you feel the same about HTML? Should HTML allow comments in more places? I can imagine alternate ways to represent an HTML document that could capture comments within attribute lists, etc (and the DOM could exclude them entirely).

replies(1): >>46241895 #
7. IshKebab ◴[12 Dec 25 07:58 UTC] No.46241895{6}[source]▶
Nah I think HTML comments are fine. I don't think there would be a benefit to allowing comments in more places and it would make it more annoying when you actually do want to process comments.

If CSS had mandated that comments could only appear in certain places (e.g. before a rule or attribute) I think that would have been fine too, though maybe slightly confusing given the resemblance to C-style comments which are allowed almost anywhere.

replies(1): >>46243677 #
8. matt_kantor ◴[12 Dec 25 12:55 UTC] No.46243677{7}[source]▶
Seems like we have broadly-similar perspectives, though I do find it a bit incongruent that the DOM preserves comments while the CSSOM doesn't. It feels like they ought to be in alignment one way or the other (though I also understand the historical reasons why they aren't).