Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names

[Dimitri Glazkov]

On Sat, Sep 3, 2011 at 4:31 AM, Anne van Kesteren  wrote:
>
> On Fri, 02 Sep 2011 20:47:27 +0200, Dimitri Glazkov  
> wrote:
>> BTW, I really ought to put this "fears" list on the Wiki.
>
> Yeah that would probably be a good idea.

Done: http://wiki.whatwg.org/wiki/Custom_Tags_Analysis it still needs
work, but the main stuff is there.

:DG<

Re: HTMLElement.register--giving components tag names

[Sean Hogan]

On 7/09/11 7:20 AM, Alex Russell wrote:

On Sat, Sep 3, 2011 at 8:20 PM, Ian Hickson  wrote:

On Sat, 3 Sep 2011, Dominic Cooney wrote:

I think the XBL approach is far superior here -- have authors use
existing elements, and use XBL to augment them. For example, if you
want the user to select a country from a map, you can use a
with a list of countries in  elements in the markup, but then
use CSS/XBL to bind that  to a "component" that instead makes
the  look like a map, with all the interactivity that implies.

That sounds appealing, but it looks really hard to implement from where
we right now.

I don't think "it's hard" is a good reason to adopt an inferior solution,

Likewise, intimating that something is better because it's hard is a
distraction.


especially given that this is something that will dramatically impact the
Web for decades to come.

The more complex the thing, the more we're saddled with. XBL(2) is
more complex than the proposed model. It likewise needs to be
justified all the more.


I agree that XBL2 may have been too ambitious for it's time.

I would say that the simplest thing that would be useful would be:
a) provide a bare-bones shadow DOM
b) implement something like the NodeWatcher proposal - 
http://www.w3.org/2008/webapps/wiki/MutationReplacement#NodeWatch_.28A_Microsoft_Proposal.29


These features are independently useful and would facilitate Javascript 
library solutions similar to both HTMLElement.register and XBL2.


Then step back and see what the Javascript guys do with it. The next 
step might write itself.


Sean

Re: HTMLElement.register--giving components tag names

[Alex Russell]

On Sat, Sep 3, 2011 at 8:20 PM, Ian Hickson  wrote:
> On Sat, 3 Sep 2011, Dominic Cooney wrote:
>> >
>> > I think the XBL approach is far superior here -- have authors use
>> > existing elements, and use XBL to augment them. For example, if you
>> > want the user to select a country from a map, you can use a 
>> > with a list of countries in  elements in the markup, but then
>> > use CSS/XBL to bind that  to a "component" that instead makes
>> > the  look like a map, with all the interactivity that implies.
>>
>> That sounds appealing, but it looks really hard to implement from where
>> we right now.
>
> I don't think "it's hard" is a good reason to adopt an inferior solution,

Likewise, intimating that something is better because it's hard is a
distraction.

> especially given that this is something that will dramatically impact the
> Web for decades to come.

The more complex the thing, the more we're saddled with. XBL(2) is
more complex than the proposed model. It likewise needs to be
justified all the more.

> XBL already has multiple implementations in various forms. I certainly
> agree that we should adjust XBL2 to take into account lessons we have
> learnt over the past five years, such as dropping namespaces and merging
> it into HTML instead of forcing an XML language on authors, but taking a
> significantly less capable solution simply because XBL is difficult seems
> like a very poor trade-off.

It *may* be capable of handling the use-cases in question, but that
case hasn't been made, and from where I sit, it's not easy or trivial
to do by inspection.

Regards

Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names

[Sean Hogan]

On 3/09/11 4:47 AM, Dimitri Glazkov wrote:

On Fri, Sep 2, 2011 at 2:30 AM, Anne van Kesteren  wrote:

Examples of elements that should not be replaced but could be changed by a
binding: Having a sortable binding for; Exposing cite="" on
; Turning a  listing countries into a map.

Great! Let's go through them:

* Sortable binding for a table is really just a table subclass with
some event listeners registered.

* Exposing cite on blockquote sounds like something CSS should do.
There's no extra behavior, and you're not really creating a new type
of element. It's just extra boxes.

* Turning select listing countries into a map -- composition to the rescue!:



   Lilliput
   Blefuscu



> From the author's perspective, you don't actually need the select
element. If you intend to show a map on cool browsers and select on
the less cool ones, you are completely uninterested in having your
select semantics dutifully reproduced. All you need is something that
does what you need. Besides, the behavior of a map and a select are so
different than you probably would scrap the former to build the latter
anyway.


The author wants the select element so that form submission works.

The semantics of select are also quite useful as you might want the 
country-map widget to allow multiple selections, have a default selected 
country, and have a non-comprehensive list of countries to choose from.


As you have indicated, the user needs the select element as the fallback 
presentation.


It would also be useful if user stylesheets could override the behavior 
chosen by the author - either reverting to a browser select widget, or 
something provided by a browser add-on. This capability depends on there 
being a defacto standard for applying the country-map behavior. Which do 
you think would take on more quickly:

a) custom tag-names, or
b) aria or data attributes
I'm almost certain it's b.

My personal opinion is that most of the perceived need for custom 
tag-names is to put presentation into HTML. Kind of like  and 
 but without the benefit of being standards (de facto or de jure).


Sean

Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names

[Dimitri Glazkov]

On Sun, Sep 4, 2011 at 5:03 PM, Robert O'Callahan  wrote:
> On Sun, Sep 4, 2011 at 1:56 PM, Dimitri Glazkov 
> wrote:
>>
>> The offsetWidth query could've triggered an event
>> handler execution
>
> I don't think "offsetWidth" should be able to trigger synchronous execution
> of an event listener in the content. How would that happen?

It's certainly possible in WebKit
(http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/dom/Document.cpp&l=1565).
All it takes for the layout bit to be dirty and an event to be queued
up prior to the hapless script accessing Element::offsetWidth
(http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/dom/Element.cpp&l=387).

Let's not rathole on this specific case though -- the whole notion is
that the interface of the object changes as a result of spooky action
at a distance is preposterous and should certainly not be codified
into the platform. Sure, you can already yank my prototype chain with
__proto__ and override my methods, bu those things are widely viewed
as bad form. We have enough bad form. Let's not add more.

:DG<

>
> Rob
> --
> "If we claim to be without sin, we deceive ourselves and the truth is not in
> us. If we confess our sins, he is faithful and just and will forgive us our
> sins and purify us from all unrighteousness. If we claim we have not sinned,
> we make him out to be a liar and his word is not in us." [1 John 1:8-10]
>

Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names

[Robert O'Callahan]

On Sun, Sep 4, 2011 at 1:56 PM, Dimitri Glazkov wrote:

> The offsetWidth query could've triggered an event
> handler execution
>

I don't think "offsetWidth" should be able to trigger synchronous execution
of an event listener in the content. How would that happen?

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]

Re: HTMLElement.register--giving components tag names

[Dimitri Glazkov]

On Sat, Sep 3, 2011 at 8:20 PM, Ian Hickson  wrote:
> On Sat, 3 Sep 2011, Dominic Cooney wrote:
>> >
>> > I think the XBL approach is far superior here -- have authors use
>> > existing elements, and use XBL to augment them. For example, if you
>> > want the user to select a country from a map, you can use a 
>> > with a list of countries in  elements in the markup, but then
>> > use CSS/XBL to bind that  to a "component" that instead makes
>> > the  look like a map, with all the interactivity that implies.
>>
>> That sounds appealing, but it looks really hard to implement from where
>> we right now.
>
> I don't think "it's hard" is a good reason to adopt an inferior solution,
> especially given that this is something that will dramatically impact the
> Web for decades to come.
>
> XBL already has multiple implementations in various forms. I certainly
> agree that we should adjust XBL2 to take into account lessons we have
> learnt over the past five years, such as dropping namespaces and merging
> it into HTML instead of forcing an XML language on authors, but taking a
> significantly less capable solution simply because XBL is difficult seems
> like a very poor trade-off.

Be careful with the big words. It can't be that inferior if it
satisfies use cases that XBL2 can't.

While trying to adjust XBL2 to the set of actual use cases
(http://wiki.whatwg.org/wiki/Component_Model_Use_Cases), you'll
quickly realize that by its nature, the decorator behavior attachment
simply isn't what's needed. You need element attachment. And once you
need element attachment, it's fairly easy to arrive at the design that
we propose with the Component Model.

:DG<

>
> --
> Ian Hickson               U+1047E                )\._.,--,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
>

Re: HTMLElement.register--giving components tag names

[Dimitri Glazkov]

Be careful with the big words. It can't be that inferior if it
satisfies use cases that XBL2 can't.

:DG<

On Sat, Sep 3, 2011 at 8:20 PM, Ian Hickson  wrote:
> On Sat, 3 Sep 2011, Dominic Cooney wrote:
>> >
>> > I think the XBL approach is far superior here -- have authors use
>> > existing elements, and use XBL to augment them. For example, if you
>> > want the user to select a country from a map, you can use a 
>> > with a list of countries in  elements in the markup, but then
>> > use CSS/XBL to bind that  to a "component" that instead makes
>> > the  look like a map, with all the interactivity that implies.
>>
>> That sounds appealing, but it looks really hard to implement from where
>> we right now.
>
> I don't think "it's hard" is a good reason to adopt an inferior solution,
> especially given that this is something that will dramatically impact the
> Web for decades to come.
>
> XBL already has multiple implementations in various forms. I certainly
> agree that we should adjust XBL2 to take into account lessons we have
> learnt over the past five years, such as dropping namespaces and merging
> it into HTML instead of forcing an XML language on authors, but taking a
> significantly less capable solution simply because XBL is difficult seems
> like a very poor trade-off.
>
> --
> Ian Hickson               U+1047E                )\._.,--,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
>

