Component Model Discussion

Overview

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

Linked pages:

• rendering sub-page: discussions on rendering details
• CSS brainstorming page: alternative solutions to styling
• isolation brainstorming page: general thoughts on isolation & confinement

Issues

• Now: in the spec draft and/or already in use for internal components
• Soon: to be included in V1 spec
• Later: issues to be discussed for later versions of the spec

CSS and Rendering

• rendering sub-page: discussions on rendering details
• CSS brainstorming page: brainstorming on alternative solutions to styling

Soon

• styling of rendering children of <content> (partially discussed in the CSS brainstorming page).
• 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?
  • assumption: static, but see discussion in public-webapps@ ML

Later

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

Derivation

Later

• 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

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

Later

• Attribute/property forwarding.

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