RE: [cssom] Constructable Stylesheets

> > Hi,
> >
> > FWIW, I just had a closer look at the specification and -- despite my
> > initial interest -- I'm not sure I still really like it.
> >
> > I would argue that a problem which is even more important than memory
> > usage to authors is debugging. Something I do like about expressing
> > things in the DOM is that it's easy to find out when/where things are
> > done as it's a
> > reflective+observable API with amazingly good dev tools; right now
> > reflective+nearly
> > all style changes must happen in the DOM in some way and trigger
> > events you can hook. This is not the case for your proposed API.
> >
> > Let's imagine we now can create stylesheets and have them not exposed
> > the usual way. From a debugging perspective, I'm afraid it would be
> > hard to find out why some style apply to an element, and where it
> > comes from. Those rules would be hard to find manually, and the order
> > in which they apply would be opaque.
> 
> I don't understand what you mean.  They're exposed in the usual way - if a
> stylesheet is being applied to a document, it'll appear in either
> document.styleSheets or document.moreStyleSheets, and you can descend
> down into those objects as normal.
> 
> Sure, we could make markup shorthands for this kind of thing too, but that's
> seems to have the same ergonomics as exposing a constructor, no?

My point is that we don't want to force people to poll these collections every now and then to find out if/when something is added/removed. To sum up, my current opinion is that your proposal is adding complexity to the platform without giving developers the necessary tools to deal with it.

If we dissociate my "it seems like I liked the fact stylesheets are all defined in the DOM after all" opinion from the rest of my arguments, it still remains that when a stylesheet is added to a document, I can currently know about it using MutationEvents. As a consequence, I would friendly "oppose" Constructable StyleSheets if we don't get at the same time at least some reflection events like "stylesheet added, stylesheet removed, stylesheet updated" and (optionally), for individual stylesheets "rule added, rule removed, rule updated" (something we can't have at this point).

That would make it possible to reach parity with what we can currently achieve, and in a way that's arguably better than what we have now. I would also like stylesheet.parentCollection to return document.moreStylesheets so that I can know where the stylesheet is defined.

And if, in addition, we get Meta APIs like "remove()" which would DoTheRightThing™ (remove the parentNode if any, remove the @import rule if any, remove from the moreStylesheet collection if any, etc...) then I would even approve the API.

My concerns are more about a lack of adequate tooling to handle your proposal than about issues with the proposal itself (which I like).


Best regards,
François

Received on Wednesday, 8 April 2015 09:48:30 UTC