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).

Difference between revisions of "Component Model Discussion"

From WHATWG Wiki
Jump to navigation Jump to search
Line 21: Line 21:
* 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?
* tab-index behavior
* tab-index behavior
* z-order behavior
* z-order behavior
Line 33: Line 33:
* details of &lt;content&gt; selector syntax
* details of &lt;content&gt; selector syntax
** <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?
* 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>
** <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>
Line 80: Line 80:
*** <span style="color:darkred">Cons:</span> implementation is hard, multiple (perhaps mutually exclusive) bindings may apply, cannot extend the API
*** <span style="color:darkred">Cons:</span> implementation is hard, multiple (perhaps mutually exclusive) bindings may apply, cannot extend the API
** other?
** other?
::[[User:Dglazkov|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.
::[[User:Dglazkov|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 &lt;button is=mywidget&gt;, explicit, e.g., with fallback content as children)
* fallback mechanisms (implicit with &lt;button is=mywidget&gt;, explicit, e.g., with fallback content as children)
* Are shadow trees dynamic or static?
* Are shadow trees dynamic or static?

Revision as of 22:02, 10 October 2011

Overview

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

Linked pages:

Issues

CSS and Rendering

Other issues:

  • styling of rendering children of <content> (partially discussed in the CSS brainstorming page).
  • Do components create a layer?
    • assumption: no
Dglazkov: isn't this an implementation detail?
  • tab-index behavior
  • z-order behavior

Shadow Nodes

  • shadow root being a separate node type vs. an element vs. document fragment vs. ??? (see rendering sub-page)
    • current state: separate node type
  • 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.
  • 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

Events

  • focus event traversing out of shadow?
    • assumption: yes, redirected
    • current state: not implemented
  • 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

  • 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
  • is it possible to have a scoped (private) names, e.g., for private components?
    • assumption: no
  • 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?)
    • assumption: no

Registration

  • 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?
  • accessibility (implicit, e.g. with <button is=mywidget>, explicit, e.g., with ARIA roles)

Derivation

  • should we do XBL-like inheritance?
    • assumption: no
  • “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

Subtyping of DOM Objects

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

Isolation/Confinement

  • JS implementation details

Forwarding

examples: sub-classing <textarea> (Maciej’s examples), auto-completion, omni-bar like drop-down, toolbar

  • JS implementation details

Other

  • 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)

  • 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?
  • Are instances of the components from the same domain isolated from each other?
  • Can instances of the same component share data somehow?
  • Can instances of the same component and its derivatives share data somehow?
  • Can instances of the components from the same domain share data somehow?
  • Can isolated components position content outside the host boundary rect? (if not, problems with, e.g., +1 widget)
    • assumption: yes

Declarative syntax

  • 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
    • introduce template types (e.g., <template type=”django”>)?
      • assumption: no
  • <element> details
  • Do we need <binding> as well?
  • How to define the API of components

Misc.

  • Do we define the shadow DOM (or parts thereof) of built-in elements?
    • assumption: no
  • How can we split the spec into (more) different parts?