Re: reaching the CSS parser

I'm sniping everything here in order to respond very generally to the topic
with what I think is a related concern - sorry for the delay, I've been
very ill.

One thing that probably bears consideration sooner rather than later is
that if there is CSS relying on something custom which is in JS, how do the
two cooperate and what's the lifecycle look like.  Custom Elements, for
example, introduced this special 'unresolved' state so that the parser can
carry on and the order of the load is, in theory at least, less a matter of
importance... The system can learn a new definition after the fact. I dont
know that that's been extremely popular with everyone or if something
similar can even work with CSS - it's pretty complex IMO. But this gets to
questions like what it would mean to be undefined/unknown to the parser and
to the CSSOM and so on as Daniel originally posed - and more, like what it
would mean to suddenly *become* defined - because that's sort of what would
need to happen, you'd need to reserve your spot and all in the order.

The simplest answer, to me, seems to be that you'd have to define things
upfront, that is - before you actually parsed the rule into some kind of
OM, else it would be unknown and lost as it is today. If this is the route
taken, then it's probably worth figuring out just how that integrates
without much complexity.  IE, how do you bootstrap the stuff that helps the
parser make sense of it - because if you can answer these questions then
you inherently have to have dealt with all of the problems we have today
about cross-origin loading, render-blocking, preserving the order of styles
and so on, and you explain an underlying system which doesn't require lots
of change to existing high-level surface.