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

CSS and Rendering

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

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