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

On 9/2/11 3:00 PM, Alex Russell wrote:
> 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.
>    

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');
>> $('#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.
>    

Makes sense.

Low-level frameworks should pick up some of these semantics, so they may 
more easily work with Web Components and other ARIA-laden structures.

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

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'm concerned (though I've not investigated), that adding additional 
behavior to role would be against the traditional non-interference of 
ARIA on host semantics. CSS on the other hand, certainly changes host 
semantics.

"becomes" as an attribute representing a CSS+ARIA profile, could make 
some sense. It should give precedent to aria role over the tag name.

>    
>> 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 = )
>    
It's like that in C++ as well, for most of the browser vendors.

There's just the issue with all-or-nothing/isolation of behavior.

Thus the fears about accessibility of custom components: once you step 
outside the compiled browser behavior, you lose most of the work vendors 
put into the UA.

How about: <x-awesome-button becomes="button">; incorporating both ARIA 
and HTML/CSS default events.
This is something you'd only use in dynamic dom / shadow dom. Setting 
becomes would also set the role attribute on the tag.

The static dom should still have <button>, or in the worst case, <div 
role="button">.


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

I meant only to show that there is now precedent for completely hiding 
an interactive target element, such as input type="file".
That example should have had: <input type="file" style="display: none;" />.

As I understand it, that kind of construct: <div role="button"><input 
style="display: none;" /></div>,
is a preview of what Web Components will handle. It would help to handle 
delegation of security-sensitive events.

It'd really be helpful to be able to forward events, such as .click().

Consider a "target" attribute, in addition to "becomes":
<div becomes="file button" target="input"><input style="display: none;" 
type="file" /></div>

That's certainly easier than setting up all of the click and focus handlers.
It does have the negative effect of disabling file on non-supporting 
non-scripted environments.

Something like this would still work, for such targets:
<div becomes="file button" target="input" style="content: '' 
replaced;"><input type="file" /></div>

If Web Components were integrated with CSS generated content, the 
content style could be improved:
<div becomes="file button" target="input" style="content: 
component;"><input type="file" /></div>

When the subtree is simple, the markup could be as well:
<div becomes="file"><input type="file" /></div>

At that point, we have reached similar proposals/solutions to these use 
cases, relying on the existing CSS generated content spec.
<input type="file" style="content: url('myimage.png') replaced;" />


-Charles

Received on Friday, 2 September 2011 22:59:21 UTC