Re: HTMLElement.register--giving components tag names

[Ian Hickson]

On Sat, 3 Sep 2011, Dominic Cooney wrote:
> > 
> > I think the XBL approach is far superior here -- have authors use 
> > existing elements, and use XBL to augment them. For example, if you 
> > want the user to select a country from a map, you can use a  
> > with a list of countries in  elements in the markup, but then 
> > use CSS/XBL to bind that  to a "component" that instead makes 
> > the  look like a map, with all the interactivity that implies.
> 
> That sounds appealing, but it looks really hard to implement from where 
> we right now.

I don't think "it's hard" is a good reason to adopt an inferior solution, 
especially given that this is something that will dramatically impact the 
Web for decades to come.

XBL already has multiple implementations in various forms. I certainly 
agree that we should adjust XBL2 to take into account lessons we have 
learnt over the past five years, such as dropping namespaces and merging 
it into HTML instead of forcing an XML language on authors, but taking a 
significantly less capable solution simply because XBL is difficult seems 
like a very poor trade-off.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names

[Dimitri Glazkov]

On Sat, Sep 3, 2011 at 12:08 PM, Ian Hickson  wrote:
> On Fri, 2 Sep 2011, Anne van Kesteren wrote:
>>
>> What we need is not a becomes="" attribute (that renames an element and
>> therefore forgoes its semantics) but rather a way to get complete
>> control over a semantic element and tweak aspects of it. Otherwise
>> creating such controls is prohibitively expensive and only useful if you
>> have vast resources.
>
> Exactly. This is in fact how XBL works. This is why the widgets in the
> HTML spec are defined in terms of bindings -- the idea is that authors can
> then provide their own alternative bindings or inherit from them. We would
> provide basic bindings that they can reuse in their inheritance chain,
> e.g. so that they can override just the look of the button but get all the
> interactive behaviour (accessibility roles, keyboard navigation, mouse
> click reactions, etc) for free.

You get all of those for free with the ability to sub-type the
elements, as explained elsewhere in this thread.

What you also get with the Component Model vs. XBL-like bindings is
the consistency of the API surface.

Note: I am explicitly calling this "XBL-like", because XBL2
intentionally avoids the ability to extend a DOM element API surface
with a binding -- so we're not operating in real of a currently
existing spec here.

But in a general XBL-like model, the problem you have is that at any
given moment of time, it is unclear whether your element has a certain
API or not. Consider this: in your JS application, you hold a
reference to DOM element, and know for a fact it has
methods/properties of some Widget binding, that's currently applied to
the element. You then access an offsetWidth property on that DOM
element...

Pop quiz: what's the API surface of your widget now? The answer is:
you can never know. The offsetWidth query could've triggered an event
handler execution, which could've modified some CSS that binds that
particular Widget binding to this element, unbinding it or worse yet,
turning it into some other type.

BOOM goes the landmine, and there you are, watching your leg fly off.
That's the trouble with decorators -- they are ephemeral things that
should never, _ever_ expose an API on DOM elements. Otherwise,
_anytime_ you are about to access a property or call a method on a DOM
element, you'd have to first do a hasBinding check on it. Show of
hands -- who wants to write their code that way? If I see any, it's
not for long -- those landmines will expeditiously take care of those
extra limbs for you.

XBL2 provides a set of machinery to make decorators, but in doing so
it fails miserably at addressing the use cases that Web application
and  Web framework developers actually need. And that's why "XBL-like
approach" is a pie-in-the-sky key phrase that should never be applied
to element behavior attachment.

:DG<

>
> --
> Ian Hickson               U+1047E                )\._.,--,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Re: HTMLElement.register--giving components tag names

[Dominic Cooney]

On Sat, Sep 3, 2011 at 12:04 PM, Ian Hickson  wrote:
> On Tue, 30 Aug 2011, Dominic Cooney wrote:
>>
>> I'm proposing we add something that lets script extend the set of tag
>> names, so there is less of a bright line between elements defined in the
>> HTML spec and elements defined in script. Something like:
>>
>> HTMLElement.register('x-contacts', ContactPicker);
>
> What's the fallback behaviour for when script is disabled?

The fallback behavior is basically that you’ll author your markup
either progressively enhance. If you want to support script being
disabled, I guess you’re going to use postbacks.

Progressive enhancement:


  
Name:


  


Fallback:


  … form same as before …


In this case when the x-contacts-picker is available, it suppresses
the fallback form with shadow DOM, or even by yanking it out of the
DOM.

Since registration is imperative, components imply running script.
There’s no story yet for when you have components but no script.
Looking at the use cases, they mostly (ie except for "panel" layout
manager) want to wire up event listeners for interactivity. I think
"has components, but doesn’t have script" will not be something people
design for.

Declarative would be nice for initializing the shadow DOM in a more
succinct way, though.

One thing that isn’t worked out is that sometimes you want to write
components that present their children, but if those children don’t
coincide with your fallback content you’re SOL. I expect one pattern
that might emerge is nested subcomponents, and have CSS handle
switching:


  

…
  
  


x-rockin {
  display: none;
}

x-rockin:bound {
  display: block;
}

Shadow DOM would select and output the subcomponent to flip the switch
on the fallback content.

> I think the XBL approach is far superior here -- have authors use existing
> elements, and use XBL to augment them. For example, if you want the user
> to select a country from a map, you can use a  with a list of
> countries in  elements in the markup, but then use CSS/XBL to bind
> that  to a "component" that instead makes the  look like a
> map, with all the interactivity that implies.

That sounds appealing, but it looks really hard to implement from
where we right now. Wearing my WebKit hat, one nice property of the
above is that we either have an element we’re going to rip out of the
DOM and replace:

 (gets replaced somewhat like renameNode)

Or one that isn’t particularly rich to begin with:

 (is HTMLUnknownElement until registered; perfect
tabula rasa for a component)

Whereas in the general case we’d be fighting with suppressing parts of
the nature of the element being bound.

Similarly, one thing that simplifies shadow DOM is that it affects the
rendering of the child content of an element, but the element (as a
block or whatever) is still there. This is relatively simple to
implement because we can just switch from one list of child content to
another when shadow DOM is present. But making the replacement happen
outside the box is more complicated, because there are many more
places that would need to be aware of this switch—many things that are
data would need to be behavior/logic. It is hard to be confident that
they interact well.

There are a few other things that I like about this compared to XBL.
However I don’t want to reject every idea in XBL out of hand—parts of
it are appealing, some parts look hard, but in total it is staggering.
Some ways in which this proposal is much simpler than XBL:

inheritance—there is none. You might layer behavioral changes in a
kind of inheritance of prototype chains in JavaScript, but one bespoke
prototype is just as onerous as many from the browser’s point of view.

multiple bindings—no, only a single binding.

unbinding—there is no "unregister". (Not stated but I am guessing
re-registering the same element name does something simple—throws, or
the last one wins.) There’s no way to remove a shadow root, either.

complexity of selectors—you just get to match on the element name. So
it is very simple and static.

Dominic

> --
> Ian Hickson               U+1047E                )\._.,--,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names

[Charles Pritchard]

On Sep 3, 2011, at 12:08 PM, Ian Hickson  wrote:

> On Fri, 2 Sep 2011, Anne van Kesteren wrote:
>> 
>> What we need is not a becomes="" attribute (that renames an element and 
>> therefore forgoes its semantics) but rather a way to get complete 
>> control over a semantic element and tweak aspects of it. Otherwise 
>> creating such controls is prohibitively expensive and only useful if you 
>> have vast resources.
> 
> Exactly. This is in fact how XBL works. This is why the widgets in the 
> HTML spec are defined in terms of bindings -- the idea is that authors can 
> then provide their own alternative bindings or inherit from them. We would 
> provide basic bindings that they can reuse in their inheritance chain, 
> e.g. so that they can override just the look of the button but get all the 
> interactive behaviour (accessibility roles, keyboard navigation, mouse 
> click reactions, etc) for free.
> 


Isn't that the domain of CSS?



> -- 
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
> 

Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names

[Ian Hickson]

On Fri, 2 Sep 2011, Anne van Kesteren wrote:
> 
> What we need is not a becomes="" attribute (that renames an element and 
> therefore forgoes its semantics) but rather a way to get complete 
> control over a semantic element and tweak aspects of it. Otherwise 
> creating such controls is prohibitively expensive and only useful if you 
> have vast resources.

Exactly. This is in fact how XBL works. This is why the widgets in the 
HTML spec are defined in terms of bindings -- the idea is that authors can 
then provide their own alternative bindings or inherit from them. We would 
provide basic bindings that they can reuse in their inheritance chain, 
e.g. so that they can override just the look of the button but get all the 
interactive behaviour (accessibility roles, keyboard navigation, mouse 
click reactions, etc) for free.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: HTMLElement.register--giving components tag names

[Ian Hickson]

On Tue, 30 Aug 2011, Dominic Cooney wrote:
> 
> I'm proposing we add something that lets script extend the set of tag 
> names, so there is less of a bright line between elements defined in the 
> HTML spec and elements defined in script. Something like:
> 
> HTMLElement.register('x-contacts', ContactPicker);

