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

On Fri, Sep 2, 2011 at 1:40 PM, Charles Pritchard <chuck@jumis.com> 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:
>>>> <button becomes="x-awesome-button">Weee!!</button>
>>>> Becomes:
>>>> <x-awesome-button>Weee!!</x-awesome-button>
>
> For the sake of ATs, that should include ARIA semantics:
> <x-awesome-button role="button" tabindex="0"></x-awesome-botton>
>
> Now the OS and ATs think of that as a button, in every way that <button>
> 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:
> <x-awesome-button role="button" style="appearance: button"> 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 <input type="file"> to be completely
> embedded, receiving .click() delegates.
> <x-awesome-button role="button"
> onclick="this.getElementsByTagName('file')[0].click()"><input type="file"
> /></x-awesome-button>

I'm not sure I understand this point. Internally, browsers
differentiate from generated click events on security-sensitive
components and "real" click events. Are you suggesting we need
something to help handle this case?

> ...
>
> 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.

Received on Friday, 2 September 2011 22:01:40 UTC