Component Model Isolation Brainstorming - Revision history

Rolandsteiner: /* Discussion and Caveats */

2011-10-12T05:25:38Z

Discussion and Caveats

← Older revision		Revision as of 05:25, 12 October 2011
Line 117:		Line 117:
	== Discussion and Caveats ==		== Discussion and Caveats ==

	~~At first I'd suggest these attributes to only apply to specific elements, such as <decls>. However, AFAICT,~~ this could ~~be useful~~ on arbitrary elements (?). Also, rather than being simply boolean, they could list a set of keywords '<code>javascript</code>', '<code>events</code>', '<code>css</code>'. e.g., <code>isolated="javascript events"</code> to isolate with regard to scripts and events, but allow CSS through (this would imply that css selectors on style rules can cross the boundary, but the same selector used in <code>querySelector()</code> couldn't). But I'd leave this for when there's an actual use case.		As conceptualized above this could apply on arbitrary elements (?). Also, rather than being simply boolean, they could list a set of keywords '<code>javascript</code>', '<code>events</code>', '<code>css</code>'. e.g., <code>isolated="javascript events"</code> to isolate with regard to scripts and events, but allow CSS through (this would imply that css selectors on style rules can cross the boundary, but the same selector used in <code>querySelector()</code> couldn't). But I'd leave this for when there's an actual use case.

	Isolation/confinement has to be contagious - i.e., a confined <template> cloned into a DocumentFragment must cause the DocumentFragment to be confined. That DocumentFragment appended into a ShadowRoot must cause the ShadowRoot to be confined. (ISSUE: what if there are already methods on the ShadowRoot at this point?)		Isolation/confinement has to be contagious - i.e., a confined <template> cloned into a DocumentFragment must cause the DocumentFragment to be confined. That DocumentFragment appended into a ShadowRoot must cause the ShadowRoot to be confined. (ISSUE: what if there are already methods on the ShadowRoot at this point?)
Line 123:		Line 123:
	One more caveat: <code><decls></code> may need to be special in that <code>isolated</code> and <code>confined</code> are applied as if they'd be present on every child of <code><decls></code> instead. Otherwise, <code><binding></code>s within <code><decls isolated></code> wouldn't be visible from the outside.		One more caveat: <code><decls></code> may need to be special in that <code>isolated</code> and <code>confined</code> are applied as if they'd be present on every child of <code><decls></code> instead. Otherwise, <code><binding></code>s within <code><decls isolated></code> wouldn't be visible from the outside.

	Now, the $1.000 question: how much of the above mirrors <code><iframe></code> and how much could we solve by simply wrapping the shadow contents in an <code><iframe></code> (isolation), or the host element of a component (confinement) - apart from it being awkward?		Now, the $1.000 question: how much of the above mirrors <code><iframe sandbox></code> and how much could we solve by simply wrapping the shadow contents in an <code><iframe></code> (isolation), or the host element of a component (confinement) - apart from it being awkward?

Rolandsteiner: /* Suggested Approach */

2011-10-07T09:10:16Z

Suggested Approach

← Older revision		Revision as of 09:10, 7 October 2011
Line 91:		Line 91:

	== <code>isolated</code> ==		== <code>isolated</code> ==

			(This was termed ''encapsulated'' in [http://wiki.whatwg.org/index.php?title=Component_Model the main component model page]. Using <code>isolated</code> here to make for a shorter keyword.)

	* Events that bubble up to the boundary element are re-targeted to appear as to have originated from the boundary element		* Events that bubble up to the boundary element are re-targeted to appear as to have originated from the boundary element

Rolandsteiner: /* Discussion and Caveats */

2011-10-07T09:05:29Z

Discussion and Caveats

← Older revision		Revision as of 09:05, 7 October 2011
Line 117:		Line 117:
	At first I'd suggest these attributes to only apply to specific elements, such as <decls>. However, AFAICT, this could be useful on arbitrary elements (?). Also, rather than being simply boolean, they could list a set of keywords '<code>javascript</code>', '<code>events</code>', '<code>css</code>'. e.g., <code>isolated="javascript events"</code> to isolate with regard to scripts and events, but allow CSS through (this would imply that css selectors on style rules can cross the boundary, but the same selector used in <code>querySelector()</code> couldn't). But I'd leave this for when there's an actual use case.		At first I'd suggest these attributes to only apply to specific elements, such as <decls>. However, AFAICT, this could be useful on arbitrary elements (?). Also, rather than being simply boolean, they could list a set of keywords '<code>javascript</code>', '<code>events</code>', '<code>css</code>'. e.g., <code>isolated="javascript events"</code> to isolate with regard to scripts and events, but allow CSS through (this would imply that css selectors on style rules can cross the boundary, but the same selector used in <code>querySelector()</code> couldn't). But I'd leave this for when there's an actual use case.

	Isolation/confinement has to be contagious - i.e., a confined <template> cloned into a DocumentFragment must cause the DocumentFragment to be confined. That DocumentFragment appended into a ShadowRoot must cause the ShadowRoot to be confined.		Isolation/confinement has to be contagious - i.e., a confined <template> cloned into a DocumentFragment must cause the DocumentFragment to be confined. That DocumentFragment appended into a ShadowRoot must cause the ShadowRoot to be confined. (ISSUE: what if there are already methods on the ShadowRoot at this point?)

	One more caveat: <code><decls></code> may need to be special in that <code>isolated</code> and <code>confined</code> are applied as if they'd be present on every child of <code><decls></code> instead. Otherwise, <code><binding></code>s within <code><decls isolated></code> wouldn't be visible from the outside.		One more caveat: <code><decls></code> may need to be special in that <code>isolated</code> and <code>confined</code> are applied as if they'd be present on every child of <code><decls></code> instead. Otherwise, <code><binding></code>s within <code><decls isolated></code> wouldn't be visible from the outside.

	Now, the $1.000 question: how much of the above mirrors <code><iframe></code> and how much could we solve by simply wrapping the shadow contents in an <code><iframe></code> (isolation), or the host element of a component (confinement) - apart from it being awkward?		Now, the $1.000 question: how much of the above mirrors <code><iframe></code> and how much could we solve by simply wrapping the shadow contents in an <code><iframe></code> (isolation), or the host element of a component (confinement) - apart from it being awkward?

Rolandsteiner: /* confined */ clarification

2011-10-07T09:04:18Z

confined: clarification

← Older revision		Revision as of 09:04, 7 October 2011
Line 110:		Line 110:
	* Style rules set within the boundary will not apply to elements outside		* Style rules set within the boundary will not apply to elements outside
	* Scripts within the boundary are run as if loaded by a separate document. They have no access to the containing document, nor its DOM.		* Scripts within the boundary are run as if loaded by a separate document. They have no access to the containing document, nor its DOM.
	* <code>:root</code> will be equal to the boundary element, as will <code>:scope</code> by default		* To scripts within the confinement, the boundary element's <code>parentNode</code> will be null.
			* <code>:root</code> will be equal to the boundary element, as will <code>:scope</code> by default.

	== Discussion and Caveats ==		== Discussion and Caveats ==

Rolandsteiner: /* isolated */

2011-10-07T09:02:52Z

isolated

← Older revision		Revision as of 09:02, 7 October 2011
Line 98:		Line 98:
	* the boundary element's <code>.innerHTML</code> will return an empty string, <code>.outerHTML</code> will return no content between the boundary element tags		* the boundary element's <code>.innerHTML</code> will return an empty string, <code>.outerHTML</code> will return no content between the boundary element tags
	* the boundary element appears as if it has no children		* the boundary element appears as if it has no children
	* the boundary element's <code>appendChild()</code> and <code>~~insertBefore~~()</code> will throw		* the boundary element's <code>appendChild()</code>, <code>insertBefore()</code> and <code>removeChild()</code> will throw

	== <code>sealed</code> ==		== <code>sealed</code> ==

Rolandsteiner: /* confined */ remove incorrect clause

2011-10-07T09:01:50Z

confined: remove incorrect clause

← Older revision		Revision as of 09:01, 7 October 2011
Line 110:		Line 110:
	* Style rules set within the boundary will not apply to elements outside		* Style rules set within the boundary will not apply to elements outside
	* Scripts within the boundary are run as if loaded by a separate document. They have no access to the containing document, nor its DOM.		* Scripts within the boundary are run as if loaded by a separate document. They have no access to the containing document, nor its DOM.
	* the boundary element's .parentNode will return null
	* <code>:root</code> will be equal to the boundary element, as will <code>:scope</code> by default		* <code>:root</code> will be equal to the boundary element, as will <code>:scope</code> by default

Rolandsteiner: /* Discussion and Caveats */

2011-10-07T08:57:25Z

Discussion and Caveats

← Older revision		Revision as of 08:57, 7 October 2011
Line 117:		Line 117:
	At first I'd suggest these attributes to only apply to specific elements, such as <decls>. However, AFAICT, this could be useful on arbitrary elements (?). Also, rather than being simply boolean, they could list a set of keywords '<code>javascript</code>', '<code>events</code>', '<code>css</code>'. e.g., <code>isolated="javascript events"</code> to isolate with regard to scripts and events, but allow CSS through (this would imply that css selectors on style rules can cross the boundary, but the same selector used in <code>querySelector()</code> couldn't). But I'd leave this for when there's an actual use case.		At first I'd suggest these attributes to only apply to specific elements, such as <decls>. However, AFAICT, this could be useful on arbitrary elements (?). Also, rather than being simply boolean, they could list a set of keywords '<code>javascript</code>', '<code>events</code>', '<code>css</code>'. e.g., <code>isolated="javascript events"</code> to isolate with regard to scripts and events, but allow CSS through (this would imply that css selectors on style rules can cross the boundary, but the same selector used in <code>querySelector()</code> couldn't). But I'd leave this for when there's an actual use case.

	One more caveat: <code><decls></code> may need to be special in that <code>isolated</code> and <code>confined</code> are applied as if they'd be present on every child of <code><decls></code> instead. Otherwise, <code><binding></code>s within <code><decls isolated></code> wouldn't be visible from the outside...		Isolation/confinement has to be contagious - i.e., a confined <template> cloned into a DocumentFragment must cause the DocumentFragment to be confined. That DocumentFragment appended into a ShadowRoot must cause the ShadowRoot to be confined.

			One more caveat: <code><decls></code> may need to be special in that <code>isolated</code> and <code>confined</code> are applied as if they'd be present on every child of <code><decls></code> instead. Otherwise, <code><binding></code>s within <code><decls isolated></code> wouldn't be visible from the outside.

	Now, the $1.000 question: how much of the above mirrors <code><iframe></code> and how much could we solve by simply wrapping the shadow contents in an <code><iframe></code> (isolation), or the host element of a component (confinement) - apart from it being awkward?		Now, the $1.000 question: how much of the above mirrors <code><iframe></code> and how much could we solve by simply wrapping the shadow contents in an <code><iframe></code> (isolation), or the host element of a component (confinement) - apart from it being awkward?