What's the fallback behaviour for when script is disabled?

I think the XBL approach is far superior here -- have authors use existing 
elements, and use XBL to augment them. For example, if you want the user 
to select a country from a map, you can use a  with a list of 
countries in  elements in the markup, but then use CSS/XBL to bind 
that  to a "component" that instead makes the  look like a 
map, with all the interactivity that implies.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names

[Charles Pritchard]

On 9/2/2011 6:39 PM, Alex Russell wrote:

Similarly, WCAG is a series of principles for designing usable, high quality
applications.


ARIA presents a set of semantic roles that don't exist in HTML, and
for those, alignment with custom element implementations is
outstanding. Components that express those semantics can use ARIA to
help communicate what they "mean", taking the burden off of the users
of the components to understand and manage the role/state groups.


When working with accessibility, it's super-set of HTML:
  img { role: 'img'; };
  img[alt=""] { role: 'presentation'; }


Yes, I'd like to see Components express aligned semantics, such as
button:aria-pressed,
in the shadow DOM. It's the same method we use with the Canvas subtree.

Pseudo-classes as a state mechanism need a lot more examination,
AFAICT. It's a non-extensible vocabulary, it doesn't appear to be
scriptable, and as a result, we haven't been able to use them to
handle things like states for animations (which should be transitions
between states in a node-graph).

+shans


I meant to short-hand the specs in the "HTML element to Accessibility 
API Role Mapping Matrix":

http://dev.w3.org/html5/html-api-map/#api-role

As evolved from:
2010:
http://www.paciellogroup.com/blog/misc/HTML5/aria-html5-proposal.html
2009:
http://dev.w3.org/html5/markup/aria/


I didn't mean to introduce a new state mechanism. CSS selectors already 
work with ARIA.

With transitions, and generated content, CSS is quite flexible.

This would work fine with transitions:
div[aria-checked="true"] { content: 'Checked'; color: red;}
div[aria-checked="false"] { content: 'Not Checked'; color: black; }

I suspect we're talking about different things.


How should ATs be notified/detect that there is a shadow DOM?

Focus works as it always has. It can move inside the shadow.


Does the following statement make sense?:

ATs that walk the DOM should check for element.shadow [currently 
webkitShadow],

prior to looking for element.childNodes.



I'd imagine the accessibility tree simply contains the appropriate data,
but for ATs using simple DOM, and getAttribute, should they now check for
a .shadow attribute on elements in addition to their usual heuristics?

That'll work for components with a public shadow, which I think will
be most of them. Components can also note state by setting role/state
directly on the outer component.


What of components that contain multiple roles?
Would those components, necessarily, require a public shadow?

There was some discussion about allowing multiple children on the shadow.
Perhaps this would be a good use case for it.



"data-*" works for arbitrary metadata, and "aria-*"  for UI semantics.


Yes! And for low-complexity tasks, they're perfect. For larger,
reusable components that need bundled behavior (Closure, JQuery UI,
Dijit), the task of setting up and managing all of this can be made
easier for users and developers of components by giving them a place
to hang behavior, shadow DOM, and data model concerns from.


We're certainly experimenting, with the Canvas tag and subtree.

The component approach turns this around, by letting you construct a
logical tree that might have  elements in the shadow, meaning
you don't need a "hidden tree" per sae.


I like to think that it encapsulates current practice. I'm all for it.
We still need a canvas subtree, to operate with the canvas 2d spec on 
drawFocusRing.



4.
Let's look at the button example:


Weee!!
Becomes:
Weee!!


For the sake of ATs, that should include ARIA semantics:


Now the OS and ATs think of that as a button, in every way that
would be.
The UA, though, does not; it leaves it up to the scripting environment.


There's a lack of terseness here that's sort of concerning. One
possible way forward might be to use "role" as a shorthand for
"becomes" and allow components to register for roles which they
implement. Hmmm.


These extended attributes are something to be managed via script. You would
not expect someone to author ARIA states into their static markup, though
you would include roles.

I do think shorthand is valuable. As I understand it, ARIA tries to stay out
of the way.
There is no current CSS+ARIA profile, it could be helpful if there were.

I think this gets back to the idea of "how does a component advertise
it's state?", and as far as I know, there's no unified approach in the
web platform. ARIA exists outside of the existing HTML pseudo-class
system. Anyone who wants to target states with CSS needs an extensible
vocabulary, and so a lot of stuff gets stuffed into CSS class names
too. Sort of mess today, and I'd love for us to find a way to unify
these theories of state.


CSS selectors make this easy enough. ARIA has an extensible vocabulary, 
and CSS has an easy query language.
ARIA is intended to advertise the state of a component. ATs need that 
information.

It was designed to be extensible and non-intrusive.

Yes, items are stuffed into CSS class names 

Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names

[Anne van Kesteren]

On Fri, 02 Sep 2011 20:47:27 +0200, Dimitri Glazkov  
 wrote:

Fear 6: Accessibility. Accessibility! Accessibility!?

I contend that the Component Model does not make accessibility any
worse. And likely the opposite.

By allowing ATs to traverse into shadow subtrees, and ensuring that
the shadow subtrees are well-behaving accessibility citizens, you
allow authors of components to encapsulate good practices and aid in
killing the "re-created poorly" anti-pattern. That's what Sencha,
SproutCore, Dijit all try to do -- and the Component Model will enable
them do this right. In fact, things like access keys or even z-index
are quite hard (impossible) to get right, unless you have something
like a well-functioning shadow DOM.


The problem is not so much that you cannot make it accessible. It is that  
making it accessible is complicated for the average authors.




This leaves us with the argument of replacing semantics. Since we're
in business of sub-typing HTML elements, we don't necessarily need to
forego their semantics:

// ...
var AwesomeButton =  
HTMLButtonElement.extend(awesomeButtonInitializerBag);

Element.register('x-awesome-button', AwesomeButton);
// ...

should give you a thing that behaves like a button, with the awesome
behavior added.

In the situations where existing semantics are representative, but
deficient, you are much better off replacing them anyway:

+1


Depending on the specifics, I suppose this might work.



What we need is not a becomes="" attribute (that renames an element and
therefore forgoes its semantics) but rather a way to get complete  
control

over a semantic element and tweak aspects of it. Otherwise creating such
controls is prohibitively expensive and only useful if you have vast
resources.


I would argue that replacing is exactly the right thing to do. You are
changing an element from having some basic meaning to a more specific
meaning. Replacement seems natural and matches what authors do today.


It depends on what is exposed to assistive technolgoy and how much authors  
have to implement themselves regarding e.g. keyboard accessibility. If you  
get them somehow magically by using extend() you might not even need  
becomes="".



Examples of elements that should not be replaced but could be changed  
by a

binding: Having a sortable binding for ; Exposing cite="" on
; Turning a  listing countries into a map.


Great! Let's go through them:

* Sortable binding for a table is really just a table subclass with
some event listeners registered.


But how do make this work as a new element? Especially for  parsing  
is somewhat hairy.




* Exposing cite on blockquote sounds like something CSS should do.
There's no extra behavior, and you're not really creating a new type
of element. It's just extra boxes.


There might be extra behavior, such as clicking on the   
exposing it, or some such.



* Turning select listing countries into a map -- composition to the  
rescue!:



   
  Lilliput
  Blefuscu
   



From the author's perspective, you don't actually need the select

element. If you intend to show a map on cool browsers and select on
the less cool ones, you are completely uninterested in having your
select semantics dutifully reproduced. All you need is something that
does what you need. Besides, the behavior of a map and a select are so
different than you probably would scrap the former to build the latter
anyway.


The idea is that the outcome is the same, but that the presentation is  
completely different. Both controls have the same goal and semantics, just  
their presentation is different. So wrapping it in a  does  
not seem like the proper approach.



Having some way to mint custom elements as a last resort may very well  
make sense too, but I think the emphasis should be on enhancing  
existing elements as that is less complex (for authors anyway) and more  
accessible.


Minting new elements only seems crazy and unreasonable if you can't do  
it.


That's not what I said.



The thing is, today's Web apps have already retreated into the mostly
imperative world. Despite the angry rumors, the battle for markup has
been lost. Look the source and weep:
http://dev.sencha.com/deploy/touch/docs/, http://www.npr.org/webapp,
and lots, and lots of others.

However, harnessing the HTML parser to construct an object tree gives
us a new round. You don't have to think divs and spans anymore. Once
you can start viewing any functional block of your page as a custom
element, you can return to using markup as composition medium. Hell,
in this case fetching markup lazily becomes more attractive than JSON!


I don't think there is any disagreement about current practice. Heck,  
maybe we do not even disagree and I just not understand it fully.




