Component Model Strawman: Declarative Syntax - Revision history

Morrita: /* Shadow DOM Template */

2011-10-27T21:12:42Z

Shadow DOM Template

@@ Line 2: / Line 2: @@
 Moved to [[Component_Model_Strawman:_Element_Registration]]
 = Isolation =
 Moved to [[Component_Model_Strawman:_Isolation]]

Morrita: /* Isolation */

2011-10-27T21:12:25Z

Isolation

← Older revision		Revision as of 21:12, 27 October 2011
Line 91:		Line 91:

	= Isolation =		= Isolation =

	~~== Standalone Form ==~~

	Moved to [[Component_Model_Strawman:_Isolation]]		Moved to [[Component_Model_Strawman:_Isolation]]

	~~== Shared definition ==~~

	~~In the default, these definitions are coming into the host document.~~
	~~That means a providing HTML doesn’t have its own document nor the global object. Agents use these of the host document.~~

	~~== Isolated definition ==~~

	~~If the <tt>rel</tt> attribute contains the term <tt>isolate</tt>, the linked HTML is loaded as a separate document object.~~
	~~The script inside the document is given a separate global object.~~

	~~For the host document, there is no way to access the loaded document directly.~~

	~~<pre>~~

	~~<html>~~
	~~<head>~~
	~~<link rel=”component” type=”text/html” href="comment.html" confined>~~
	~~</head>~~
	~~</html>~~

	~~</pre>~~

	[[User:Rolandsteiner\|RolandSteiner]] Should we make <tt>isolate</tt> an attribute on <tt>link</tt> rather than a <tt>rel</tt> value? As Dimitri mentioned, this could be useful in general and would allow us to branch it off into a separate spec.

	[[User:Morrita\|Morrita]] Any declarative syntax is a part of other spec. This is cross-cutting view of multiple proposals. moved out confined declaration to standalone attribute. I have no idea how this works for other types of linked resources though.

Morrita: /* Standalone Form */

2011-10-27T20:43:29Z

Standalone Form

@@ Line 94: / Line 94: @@
 == Standalone Form ==
-The element registration and template definition are also done in a separate HTML.
+Moved to [[Component_Model_Strawman:_Isolation]]
 == Shared definition ==

Morrita: /* Element Registration */

2011-10-26T20:09:04Z

Element Registration

@@ Line 1: / Line 1: @@
 = Element Registration =
-Let’s start from the minimum form of the element registration.
+Moved to [[Component_Model_Strawman:_Element_Registration]]
 = Shadow DOM Template =

Morrita: /* Scripting */

2011-10-26T16:56:33Z

Scripting

← Older revision		Revision as of 16:56, 26 October 2011
Line 34:		Line 34:
	</pre>		</pre>

	~~Using <tt>~~HTMLElementElement~~.register()</tt>~~, ~~authors~~ can register a ~~set~~ of lifecycle ~~callbacks~~ for ~~each~~ registered element.		By setting the properties on HTMLElementElement, author can register a series of lifecycle hooks for the registered element.
	There are two types of lifecycle event: <tt>~~open~~</tt> and <tt>~~close~~</tt>. The ~~open~~ is for creating the new instance of the <tt>Element</tt>.		There are two types of lifecycle event: <tt>create</tt> and <tt>init</tt>. The <tt>create</tt> is for creating the new instance of the <tt>Element</tt>.
	You can override the constructor of the element by providing <tt>~~open~~</tt> callback.		You can override the constructor of the element by providing <tt>create</tt> callback.
	The <tt>~~close~~</tt> callback provides the way to enhance created instance.		The <tt>init</tt> callback provides the way to enhance created instance.
	This is useful when you use given attributes to define the behavior.		This is useful when you use given attributes to define the behavior.

	To make the definition self-contained, we can put a <tt>script</tt> ~~blocks~~ inside an <tt>element</tt> element.		To make the definition self-contained, we can put a <tt>script</tt> block inside an <tt>element</tt> element.

	<pre>		<pre>
Line 54:		Line 54:

	this.create = Comment;		this.create = Comment;
			this.init = function(element) { element.init(); };
	</script>		</script>
	</element>		</element>

Morrita: /* Scripting */

2011-10-26T16:44:45Z

Scripting

← Older revision		Revision as of 16:44, 26 October 2011
Line 48:		Line 48:
	<script>		<script>
	class Comment : HTMLElement {		class Comment : HTMLElement {
			HTMLElement.call(this);
	this.shadow = new ShawowRoot(this);		this.shadow = new ShawowRoot(this);
	..;		..;

Morrita: /* Scripting */

2011-10-26T16:30:08Z

Scripting

← Older revision		Revision as of 16:30, 26 October 2011
Line 52:		Line 52:
	}		}

	~~HTMLElementElement~~.~~current.open~~ = ~~function() { return new~~ Comment~~(); }})~~;		this.create = Comment;
	</script>		</script>
	</element>		</element>
