A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

Why are we still thinking in globals?

trusktr
2018-05-12

The new CSS.registerPaint API registers globals in the CSS space. There has to be a better way.

Can they be scoped to shadow roots? If they were, an element could be responsible for finding it’s root ancestor (or document if it doesn’t find a root), and registering properties automatically. A custom element author could also make it a manual step for the user, like “hey, call this API on your shadow root or document to registered necessary CSS properties”. This would, for example, prevent name collisions to some degree, and provide a way to fix name collisions by adding roots.

What other possibilities are there?

Maybe, the ability to associate custom property names with custom elements, so that they can have entirely different meaning (differing syntax, etc). Things like inheritance would only inherit to the next grandchild of the same custom element type, etc.

Maybe, it doesn’t matter much? Just let people figure out what to do when names clash in a big application?

Androbin
2018-05-14

I agree that the Web is broken, in general and regarding globals. I think that many things are global because of (backwards-)compatibility reasons. Defining something as global in the original design spec makes promises if not guarantees. But we should be able to use (scope-)prefixes for the keys and define a separator sequence.