Rolandsteiner: Add description of suggested 'isolated' and 'confined' attributes

2011-10-06T04:08:10Z

Add description of suggested 'isolated' and 'confined' attributes

@@ Line 1: / Line 1: @@
-= Component Model Isolation Brainstorming =
+= Overview =
 Depending on the source and the purpose of a component it may be desirable to limit access to the component from the containing document, or vice versa. E.g., a page may want to include components from a third party out of convenience, but limit the access those components have to other contents of the page. Conversely, a component with a complicated internal structure and scripting may want to disallow the containing page from (inadvertently, perhaps) meddling with its internal structure. There are several dimensions to this problem:
@@ Line 85: / Line 85: @@
 '''Exception''': The <code>&lt;content&gt;</code> element has the <code>apply-binding-sheets</code> attribute AND the containing document or template does not prohibit that it's ok that bindings from that source act as inheritance parent (default: allowed) (TODO: how?)

Rolandsteiner: Brainstorming stub

2011-08-03T00:45:10Z

Brainstorming stub

New page

= Component Model Isolation Brainstorming =

Depending on the source and the purpose of a component it may be desirable to limit access to the component from the containing document, or vice versa. E.g., a page may want to include components from a third party out of convenience, but limit the access those components have to other contents of the page. Conversely, a component with a complicated internal structure and scripting may want to disallow the containing page from (inadvertently, perhaps) meddling with its internal structure. There are several dimensions to this problem:

