This is in relation to #4470 custom-origin proposal, and Cascade 5.

There are several (non-exclusive) ways the feature could be implemented and managed by authors, at different levels. (Any new syntax here is for demo purposes, not a final proposal):

1. Entire files, via html (e.g. <link> & <style>)
2. Entire files, via css rules (e.g. CSS @import)
3. One or more selector blocks, via css conditionals (e.g. @origin)
4. Individual declarations, via flags (e.g. !<origin>)

If custom origins are managed only by the html file:

• All origins for a page are clearly visible in one location
• Custom origins are a way of using CSS, rather than part of the CSS
• Page authors have full control of the origins defined, and what CSS belongs in what origin
• There is no need to handle “nested” origins from different sources

I think this could cover the main use-cases (Reset < Design System < Overrides, Reset < Defaults < Patterns < Layouts < Components, CMS Core < CMS Extend < Base Theme < Site Styles, Old Styles < New Styles). Those layers can often be divided cleanly into files.

One downside might be a performance hit from multiple links? It also ignores inline style attributes, which would either need a default relationship to custom origins, or a unique syntax.

Options 2-4, would support the same use-cases without enforcing any particular code organization or file-splitting. Overrides could be written directly next to the code they override. But the distributed approach makes things more complicated:

If custom origins are defined anywhere and shared globally, then an author would have to keep all possible origins in mind while working. If a library like Bootstrap decides to use 6 origins internally, you’ll need an origin-7 in order to override that. That doesn't feel manageable, and is where most concerns have been raised (the "z-index wars" comparison).

On the other hand, it might be resolved by allowing custom origins to be nested, so that the final link/import would retain full control over stacking. You could import hypothetical bootstrap.css with a file-level origin of 0, and any internal origin of 6 becomes 0.6 in context. This avoids escalation across CSS documents.

This also opens up some new use-cases – similar to the proposed !default – for defining component properties that should accept values from a lower-origin (e.g. "theme"), or using custom origins inside a style attribute. (These use-cases are currently handled by custom properties in Shadow DOM and elsewhere).

ToDo:

• Flesh out use-case details for each level?
• Compare to use of custom-properties for explicitly "defaulting" values?