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

On Fri, Sep 2, 2011 at 3:58 PM, Charles Pritchard <chuck@jumis.com> wrote:
> 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.

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

Agreed.

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

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

This is the problem that every JS-built component has today. Web
Components are a no-op as far as this is concerned.

> How about: <x-awesome-button becomes="button">; incorporating both ARIA and
> HTML/CSS default events.

It's unclear why you need both. If x-awesome-button is built as a
Button subclass, it's all good. If you had <button
becomes="x-awesome-button">, then you might get some fallback behavior
for old UAs which might be a win, but tag nesting can get you there
too.

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

Not sure I understand this point. Can you clarify?

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

In the WebKit implementation of shadow-DOM, we already handle such
forwarding correctly. Events that bubble out do "appear" to have come
from the component, not the item in the shadow DOM.

> 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 Saturday, 3 September 2011 01:40:47 UTC