[Bug 18669] Switch from is= to <tag if a decision has been reached among implementers

https://www.w3.org/Bugs/Public/show_bug.cgi?id=18669

--- Comment #36 from Ian 'Hixie' Hickson <ian@hixie.ch> ---
Here's an alternative proposal that dglazkov and I came up with over lunch.

Provide two alternatives for authors to pick from:

1. Extending an existing element, using the declaration syntax:
     <element extends="ul" name="mylib-speciallist">
   ...and the use syntax:
     <ul is="mylib-speciallist">...</ul>
   Changing the is="" attribute doesn't do anything (and we provide an API to
   expose the element's original 'is' value somehow). This is suboptimal (as
   noted earlier) but it avoids even less pleasant changes to the HTML parser
   and differences between HTML and XML syntax.

2. Creating new elements that inherit straight from CustomElement (which
   inherits from Element, like HTMLElement, and has things like .style,
   focus(), and tabindex=""), using the declaration syntax:
     <element name="mylib-myelement">
   ...and the use syntax:
     <mylib-myelement>

(Both types would also be able to extend other components; whether it's the
kind of component that extends an existing element type or creates a new
element depends on the which is at the root of the hierarchy.)

This is on top of the existing decorator alternative also available:

3. Decorators. These can't provide a new API. Declaration:
     <decorator name="mylib-mybutton">
   Use:
     /*CSS*/ input[type=button] { binding: url(mylib.html#mylib-mybutton); }
     <input type=button>

We also discussed a third alternative for authors to use, which we'd not
provide in v1 but might provide in v2:

4. Providing a new type="" value for <input> (and maybe <button>, we didn't 
   discuss that). Declaration (straw man, we didn't discuss syntax):
     <inputtype name="mylib-map">
   Use:
     <input type="mylib-map">

I think this manages to hit the main use cases:

A. Just changing the shadow tree of existing elements (e.g. making prettier
buttons) is handled by decorators, #3.

B. Extending semantics of existing elements, providing more API surface and
with a mostly presentational shadow DOM (e.g. making a <select> of country
names be rendered as a graphical map), is provided by #1.

C. Creating precomposed groups of elements, maybe providing some API surface,
with a shadow DOM that is mostly semantic elements (e.g. something like <input
type=file> or a group of datetime controls that exposes start and end times),
is provided by #2.

D. New controls that fit the <input> model but don't map to existing semantics
(e.g. a type=bugzilla-bugid or something), are eventually provided by #4.

E. Completely new semantics, e.g. a platform game's graphics area and key
handling (essentially, mini applications) are handled by #2.

F. Creating new widgets in SVG, which render as SVG fragments and react to UI
events to change the graphics, and expose an API (e.g. a clickable "switch"
button in a train layout UI), are handled by #2 with a minor tweak to the SVG
processing algorithm that says that if an element's parent is an SVG node (or
another component to which this applies), its shadow tree is processed as if
the element was a <g> with that shadow tree as descendants.

It avoids most of the key pitfalls that were worrying people with earlier
suggestions. The main ones it doesn't avoid are that the #1 syntax above might
still mislead authors into thinking they can change the is="" attribute, but
that is somewhat mitigated by providing a syntax without is="" as well (#2).
The syntax is as terse as possible for #2, and relatively terse for #1 but
clearly not ultimately terse. Where there is a real standard semantic, we still
expose it, though we don't force it where that doesn't make sense. By
preventing authors from extending elements when they don't expose the semantic
in the original markup, we discourage people from using #2 when #1 is easier.
Unfortunately we don't prevent misuse of #2, but discouraging it is probably as
good as we can do in practice (people can always extend <div>...).

To avoid stepping on the HTML vocabulary, we use a hyphen ("-") in the element
name as an indicator that the element is a custom element, and HTML reserves
all element names without a hyphen for future use. For consistency, we'd also
require a hyphen in the name of is="" values. We'd document the syntax as being
"libraryname-componentname", which encourages avoiding cross-library clashes.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 14 January 2013 23:31:39 UTC