And FWIW, I do not think that has to be seen as "Decorator"
http://wiki.whatwg.org/wiki/Behavior_Attachment as for the examples I  
listed
above I would expect the binding to be permanent. (I would also expect  
yo

Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names

[Alex Russell]

On Fri, Sep 2, 2011 at 3:58 PM, Charles Pritchard  wrote:
> On 9/2/11 3:00 PM, Alex Russell wrote:
>>
>> On Fri, Sep 2, 2011 at 1:40 PM, Charles Pritchard  wrote:
>>
>>>
>>> On 9/2/11 12:10 PM, Alex Russell wrote:
>>>

 Since Dimitri has already said everything I would, and better, I just
 want to very quickly second his point about where we are today vs.
 where we fear we might be: non-trivial apps have *already* given up on
 HTML. Suggesting that there's an un-semantic future that will be
 *caused* by the component model is to fight a battle that's already
 lost.

 The only question we need to answer now is: how do we repair the
 situation?

 In spending the last 9 months thinking and working through the issues
 Dimitri presents below, our strongest theory now is that there *is* a
 market for semantics, that it *does* organize around winners (e.g.,
 Microformats), and that we're missing a mechanism for more directly
 allowing authors to express their intent at app construction time in
 ways that don't either pull them fully out of markup/html (see:
 Closure, GWT, etc.).

 Instead of imagining total anarchy, imagine a world where something
 like jquery-for-WebComponents comes along: a "winner" toolkit that a
 statistically significant fraction of the web uses. Once that intent
 is in markup and not code, it helps us set the agenda for the next
 round of HTML's evolution.


>>>
>>> Alex, Dimitri:
>>>
>>> 1.
>>> I've found ARIA to be an appropriate microformat for new components.
>>> That is what it was designed for, after all.
>>>
>>
>> ARIA is how we envision components developed in this world will
>> communicate with assistive technology. Nothing in Web Components is
>> designed to supplant or replace it.
>>
>
> I suggest looking at ARIA as more than a method for communicating with
> assistive technology.
> It's a means for communicating UI component states.

And Web Components is designed explicitly to work with it.

> Similarly, WCAG is a series of principles for designing usable, high quality
> applications.
>
>> ARIA presents a set of semantic roles that don't exist in HTML, and
>> for those, alignment with custom element implementations is
>> outstanding. Components that express those semantics can use ARIA to
>> help communicate what they "mean", taking the burden off of the users
>> of the components to understand and manage the role/state groups.
>>
>
> When working with accessibility, it's super-set of HTML:
>  img { role: 'img'; };
>  img[alt=""] { role: 'presentation'; }
>
>
> Yes, I'd like to see Components express aligned semantics, such as
> button:aria-pressed,
> in the shadow DOM. It's the same method we use with the Canvas subtree.

Pseudo-classes as a state mechanism need a lot more examination,
AFAICT. It's a non-extensible vocabulary, it doesn't appear to be
scriptable, and as a result, we haven't been able to use them to
handle things like states for animations (which should be transitions
between states in a node-graph).

+shans

> How should ATs be notified/detect that there is a shadow DOM?

Focus works as it always has. It can move inside the shadow.

> I'd imagine the accessibility tree simply contains the appropriate data,
> but for ATs using simple DOM, and getAttribute, should they now check for
> a .shadow attribute on elements in addition to their usual heuristics?

That'll work for components with a public shadow, which I think will
be most of them. Components can also note state by setting role/state
directly on the outer component.

>>> "data-*" works for arbitrary metadata, and "aria-*"  for UI semantics.
>>>
>>
>> Yes! And for low-complexity tasks, they're perfect. For larger,
>> reusable components that need bundled behavior (Closure, JQuery UI,
>> Dijit), the task of setting up and managing all of this can be made
>> easier for users and developers of components by giving them a place
>> to hang behavior, shadow DOM, and data model concerns from.
>>
>
> We're certainly experimenting, with the Canvas tag and subtree.

The component approach turns this around, by letting you construct a
logical tree that might have  elements in the shadow, meaning
you don't need a "hidden tree" per sae.

> It seems like "event.preventDefault()" is an important hook to keep in mind.
> Is Web Components, in some manner, calling for a registerDefault method?
>
>
>>> 2.
>>> ARIA 1.0 may not be sufficient, but I do think it's been designed to be
>>> forward compatible, and "meta" compatible with HTML5.
>>> I can, for instance, use: role="spreadsheet grid" even though
>>> "spreadsheet"
>>> is not an ARIA 1.0 role; thus forward compatibility, and semantic
>>> lenience.
>>>
>>
>> Nothing we're doing reduces the utility or need for ARIA. It works
>> *great* with these component types, and to the extent that we can
>> align them, I'm excited by how much easier it's going to be for
>> component

Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names

[Charles Pritchard]

On 9/2/11 3:00 PM, Alex Russell wrote:

On Fri, Sep 2, 2011 at 1:40 PM, Charles Pritchard  wrote:
   

On 9/2/11 12:10 PM, Alex Russell wrote:
 

Since Dimitri has already said everything I would, and better, I just
want to very quickly second his point about where we are today vs.
where we fear we might be: non-trivial apps have *already* given up on
HTML. Suggesting that there's an un-semantic future that will be
*caused* by the component model is to fight a battle that's already
lost.

The only question we need to answer now is: how do we repair the
situation?

In spending the last 9 months thinking and working through the issues
Dimitri presents below, our strongest theory now is that there *is* a
market for semantics, that it *does* organize around winners (e.g.,
Microformats), and that we're missing a mechanism for more directly
allowing authors to express their intent at app construction time in
ways that don't either pull them fully out of markup/html (see:
Closure, GWT, etc.).

Instead of imagining total anarchy, imagine a world where something
like jquery-for-WebComponents comes along: a "winner" toolkit that a
statistically significant fraction of the web uses. Once that intent
is in markup and not code, it helps us set the agenda for the next
round of HTML's evolution.

   

Alex, Dimitri:

1.
I've found ARIA to be an appropriate microformat for new components.
That is what it was designed for, after all.
 

ARIA is how we envision components developed in this world will
communicate with assistive technology. Nothing in Web Components is
designed to supplant or replace it.
   


I suggest looking at ARIA as more than a method for communicating with 
assistive technology.

It's a means for communicating UI component states.

Similarly, WCAG is a series of principles for designing usable, high 
quality applications.



ARIA presents a set of semantic roles that don't exist in HTML, and
for those, alignment with custom element implementations is
outstanding. Components that express those semantics can use ARIA to
help communicate what they "mean", taking the burden off of the users
of the components to understand and manage the role/state groups.
   


When working with accessibility, it's super-set of HTML:
 img { role: 'img'; };
 img[alt=""] { role: 'presentation'; }


Yes, I'd like to see Components express aligned semantics, such as 
button:aria-pressed,

in the shadow DOM. It's the same method we use with the Canvas subtree.

How should ATs be notified/detect that there is a shadow DOM?
I'd imagine the accessibility tree simply contains the appropriate data,
but for ATs using simple DOM, and getAttribute, should they now check for
a .shadow attribute on elements in addition to their usual heuristics?




"data-*" works for arbitrary metadata, and "aria-*"  for UI semantics.
 

Yes! And for low-complexity tasks, they're perfect. For larger,
reusable components that need bundled behavior (Closure, JQuery UI,
Dijit), the task of setting up and managing all of this can be made
easier for users and developers of components by giving them a place
to hang behavior, shadow DOM, and data model concerns from.
   


We're certainly experimenting, with the Canvas tag and subtree.

It seems like "event.preventDefault()" is an important hook to keep in mind.
Is Web Components, in some manner, calling for a registerDefault method?



2.
ARIA 1.0 may not be sufficient, but I do think it's been designed to be
forward compatible, and "meta" compatible with HTML5.
I can, for instance, use: role="spreadsheet grid" even though "spreadsheet"
is not an ARIA 1.0 role; thus forward compatibility, and semantic lenience.
 

Nothing we're doing reduces the utility or need for ARIA. It works
*great* with these component types, and to the extent that we can
align them, I'm excited by how much easier it's going to be for
component authors to be, allowing them to focus on concerns like a11y
instead of "how do I get this thing to fly in the first place?"
   


I agree, I think it'll work great, and be easier.

I'm hopeful there will be lessons to apply to an ARIA 1.1 spec.
ARIA 1.0 has gone through a lot of work, but it hasn't gone through the 
rugged real-world testing of hundreds of thousands of programmers 
developing custom components.


Authoring a spreadsheet component in ARIA is a mixed-bag. There are 
great items, lots of expressiveness, but also some areas that feel 
lacking.  The spreadsheet widget metaphor has been around a long time, 
but it's open-ended in ways, much like rich text editing, and so, only 
by authoring, do we get an idea of the vocabulary.  contentEditable 
could be wrapped as a web component. Rich text styles have long been in 
accessibility interfaces.





3.
Let's look at how jquery "fails" to support ARIA, though it's an easy fix.
Many jquery widgets have ARIA hooks in place. But what about jquery itself?
$('#div').attr('role', 'button') vs $('#div').role('button');
$('#d

Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names

[Alex Russell]

On Fri, Sep 2, 2011 at 1:40 PM, Charles Pritchard  wrote:
> On 9/2/11 12:10 PM, Alex Russell wrote:
>>
>> Since Dimitri has already said everything I would, and better, I just
>> want to very quickly second his point about where we are today vs.
>> where we fear we might be: non-trivial apps have *already* given up on
>> HTML. Suggesting that there's an un-semantic future that will be
>> *caused* by the component model is to fight a battle that's already
>> lost.
>>
>> The only question we need to answer now is: how do we repair the
>> situation?
>>
>> In spending the last 9 months thinking and working through the issues
>> Dimitri presents below, our strongest theory now is that there *is* a
>> market for semantics, that it *does* organize around winners (e.g.,
>> Microformats), and that we're missing a mechanism for more directly
>> allowing authors to express their intent at app construction time in
>> ways that don't either pull them fully out of markup/html (see:
>> Closure, GWT, etc.).
>>
>> Instead of imagining total anarchy, imagine a world where something
>> like jquery-for-WebComponents comes along: a "winner" toolkit that a
>> statistically significant fraction of the web uses. Once that intent
>> is in markup and not code, it helps us set the agenda for the next
>> round of HTML's evolution.
>>
>
> Alex, Dimitri:
>
> 1.
> I've found ARIA to be an appropriate microformat for new components.
> That is what it was designed for, after all.

