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 Discussion: Difference between revisions

From WHATWG Wiki
Jump to navigation Jump to search
No edit summary
(→‎Issues: Add categories "Now", "Soon", "Later")
Line 10: Line 10:


= Issues =
= Issues =
* '''<span style="color: #006633">Now</span>''': issues regarding parts that are already implemented
* '''<span style="color: #008866">Soon</span>''': issues regarding parts that we intend to implement soon
* '''<span style="color: #00AA88">Later</span>''': issues regarding parts that we intend to postpone (may change substantially and/or not be implemented at all)


== CSS and Rendering ==
== CSS and Rendering ==
Line 16: Line 20:
* [http://wiki.whatwg.org/wiki/Component_Model_CSS_Brainstorming CSS brainstorming page]: brainstorming on alternative solutions to styling
* [http://wiki.whatwg.org/wiki/Component_Model_CSS_Brainstorming CSS brainstorming page]: brainstorming on alternative solutions to styling


Other issues:
=== <span style="color: #006633">Now</span> ===


* styling of rendering children of &lt;content&gt; (partially discussed in the [http://wiki.whatwg.org/wiki/Component_Model_CSS_Brainstorming CSS brainstorming page]).
* Do components create a layer?
* Do components create a layer?
** <span style="color: blue">assumption: no</span>
** <span style="color: blue">assumption: no</span>
::[[User:Dglazkov|Dglazkov]]: isn't this an implementation detail?
::[[User:Dglazkov|Dglazkov]]: isn't this an implementation detail?
=== <span style="color: #008866">Soon</span> ===
* styling of rendering children of &lt;content&gt; (partially discussed in the [http://wiki.whatwg.org/wiki/Component_Model_CSS_Brainstorming CSS brainstorming page]).
=== <span style="color: #00AA88">Later</span> ===
* tab-index behavior
* tab-index behavior
* z-order behavior
* z-order behavior


== Shadow Nodes ==
== Shadow Nodes ==
=== <span style="color: #006633">Now</span> ===


* shadow root being a separate node type vs. an element vs. document fragment vs. ??? (see [http://wiki.whatwg.org/index.php?title=Component_Model_Discussion:_Rendering rendering sub-page])
* shadow root being a separate node type vs. an element vs. document fragment vs. ??? (see [http://wiki.whatwg.org/index.php?title=Component_Model_Discussion:_Rendering rendering sub-page])
** <span style="color: purple">current state: separate node type</span>
** <span style="color: purple">current state: separate node type</span>
* Can the same host element child be rendered under multiple &lt;content&gt; elements that all select it?
** <span style="color:blue">assumption: no - the first to select it "gets" it. &lt;content&gt; without <code>select</code> is always last in this regard</span>
* Is &lt;content&gt; is a bona-fide HTML element (vs. a DOM subtype)?
** <span style="color: blue">assumption: HTML element</span>
=== <span style="color: #008866">Soon</span> ===
* Does ShadowRoot have innerHTML?
* Does ShadowRoot have innerHTML?
** <span style="color: blue">assumption: yes</span>
** <span style="color: blue">assumption: yes</span>
Line 34: Line 54:
** <span style="color:blue">suggestion: space-separated list of selector sequences: [tag]?[class]*[id]*[attr]*[pseudo-class]* (NO pseudo-elements)</span>
** <span style="color:blue">suggestion: space-separated list of selector sequences: [tag]?[class]*[id]*[attr]*[pseudo-class]* (NO pseudo-elements)</span>
::[[User:Dglazkov|Dglazkov]]: will space-separation be confusing? I like the idea, but just thought I should raise this as a concern.
::[[User:Dglazkov|Dglazkov]]: will space-separation be confusing? I like the idea, but just thought I should raise this as a concern.
* Can the same host element child be rendered under multiple &lt;content&gt; elements that all select it?
:::[[User:Rolandsteiner|Rolandsteiner]]: I thought a space-separated list follows HTML conventions more closely, but perhaps to draw an analogue to CSS (and to allow potential later extensions), a comma-separated list may be better (?).
** <span style="color:blue">assumption: no - the first to select it "gets" it. &lt;content&gt; without <code>select</code> is always last in this regard</span>
 
* Is &lt;content&gt; is a bona-fide HTML element (vs. a DOM subtype)?
** <span style="color: blue">assumption: HTML element</span>


== Events ==
== Events ==
=== <span style="color: #008866">Soon</span> ===


* focus event traversing out of shadow?
* focus event traversing out of shadow?
** <span style="color: blue">assumption: yes, redirected</span>
** <span style="color: blue">assumption: yes, redirected</span>
** <span style="color: purple">current state: not implemented</span>
** <span style="color: purple">current state: not implemented</span>
=== <span style="color: #00AA88">Later</span> ===
* instantiation events (which events & when?)
* instantiation events (which events & when?)
** for <template> instantiations
** for <template> instantiations
Line 51: Line 74:


== Loading and Life Cycle ==
== Loading and Life Cycle ==
=== <span style="color: #008866">Soon</span> ===


* loading mechanism (syntax)
* loading mechanism (syntax)
Line 58: Line 83:
* is it possible to rename a component? e.g., to avoid name clashes?
* is it possible to rename a component? e.g., to avoid name clashes?
** <span style="color:blue">assumption: no</span>
** <span style="color:blue">assumption: no</span>
* define all edge cases and “unhappy” cases. Examples: constructor throws exception (general case), constructor throws exception during parsing
=== <span style="color: #00AA88">Later</span> ===
* is it possible to have a scoped (private) names, e.g., for private components?
* is it possible to have a scoped (private) names, e.g., for private components?
** <span style="color:blue">assumption: no</span>
** <span style="color:blue">assumption: no</span>
* define all edge cases and “unhappy” cases. Examples: constructor throws exception (general case), constructor throws exception during parsing
* Is it possible to undefine a component? (if yes, how?)
* Is it possible to undefine a component? (if yes, how?)
** <span style="color:blue">assumption: no</span>
** <span style="color:blue">assumption: no</span>


== Registration ==
== Registration ==
=== <span style="color: #008866">Soon</span> ===


* how to handle name clashes between components?
* how to handle name clashes between components?
Line 84: Line 115:
* Are shadow trees dynamic or static?
* Are shadow trees dynamic or static?
** <span style="color:blue">assumption: static, but see discussion in [email protected] ML</span>
** <span style="color:blue">assumption: static, but see discussion in [email protected] ML</span>
=== <span style="color: #00AA88">Later</span> ===
* accessibility (implicit, e.g. with &lt;button is=mywidget&gt;, explicit, e.g., with ARIA roles)
* accessibility (implicit, e.g. with &lt;button is=mywidget&gt;, explicit, e.g., with ARIA roles)


== Derivation ==
== Derivation ==
=== <span style="color: #006633">Now</span> ===


* should we do XBL-like inheritance?
* should we do XBL-like inheritance?
** <span style="color:blue">assumption: no</span>
** <span style="color:blue">assumption: no</span>
=== <span style="color: #00AA88">Later</span> ===
* “aspect-oriented" components (components defining the parts they use, derived components can override or re-use specific parts, part names automatically become pseudos)
* “aspect-oriented" components (components defining the parts they use, derived components can override or re-use specific parts, part names automatically become pseudos)
* composition vs. inheritance (i.e., do we need inheritance at all, or can composition handle all use cases?)
* composition vs. inheritance (i.e., do we need inheritance at all, or can composition handle all use cases?)
** <span style="color:blue">temporary assumption: composition only</span>
** <span style="color:blue">temporary assumption: composition only</span>


== JavaScript  ==
== JavaScript  ==


=== Subtyping of DOM Objects===
=== <span style="color: #006633">Now</span> ===


* Can one subtype anything (text/attribute nodes, events, ...), or just HTMLElement?
* Can one subtype anything (text/attribute nodes, events, ...), or just HTMLElement?
** <span style="color:blue">assumption: just HTML element</span>
** <span style="color:blue">assumption: just HTML element</span>
* details of construction
* details of construction
* can one write a constructor with <supertype>.call(...), or does one have to use createElement?


=== Isolation/Confinement ===
=== <span style="color: #008866">Soon</span> ===
 
* JS implementation details
 
=== Forwarding ===
 
examples: sub-classing &lt;textarea&gt; (Maciej’s examples), auto-completion, omni-bar like drop-down, toolbar
 
* JS implementation details
 
=== Other ===


* can one write a constructor with <supertype>.call(...), or does one have to use createElement?
* Isolation/Confinement JS implementation details
* Forwarding JS implementation details (ex: sub-classing &lt;textarea&gt; (Maciej’s examples), auto-completion, omni-bar like drop-down, toolbar)
* how to handle Element.register being overwritten?
* how to handle Element.register being overwritten?
** <span style="color:blue">assumption: don't care</span>
** <span style="color:blue">assumption: don't care</span>
* how to handle, e.g., appendChild being overwritten on a component?
* how to handle, e.g., appendChild being overwritten on a component?
** <span style="color:blue">assumption: don't care</span>
** <span style="color:blue">assumption: don't care</span>


== Isolation and Confinement ==
== Isolation and Confinement ==


(see also the [http://wiki.whatwg.org/wiki/Component_Model_Isolation_Brainstorming isolation brainstorming page])
(see also the [http://wiki.whatwg.org/wiki/Component_Model_Isolation_Brainstorming isolation brainstorming page])
=== <span style="color: #008866">Soon</span> ===


* To what degree is isolation/confinement really necessary? (scripts? DOM access? CSS properties?)
* To what degree is isolation/confinement really necessary? (scripts? DOM access? CSS properties?)
Line 128: Line 164:
* Can we substitute isolation with &lt;iframe&gt;s?
* Can we substitute isolation with &lt;iframe&gt;s?
* Are instances of the same component isolated from each other?
* Are instances of the same component isolated from each other?
** <span style="color:blue">assumption: yes, but they should be able to set up shared data structures</span>
* Are instances of the components from the same domain isolated from each other?
* Are instances of the components from the same domain isolated from each other?
** <span style="color:blue">assumption: yes, but they should be able to set up shared data structures</span>
* Can instances of the same component share data somehow?
* Can instances of the same component share data somehow?
** <span style="color:blue">assumption: yes (how?)</span>
* Can instances of the same component and its derivatives share data somehow?
* Can instances of the same component and its derivatives share data somehow?
** <span style="color:blue">assumption: yes (how?)</span>
* Can instances of the components from the same domain share data somehow?
* Can instances of the components from the same domain share data somehow?
** <span style="color:blue">assumption: yes (how?)</span>
* Can isolated components position content outside the host boundary rect? (if not, problems with, e.g., +1 widget)
* Can isolated components position content outside the host boundary rect? (if not, problems with, e.g., +1 widget)
** <span style="color:blue">assumption: yes</span>
** <span style="color:blue">assumption: yes</span>


== Declarative syntax ==
== Declarative syntax ==
=== <span style="color: #008866">Soon</span> ===


* how/when to run scripts?
* how/when to run scripts?
Line 143: Line 187:
** instantiable without explicit components (e.g., &lt;instance select=”x-cyberdyne-terminator”&gt;)
** instantiable without explicit components (e.g., &lt;instance select=”x-cyberdyne-terminator”&gt;)
** event handler registration syntax
** event handler registration syntax
** introduce template types (e.g., &lt;template type=”django”&gt;)?
*** <span style="color:blue">assumption: no</span>
* &lt;element&gt; details
* &lt;element&gt; details
* Do we need &lt;binding&gt; as well?
* Do we need &lt;binding&gt; as well?
* How to define the API of components
* How to define the API of components
=== <span style="color: #00AA88">Later</span> ===
* &lt;template&gt;: introduce template types (e.g., &lt;template type=”django”&gt;)?
** <span style="color:blue">assumption: no</span>


== Misc. ==
== Misc. ==
=== <span style="color: #006633">Now</span> ===
* How can we split the spec into (more) different parts?
=== <span style="color: #00AA88">Later</span> ===


* Do we define the shadow DOM (or parts thereof) of built-in elements?
* Do we define the shadow DOM (or parts thereof) of built-in elements?
** <span style="color:blue">assumption: no</span>
** <span style="color:blue">assumption: no</span>
* How can we split the spec into (more) different parts?

Revision as of 05:42, 11 October 2011

Overview

This document attempts to exhaustively list issues that we feel are unanswered or ambiguous.

Linked pages:

Issues

  • Now: issues regarding parts that are already implemented
  • Soon: issues regarding parts that we intend to implement soon
  • Later: issues regarding parts that we intend to postpone (may change substantially and/or not be implemented at all)

CSS and Rendering

Now

  • Do components create a layer?
    • assumption: no
Dglazkov: isn't this an implementation detail?

Soon

Later

  • tab-index behavior
  • z-order behavior


Shadow Nodes

Now

  • shadow root being a separate node type vs. an element vs. document fragment vs. ??? (see rendering sub-page)
    • current state: separate node type
  • Can the same host element child be rendered under multiple <content> elements that all select it?
    • assumption: no - the first to select it "gets" it. <content> without select is always last in this regard
  • Is <content> is a bona-fide HTML element (vs. a DOM subtype)?
    • assumption: HTML element

Soon

  • Does ShadowRoot have innerHTML?
    • assumption: yes
  • details of <content> selector syntax
    • suggestion: space-separated list of selector sequences: [tag]?[class]*[id]*[attr]*[pseudo-class]* (NO pseudo-elements)
Dglazkov: will space-separation be confusing? I like the idea, but just thought I should raise this as a concern.
Rolandsteiner: I thought a space-separated list follows HTML conventions more closely, but perhaps to draw an analogue to CSS (and to allow potential later extensions), a comma-separated list may be better (?).


Events

Soon

  • focus event traversing out of shadow?
    • assumption: yes, redirected
    • current state: not implemented

Later

  • instantiation events (which events & when?)
    • for <template> instantiations
    • for component instances
    • on rebinding? (provided CSS 'binding' is possible)
  • event on component registration?

Loading and Life Cycle

Soon

  • loading mechanism (syntax)
  • How to handle definition after use
    • assumption: don't do anything
  • packaging
  • is it possible to rename a component? e.g., to avoid name clashes?
    • assumption: no
  • define all edge cases and “unhappy” cases. Examples: constructor throws exception (general case), constructor throws exception during parsing

Later

  • is it possible to have a scoped (private) names, e.g., for private components?
    • assumption: no
  • Is it possible to undefine a component? (if yes, how?)
    • assumption: no


Registration

Soon

  • how to handle name clashes between components?
    • assumption: teach authors to add unique prefix, e.g., <x-cyberdyne-terminator>
  • details on attaching a shadow tree?
    • <x-mywidget>
      • Pros: flexible, tag is inherently static, most performant
      • Cons: accessibility, fall-back
        • <div becomes=mywidget> even more problematic in these regards and also requires duplication of style rules (?)
    • <button is=mywidget>
      • Pros: accessibility of base element, natural fallback
      • Cons: not a priori obvious that 'is' cannot be rebound, limited to existing element names
    • CSS binding: button { binding: mywidget; }
      • Pros: accessibility and fallback, most flexible
      • Cons: implementation is hard, multiple (perhaps mutually exclusive) bindings may apply, cannot extend the API
    • other?
Dglazkov: Hixie suggested a mix of decorator and element, where the API is bound using magic attribute and shadow tree + events are bound using css binding.
  • fallback mechanisms (implicit with <button is=mywidget>, explicit, e.g., with fallback content as children)
  • Are shadow trees dynamic or static?

Later

  • accessibility (implicit, e.g. with <button is=mywidget>, explicit, e.g., with ARIA roles)


Derivation

Now

  • should we do XBL-like inheritance?
    • assumption: no

Later

  • “aspect-oriented" components (components defining the parts they use, derived components can override or re-use specific parts, part names automatically become pseudos)
  • composition vs. inheritance (i.e., do we need inheritance at all, or can composition handle all use cases?)
    • temporary assumption: composition only


JavaScript

Now

  • Can one subtype anything (text/attribute nodes, events, ...), or just HTMLElement?
    • assumption: just HTML element
  • details of construction

Soon

  • can one write a constructor with <supertype>.call(...), or does one have to use createElement?
  • Isolation/Confinement JS implementation details
  • Forwarding JS implementation details (ex: sub-classing <textarea> (Maciej’s examples), auto-completion, omni-bar like drop-down, toolbar)
  • how to handle Element.register being overwritten?
    • assumption: don't care
  • how to handle, e.g., appendChild being overwritten on a component?
    • assumption: don't care


Isolation and Confinement

(see also the isolation brainstorming page)

Soon

  • To what degree is isolation/confinement really necessary? (scripts? DOM access? CSS properties?)
  • How far is isolation/confinement handling for components similar to <iframe>?
  • Can we substitute isolation with <iframe>s?
  • Are instances of the same component isolated from each other?
    • assumption: yes, but they should be able to set up shared data structures
  • Are instances of the components from the same domain isolated from each other?
    • assumption: yes, but they should be able to set up shared data structures
  • Can instances of the same component share data somehow?
    • assumption: yes (how?)
  • Can instances of the same component and its derivatives share data somehow?
    • assumption: yes (how?)
  • Can instances of the components from the same domain share data somehow?
    • assumption: yes (how?)
  • Can isolated components position content outside the host boundary rect? (if not, problems with, e.g., +1 widget)
    • assumption: yes


Declarative syntax

Soon

  • how/when to run scripts?
  • syntax to style the host (provided we select a model where it is rendered)?
  • <template> details:
    • usable without components?
    • instantiable without explicit components (e.g., <instance select=”x-cyberdyne-terminator”>)
    • event handler registration syntax
  • <element> details
  • Do we need <binding> as well?
  • How to define the API of components

Later

  • <template>: introduce template types (e.g., <template type=”django”>)?
    • assumption: no


Misc.

Now

  • How can we split the spec into (more) different parts?

Later

  • Do we define the shadow DOM (or parts thereof) of built-in elements?
    • assumption: no