A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.
To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).
Component Model Strawman: Styling: Difference between revisions
m (add link to brainstorming page) |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
see also the [http://wiki.whatwg.org/wiki/Component_Model_CSS_Brainstorming brainstorming page]. | |||
= Overview = | = Overview = | ||
| Line 14: | Line 16: | ||
To style the component in a way that meets expectations, we probably need an algorithm similar to the following: | To style the component in a way that meets expectations, we probably need an algorithm similar to the following: | ||
# The shadow root | # The shadow root inherits styles from host element's parent ([[User:Rolandsteiner|RolandSteiner]]: directly or via ShadowScope?) | ||
# All styles set on the host element (+) all styles set on the shadow root are applied to the shadow root element. To this end, the cascade order is (from least to most important): | # All styles set on the host element (+) all styles set on the shadow root are applied to the shadow root element. To this end, the cascade order is (from least to most important): | ||
## browser styles | ## browser styles | ||
Latest revision as of 18:08, 31 October 2011
see also the brainstorming page.
Overview
There are 4 actors that may modify the style of (parts of) a component:
- the browser
- the component author
- the page author
- the user
We intend to use the ShadowScope to be the staging point for component styling
Specified Styles and Inheritance
To style the component in a way that meets expectations, we probably need an algorithm similar to the following:
- The shadow root inherits styles from host element's parent (RolandSteiner: directly or via ShadowScope?)
- All styles set on the host element (+) all styles set on the shadow root are applied to the shadow root element. To this end, the cascade order is (from least to most important):
- browser styles
- user styles
- component author styles on shadow root
- page author styles on the host element
- !important page author styles on the host element
- !important component author styles on the shadow root
- !important user styles
Issues and Questions
What does it mean if the host element is assigned, e.g., display: table?
We could ignore that property value, but that seems rather arbitrary and requires a detailed spec on what is ignored when, how and why. Another (better?) approach could be to define a new value display: component. If this value is set, an element renders as if it was a component - i.e., the element itself is not rendered, nor are its children by default. If it has a component bound to it, it is rendered instead. Otherwise, this is effectively equivalent to display: none (or we could set a different fallback, e.g. display: inline, but IMHO this just complicates things).
To further facilitate this, we can add a pseudo-class :component that matches if the element is a component. With this, the UA stylesheet just needs an entry :component { display: component } to properly render components, while still allowing the page author to override specific elements he doesn't want to be rendered as components.
In that case, what does it mean if a generated-content pseudo element such as ::before sets display: component?
We can either ignore this and treat it as equivalent to display: none - the generated content does not have a component assigned to it after all - or use that as a staging point for decorators somehow.