ARIA is how we envision components developed in this world will
communicate with assistive technology. Nothing in Web Components is
designed to supplant or replace it.

As someone who helped add ARIA support to a large framework, let me
suggest that the goal here isn't to supplant what works, but to
provide backbone and hooks into the parts of the system that don't.

ARIA presents a set of semantic roles that don't exist in HTML, and
for those, alignment with custom element implementations is
outstanding. Components that express those semantics can use ARIA to
help communicate what they "mean", taking the burden off of the users
of the components to understand and manage the role/state groups.

Where ARIA exposes behavioral, cross-cutting roles, there should be no
change in a world with Web Components.

> "data-*" works for arbitrary metadata, and "aria-*"  for UI semantics.

Yes! And for low-complexity tasks, they're perfect. For larger,
reusable components that need bundled behavior (Closure, JQuery UI,
Dijit), the task of setting up and managing all of this can be made
easier for users and developers of components by giving them a place
to hang behavior, shadow DOM, and data model concerns from.

> 2.
> ARIA 1.0 may not be sufficient, but I do think it's been designed to be
> forward compatible, and "meta" compatible with HTML5.
> I can, for instance, use: role="spreadsheet grid" even though "spreadsheet"
> is not an ARIA 1.0 role; thus forward compatibility, and semantic lenience.

Nothing we're doing reduces the utility or need for ARIA. It works
*great* with these component types, and to the extent that we can
align them, I'm excited by how much easier it's going to be for
component authors to be, allowing them to focus on concerns like a11y
instead of "how do I get this thing to fly in the first place?"

> 3.
> Let's look at how jquery "fails" to support ARIA, though it's an easy fix.
> Many jquery widgets have ARIA hooks in place. But what about jquery itself?
> $('#div').attr('role', 'button') vs $('#div').role('button');
> $('#div').attr('aria-pressed','true') vs $('div').pressed();
> Those later examples are what first class ARIA support would look like, in a
> JS framework.

The widgets themselves are the pattern that we'd like to bolster. What
low-level frameworks do is unchanged by any of this.

> 4.
> Let's look at the button example:
 Weee!!
 Becomes:
 Weee!!
>
> For the sake of ATs, that should include ARIA semantics:
> 
>
> Now the OS and ATs think of that as a button, in every way that 
> would be.
> The UA, though, does not; it leaves it up to the scripting environment.

There's a lack of terseness here that's sort of concerning. One
possible way forward might be to use "role" as a shorthand for
"becomes" and allow components to register for roles which they
implement. Hmmm.

> It'd be darn-handy if the UA would enable additional markup, such that:
>  would inherit
> default events for buttons,

In our world, you'd just subclass from HTMLButtonElement in your
component definition to do this.

Problem solved = )

> For instance, when a user presses down, on the button, the UA would actually
> set the aria-pressed property
> if onmousedown does not run event.preventDefault(). There's precedent for
> this with textarea css resize.
>
> 5.
> Mozilla has gone ahead and allowed  to be completely
> embedded, receiving .click() delegates.
>  onclick="this.getElementsByTagName('file')[0].click()"> />

I'm not sure I understand this point. I

Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names

[Charles Pritchard]

On 9/2/11 12:10 PM, Alex Russell wrote:

Since Dimitri has already said everything I would, and better, I just
want to very quickly second his point about where we are today vs.
where we fear we might be: non-trivial apps have *already* given up on
HTML. Suggesting that there's an un-semantic future that will be
*caused* by the component model is to fight a battle that's already
lost.

The only question we need to answer now is: how do we repair the situation?

In spending the last 9 months thinking and working through the issues
Dimitri presents below, our strongest theory now is that there *is* a
market for semantics, that it *does* organize around winners (e.g.,
Microformats), and that we're missing a mechanism for more directly
allowing authors to express their intent at app construction time in
ways that don't either pull them fully out of markup/html (see:
Closure, GWT, etc.).

Instead of imagining total anarchy, imagine a world where something
like jquery-for-WebComponents comes along: a "winner" toolkit that a
statistically significant fraction of the web uses. Once that intent
is in markup and not code, it helps us set the agenda for the next
round of HTML's evolution.
   

Alex, Dimitri:

1.
I've found ARIA to be an appropriate microformat for new components.
That is what it was designed for, after all.

"data-*" works for arbitrary metadata, and "aria-*"  for UI semantics.

2.
ARIA 1.0 may not be sufficient, but I do think it's been designed to be 
forward compatible, and "meta" compatible with HTML5.
I can, for instance, use: role="spreadsheet grid" even though 
"spreadsheet" is not an ARIA 1.0 role; thus forward compatibility, and 
semantic lenience.


3.
Let's look at how jquery "fails" to support ARIA, though it's an easy fix.
Many jquery widgets have ARIA hooks in place. But what about jquery itself?
$('#div').attr('role', 'button') vs $('#div').role('button');
$('#div').attr('aria-pressed','true') vs $('div').pressed();
Those later examples are what first class ARIA support would look like, 
in a JS framework.


4.
Let's look at the button example:
>>> Weee!!
>>> Becomes:
>>> Weee!!

For the sake of ATs, that should include ARIA semantics:


Now the OS and ATs think of that as a button, in every way that  
would be.

The UA, though, does not; it leaves it up to the scripting environment.

It'd be darn-handy if the UA would enable additional markup, such that:
 would 
inherit default events for buttons,


For instance, when a user presses down, on the button, the UA would 
actually set the aria-pressed property
if onmousedown does not run event.preventDefault(). There's precedent 
for this with textarea css resize.


5.
Mozilla has gone ahead and allowed  to be completely 
embedded, receiving .click() delegates.
onclick="this.getElementsByTagName('file')[0].click()">type="file" />


...

This e-mail was heavy with examples, and my examples lately have been a 
little loose. Let me know if there is any confusion on these.


-Charles

Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names

[Alex Russell]

Since Dimitri has already said everything I would, and better, I just
want to very quickly second his point about where we are today vs.
where we fear we might be: non-trivial apps have *already* given up on
HTML. Suggesting that there's an un-semantic future that will be
*caused* by the component model is to fight a battle that's already
lost.

The only question we need to answer now is: how do we repair the situation?

In spending the last 9 months thinking and working through the issues
Dimitri presents below, our strongest theory now is that there *is* a
market for semantics, that it *does* organize around winners (e.g.,
Microformats), and that we're missing a mechanism for more directly
allowing authors to express their intent at app construction time in
ways that don't either pull them fully out of markup/html (see:
Closure, GWT, etc.).

Instead of imagining total anarchy, imagine a world where something
like jquery-for-WebComponents comes along: a "winner" toolkit that a
statistically significant fraction of the web uses. Once that intent
is in markup and not code, it helps us set the agenda for the next
round of HTML's evolution.

Think of Web Components and custom elements not as (marginally) a way
to defeat HTML's semantics, but as a way for developers to get back in
touch with markup and a path for HTML's evolution that paves a
sustainable path.

The toolkits and frameworks of today are the TODO list for the current
round of HTML's evolution, and Web Components give us a better, *more*
semantic, lower-friction way to evolve in the future.

On Fri, Sep 2, 2011 at 11:47 AM, Dimitri Glazkov  wrote:
> On Fri, Sep 2, 2011 at 2:30 AM, Anne van Kesteren  wrote:
>> On Wed, 31 Aug 2011 19:29:28 +0200, Dimitri Glazkov 
>> wrote:
>>>
>>> To put it differently, you want to start with a well-known element in
>>> markup, and, through the magic of computing, this element _becomes_
>>> your component in the DOM tree. In other words, the markup:
>>>
>>> Weee!!
>>>
>>> Becomes:
>>>
>>> Weee!!
>>
>> This does not work for assistive technology. That is, you would still have
>> to completely implement the  element from scratch, including all its
>> semantics such as keyboard accessibility, etc.
>
> Ah, thanks Anne! I do indeed need to enumerate...
>
> Fear 6: Accessibility. Accessibility! Accessibility!?
>
> I contend that the Component Model does not make accessibility any
> worse. And likely the opposite.
>
> By allowing ATs to traverse into shadow subtrees, and ensuring that
> the shadow subtrees are well-behaving accessibility citizens, you
> allow authors of components to encapsulate good practices and aid in
> killing the "re-created poorly" anti-pattern. That's what Sencha,
> SproutCore, Dijit all try to do -- and the Component Model will enable
> them do this right. In fact, things like access keys or even z-index
> are quite hard (impossible) to get right, unless you have something
> like a well-functioning shadow DOM.
>
> This leaves us with the argument of replacing semantics. Since we're
> in business of sub-typing HTML elements, we don't necessarily need to
> forego their semantics:
>
> // ...
> var AwesomeButton = HTMLButtonElement.extend(awesomeButtonInitializerBag);
> Element.register('x-awesome-button', AwesomeButton);
> // ...
>
> should give you a thing that behaves like a button, with the awesome
> behavior added.
>
> In the situations where existing semantics are representative, but
> deficient, you are much better off replacing them anyway:
>
> +1
>
>>
>> What we need is not a becomes="" attribute (that renames an element and
>> therefore forgoes its semantics) but rather a way to get complete control
>> over a semantic element and tweak aspects of it. Otherwise creating such
>> controls is prohibitively expensive and only useful if you have vast
>> resources.
>
> I would argue that replacing is exactly the right thing to do. You are
> changing an element from having some basic meaning to a more specific
> meaning. Replacement seems natural and matches what authors do today.
>
>>
>> Examples of elements that should not be replaced but could be changed by a
>> binding: Having a sortable binding for ; Exposing cite="" on
>> ; Turning a  listing countries into a map.
>
> Great! Let's go through them:
>
> * Sortable binding for a table is really just a table subclass with
> some event listeners registered.
>
> * Exposing cite on blockquote sounds like something CSS should do.
> There's no extra behavior, and you're not really creating a new type
> of element. It's just extra boxes.
>
> * Turning select listing countries into a map -- composition to the rescue!:
>
> 
>   
>      Lilliput
>      Blefuscu
>   
> 
>
> >From the author's perspective, you don't actually need the select
> element. If you intend to show a map on cool browsers and select on
> the less cool ones, you are completely uninterested in having your
> select semantics dutifully reproduced. All you need is something that
> does what

Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names

