Comment by IshKebab

4 days ago

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.

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.

  • 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.

    • 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).

      2 replies →