Re: reaching the CSS parser

Good point, and there are a lot of ways to handle this, depending on the
details of whatever solution proposal we're looking at. For example, off
the top of my head, unknown rules could have no structure at all (or maybe
just a token stream), and require you to request the full-featured rule
(built from whatever JS definition we allow) from a promise. This removes
order dependence.

But anyway, this is just something to keep in mind as we develop APIs. We
obviously shouldn't try to come up with anything yet.

~TJ
On Dec 28, 2014 2:22 PM, "Brian Kardell" <bkardell@gmail.com> wrote:

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