Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names
On Sat, Sep 3, 2011 at 4:31 AM, Anne van Kesteren wrote: > > On Fri, 02 Sep 2011 20:47:27 +0200, Dimitri Glazkov > wrote: >> BTW, I really ought to put this "fears" list on the Wiki. > > Yeah that would probably be a good idea. Done: http://wiki.whatwg.org/wiki/Custom_Tags_Analysis it still needs work, but the main stuff is there. :DG<
Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names
On 3/09/11 4:47 AM, Dimitri Glazkov wrote: On Fri, Sep 2, 2011 at 2:30 AM, Anne van Kesteren wrote: Examples of elements that should not be replaced but could be changed by a binding: Having a sortable binding for; Exposing cite="" on ; Turning a listing countries into a map. Great! Let's go through them: * Sortable binding for a table is really just a table subclass with some event listeners registered. * Exposing cite on blockquote sounds like something CSS should do. There's no extra behavior, and you're not really creating a new type of element. It's just extra boxes. * Turning select listing countries into a map -- composition to the rescue!: Lilliput Blefuscu > From the author's perspective, you don't actually need the select element. If you intend to show a map on cool browsers and select on the less cool ones, you are completely uninterested in having your select semantics dutifully reproduced. All you need is something that does what you need. Besides, the behavior of a map and a select are so different than you probably would scrap the former to build the latter anyway. The author wants the select element so that form submission works. The semantics of select are also quite useful as you might want the country-map widget to allow multiple selections, have a default selected country, and have a non-comprehensive list of countries to choose from. As you have indicated, the user needs the select element as the fallback presentation. It would also be useful if user stylesheets could override the behavior chosen by the author - either reverting to a browser select widget, or something provided by a browser add-on. This capability depends on there being a defacto standard for applying the country-map behavior. Which do you think would take on more quickly: a) custom tag-names, or b) aria or data attributes I'm almost certain it's b. My personal opinion is that most of the perceived need for custom tag-names is to put presentation into HTML. Kind of like and but without the benefit of being standards (de facto or de jure). Sean
Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names
On Sun, Sep 4, 2011 at 5:03 PM, Robert O'Callahan wrote: > On Sun, Sep 4, 2011 at 1:56 PM, Dimitri Glazkov > wrote: >> >> The offsetWidth query could've triggered an event >> handler execution > > I don't think "offsetWidth" should be able to trigger synchronous execution > of an event listener in the content. How would that happen? It's certainly possible in WebKit (http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/dom/Document.cpp&l=1565). All it takes for the layout bit to be dirty and an event to be queued up prior to the hapless script accessing Element::offsetWidth (http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/dom/Element.cpp&l=387). Let's not rathole on this specific case though -- the whole notion is that the interface of the object changes as a result of spooky action at a distance is preposterous and should certainly not be codified into the platform. Sure, you can already yank my prototype chain with __proto__ and override my methods, bu those things are widely viewed as bad form. We have enough bad form. Let's not add more. :DG< > > Rob > -- > "If we claim to be without sin, we deceive ourselves and the truth is not in > us. If we confess our sins, he is faithful and just and will forgive us our > sins and purify us from all unrighteousness. If we claim we have not sinned, > we make him out to be a liar and his word is not in us." [1 John 1:8-10] >
Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names
On Sun, Sep 4, 2011 at 1:56 PM, Dimitri Glazkov wrote: > The offsetWidth query could've triggered an event > handler execution > I don't think "offsetWidth" should be able to trigger synchronous execution of an event listener in the content. How would that happen? Rob -- "If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us." [1 John 1:8-10]
Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names
On Sat, Sep 3, 2011 at 12:08 PM, Ian Hickson wrote: > On Fri, 2 Sep 2011, Anne van Kesteren wrote: >> >> What we need is not a becomes="" attribute (that renames an element and >> therefore forgoes its semantics) but rather a way to get complete >> control over a semantic element and tweak aspects of it. Otherwise >> creating such controls is prohibitively expensive and only useful if you >> have vast resources. > > Exactly. This is in fact how XBL works. This is why the widgets in the > HTML spec are defined in terms of bindings -- the idea is that authors can > then provide their own alternative bindings or inherit from them. We would > provide basic bindings that they can reuse in their inheritance chain, > e.g. so that they can override just the look of the button but get all the > interactive behaviour (accessibility roles, keyboard navigation, mouse > click reactions, etc) for free. You get all of those for free with the ability to sub-type the elements, as explained elsewhere in this thread. What you also get with the Component Model vs. XBL-like bindings is the consistency of the API surface. Note: I am explicitly calling this "XBL-like", because XBL2 intentionally avoids the ability to extend a DOM element API surface with a binding -- so we're not operating in real of a currently existing spec here. But in a general XBL-like model, the problem you have is that at any given moment of time, it is unclear whether your element has a certain API or not. Consider this: in your JS application, you hold a reference to DOM element, and know for a fact it has methods/properties of some Widget binding, that's currently applied to the element. You then access an offsetWidth property on that DOM element... Pop quiz: what's the API surface of your widget now? The answer is: you can never know. The offsetWidth query could've triggered an event handler execution, which could've modified some CSS that binds that particular Widget binding to this element, unbinding it or worse yet, turning it into some other type. BOOM goes the landmine, and there you are, watching your leg fly off. That's the trouble with decorators -- they are ephemeral things that should never, _ever_ expose an API on DOM elements. Otherwise, _anytime_ you are about to access a property or call a method on a DOM element, you'd have to first do a hasBinding check on it. Show of hands -- who wants to write their code that way? If I see any, it's not for long -- those landmines will expeditiously take care of those extra limbs for you. XBL2 provides a set of machinery to make decorators, but in doing so it fails miserably at addressing the use cases that Web application and Web framework developers actually need. And that's why "XBL-like approach" is a pie-in-the-sky key phrase that should never be applied to element behavior attachment. :DG< > > -- > Ian Hickson U+1047E )\._.,--,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >
Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names
On Sep 3, 2011, at 12:08 PM, Ian Hickson wrote: > On Fri, 2 Sep 2011, Anne van Kesteren wrote: >> >> What we need is not a becomes="" attribute (that renames an element and >> therefore forgoes its semantics) but rather a way to get complete >> control over a semantic element and tweak aspects of it. Otherwise >> creating such controls is prohibitively expensive and only useful if you >> have vast resources. > > Exactly. This is in fact how XBL works. This is why the widgets in the > HTML spec are defined in terms of bindings -- the idea is that authors can > then provide their own alternative bindings or inherit from them. We would > provide basic bindings that they can reuse in their inheritance chain, > e.g. so that they can override just the look of the button but get all the > interactive behaviour (accessibility roles, keyboard navigation, mouse > click reactions, etc) for free. > Isn't that the domain of CSS? > -- > Ian Hickson U+1047E)\._.,--,'``.fL > http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >
Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names
On Fri, 2 Sep 2011, Anne van Kesteren wrote: > > What we need is not a becomes="" attribute (that renames an element and > therefore forgoes its semantics) but rather a way to get complete > control over a semantic element and tweak aspects of it. Otherwise > creating such controls is prohibitively expensive and only useful if you > have vast resources. Exactly. This is in fact how XBL works. This is why the widgets in the HTML spec are defined in terms of bindings -- the idea is that authors can then provide their own alternative bindings or inherit from them. We would provide basic bindings that they can reuse in their inheritance chain, e.g. so that they can override just the look of the button but get all the interactive behaviour (accessibility roles, keyboard navigation, mouse click reactions, etc) for free. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names
On 9/2/2011 6:39 PM, Alex Russell wrote:
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
I meant to short-hand the specs in the "HTML element to Accessibility
API Role Mapping Matrix":
http://dev.w3.org/html5/html-api-map/#api-role
As evolved from:
2010:
http://www.paciellogroup.com/blog/misc/HTML5/aria-html5-proposal.html
2009:
http://dev.w3.org/html5/markup/aria/
I didn't mean to introduce a new state mechanism. CSS selectors already
work with ARIA.
With transitions, and generated content, CSS is quite flexible.
This would work fine with transitions:
div[aria-checked="true"] { content: 'Checked'; color: red;}
div[aria-checked="false"] { content: 'Not Checked'; color: black; }
I suspect we're talking about different things.
How should ATs be notified/detect that there is a shadow DOM?
Focus works as it always has. It can move inside the shadow.
Does the following statement make sense?:
ATs that walk the DOM should check for element.shadow [currently
webkitShadow],
prior to looking for element.childNodes.
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.
What of components that contain multiple roles?
Would those components, necessarily, require a public shadow?
There was some discussion about allowing multiple children on the shadow.
Perhaps this would be a good use case for it.
"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 elements in the shadow, meaning
you don't need a "hidden tree" per sae.
I like to think that it encapsulates current practice. I'm all for it.
We still need a canvas subtree, to operate with the canvas 2d spec on
drawFocusRing.
4.
Let's look at the button example:
Weee!!
Becomes:
Weee!!
For the sake of ATs, that should include ARIA semantics:
Now the OS and ATs think of that as a button, in every way that
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.
CSS selectors make this easy enough. ARIA has an extensible vocabulary,
and CSS has an easy query language.
ARIA is intended to advertise the state of a component. ATs need that
information.
It was designed to be extensible and non-intrusive.
Yes, items are stuffed into CSS class names
Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names
On Fri, 02 Sep 2011 20:47:27 +0200, Dimitri Glazkov
wrote:
Fear 6: Accessibility. Accessibility! Accessibility!?
I contend that the Component Model does not make accessibility any
worse. And likely the opposite.
By allowing ATs to traverse into shadow subtrees, and ensuring that
the shadow subtrees are well-behaving accessibility citizens, you
allow authors of components to encapsulate good practices and aid in
killing the "re-created poorly" anti-pattern. That's what Sencha,
SproutCore, Dijit all try to do -- and the Component Model will enable
them do this right. In fact, things like access keys or even z-index
are quite hard (impossible) to get right, unless you have something
like a well-functioning shadow DOM.
The problem is not so much that you cannot make it accessible. It is that
making it accessible is complicated for the average authors.
This leaves us with the argument of replacing semantics. Since we're
in business of sub-typing HTML elements, we don't necessarily need to
forego their semantics:
// ...
var AwesomeButton =
HTMLButtonElement.extend(awesomeButtonInitializerBag);
Element.register('x-awesome-button', AwesomeButton);
// ...
should give you a thing that behaves like a button, with the awesome
behavior added.
In the situations where existing semantics are representative, but
deficient, you are much better off replacing them anyway:
+1
Depending on the specifics, I suppose this might work.
What we need is not a becomes="" attribute (that renames an element and
therefore forgoes its semantics) but rather a way to get complete
control
over a semantic element and tweak aspects of it. Otherwise creating such
controls is prohibitively expensive and only useful if you have vast
resources.
I would argue that replacing is exactly the right thing to do. You are
changing an element from having some basic meaning to a more specific
meaning. Replacement seems natural and matches what authors do today.
It depends on what is exposed to assistive technolgoy and how much authors
have to implement themselves regarding e.g. keyboard accessibility. If you
get them somehow magically by using extend() you might not even need
becomes="".
Examples of elements that should not be replaced but could be changed
by a
binding: Having a sortable binding for ; Exposing cite="" on
; Turning a listing countries into a map.
Great! Let's go through them:
* Sortable binding for a table is really just a table subclass with
some event listeners registered.
But how do make this work as a new element? Especially for parsing
is somewhat hairy.
* Exposing cite on blockquote sounds like something CSS should do.
There's no extra behavior, and you're not really creating a new type
of element. It's just extra boxes.
There might be extra behavior, such as clicking on the
exposing it, or some such.
* Turning select listing countries into a map -- composition to the
rescue!:
Lilliput
Blefuscu
From the author's perspective, you don't actually need the select
element. If you intend to show a map on cool browsers and select on
the less cool ones, you are completely uninterested in having your
select semantics dutifully reproduced. All you need is something that
does what you need. Besides, the behavior of a map and a select are so
different than you probably would scrap the former to build the latter
anyway.
The idea is that the outcome is the same, but that the presentation is
completely different. Both controls have the same goal and semantics, just
their presentation is different. So wrapping it in a does
not seem like the proper approach.
Having some way to mint custom elements as a last resort may very well
make sense too, but I think the emphasis should be on enhancing
existing elements as that is less complex (for authors anyway) and more
accessible.
Minting new elements only seems crazy and unreasonable if you can't do
it.
That's not what I said.
The thing is, today's Web apps have already retreated into the mostly
imperative world. Despite the angry rumors, the battle for markup has
been lost. Look the source and weep:
http://dev.sencha.com/deploy/touch/docs/, http://www.npr.org/webapp,
and lots, and lots of others.
However, harnessing the HTML parser to construct an object tree gives
us a new round. You don't have to think divs and spans anymore. Once
you can start viewing any functional block of your page as a custom
element, you can return to using markup as composition medium. Hell,
in this case fetching markup lazily becomes more attractive than JSON!
I don't think there is any disagreement about current practice. Heck,
maybe we do not even disagree and I just not understand it fully.
And FWIW, I do not think that has to be seen as "Decorator"
http://wiki.whatwg.org/wiki/Behavior_Attachment as for the examples I
listed
above I would expect the binding to be permanent. (I would also expect
yo
Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names
On Fri, Sep 2, 2011 at 3:58 PM, Charles Pritchard wrote:
> On 9/2/11 3:00 PM, Alex Russell wrote:
>>
>> On Fri, Sep 2, 2011 at 1:40 PM, Charles Pritchard 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 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
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 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');
$('#d
Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names
On Fri, Sep 2, 2011 at 1:40 PM, Charles Pritchard 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:
Weee!!
Becomes:
Weee!!
>
> For the sake of ATs, that should include ARIA semantics:
>
>
> Now the OS and ATs think of that as a button, in every way that
> 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:
> 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 to be completely
> embedded, receiving .click() delegates.
> onclick="this.getElementsByTagName('file')[0].click()"> />
I'm not sure I understand this point. I
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:
>>> Weee!!
>>> Becomes:
>>> Weee!!
For the sake of ATs, that should include ARIA semantics:
Now the OS and ATs think of that as a button, in every way that
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:
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 to be completely
embedded, receiving .click() delegates.
onclick="this.getElementsByTagName('file')[0].click()">type="file" />
...
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
Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names
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.
Think of Web Components and custom elements not as (marginally) a way
to defeat HTML's semantics, but as a way for developers to get back in
touch with markup and a path for HTML's evolution that paves a
sustainable path.
The toolkits and frameworks of today are the TODO list for the current
round of HTML's evolution, and Web Components give us a better, *more*
semantic, lower-friction way to evolve in the future.
On Fri, Sep 2, 2011 at 11:47 AM, Dimitri Glazkov wrote:
> On Fri, Sep 2, 2011 at 2:30 AM, Anne van Kesteren wrote:
>> On Wed, 31 Aug 2011 19:29:28 +0200, Dimitri Glazkov
>> wrote:
>>>
>>> To put it differently, you want to start with a well-known element in
>>> markup, and, through the magic of computing, this element _becomes_
>>> your component in the DOM tree. In other words, the markup:
>>>
>>> Weee!!
>>>
>>> Becomes:
>>>
>>> Weee!!
>>
>> This does not work for assistive technology. That is, you would still have
>> to completely implement the element from scratch, including all its
>> semantics such as keyboard accessibility, etc.
>
> Ah, thanks Anne! I do indeed need to enumerate...
>
> Fear 6: Accessibility. Accessibility! Accessibility!?
>
> I contend that the Component Model does not make accessibility any
> worse. And likely the opposite.
>
> By allowing ATs to traverse into shadow subtrees, and ensuring that
> the shadow subtrees are well-behaving accessibility citizens, you
> allow authors of components to encapsulate good practices and aid in
> killing the "re-created poorly" anti-pattern. That's what Sencha,
> SproutCore, Dijit all try to do -- and the Component Model will enable
> them do this right. In fact, things like access keys or even z-index
> are quite hard (impossible) to get right, unless you have something
> like a well-functioning shadow DOM.
>
> This leaves us with the argument of replacing semantics. Since we're
> in business of sub-typing HTML elements, we don't necessarily need to
> forego their semantics:
>
> // ...
> var AwesomeButton = HTMLButtonElement.extend(awesomeButtonInitializerBag);
> Element.register('x-awesome-button', AwesomeButton);
> // ...
>
> should give you a thing that behaves like a button, with the awesome
> behavior added.
>
> In the situations where existing semantics are representative, but
> deficient, you are much better off replacing them anyway:
>
> +1
>
>>
>> What we need is not a becomes="" attribute (that renames an element and
>> therefore forgoes its semantics) but rather a way to get complete control
>> over a semantic element and tweak aspects of it. Otherwise creating such
>> controls is prohibitively expensive and only useful if you have vast
>> resources.
>
> I would argue that replacing is exactly the right thing to do. You are
> changing an element from having some basic meaning to a more specific
> meaning. Replacement seems natural and matches what authors do today.
>
>>
>> Examples of elements that should not be replaced but could be changed by a
>> binding: Having a sortable binding for ; Exposing cite="" on
>> ; Turning a listing countries into a map.
>
> Great! Let's go through them:
>
> * Sortable binding for a table is really just a table subclass with
> some event listeners registered.
>
> * Exposing cite on blockquote sounds like something CSS should do.
> There's no extra behavior, and you're not really creating a new type
> of element. It's just extra boxes.
>
> * Turning select listing countries into a map -- composition to the rescue!:
>
>
>
> Lilliput
> Blefuscu
>
>
>
> >From the author's perspective, you don't actually need the select
> element. If you intend to show a map on cool browsers and select on
> the less cool ones, you are completely uninterested in having your
> select semantics dutifully reproduced. All you need is something that
> does what
Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names
On Fri, Sep 2, 2011 at 2:30 AM, Anne van Kesteren wrote:
> On Wed, 31 Aug 2011 19:29:28 +0200, Dimitri Glazkov
> wrote:
>>
>> To put it differently, you want to start with a well-known element in
>> markup, and, through the magic of computing, this element _becomes_
>> your component in the DOM tree. In other words, the markup:
>>
>> Weee!!
>>
>> Becomes:
>>
>> Weee!!
>
> This does not work for assistive technology. That is, you would still have
> to completely implement the element from scratch, including all its
> semantics such as keyboard accessibility, etc.
Ah, thanks Anne! I do indeed need to enumerate...
Fear 6: Accessibility. Accessibility! Accessibility!?
I contend that the Component Model does not make accessibility any
worse. And likely the opposite.
By allowing ATs to traverse into shadow subtrees, and ensuring that
the shadow subtrees are well-behaving accessibility citizens, you
allow authors of components to encapsulate good practices and aid in
killing the "re-created poorly" anti-pattern. That's what Sencha,
SproutCore, Dijit all try to do -- and the Component Model will enable
them do this right. In fact, things like access keys or even z-index
are quite hard (impossible) to get right, unless you have something
like a well-functioning shadow DOM.
This leaves us with the argument of replacing semantics. Since we're
in business of sub-typing HTML elements, we don't necessarily need to
forego their semantics:
// ...
var AwesomeButton = HTMLButtonElement.extend(awesomeButtonInitializerBag);
Element.register('x-awesome-button', AwesomeButton);
// ...
should give you a thing that behaves like a button, with the awesome
behavior added.
In the situations where existing semantics are representative, but
deficient, you are much better off replacing them anyway:
+1
>
> What we need is not a becomes="" attribute (that renames an element and
> therefore forgoes its semantics) but rather a way to get complete control
> over a semantic element and tweak aspects of it. Otherwise creating such
> controls is prohibitively expensive and only useful if you have vast
> resources.
I would argue that replacing is exactly the right thing to do. You are
changing an element from having some basic meaning to a more specific
meaning. Replacement seems natural and matches what authors do today.
>
> Examples of elements that should not be replaced but could be changed by a
> binding: Having a sortable binding for ; Exposing cite="" on
> ; Turning a listing countries into a map.
Great! Let's go through them:
* Sortable binding for a table is really just a table subclass with
some event listeners registered.
* Exposing cite on blockquote sounds like something CSS should do.
There's no extra behavior, and you're not really creating a new type
of element. It's just extra boxes.
* Turning select listing countries into a map -- composition to the rescue!:
Lilliput
Blefuscu
>From the author's perspective, you don't actually need the select
element. If you intend to show a map on cool browsers and select on
the less cool ones, you are completely uninterested in having your
select semantics dutifully reproduced. All you need is something that
does what you need. Besides, the behavior of a map and a select are so
different than you probably would scrap the former to build the latter
anyway.
> Having some way to mint custom elements as a last resort may very well make
> sense too, but I think the emphasis should be on enhancing existing elements
> as that is less complex (for authors anyway) and more accessible.
Minting new elements only seems crazy and unreasonable if you can't do it.
The thing is, today's Web apps have already retreated into the mostly
imperative world. Despite the angry rumors, the battle for markup has
been lost. Look the source and weep:
http://dev.sencha.com/deploy/touch/docs/, http://www.npr.org/webapp,
and lots, and lots of others.
However, harnessing the HTML parser to construct an object tree gives
us a new round. You don't have to think divs and spans anymore. Once
you can start viewing any functional block of your page as a custom
element, you can return to using markup as composition medium. Hell,
in this case fetching markup lazily becomes more attractive than JSON!
>
> And FWIW, I do not think that has to be seen as "Decorator"
> http://wiki.whatwg.org/wiki/Behavior_Attachment as for the examples I listed
> above I would expect the binding to be permanent. (I would also expect you
> could expose additional DOM members, etc.)
Right. The problem with aspects/decorators is that they are
essentially the October Revolution
(http://en.wikipedia.org/wiki/October_Revolution): we attempt to make
things better by abandoning the old ways (sub-typing, that is) that
quite obviously have flaws, and installing a whole new set of ways
that are ideal and awesome -- and full of problems yet undiscovered,
yearning to waste years of our lives. As one lolcat famously s
Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names
On Wed, 31 Aug 2011 19:29:28 +0200, Dimitri Glazkov wrote: To put it differently, you want to start with a well-known element in markup, and, through the magic of computing, this element _becomes_ your component in the DOM tree. In other words, the markup: Weee!! Becomes: Weee!! This does not work for assistive technology. That is, you would still have to completely implement the element from scratch, including all its semantics such as keyboard accessibility, etc. What we need is not a becomes="" attribute (that renames an element and therefore forgoes its semantics) but rather a way to get complete control over a semantic element and tweak aspects of it. Otherwise creating such controls is prohibitively expensive and only useful if you have vast resources. Examples of elements that should not be replaced but could be changed by a binding: Having a sortable binding for ; Exposing cite="" on ; Turning a listing countries into a map. Having some way to mint custom elements as a last resort may very well make sense too, but I think the emphasis should be on enhancing existing elements as that is less complex (for authors anyway) and more accessible. And FWIW, I do not think that has to be seen as "Decorator" http://wiki.whatwg.org/wiki/Behavior_Attachment as for the examples I listed above I would expect the binding to be permanent. (I would also expect you could expose additional DOM members, etc.) -- Anne van Kesteren http://annevankesteren.nl/
Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names
On Wed, Aug 31, 2011 at 10:29 AM, Dimitri Glazkov wrote: > I will write up the exact algorithm in a wiki shortly. Here it is: http://wiki.whatwg.org/wiki/Component_Model_Progressive_Enhancement :DG<
Custom tags over wire, was Re: HTMLElement.register--giving components tag names
Splitting off to its own thread, because this deserves a good discussion. On Wed, Aug 31, 2011 at 12:00 AM, Anne van Kesteren wrote: > On Wed, 31 Aug 2011 07:33:16 +0200, Dominic Cooney > wrote: >> >> Thanks for reading this far! These proposals aren't formal or >> detailed. I would love to get feedback as I try to nail down some >> specifics. > > The basic problem with this is that you get proprietary markup going over > the wire: > > http://ln.hixie.ch/?start=1064828134&count=1 FWIW, I am in total agreement with this post. If the author requires a UA to have a proprietary parser that has its own, separate means of producing a valid DOM tree, you are so screwed. > > Having said that, I am not sure what the "correct" alternative would be. XBL > (as Ian envisioned it anyway) was meant to enhance non-proprietary markup, > not to let authors create novel constructs. Now you cannot stop authors from > exploring novel constructs of course, but whether we should explicitly > endorse it is another matter. Yes, indeed. We are at the crossroads. The Web needs element behavior attachment (http://wiki.whatwg.org/wiki/Behavior_Attachment) and the ability to define new types elements, yet we are really afraid of following through with that. But... are these fears rational? Let's examine the them in detail. Fear 1: Fallback bogeyman cometh. is no worse than in every mechanical sense. In the absence of definition for "x-accordion" (or Component Model plumbing), both mean the same thing, both can be styled in the same way. One is HTMLUnknownElement, the other is HTMLDivElement, and their API surface is identical. So... no fallback problems. Fear 2: Custom tags are confusing. The clearly identifies the type of the behavior expected from the element, and conveys element behavior attachment nicely. On the other hand, implies decorator behavior attachement, e.g. that removing the class value (and thus turning it back into a vanilla ) is perfectly ok, which by the way, is probably _not_ what the author of the Accordion component expects "in real life". I mean, you can _make_ the author expect that, but that seems like cruel and unusual punishment. In other words -- it's quite the opposite. Custom tags are more _clear_. In fact, they are as close as _saying_what_you_mean_ as it gets. Fear 3: Custom tags have no meaning. Well, friends -- this train had left the station a long time ago. Alex Russell joked once that you already totally can add custom tags in HTML -- as long as you're Hixie. As HTML spec grows new tags, their meaning is only captured in a written document that's meaningless to the UAs that were built a priori. If anything, the Component Model provides an explicit path _learn_ about the need for new elements in the spec. Just grep the Web for "Weee!! Becomes: Weee!! As soon as: 1) the definition of "x-awesome-button" is registered and; 2) the element is in the DOM tree. I will write up the exact algorithm in a wiki shortly. I hope this addressed our worst fears and some. I thereby declare that we should stop being afraid and liberate ourselves from the burden of custom tag anxiety. Long live custom tags! :DG<
