[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 #37 from brian kardell <bkardell@gmail.com> ---
(In reply to comment #34)
> (In reply to comment #31)
> > hsivonen: I think it's fine for this not to work in XML, or require XML
> > changes, or use an attribute like xml:component="" in XML. It's not going to
> > be used in XML much anyway in practice. I've already had browser vendors ask
> > me how they can just drop XML support; I don't think we can, at least not
> > currently, but that's the direction things are going in, not the opposite.
> 
> I took this part to the mailing list:
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-January/038632.html

(In reply to comment #36)
> 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.


Also no existing tools should be hurt by this approach... I am gonna have to
read this again, but so far I think I am good with it.  Someone show me if I've
missed something.

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

Received on Monday, 14 January 2013 23:50:12 UTC