Component Model CSS Brainstorming - Revision history

FrShorts7: None

2011-11-07T21:25:07Z

None

Rolandsteiner: /* Styling <content> elements */

2011-10-07T02:15:15Z

Styling <content> elements

← Older revision		Revision as of 02:15, 7 October 2011
Line 261:		Line 261:
	<B> <content>		<B> <content>
	</x-foo>		</x-foo>

			(not very elegant, though...)

Rolandsteiner: /* CSS extensions */ ::binding -> ::shadow, clarification

2011-10-07T02:08:45Z

CSS extensions: ::binding -> ::shadow, clarification

← Older revision		Revision as of 02:08, 7 October 2011
Line 98:		Line 98:
	(WARNING: Inane scribblings!)		(WARNING: Inane scribblings!)

	'::~~binding'~~ sets the style to inherit for the shadow tree.		<code>::shadow</code> sets the style to inherit for the shadow tree.
	By default, this is equal to the effective style of the host element.		By default, this is equal to the effective style of the host element.

	x-foo::~~binding~~ {		x-foo::shadow {
	background-color: grey; // overrides the background color (only!) for the shadow DOM		background-color: grey; // overrides the background color (only!) for the shadow DOM
	}		}

	On the shadow side, the ShadowRoot ~~gets~~ this styling ~~as the styling~~ to inherit ~~from.~~		On the shadow side, the ShadowRoot inherits from this styling by default, but can override what exactly to inherit as well (see below).
	~~By default, it inherits the styling~~.

	=== Preventing automatic inheritance ===		=== Preventing automatic inheritance ===

Rolandsteiner: /* Using pseudo-attributes and CSS apply */

2011-10-07T02:03:42Z

Using pseudo-attributes and CSS apply

← Older revision		Revision as of 02:03, 7 October 2011
Line 68:		Line 68:
	# Overriding the background color of labels by the same mechanism as in [2]. Unlike ::label-color, ::label-background-color is defined in the example though, so this line would take effect.		# Overriding the background color of labels by the same mechanism as in [2]. Unlike ::label-color, ::label-background-color is defined in the example though, so this line would take effect.
	# Setting the background-color of the selected label.		# Setting the background-color of the selected label.
	# This line forwards the passed-in ::selected-label-background-color pseudo-attribute as ::tab-background, ~~p[resumably~~ for use in nested components of x-label.		# This line forwards the passed-in ::selected-label-background-color pseudo-attribute as ::tab-background, presumably for use in nested components of x-label.

	Advantages of this approach:		Advantages of this approach:
Line 83:		Line 83:
	* General text & link-styling is unsatisfactory with this approach alone.		* General text & link-styling is unsatisfactory with this approach alone.
	* This only handles styling of specific elements of the shadow DOM, but does not address how the component could style children of the host element that are attached to a content element, nor how inheritance into/out of the shadow DOM is to be handled.		* This only handles styling of specific elements of the shadow DOM, but does not address how the component could style children of the host element that are attached to a content element, nor how inheritance into/out of the shadow DOM is to be handled.


	= Inheritance Across Boundaries =		= Inheritance Across Boundaries =

Rolandsteiner: /* Component Model CSS Brainstorming */ reformat for better clarity

2011-10-07T01:50:03Z

Component Model CSS Brainstorming: reformat for better clarity

← Older revision		Revision as of 01:50, 7 October 2011
Line 1:		Line 1:
	~~= Component Model CSS Brainstorming =~~		= Selectors Crossing Boundaries =

	== Selectors ==

	~~===~~ Crossing ~~boundaries ==~~=

	Style rules from the host element's DOM tree are not normally allowed to cross into the shadow DOM. Conversely, style rules defined in the shadow tree are not normally allowed to cross over the content boundary back into the host element's tree.		Style rules from the host element's DOM tree are not normally allowed to cross into the shadow DOM. Conversely, style rules defined in the shadow tree are not normally allowed to cross over the content boundary back into the host element's tree.

	==== The XBL way ====		== The XBL way ==

	The following is the the current "state of the art", but suffers from various drawbacks		The following is the the current "state of the art", but suffers from various drawbacks