* DOM access via JavaScript
* event propagation
* CSS
** styling
** changing of display type, or setting display: none
** generated content

Note that since components may include other components, "containing document" may also refer to "containing component", or - to be more general - "containing tree scopes".

=== Component distrusts Document ===

==== JavaScript ====

* <code>getElementById()</code>, <code>getElementsByTagName()</code>, <code>getElementsByName()</code> and <code>getElementsByClassName()</code> (and their <code>...NS</code> incarnations) do not reach into shadow trees.

'''Exception''': ''none''

* <code>querySelector()</code> and <code>querySelectorAll()</code> do not reach into shadow trees, even when using a shadow pseudo-ID (!).

'''Exception''': ''none''

* The host element's <code>.shadow</code> property is ''null'' (TODO: as an alternative, accessing it throws an exception?).

'''Exception''': TODO: the template has the attribute <code>allow-shadow-accessor</code> (?)

==== CSS ====

* Style rules of the containing document do ''not'' match nodes in the shadow tree.

'''Exception''': Shadow tree elements that have explicit <code>pseudoID</code> attributes may match, provided they are explicitly matched by an equivalent pseudo-element selector.

'''Exception''': The template has the <code>allow-selectors-through</code> attribute: outside selectors may cross into the shadow tree.

'''Exception''': The template has the <code>apply-author-sheets</code> attribute: outside selectors may be applied fully within the shadow tree. (TODO: is that really required on top of <code>allow-selectors-through</code>?)

