Csswg-drafts: Time to assume implementations of CSS are using the DOM?

[gsnedders]

Related: #2260.

We've still been trying to define CSS in terms of some never-defined abstract document tree, all the while doing things like 3f70d30b33f29992133f128230301545f3eb8be2 informatively referencing DOM because it's unclear how the DOM matches to our abstract data structure.

At this point, I'm unaware of any CSS implementation that _doesn't_ construct the DOM or something black-box equivalent to it. It feels like we're keeping this abstraction around for no good reason?

[frivoal]

@faceless2, as far as I know, your implementation does not have a javascript-accessible DOM, but it is still reasonable to describe it in terms of the DOM, or or similar abstraction that is not observably different from the DOM, or does it work in some other way?

@gsnedders Your assumption seems realistic for HTML (including the XHTML serialization), but CSS is supposed to be applicable to arbitrary forms of XML (RSS? XUL, XAML?, non specific XML?), (and I suppose non-XML tree structured markup languages as well). Is the DOM equally well defined in those cases? How about some of the more creative / unconventional uses of CSS, such as CSS in Gtk3+?

[faceless2]

(see also https://docs.oracle.com/javafx/2/layout/style_css.htm for another non-DOM example)

That's us. Yes, we have no DOM, and are laying out boxes directly from the event stream, building up lookaheads where necessary to do this (such as auto tables, :empty selectors, the target-counter() function). But I'm aware we're an outlier.

You need a tree structure - parent, next, prev, and (due to the addition of :has) first and last - plus the concepts of tag name, namespace, id, class, lang, rtl-or-ltr, attributes, and "state" (eg hover, placeholder, target) for all current selectors except the column-related ones, which we haven't got around to yet. Many of those you can ignore if not applicable - most XML dialects have no concept of "class", for example, so they just wouldn't match. Reassuringly I see this matches what's described at https://drafts.csswg.org/selectors/#dom-mapping, so this is well established.

Add in the base-url of a node, replaced-content, pseudo-nodes, and a counter registry and that's everything you need to build the box tree - I know this, because that's our whole "Node" interface.

Overall I agree with @frivoal, _describing_ it in terms of the DOM seems a reasonable thing to do, because it is a very well understood representation of the above concepts. I think something would be lost from the language if it evolved in a way that made it _only_ applicable to the DOM, but I know that's not the intention, and it's clear from the link above that that's intentional.

[gsnedders]

@frivoal Fine for XML, not an issue; for other uses like Gtk3+ it really feels like someone needs to define how their model maps to the model in the spec, and I don't think it really makes any real difference whether that's the current vaguely defined thing or the DOM? I don't think describing it in terms of the DOM should be black-box observable for implementations that don't expose the document tree?

@faceless2 That sounds fine, really; as long as there's something isomorphic to the DOM it shouldn't be a problem.

Mostly I'm concerned about making sure things with shadow elements is well-defined in CSS, and we haven't added any notion of shadow elements to our document model as far as I'm aware, we just rely on hand-waving there.