Line 31:		Line 27:
	* Pseudo-IDs allow selectors like x-foo::label div { color: red; } to style arbitrary elements of the shadow tree rather than just the designated element(s). This again makes it harder for component authors to later redesign components without breaking user sites.		* Pseudo-IDs allow selectors like x-foo::label div { color: red; } to style arbitrary elements of the shadow tree rather than just the designated element(s). This again makes it harder for component authors to later redesign components without breaking user sites.

	==== Using pseudo-attributes and CSS apply ====		== Using pseudo-attributes and CSS apply ==

	The following is a proposal that has not seen widespread discussion.		The following is a proposal that has not seen widespread discussion.
Line 89:		Line 85:


	== Inheritance ==		= Inheritance Across Boundaries =

	~~=== Inheritance across the boundary ==~~=

	For several use cases (e.g., components creating native-like widgets) it may be beneficial to specify how CSS inheritance works across host-shadow boundaries.		For several use cases (e.g., components creating native-like widgets) it may be beneficial to specify how CSS inheritance works across host-shadow boundaries.

	==== The XBL way ====		== The XBL way ==

	The following is AFAICT		The following is AFAICT
Line 101:		Line 95:
	In XBL, CSS inheritance crossses the flattened tree. There is no way to limit or steer this behavior.		In XBL, CSS inheritance crossses the flattened tree. There is no way to limit or steer this behavior.

	==== CSS extensions ====		== CSS extensions ==

	(WARNING: Inane scribblings!)		(WARNING: Inane scribblings!)
Line 211:		Line 205:
	* Doesn't handle the case where a <content> element selects multiple different elements and wants to style different elements differently.		* Doesn't handle the case where a <content> element selects multiple different elements and wants to style different elements differently.

	== Styling the host element ==		= Styling the host element =

	(see also the [http://wiki.whatwg.org/index.php?title=Component_Model_Discussion:_Rendering rendering discussion page])		(see also the [http://wiki.whatwg.org/index.php?title=Component_Model_Discussion:_Rendering rendering discussion page])
Line 239:		Line 233:
	:: ...		:: ...

	== Styling content elements ==		= Styling <code><content></code> elements =

	This has similar issues and raises similar questions as styling the host element.		This has similar issues and raises similar questions as styling the host element.

Rolandsteiner: /* Preventing automatic inheritance */ add another example

2011-10-07T01:44:50Z

Preventing automatic inheritance: add another example

← Older revision		Revision as of 01:44, 7 October 2011
Line 155:		Line 155:
	border-group: initial; // Don't allow 'border-...' attributes to be inherited from outside document		border-group: initial; // Don't allow 'border-...' attributes to be inherited from outside document
	table-group: initial; // Don't allow table-related attributes to be inherited from outside document		table-group: initial; // Don't allow table-related attributes to be inherited from outside document
			}
			</style>

			or

			<style scoped>
			:scope {
			all: initial; // reset everything
			background-color: apply(background-color); // ...except background-color (reapply the inherited value)
	}		}
	</style>		</style>
Line 201:		Line 210:

	* Doesn't handle the case where a <content> element selects multiple different elements and wants to style different elements differently.		* Doesn't handle the case where a <content> element selects multiple different elements and wants to style different elements differently.


	== Styling the host element ==		== Styling the host element ==

Rolandsteiner: /* Styling content elements */ potential approaches to styling children

2011-10-05T06:46:20Z

Styling content elements: potential approaches to styling <content> children