[Dimitri Glazkov]

On Fri, Sep 2, 2011 at 2:30 AM, Anne van Kesteren  wrote:
> On Wed, 31 Aug 2011 19:29:28 +0200, Dimitri Glazkov 
> wrote:
>>
>> To put it differently, you want to start with a well-known element in
>> markup, and, through the magic of computing, this element _becomes_
>> your component in the DOM tree. In other words, the markup:
>>
>> Weee!!
>>
>> Becomes:
>>
>> Weee!!
>
> This does not work for assistive technology. That is, you would still have
> to completely implement the  element from scratch, including all its
> semantics such as keyboard accessibility, etc.

Ah, thanks Anne! I do indeed need to enumerate...

Fear 6: Accessibility. Accessibility! Accessibility!?

I contend that the Component Model does not make accessibility any
worse. And likely the opposite.

By allowing ATs to traverse into shadow subtrees, and ensuring that
the shadow subtrees are well-behaving accessibility citizens, you
allow authors of components to encapsulate good practices and aid in
killing the "re-created poorly" anti-pattern. That's what Sencha,
SproutCore, Dijit all try to do -- and the Component Model will enable
them do this right. In fact, things like access keys or even z-index
are quite hard (impossible) to get right, unless you have something
like a well-functioning shadow DOM.

This leaves us with the argument of replacing semantics. Since we're
in business of sub-typing HTML elements, we don't necessarily need to
forego their semantics:

// ...
var AwesomeButton = HTMLButtonElement.extend(awesomeButtonInitializerBag);
Element.register('x-awesome-button', AwesomeButton);
// ...

should give you a thing that behaves like a button, with the awesome
behavior added.

In the situations where existing semantics are representative, but
deficient, you are much better off replacing them anyway:

+1

>
> What we need is not a becomes="" attribute (that renames an element and
> therefore forgoes its semantics) but rather a way to get complete control
> over a semantic element and tweak aspects of it. Otherwise creating such
> controls is prohibitively expensive and only useful if you have vast
> resources.

I would argue that replacing is exactly the right thing to do. You are
changing an element from having some basic meaning to a more specific
meaning. Replacement seems natural and matches what authors do today.

>
> Examples of elements that should not be replaced but could be changed by a
> binding: Having a sortable binding for ; Exposing cite="" on
> ; Turning a  listing countries into a map.

Great! Let's go through them:

* Sortable binding for a table is really just a table subclass with
some event listeners registered.

* Exposing cite on blockquote sounds like something CSS should do.
There's no extra behavior, and you're not really creating a new type
of element. It's just extra boxes.

* Turning select listing countries into a map -- composition to the rescue!:


   
  Lilliput
  Blefuscu
   


>From the author's perspective, you don't actually need the select
element. If you intend to show a map on cool browsers and select on
the less cool ones, you are completely uninterested in having your
select semantics dutifully reproduced. All you need is something that
does what you need. Besides, the behavior of a map and a select are so
different than you probably would scrap the former to build the latter
anyway.

> Having some way to mint custom elements as a last resort may very well make
> sense too, but I think the emphasis should be on enhancing existing elements
> as that is less complex (for authors anyway) and more accessible.

Minting new elements only seems crazy and unreasonable if you can't do it.

The thing is, today's Web apps have already retreated into the mostly
imperative world. Despite the angry rumors, the battle for markup has
been lost. Look the source and weep:
http://dev.sencha.com/deploy/touch/docs/, http://www.npr.org/webapp,
and lots, and lots of others.

However, harnessing the HTML parser to construct an object tree gives
us a new round. You don't have to think divs and spans anymore. Once
you can start viewing any functional block of your page as a custom
element, you can return to using markup as composition medium. Hell,
in this case fetching markup lazily becomes more attractive than JSON!

>
> And FWIW, I do not think that has to be seen as "Decorator"
> http://wiki.whatwg.org/wiki/Behavior_Attachment as for the examples I listed
> above I would expect the binding to be permanent. (I would also expect you
> could expose additional DOM members, etc.)

