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

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

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,

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>

...

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

Received on Friday, 2 September 2011 20:41:10 UTC