← Older revision		Revision as of 06:46, 5 October 2011
Line 240:		Line 240:
	* it can style any descendant, not just direct children		* it can style any descendant, not just direct children
	* it breaks confinement		* it breaks confinement

			Approaches to solve this:

			* Allow the component to not just style the host, but also the host's direct children - i.e. don't see the problem as styling render children of <content>, but as styling HTML children of the host
			* Require wrapper components that do styling only, reducing the problem to styling the host element

			Example for the 2nd suggestion: Rather than having

			<x-foo> ----------> [ShadowRoot]
			<A> <content> (A's in red, B's in green)
			<B>
			</x-foo>

			require

			<x-foo> ----------------------------------> [ShadowRoot]
			<x-A> --------> [ShadowRoot] (red) <content>
			<A> <content>
			<x-B> --------> [ShadowRoot] (green)
			<B> <content>
			</x-foo>

Rolandsteiner: /* Styling the host element */ link to rendering discussion page

2011-10-04T07:35:06Z

Styling the host element: link to rendering discussion page

← Older revision		Revision as of 07:35, 4 October 2011
Line 204:		Line 204:

	== Styling the host element ==		== Styling the host element ==

			(see also the [http://wiki.whatwg.org/index.php?title=Component_Model_Discussion:_Rendering rendering discussion page])

	If the host element is rendered (this is the current default assumption.)		If the host element is rendered (this is the current default assumption.)

Rolandsteiner: /* Styling content elements */ elaborate

2011-10-04T07:33:59Z

Styling content elements: elaborate

← Older revision		Revision as of 07:33, 4 October 2011
Line 232:		Line 232:

	This has similar issues and raises similar questions as styling the host element.		This has similar issues and raises similar questions as styling the host element.

			In addition, a content element may select multiple different child elements from under the host element. E.g., <content select="A B .left">, or a simple <content> that takes whatever isn't taken by other contents. In this case it's conceivable that different elements should be styled different. I.e., a single style assigned to <content> is not sufficient.
			XBL2's <code>apply-binding-sheets</code> allows to do this, but:

			* it can style any descendant, not just direct children
			* it breaks confinement

Rolandsteiner: Brainstorming on how to treat CSS within the component model

2011-09-29T08:25:59Z

Brainstorming on how to treat CSS within the component model

New page

= Component Model CSS Brainstorming =

== Selectors ==

=== Crossing boundaries ===

Style rules from the host element's DOM tree are not normally allowed to cross into the shadow DOM. Conversely, style rules defined in the shadow tree are not normally allowed to cross over the content boundary back into the host element's tree.

==== The XBL way ====

The following is the the current "state of the art", but suffers from various drawbacks

XBL defines the ''allow-selectors-through'' and ''apply-author-sheets'' attributes on the binding template.

'''allow-selectors-through''' allows style selectors defined for the outer tree to cross the boundary into the shadow tree.

'''apply-author-sheets''' allows style rules defined for the outer tree to be applied entirely inside the shadow tree.

XBL furthermore defines the '''apply-binding-sheets''' attribute on content elements. If set, this allows style rules defined for the shadow tree to apply to the host element's children that are selected by that content element.

Finally, XBL defines the pseudo attribute on elements inside the shadow tree. Its content is an ID that then can be used in outside style rules as pseudo-element in order to style that element specifically. E.g., a <div pseudo="label"> inside a "x-foo" component could be styled by an outside rule 'x-foo::label { color: red; }'.

The XBL approach has several drawbacks:

* It's an HTML solution to a CSS problem.
* allow-selectors-through, apply-author-sheets and apply-binding-sheets break confinement.
* allow-selectors-through and apply-author-sheets do not allow control over what kind of styles attributes to apply/let through.
* pseudo-IDs are either very limited (XBL proposes to allow only value, choices, label, repeat-item and icon), or pollute the CSS pseudo-element namespace. If allowed arbitrarily they may clash across components, which would makes it hard for the CSS working group to define new pseudo-elements.
* It is not clear whether the same pseudo-ID could be applied to several different elements
* Associating a pseudo-ID with a specific element (elements?) makes it harder to later re-design the component without breaking using sites.
* Pseudo-IDs allow selectors like x-foo::label div { color: red; } to style arbitrary elements of the shadow tree rather than just the designated element(s). This again makes it harder for component authors to later redesign components without breaking user sites.

==== Using pseudo-attributes and CSS apply ====

The following is a proposal that has not seen widespread discussion.

The following is similar, but not identical, to CSS variables and CSS constants.

An alternative to the XBL approach could be (for the lack of a better term) pseudo attributes. In this approach, a style rule may set a number of arbitrary attribute-value pairs that in and of themselves have no effect. However, a style sheet in the shadow tree can use a new CSS attribute apply to select which values to apply.

Example, using a prefix '::' for pseudo-attributes:

x-tabbar {
background-color: azure;
::label-backround-color: lightblue;
::selected-label-background-color: slategray;
}

Within the component:

#ShadowRoot
<style scoped>
x-label {
color: apply(background-color); [1.]
background-color: apply(color);
color: apply(::label-color); [2.]
background-color: apply(::label-background-color) [3.]
}
x-label[selected] {
background-color: apply(::selected-label-background-color) [4.]
::tab-background: apply(::selected-label-background-color) [5.]
}
</style>
<div id="background">
<x-label>Tasks</x-label>
<x-label selected>Calendar</x-label>
<x-label>Contacts<x-label>
</div>

# These 2 lines revert foreground (text) color and background color. This example shows how apply could apply not only to pseudo-attributes.
# The foreground-color of non-selected label is set to the ::label-color pseudo-attribute, if defined. As this comes after the initial setting of the label color in [1], it gets precedence. If, on the other hand, ::label-color is not defined (as is the case in above example), this line has no effect.
# Overriding the background color of labels by the same mechanism as in [2]. Unlike ::label-color, ::label-background-color is defined in the example though, so this line would take effect.
# Setting the background-color of the selected label.
# This line forwards the passed-in ::selected-label-background-color pseudo-attribute as ::tab-background, p[resumably for use in nested components of x-label.

Advantages of this approach:

* Avoids pseudo-element namespace pollution, while still allowing arbitrary names.
* A given pseudo-attribute can be applied in various places in a stright-forward manner.
* Pseudo-attributes can be applied directyl, or forwarded to nested components - the user does not need to know about the internal structure.
* Pseudo-attributes that are not applied have no effect, giving the author control over how the component is stylable.
* ''apply'' can be used for other effects, as shown in [1] in the example above.

Downsides:

* Requires extension to the CSS spec.
* General text & link-styling is unsatisfactory with this approach alone.
* This only handles styling of specific elements of the shadow DOM, but does not address how the component could style children of the host element that are attached to a content element, nor how inheritance into/out of the shadow DOM is to be handled.

== Inheritance ==

=== Inheritance across the boundary ===

For several use cases (e.g., components creating native-like widgets) it may be beneficial to specify how CSS inheritance works across host-shadow boundaries.

==== The XBL way ====

The following is AFAICT

In XBL, CSS inheritance crossses the flattened tree. There is no way to limit or steer this behavior.

==== CSS extensions ====

(WARNING: Inane scribblings!)

'::binding' sets the style to inherit for the shadow tree.
By default, this is equal to the effective style of the host element.

x-foo::binding {
background-color: grey; // overrides the background color (only!) for the shadow DOM
}

On the shadow side, the ShadowRoot gets this styling as the styling to inherit from.
By default, it inherits the styling.

=== Preventing automatic inheritance ===

The including document can reset the individual style-attributes to 'initial', to prevent the component from 'snooping' the outside styles.
Conversely, the component can just override the style-attributes to prevent the outside document from interfering with its beautiful designs.

Now, having to reset every possible CSS attribute would be cumbersome, to say the least.
In order to make this useful, attribute group names could be introduced, that set the style for multiple attributes at once.
The only value a group can take is either:

'initial': back to the initial value as determined by the UA
'inherit': inherit from DOM parent

Also note that groups could be overlapping. E.g.,:

all: sets all attributes
color-group: sets color, background-color, border-color
border-group: border-...
background-group: background-...
images-group: background-image, border-image, list-style-image [e.g., prevent image loading]
text-group: color, font-family, font-style, font-weight, letter-spacing, quotes, text-align, text-indend, text-transform, word-spacing, white-space,
list-group: list-style-...
table-group: empty-cells, caption-side,
sound-group: azimuth, elevation, pitch, richness, speak-..., speech-rate, stress, voice-family, volume
paged-group: orphans, widows
visibility: not in a group (only contained in 'all')
cursor: not in a group (only contained in 'all')

E.g.,

x-foo::binding {
images-group: initial; // Don't allow '...-image' attributes to inherit into shadow DOM
border-group: initial; // Don't allow 'border-...' attributes to inherit into shadow DOM
}

within the shadow DOM:

<style scoped>
:scope {
border-group: initial; // Don't allow 'border-...' attributes to be inherited from outside document
table-group: initial; // Don't allow table-related attributes to be inherited from outside document
}
</style>

Other inherited attributes (e.g., text, list styles) would be inherited in this example.
Also note that the above groups with the described behavior could potentially be useful even outside the context of shadow DOM.

A similar mechanism could be used to steer inheritance from the <content> element onto its selected children of the host element.
The selection here is whether to inherit from the host element, or from the style set on <content>.

However, the problem here is that there are more options:

* initial as by the UA (+user sheets)
* original value as passed-in to the shadow DOM (only relevant to the shadow DOM side)
* inherited from the host element (only relevant to the ouside document's side)
* inherited from the <content> element

To this end we might specify additional values besides 'initial' and 'inherited':

'original': back to the value set on the root node (equivalent to 'initial' outside shadow DOMs, the value on ShadowRoot inside shadow DOMs)
'current': use the current render style - this is equivalent to 'inherit' outside the "interference" of a shadow DOM

On the shadow DOM side, "leaking" of styles can be prevented by re-setting attributes/attribute groups on the <content> element:

<style scoped>
content {
images-group: original; // reset '...-image' attributes to as they were set on the ShadowRoot
}
content[clean] {
all: initial; // reset everything to pristine initial values for a <content> element that has the (user) attribute 'clean'.
}
</style>

On the outside document's side we could introduce yet another pseudo-element ::inside that specifies the style to inherit from
(just reusing the name, since this pseude-element already has been proposed once):

x-foo::inside {
all: inherit; // reset all styles to inherit from the host element
background-group: current; // ... except for 'background-...' attributes, which are used with the current style (from <content>)
white-space: initial; // reset 'white-space' to the default value ('normal' in the case of 'white-space')
}

Note: can't use 'x-foo > *' as selector here, because that would "miss" child text nodes!

Another issue:

* Doesn't handle the case where a <content> element selects multiple different elements and wants to style different elements differently.

== Styling the host element ==

If the host element is rendered (this is the current default assumption.)
: If the component is confined (this is the currently thought-of scenario).

:: This requires a second stylesheet in addition to any (scoped) stylesheet within the component.

: If the component is ''not'' confined

:: The component's stylesheet can style the host element directly, not requiring a second stylesheet

:: The host element can be styled by stylesheets from 2 different scopes, requiring a resolution order. Most likely ''author'' > ''component'' > ''user'' > ''UA''.

:: The components stylesheet could be written so as to style descendants of the host element. Preventing this adds additional complexity.

If the host element is NOT rendered
This raises the question how styles that address the host element are to be handled. Most likely by storing the style on the host element, but applying it to the shadow tree instead, causing additional complexity

: If the ShadowRoot is rendered (if it is an element instead of a separate node type)

:: ...

: If the ShadowRoot is not rendered

:: ...

== Styling content elements ==

This has similar issues and raises similar questions as styling the host element.