Right. The problem with aspects/decorators is that they are
essentially the October Revolution
(http://en.wikipedia.org/wiki/October_Revolution): we attempt to make
things better by abandoning the old ways (sub-typing, that is) that
quite obviously have flaws, and installing a whole new set of ways
that are ideal and awesome -- and full of problems yet undiscovered,
yearning to waste years of our lives. As one lolcat famously s

Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names

[Anne van Kesteren]

On Wed, 31 Aug 2011 19:29:28 +0200, Dimitri Glazkov  
 wrote:

To put it differently, you want to start with a well-known element in
markup, and, through the magic of computing, this element _becomes_
your component in the DOM tree. In other words, the markup:

Weee!!

Becomes:

Weee!!


This does not work for assistive technology. That is, you would still have  
to completely implement the  element from scratch, including all  
its semantics such as keyboard accessibility, etc.


What we need is not a becomes="" attribute (that renames an element and  
therefore forgoes its semantics) but rather a way to get complete control  
over a semantic element and tweak aspects of it. Otherwise creating such  
controls is prohibitively expensive and only useful if you have vast  
resources.


Examples of elements that should not be replaced but could be changed by a  
binding: Having a sortable binding for ; Exposing cite="" on  
; Turning a  listing countries into a map.


Having some way to mint custom elements as a last resort may very well  
make sense too, but I think the emphasis should be on enhancing existing  
elements as that is less complex (for authors anyway) and more accessible.


And FWIW, I do not think that has to be seen as "Decorator"  
http://wiki.whatwg.org/wiki/Behavior_Attachment as for the examples I  
listed above I would expect the binding to be permanent. (I would also  
expect you could expose additional DOM members, etc.)



--
Anne van Kesteren
http://annevankesteren.nl/

Re: HTMLElement.register--giving components tag names

[Sergey Ilinsky]

Referencing a note dated 2003 may not sound strong any more - web-based
applications (or to be more specific - their UI) have evolved significantly
since the date. Today limiting developers to an extremely low level markup
API, such as SVG or HTML only leads to huge, hardly manageable JavaScript UI
code in any more or less complex solution.

The need in custom markup that facilitates higher level UI technologies
abstractions is here. (Meaning - has been here. Since, say 2003)

As for searching engines "not capable of indexing applications" - this is in
no way a concern, I bet neither GMail, nor AdSense apps etc. have been
successfully indexed so far. Exposing data or electronic documents is
something else.

Sergey/

On 31 August 2011 09:00, Anne van Kesteren  wrote:

> On Wed, 31 Aug 2011 07:33:16 +0200, Dominic Cooney 
> wrote:
>
>> Thanks for reading this far! These proposals aren't formal or
>> detailed. I would love to get feedback as I try to nail down some
>> specifics.
>>
>
> The basic problem with this is that you get proprietary markup going over
> the wire:
>
> http://ln.hixie.ch/?start=**1064828134&count=1
>
> Having said that, I am not sure what the "correct" alternative would be.
> XBL (as Ian envisioned it anyway) was meant to enhance non-proprietary
> markup, not to let authors create novel constructs. Now you cannot stop
> authors from exploring novel constructs of course, but whether we should
> explicitly endorse it is another matter.
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>
>

Re: HTMLElement.register--giving components tag names

[Dominic Cooney]

On Wed, Aug 31, 2011 at 1:38 PM, Erik Arvidsson  wrote:
> On Tue, Aug 30, 2011 at 22:33, Dominic Cooney  wrote:
>
>> You will notice that this says nothing about how prototypes are wired
>> up. It should. Maybe the argument to extend should have an optional
>> second field, proto, that specifies the new methods/getters/setters
>> that ContactPicker's prototype should introduce.
>>
>> This is not a general subtyping mechanism! It is only designed for
>> setting up subtypes of HTMLElement for use with register. When
>> ECMAScript and the DOM bindings are sufficiently aligned,
>> HTMLElement.register can be opened up to accept constructors defined
>> using ordinary ECMAScript mechanisms for subtyping DOM interfaces.
>> Scripts can continue to use extend (it is pretty succinct) or
>> constructors set up their own way.
>
> Providing a prototype is important.

So here’s a refinement. I will add this to the wiki:

interface ExtensibleElement {
  object extend(ElementRegisterOptions options) raises (DOMException);
}
HTMLElement implements ExtensibleElement;
…

[Callback]
interface ExtensionElementInitializer {
  void init(HTMLElement element);  // should this have a return value,
to allow replacement?
}

dictionary ElementRegisterOptions {
  ExtensionElementInitializer init;
  object? proto;  // ECMAScript-ism?
}

Author: If options.proto is specified,
HTMLElement.prototype.isPrototypeOf(options.proto) should be true, and
options.proto should not be a platform object, nor have a platform
object on the prototype chain.

UA: If options.proto is specified, and
HTMLElement.prototype.isPrototypeOf(options.proto) is false, or
options.proto is a platform object, or options.proto has a platform
object on the prototype chain, register may throw a TYPE_ERROR.

If options.proto is not specified, the resulting constructor’s
prototype property will be HTMLElement.prototype or
HTMLElement.prototype.isPrototypeOf(<>) will be
true. This object might have been synthesized by the UA.

UA: When the constructor is invoked, (same conditions on the proto as
before) the constructor may throw a TYPE_ERROR.

> For example I can imagine UI toolkits providing their own "base class"
> that all the custom elements extend.

That is most straightforward when you have

FancyWidgetBase : HTMLElement
FancyButton : FancyWidgetBase

It does not work so well when you want FancyButton to be a
HTMLButtonElement. Then you need a factory of FancyWidgetBases that
hook one up to HTMLButtonElement, HTMLDivElement, etc.

> Also, it seems essential to allow extending other things than just 
> HTMLElement.

Wearing my author hat, that sounds appealing. Browser internals may do
things like switch on an element’s tag name. It would need to start
consulting the table of extensions when it did that in order to
realize that x-fancy-button is a button element.

Re: HTMLElement.register--giving components tag names

[Erik Arvidsson]

On Tue, Aug 30, 2011 at 22:33, Dominic Cooney  wrote:

> You will notice that this says nothing about how prototypes are wired
> up. It should. Maybe the argument to extend should have an optional
> second field, proto, that specifies the new methods/getters/setters
> that ContactPicker's prototype should introduce.
>
> This is not a general subtyping mechanism! It is only designed for
> setting up subtypes of HTMLElement for use with register. When
> ECMAScript and the DOM bindings are sufficiently aligned,
> HTMLElement.register can be opened up to accept constructors defined
> using ordinary ECMAScript mechanisms for subtyping DOM interfaces.
> Scripts can continue to use extend (it is pretty succinct) or
> constructors set up their own way.

Providing a prototype is important.

For example I can imagine UI toolkits providing their own "base class"
that all the custom elements extend.

Also, it seems essential to allow extending other things than just HTMLElement.

-- 
erik

Re: HTMLElement.register--giving components tag names

[Dimitri Glazkov]

On Tue, Aug 30, 2011 at 10:33 PM, Dominic Cooney  wrote:
> "Components" (see
> http://wiki.whatwg.org/wiki/Component_Model_Use_Cases for examples of
> what I mean) need to present an API to script. For example, a
> "contacts" component might want to expose a refresh() method that
> pulls new contacts from the server. Components also need to hook up
> internal behavior implemented in script; a split pane might need to
> hook up a mouse listener on its splitter before it can really behave
> like a split pane.
>
> In script widget libraries today (YUI, Closure, etc.) this is easy
> when the widget has been created from script: when the author calls
> the constructor/factory method/whatever the widget can create DOM,
> hook up event listeners, set up the prototype chain however it wants,
> etc.
>
> However things get really murky when authors start to use markup,
> because then the parser is creating elements that are at best only
> minimally functional until they're "enhanced." So today widget
> implementations need to handle enhancing an existing element;
> frameworks need to detect these unenhanced elements and invoke
> something to enhance them; and authors needs to debug this unholy mess
> when an unenhanced element escapes and their page breaks.
>
> Wouldn't it be nice if the browser made this problem go away?
>
> I think HTML itself shows us how life could be better: Consider the
> HTML video element. It looks like a "subtype" of HTML element, with
> all of the methods and attributes a HTML element has (via the
> prototype chain), and adds methods and attributes specific for doing
> video. When you do document.createElement('video') you get back an
> object that is ready to use. There's no step to "enhance" it. When you
> do p.innerHTML = "", you get a video
> player. There's no flash of unstyled content. If you clone it and
> insert the copy into the DOM again, all of the playback controls are
> still wired up and responsive.
>
> I'm proposing we add something that lets script extend the set of tag
> names, so there is less of a bright line between elements defined in
> the HTML spec and elements defined in script. Something like:
>
> HTMLElement.register('x-contacts', ContactPicker);
>
> The first argument is an element name. The second is a constructor
> function, whose prototype property points to an object which
> introduces the API for contacts (eg a refresh method) and is wired up
> to HTMLElement.prototype.
>
> When the parser encounters , it creates an object by
> calling the ContactPicker function as a constructor. The constructor
> can wire up any internal state it wants, like creating DOM and
> attaching event listeners. When a script later retrieves the element,
> say with document.querySelector('x-contacts'), the object created
> earlier with ContactPicker is what it gets back. Since the constructor
> is run as the parser is creating the element, there's no time when the
> unenhanced element is available to script.
>
> My proposal pretty much ends here: The component itself is just
> implemented with script, DOM and CSS. There are no special hooks for
> participating in layout (just use DOM and CSS) or form submission
> (just create form controls using DOM) or security (same origin policy
> still applies) or networking (just use WebSockets or XHR) or anything
> else. There is no magic, other than teaching the browser about the new
> tag name.
>
> I'm suggesting that all registered tag names have to start with x-.
> This is to give component authors a place to build without worrying
> about conflicting with future HTML specs; the HTML spec won't define
> elements with names starting with x-. (Component authors may chose x-
> names that conflict with each other, though.) People working on the
> HTML spec can study what kinds of components are popular in the wild
> and consolidate the best ideas into new HTML elements. Page authors
> can decide if and when to move their pages from their bespoke x-
> components to the HTML alternatives, which should be better.
>
> Pages that have to work in older browsers can use fallback content.
> (This is exactly what the HTML spec advises authors to do with the
> video element, incidentally.) In newer browsers the component script
> can remove or hide the fallback content.
>
> There's the question of what to do when there is a call to
> HTMLElement.register('x-contacts', …) at some point after an x-contact
> element has been parsed. We have to do something that makes sense for
> async scripts. I think the solution is to replace the element, and the
> recent discussion on this list about renameNode is interesting and
> relevant.
>
> One practical issue with this proposal is that creating a subtype of
> HTMLElement in script (ie defining the ContactPicker function in the
> above example) is hard/impossible. A couple of the problems are:
>
> - Defining a subtypes in JavaScript is hard to begin with: You need to
> create a function, and maybe set its object pr

Re: HTMLElement.register--giving components tag names

[Dimitri Glazkov]

On Tue, Aug 30, 2011 at 10:33 PM, Dominic Cooney  wrote:
> "Components" (see
> http://wiki.whatwg.org/wiki/Component_Model_Use_Cases for examples of
> what I mean) need to present an API to script. For example, a
> "contacts" component might want to expose a refresh() method that
> pulls new contacts from the server. Components also need to hook up
> internal behavior implemented in script; a split pane might need to
> hook up a mouse listener on its splitter before it can really behave
> like a split pane.
>
> In script widget libraries today (YUI, Closure, etc.) this is easy
> when the widget has been created from script: when the author calls
> the constructor/factory method/whatever the widget can create DOM,
> hook up event listeners, set up the prototype chain however it wants,
> etc.
>
> However things get really murky when authors start to use markup,
> because then the parser is creating elements that are at best only
> minimally functional until they're "enhanced." So today widget
> implementations need to handle enhancing an existing element;
> frameworks need to detect these unenhanced elements and invoke
> something to enhance them; and authors needs to debug this unholy mess
> when an unenhanced element escapes and their page breaks.
>
> Wouldn't it be nice if the browser made this problem go away?
>
> I think HTML itself shows us how life could be better: Consider the
> HTML video element. It looks like a "subtype" of HTML element, with
> all of the methods and attributes a HTML element has (via the
> prototype chain), and adds methods and attributes specific for doing
> video. When you do document.createElement('video') you get back an
> object that is ready to use. There's no step to "enhance" it. When you
> do p.innerHTML = "", you get a video
> player. There's no flash of unstyled content. If you clone it and
> insert the copy into the DOM again, all of the playback controls are
> still wired up and responsive.
>
> I'm proposing we add something that lets script extend the set of tag
> names, so there is less of a bright line between elements defined in
> the HTML spec and elements defined in script. Something like:
>
> HTMLElement.register('x-contacts', ContactPicker);
>
> The first argument is an element name. The second is a constructor
> function, whose prototype property points to an object which
> introduces the API for contacts (eg a refresh method) and is wired up
> to HTMLElement.prototype.
>
> When the parser encounters , it creates an object by
> calling the ContactPicker function as a constructor. The constructor
> can wire up any internal state it wants, like creating DOM and
> attaching event listeners. When a script later retrieves the element,
> say with document.querySelector('x-contacts'), the object created
> earlier with ContactPicker is what it gets back. Since the constructor
> is run as the parser is creating the element, there's no time when the
> unenhanced element is available to script.
>
> My proposal pretty much ends here: The component itself is just
> implemented with script, DOM and CSS. There are no special hooks for
> participating in layout (just use DOM and CSS) or form submission
> (just create form controls using DOM) or security (same origin policy
> still applies) or networking (just use WebSockets or XHR) or anything
> else. There is no magic, other than teaching the browser about the new
> tag name.
>
> I'm suggesting that all registered tag names have to start with x-.
> This is to give component authors a place to build without worrying
> about conflicting with future HTML specs; the HTML spec won't define
> elements with names starting with x-. (Component authors may chose x-
> names that conflict with each other, though.) People working on the
> HTML spec can study what kinds of components are popular in the wild
> and consolidate the best ideas into new HTML elements. Page authors
> can decide if and when to move their pages from their bespoke x-
> components to the HTML alternatives, which should be better.
>
> Pages that have to work in older browsers can use fallback content.
> (This is exactly what the HTML spec advises authors to do with the
> video element, incidentally.) In newer browsers the component script
> can remove or hide the fallback content.
>
> There's the question of what to do when there is a call to
> HTMLElement.register('x-contacts', …) at some point after an x-contact
> element has been parsed. We have to do something that makes sense for
> async scripts. I think the solution is to replace the element, and the
> recent discussion on this list about renameNode is interesting and
> relevant.
>
> One practical issue with this proposal is that creating a subtype of
> HTMLElement in script (ie defining the ContactPicker function in the
> above example) is hard/impossible. A couple of the problems are:
>
> - Defining a subtypes in JavaScript is hard to begin with: You need to
> create a function, and maybe set its object pr

Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names

[Dimitri Glazkov]

On Wed, Aug 31, 2011 at 10:29 AM, Dimitri Glazkov  wrote:
> I will write up the exact algorithm in a wiki shortly.

Here it is: http://wiki.whatwg.org/wiki/Component_Model_Progressive_Enhancement

:DG<

Custom tags over wire, was Re: HTMLElement.register--giving components tag names

[Dimitri Glazkov]

Splitting off to its own thread, because this deserves a good discussion.

On Wed, Aug 31, 2011 at 12:00 AM, Anne van Kesteren  wrote:
> On Wed, 31 Aug 2011 07:33:16 +0200, Dominic Cooney 
> wrote:
>>
>> Thanks for reading this far! These proposals aren't formal or
>> detailed. I would love to get feedback as I try to nail down some
>> specifics.
>
> The basic problem with this is that you get proprietary markup going over
> the wire:
>
> http://ln.hixie.ch/?start=1064828134&count=1

FWIW, I am in total agreement with this post. If the author requires a
UA to have a proprietary parser that has its own, separate means of
producing a valid DOM tree, you are so screwed.

>
> Having said that, I am not sure what the "correct" alternative would be. XBL
> (as Ian envisioned it anyway) was meant to enhance non-proprietary markup,
> not to let authors create novel constructs. Now you cannot stop authors from
> exploring novel constructs of course, but whether we should explicitly
> endorse it is another matter.

Yes, indeed. We are at the crossroads. The Web needs element behavior
attachment (http://wiki.whatwg.org/wiki/Behavior_Attachment) and the
ability to define new types elements, yet we are really afraid of
following through with that. But... are these fears rational? Let's
examine the them in detail.


Fear 1: Fallback bogeyman cometh.

 is no worse than  in every mechanical sense. In the absence of
definition for "x-accordion" (or Component Model plumbing), both mean
the same thing, both can be styled in the same way. One is
HTMLUnknownElement, the other is HTMLDivElement, and their API surface
is identical. So... no fallback problems.


Fear 2: Custom tags are confusing.

The  clearly identifies the type of the behavior expected
from the element, and conveys element behavior attachment nicely. On
the other hand,  implies decorator behavior
attachement, e.g. that removing the class value (and thus turning it
back into a vanilla ) is perfectly ok, which by the way, is
probably _not_ what the author of the Accordion component expects "in
real life". I mean, you can _make_ the author expect that, but that
seems like cruel and unusual punishment.

In other words -- it's quite the opposite. Custom tags are more
_clear_. In fact, they are as close as _saying_what_you_mean_ as it
gets.


Fear 3: Custom tags have no meaning.

Well, friends -- this train had left the station a long time ago. Alex
Russell joked once that you already totally can add custom tags in
HTML -- as long as you're Hixie. As HTML spec grows new tags, their
meaning is only captured in a written document that's meaningless to
the UAs that were built a priori. If anything, the Component Model
provides an explicit path _learn_ about the need for new elements in
the spec. Just grep the Web for "Weee!!

Becomes:

Weee!!

As soon as:
1) the definition of "x-awesome-button" is registered and;
2) the element is in the DOM tree.