* Nodes in the shadow tree do not inherit styles from the host element

'''Exception''': TODO: define a shadow tree to reset all CSS attributes to <code>initial</code>, but allow a (scoped) style sheet to set them to <code>inherit</code>?

* A child or descendant selector of a shadow pseudo-ID selector (e.g., <code>host::pseudo div</code>) does ''not'' match, even if the shadow tree's element with pseudo-ID <code>pseudo</code> does happen to have a <code><div></code> descendant. In other words, the shadow pseudo-ID simple selector(s) must be a member of the last selector sequence.

'''Exception''': ''none''

* TODO: prevent setting <code>display</code> and <code>content</code>?

'''Exception''': TODO: see "CSS filtering" below.

* TODO: prevent generated content - i.e., <code>::before</code> and <code>::after</code>?

'''Exception''': TODO: ?

* TODO: in general, add a way to specify specifically which CSS attributes are allowed?

=== Document distrusts Component ===

==== JavaScript ====

* A component does ''not'' have access to <code>document</code>, nor <code>windows</code>. <code>treeScope.document</code> returns ''null'' (TODO: throws?).

'''Exception''': The document specifies that it's ok that bindings from that source access its DOM (TODO: how?).

* A component has access to its tree scope, but not to its parent tree scope. <code>treeScope.parentTreeScope</code> returns ''null'' (TODO: throws?).

'''Exception''': The parent tree scope (document or template) specifies that it's ok that bindings from that source access its DOM (TODO: how?).

* A component does ''not'' have access to its host element. <code>element.treeScope.hostElement</code> is ''null'' (TODO: throws?).

'''Exception''': The containing document or template specifies that it's ok that bindings from that source access the host element (TODO: how?)

* TODO: Communication to the containing page takes place via attribute-forwarding and events?

TODO: is it safe to allow the document to grant access to the <code>document</code> or <code>window</code> object to a component, even considering that that component might be included as part of a different component elsewhere? In this case the nested component could manipulate the document, and the document's DOM, but if the containing component distrusts the document (and by extension presumably the nested component as well), it would not get access to the containing component from the document.

==== CSS ====

* Style rules are not applied to nodes outside the shadow tree, even if declared in style sheets that are defined or imported via <code><style></code> that has no ''scoped'' attribute. <code><style></code> elements within a shadow tree that don't have the <code>scoped</code> attribute set must be treated as if it was set and every rule was prefixed with <code>:root</code>.

'''Exception''': The containing document or template does not prohibit that style sheets of bindings from that source may affect its nodes (default: allowed) (TODO: how?)

* Children of the host element do ''not'' inherit styles from a shadow tree's <code><content></code> element that they are rendered "under".

'''Exception''': The <code><content></code> element has the <code>apply-binding-sheets</code> attribute AND the containing document or template does not prohibit that it's ok that bindings from that source act as inheritance parent (default: allowed) (TODO: how?)