W3C home > Mailing lists > Public > public-css-archive@w3.org > April 2020

[csswg-drafts] [css-cascade] What are the proper "levels" for managing "custom origins"? (#4969)

From: Miriam Suzanne via GitHub <sysbot+gh@w3.org>
Date: Sat, 18 Apr 2020 19:45:45 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-602537120-1587239144-sysbot+gh@w3.org>
mirisuzanne has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-cascade] What are the proper "levels" for managing "custom origins"? ==
This is in relation to #4470 custom-origin proposal.

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?

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4969 using your GitHub account
Received on Saturday, 18 April 2020 19:45:49 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 19 October 2021 01:31:23 UTC