Re: [cssom] Constructable Stylesheets

On Wed, Apr 8, 2015 at 12:00 AM, Patrick Dark
<> wrote:
> On 3/18/2015 5:30 PM, Tab Atkins Jr. wrote:
>> Draft spec:
>> When dealing with Shadow DOM-related things, we've found that the
>> existing ways to style a component are somewhat suboptimal.  In
>> particular, the standard way to style a component is to insert a
>> <style> element into its shadow tree during initialization.  If you
>> create a bunch of instances of this component, though, that means you
>> have a bunch of identical <style> elements cluttering up your DOM and
>> making things more expensive.
> I'm guessing the "standard way to style a component" of which you speak is
> reflected in the code at
> In that poorly-designed code, they've baked a style element into a template
> instead of creating an active, singular style element like they should have.

That example is the correct way to handle styling in shadow DOM, currently.

> I think a better proposal would be to expect authors to write code that
> doesn't create a new style sheet each time a component is generated.

Agree; that's my proposal. ^_^

> They
> could do that by using techniques that make style sheet-scoping unnecessary:
> use of prefixed class names, custom element names, custom attributes, and/or
> namespaces. Examples:
> <_ class=""><content></content></_>→
> _[class=""] { /* styles */ }
> <_""><content></content></_> → _[] { /*
> styles */ }
> <_ xmlns=""><content
> xmlns=""/></_> → @namespace e
> ""; e|_ { /* styles */ } (HTML as XML)
> <_ xmlns=""><content></content></_> →
> _[xmlns=""] { /* styles */ } (HTML as HTML)
> The above examples are written with inter-site component sharing in mind;
> otherwise, just using unique class names should suffice.
> (Given the above, I'm not sure why you'd need style isolation of the shadow
> DOM or a shadow-piercing combinator. Maybe I'm missing something?)

Prefixes and such are fragile methods of composition, and don't scale.
Shadow DOM offers true composition.

> That said, I do think the style sheet construction API could use an
> overhaul. I'd automate existing techniques though. Currently, you need this
> code:
> var styleSheet = document.createElement("style");
> document.head.appendChild(styleSheet);
> styleSheet = styleSheet.sheet;
> The following would be easier:
> var styleSheet = document.createStyleSheet();
> The above would append a style element to the head element and return the
> style element. The style element would be a CSSOM object instead of a CSSOM
> host object which would allow code like styleSheet.remove(),
> styleSheet.textContent.replace(/blue/, "lightblue"), and
> styleSheet.setAttribute("id", "") to work. (I'm guessing that the
> reason for the current, disconnected design was the same behind the type
> attribute: the unrealistic idea that the style element should be an anchor
> for multiple style language.)

Not really; the current design is because you're crossing language
boundaries, and so the DOM no longer applies.  The stylesheet is the
root for the new object model, and it has to be attached to the
element hosting it.


Received on Wednesday, 8 April 2015 23:55:51 UTC