search

w3c / css-houdini-drafts

Mirror of https://hg.css-houdini.org/drafts
https://drafts.css-houdini.org/
Other
1.84k stars 141 forks source link

[css-paint-api] should registered paint names be somehow limited to shadow trees they are registered in? #223

Open heycam opened 8 years ago

heycam commented 8 years ago

I assume that registered custom paints are available globally within a document, including in all shadow trees. Should we be providing for the ability to register a paint name available only within a shadow tree (and possibly its descendants)? I can imagine custom elements defining a custom paint and clobbering custom paints used elsewhere in the document.

heycam commented 8 years ago

CC @annevk

tabatkins commented 8 years ago

If we do something here, we should probably try and generalize it to all the global-definers in CSS.

annevk commented 8 years ago

Also paging @hayatoito @rniwa @travisleithead. If I understood correctly, I think we should address this as names introduced in shadow trees should not be observable to their shadow host tree.

hayatoito commented 8 years ago

Yeah, if we do something here, we can have a registry per node tree (DocumentOrShadowRoot), rather than per Document.

esprehn commented 8 years ago

This has the same problems as @font-face as @tabatkins mentions, for example if you do background-image: inherit and that pulls in a paint(foo) or if you do ::slotted(x) { background: paint(...); } that would resolve against the scope of x, not the shadow that defined the rule.

Fonts are super hard, you do actually expect them to apply all over even if the face is defined in the wrong scope. For that reason we forbid font faces in shadow roots for now.

Painters might be okay, it's what we did for animations, though it has caused some mild developer confusion: https://bugs.chromium.org/p/chromium/issues/detail?id=382498 making it resolve against the location where the rule is defined is not something that's easily possible.

esprehn commented 8 years ago

Hmm, also scoping doesn't really work with the worklet system, you just import scripts into the worklet and they define the painters any part of the page can use. This is the same as global element names, CSS display types, or the urls to the image resources the custom element might use.

window.paintWorklet.import("painter.js")

I'm not sure how to make that work for ShadowRoot, you'd need to somehow associate specific names in the worklet with specific custom element names or shadow roots. Per ShadowRoot or Element worklets would be too expensive. So we'd have to redesign the API somehow, I guess registerPainter in the Worklet itself could limit it to specific element names?

I'm not sure that complexity is much better than just prefixing your layouts or painters with the element name, just like you'd scope the urls for images, or prefix the custom element name itself.

bfgeek commented 8 years ago

Resolved in houdini to address this in a future CSS spec.

tabatkins commented 8 years ago

In other words, paint worker names will be global, and a future CSS spec should address scoping these kinds of things for CSS in general.