- From: Mike Bremford via GitHub <sysbot+gh@w3.org>
- Date: Thu, 19 Mar 2020 10:04:09 +0000
- To: public-css-archive@w3.org
(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. -- GitHub Notification of comment by faceless2 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4888#issuecomment-601092675 using your GitHub account
Received on Thursday, 19 March 2020 10:04:14 UTC