I will write up the exact algorithm in a wiki shortly.

I hope this addressed our worst fears and some. I thereby declare that
we should stop being afraid and liberate ourselves from the burden of
custom tag anxiety. Long live custom tags!

:DG<

Re: HTMLElement.register--giving components tag names

[Anne van Kesteren]

On Wed, 31 Aug 2011 07:33:16 +0200, Dominic Cooney   
wrote:

Thanks for reading this far! These proposals aren't formal or
detailed. I would love to get feedback as I try to nail down some
specifics.


The basic problem with this is that you get proprietary markup going over  
the wire:


http://ln.hixie.ch/?start=1064828134&count=1

Having said that, I am not sure what the "correct" alternative would be.  
XBL (as Ian envisioned it anyway) was meant to enhance non-proprietary  
markup, not to let authors create novel constructs. Now you cannot stop  
authors from exploring novel constructs of course, but whether we should  
explicitly endorse it is another matter.



--
Anne van Kesteren
http://annevankesteren.nl/

HTMLElement.register--giving components tag names

[Dominic Cooney]

"Components" (see
http://wiki.whatwg.org/wiki/Component_Model_Use_Cases for examples of
what I mean) need to present an API to script. For example, a
"contacts" component might want to expose a refresh() method that
pulls new contacts from the server. Components also need to hook up
internal behavior implemented in script; a split pane might need to
hook up a mouse listener on its splitter before it can really behave
like a split pane.

In script widget libraries today (YUI, Closure, etc.) this is easy
when the widget has been created from script: when the author calls
the constructor/factory method/whatever the widget can create DOM,
hook up event listeners, set up the prototype chain however it wants,
etc.

However things get really murky when authors start to use markup,
because then the parser is creating elements that are at best only
minimally functional until they're "enhanced." So today widget
implementations need to handle enhancing an existing element;
frameworks need to detect these unenhanced elements and invoke
something to enhance them; and authors needs to debug this unholy mess
when an unenhanced element escapes and their page breaks.

Wouldn't it be nice if the browser made this problem go away?

I think HTML itself shows us how life could be better: Consider the
HTML video element. It looks like a "subtype" of HTML element, with
all of the methods and attributes a HTML element has (via the
prototype chain), and adds methods and attributes specific for doing
video. When you do document.createElement('video') you get back an
object that is ready to use. There's no step to "enhance" it. When you
do p.innerHTML = "", you get a video
player. There's no flash of unstyled content. If you clone it and
insert the copy into the DOM again, all of the playback controls are
still wired up and responsive.

I'm proposing we add something that lets script extend the set of tag
names, so there is less of a bright line between elements defined in
the HTML spec and elements defined in script. Something like:

HTMLElement.register('x-contacts', ContactPicker);

The first argument is an element name. The second is a constructor
function, whose prototype property points to an object which
introduces the API for contacts (eg a refresh method) and is wired up
to HTMLElement.prototype.

When the parser encounters , it creates an object by
calling the ContactPicker function as a constructor. The constructor
can wire up any internal state it wants, like creating DOM and
attaching event listeners. When a script later retrieves the element,
say with document.querySelector('x-contacts'), the object created
earlier with ContactPicker is what it gets back. Since the constructor
is run as the parser is creating the element, there's no time when the
unenhanced element is available to script.

My proposal pretty much ends here: The component itself is just
implemented with script, DOM and CSS. There are no special hooks for
participating in layout (just use DOM and CSS) or form submission
(just create form controls using DOM) or security (same origin policy
still applies) or networking (just use WebSockets or XHR) or anything
else. There is no magic, other than teaching the browser about the new
tag name.

I'm suggesting that all registered tag names have to start with x-.
This is to give component authors a place to build without worrying
about conflicting with future HTML specs; the HTML spec won't define
elements with names starting with x-. (Component authors may chose x-
names that conflict with each other, though.) People working on the
HTML spec can study what kinds of components are popular in the wild
and consolidate the best ideas into new HTML elements. Page authors
can decide if and when to move their pages from their bespoke x-
components to the HTML alternatives, which should be better.

Pages that have to work in older browsers can use fallback content.
(This is exactly what the HTML spec advises authors to do with the
video element, incidentally.) In newer browsers the component script
can remove or hide the fallback content.

There's the question of what to do when there is a call to
HTMLElement.register('x-contacts', …) at some point after an x-contact
element has been parsed. We have to do something that makes sense for
async scripts. I think the solution is to replace the element, and the
recent discussion on this list about renameNode is interesting and
relevant.

One practical issue with this proposal is that creating a subtype of
HTMLElement in script (ie defining the ContactPicker function in the
above example) is hard/impossible. A couple of the problems are:

- Defining a subtypes in JavaScript is hard to begin with: You need to
create a function, and maybe set its object prototype up; you need to
create a prototype object and wire its object prototype up; you might
add a constructor property to the new prototype object; and you need
to remember to call your "base type" constructor to let it do an