Line 59:		Line 59:
	</pre>		</pre>

	In this example, the script refers ~~a static property called~~ <tt>~~HTMLElementElement.current~~</tt>,		In this example, the script refers <tt>this</tt>, which points the enclosing <tt>element</tt> element.
	which points the enclosing <tt>element</tt> element.		This example also shows how we can provide an <tt>create</tt> lifecycle callback.
	This example also shows how we can provide an <tt>~~open~~</tt> lifecycle callback.
			* TODO: What is the context of the script block? Is the "Comment" class visible globally? How to explain that?
			* TODO: How to define "constructor" semantics using WebIDL?
			* TODO: Is it possible to define a new element without subclassing?

	== Styling ==		== Styling ==

Morrita at 16:26, 26 October 2011

2011-10-26T16:26:11Z

← Older revision		Revision as of 16:26, 26 October 2011
Line 174:		Line 174:

	The element registration and template definition are also done in a separate HTML.		The element registration and template definition are also done in a separate HTML.
	~~Each HTML file which provides the element registration should have a <tt>provide</tt> attribute on the root html element.~~		Effective markup vocabulary for the defining HTML is limited.
	~~This attribute prevents accidental loading of existing HTML files.~~

	Effective markup vocabulary for the ~~providing~~ HTML is limited.
	Agents only recognize a head element as a child of the root element when the HTML document is loaded as required.		Agents only recognize a head element as a child of the root element when the HTML document is loaded as required.

	<pre>		<pre>

	<html ~~provide~~>		<html>
	<head>		<head>
	<element for="x-comment">..</element>		<element for="x-comment">..</element>
Line 242:		Line 239:
	<html>		<html>
	<head>		<head>
	<link rel=~~”component; isolate”~~ type=”text/html” href="comment.html">		<link rel=”component” type=”text/html” href="comment.html" confined>
	</head>		</head>
	</html>		</html>
Line 250:		Line 247:
	[[User:Rolandsteiner\|RolandSteiner]] Should we make <tt>isolate</tt> an attribute on <tt>link</tt> rather than a <tt>rel</tt> value? As Dimitri mentioned, this could be useful in general and would allow us to branch it off into a separate spec.		[[User:Rolandsteiner\|RolandSteiner]] Should we make <tt>isolate</tt> an attribute on <tt>link</tt> rather than a <tt>rel</tt> value? As Dimitri mentioned, this could be useful in general and would allow us to branch it off into a separate spec.

	[[User:Morrita\|Morrita]] Any declarative syntax is a part of other spec. This is cross-cutting view of multiple proposals.		[[User:Morrita\|Morrita]] Any declarative syntax is a part of other spec. This is cross-cutting view of multiple proposals. moved out confined declaration to standalone attribute. I have no idea how this works for other types of linked resources though.

Morrita: /* Isolated definition */

2011-10-25T20:16:00Z

Isolated definition

← Older revision		Revision as of 20:16, 25 October 2011
Line 249:		Line 249:

	[[User:Rolandsteiner\|RolandSteiner]] Should we make <tt>isolate</tt> an attribute on <tt>link</tt> rather than a <tt>rel</tt> value? As Dimitri mentioned, this could be useful in general and would allow us to branch it off into a separate spec.		[[User:Rolandsteiner\|RolandSteiner]] Should we make <tt>isolate</tt> an attribute on <tt>link</tt> rather than a <tt>rel</tt> value? As Dimitri mentioned, this could be useful in general and would allow us to branch it off into a separate spec.

			[[User:Morrita\|Morrita]] Any declarative syntax is a part of other spec. This is cross-cutting view of multiple proposals.

Morrita: /* Styling */

2011-10-25T20:12:22Z

Styling

← Older revision		Revision as of 20:12, 25 October 2011
Line 65:		Line 65:
	== Styling ==		== Styling ==

	The <tt>element</tt> element allows a <tt>style</tt> element as a child,		The <tt>element</tt> element allows a <tt>style</tt> element as a child.
	~~which accept~~ <tt>~~:current~~</tt> ~~pseudo-class to specify the registering element.~~		This <tt>style</tt> is part of the document stylesheet.

	~~Following example gives "color: gray" to~~ the ~~<tt>x-comment</tt> element~~.

	<pre>		<pre>
Line 75:		Line 73:
	<element for="x-comment">		<element for="x-comment">
	<style>		<style>
	~~:current~~ {		x-comment {
	color: gray;		color: gray;
	}		}
Line 83:		Line 81:

	</pre>		</pre>

	[[User:Rolandsteiner\|RolandSteiner]] IMHO it's simpler to just create a 'x-comment' style rule in some style sheet within the head. This way we don't need to add a :current pseudo-class. Also, there's no way we could limit the style rules within <tt>element</tt> to only affect that element anyway.

	= Shadow DOM Template =		= Shadow DOM Template =