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

From WHATWG Wiki
Jump to navigation Jump to search
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 node inherits all styles from the host element's parent
# 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:

  1. The shadow root inherits styles from host element's parent (RolandSteiner: directly or via ShadowScope?)
  2. 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):
    1. browser styles
    2. user styles
    3. component author styles on shadow root
    4. page author styles on the host element
    5. !important page author styles on the host element
    6. !important component author styles on the shadow root
    7. !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.