W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

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

From: Charles Pritchard <chuck@jumis.com>
Date: Fri, 02 Sep 2011 15:58:58 -0700
Message-ID: <4E615FB2.5000702@jumis.com>
To: Alex Russell <alex@dojotoolkit.org>
CC: Dimitri Glazkov <dglazkov@chromium.org>, Anne van Kesteren <annevk@opera.com>, WebApps WG <public-webapps@w3.org>, Dominic Cooney <dominicc@chromium.org>
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 
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 

"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 

>> 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;" />

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

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:34 UTC