Component Model Strawman: Styling - Revision history

Rolandsteiner: add link to brainstorming page

2011-10-31T18:08:09Z

add link to brainstorming page

← Older revision		Revision as of 18:08, 31 October 2011
Line 1:		Line 1:
			see also the [http://wiki.whatwg.org/wiki/Component_Model_CSS_Brainstorming brainstorming page].

	= Overview =		= Overview =

Rolandsteiner: /* Specified Styles and Inheritance */

2011-10-29T00:40:55Z

Specified Styles and Inheritance

← Older revision		Revision as of 00:40, 29 October 2011
Line 14:		Line 14:
	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

Rolandsteiner: /* Issues and Questions */

2011-10-29T00:22:13Z

Issues and Questions

← Older revision		Revision as of 00:22, 29 October 2011
Line 26:		Line 26:
	= Issues and Questions =		= Issues and Questions =

	* What does it mean if the host element is assigned, e.g., <tt>display: table</tt>?		'''''What does it mean if the host element is assigned, e.g., <tt>display: table</tt>?'''''

	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 <tt>display: component</tt>. 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 <tt>display: none</tt> (or we could set a different fallback, e.g. <tt>display: inline</tt>, but IMHO this just complicates things).		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 <tt>display: component</tt>. 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 <tt>display: none</tt> (or we could set a different fallback, e.g. <tt>display: inline</tt>, but IMHO this just complicates things).
Line 32:		Line 32:
	To further facilitate this, we can add a pseudo-class <tt>:component</tt> that matches if the element is a component. With this, the UA stylesheet just needs an entry <tt>:component { display: component }</tt> to properly render components, while still allowing the page author to override specific elements he doesn't want to be rendered as components.		To further facilitate this, we can add a pseudo-class <tt>:component</tt> that matches if the element is a component. With this, the UA stylesheet just needs an entry <tt>:component { display: component }</tt> 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 <tt>::before</tt> sets <tt>display: component</tt>?		'''''In that case, what does it mean if a generated-content pseudo element such as <tt>::before</tt> sets <tt>display: component</tt>?'''''

	We can either ignore this and treat it as equivalent to <tt>display: none</tt> - the generated content does not have a component assigned to it after all - or use that as a staging point for decorators somehow.		We can either ignore this and treat it as equivalent to <tt>display: none</tt> - the generated content does not have a component assigned to it after all - or use that as a staging point for decorators somehow.

Rolandsteiner: Styling part 1

2011-10-26T20:29:35Z

Styling part 1

← Older revision		Revision as of 20:29, 26 October 2011
Line 7:		Line 7:
	* the page author		* the page author
	* the user		* 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 node inherits all styles from the host element's parent
			# 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
			## <tt>!important</tt> page author styles on the host element
			## <tt>!important</tt> component author styles on the shadow root
			## <tt>!important</tt> user styles

			= Issues and Questions =

			* What does it mean if the host element is assigned, e.g., <tt>display: table</tt>?

			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 <tt>display: component</tt>. 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 <tt>display: none</tt> (or we could set a different fallback, e.g. <tt>display: inline</tt>, but IMHO this just complicates things).

			To further facilitate this, we can add a pseudo-class <tt>:component</tt> that matches if the element is a component. With this, the UA stylesheet just needs an entry <tt>:component { display: component }</tt> 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 <tt>::before</tt> sets <tt>display: component</tt>?

			We can either ignore this and treat it as equivalent to <tt>display: none</tt> - the generated content does not have a component assigned to it after all - or use that as a staging point for decorators somehow.

Rolandsteiner at 20:37, 25 October 2011

2011-10-25T20:37:42Z

← Older revision		Revision as of 20:37, 25 October 2011
Line 1:		Line 1:
	~~Stub~~		= 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

Rolandsteiner: creating the page

2011-10-24T21:57:02Z

creating the page

New page

Stub