Re: [cssom] Constructable Stylesheets

On Sat, Apr 4, 2015 at 7:11 AM, François REMY
<francois.remy.dev@outlook.com> wrote:
> 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 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.

> That being said, I do understand the memory usage concern. Couldn't the
> problem be solved by allowing <style scoped src="{{some-blob-url}}" /> and
> share that blob? A <style> element isn't that much memory wasted, but it
> would allow to retain the spirit of the html usual style guide and (I think)
> make the page much easier to debug for a vast majority of developers.

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?

~TJ

Received on Wednesday, 8 April 2015 00:00:05 UTC