Re: Custom Elements: insert/remove callbacks
On 5/9/15 12:40 PM, Anne van Kesteren wrote: So that seems clearly wrong (in the specification)... Are descendants notified in tree order? In Gecko, yes. Note that running script during these insert/remove notifications is not OK, so anything that needs to run script has to do it "later" (for various definitions of later). -Boris
Re: Custom Elements: is=""
On Thu, May 7, 2015 at 1:00 AM, Anne van Kesteren wrote: > On Wed, May 6, 2015 at 6:59 PM, Alice Boxhall wrote: > > I definitely acknowledge is= may not be the ideal solution to the latter > > problem - it definitely has some holes in it, especially when you start > > adding author shadow roots to things - but I think it does have > potential. > > I'd really like to be convinced that we either have a reasonable > alternative > > solution, or that it's not worth worrying about. > > I think it is worth worrying about, but I don't think it's worth > holding up a minimal v1 of Custom Elements for. The way to get > agreement among all parties is to do less. And then take baby steps > from. > I can definitely see that logic. My concerns with this in practice are: - In the time between v1 and v2 (however long that ends up being) we are left without any way to solve this problem, assuming we don't come up with something else for v1. If developers start using custom elements where they would previously have used a native element, this could well result in a regression in accessibility for the web as a whole for this period, and we will be stuck with the legacy of code written during this period for much longer as well. - I realise that to some extent developers already aren't using native elements, in part because of the styling issues we've discussed which also affect is=. My concern here is that custom elements will further legitimise this habit, which we've been making some recent progress in changing - we stand to backslide on that effort. Having is= would allow us to roll it into the "use native elements where possible" message rather than diluting it with "unless you're using a custom element in which case here's a checklist which you're not going to look at of everything it should do" until we come up with an alternative. - v1 sets the stage for people to develop habits and expectations about how custom elements work. New features tend to be slowly adopted, by both browser vendors and (partly as a consequence) developers, so even if we do come up with something for v2, it will be even longer before it becomes mainstream (and as I mentioned earlier we will still be stuck with code written to v1 for much longer again). > The way I look at this is that currently you have nothing, since only > Chrome ships this. There's a chance to get three more browsers if you > make some concessions on the warts. And then hopefully we can iterate > from there in a more cooperative fashion. > Here's where we differ, because: - I don't think it's a wart. I've given this a great deal of thought and I keep ending up back at the current syntax when I try to think of reasonable alternatives, even assuming we could magically fix all the implementation issues with any alternative proposal. - I don't think shipping in one browser is "nothing". People (both framework authors and web page authors) are already writing code using is=. > (The thread Steve shared about ARIA seemed like an equivalent effort > by the way, to expose some of the semantics of native elements through > simple attributes.) > Thanks for the pointer - I followed up on that thread with some thoughts on that proposal.
Re: Making ARIA and native HTML play better together
I agree we badly need the primitives, but it seems to me like there is
potentially an easier and maybe even bigger win in making it more
straightforward for developers to reuse existing patterns (like the one you
described for "button" earlier) than in explaining the existing patterns
and allowing developers to create new ones.
As Patrick pointed out, we can approximately explain these things today -
not perfectly, as you demonstrate, but we can achieve much the same
functionality with effort - but we've seen time and time again that
developers aren't going to that effort. If it were more straightforward to
do so, we would probably see some increase in compliance, but it would
still require understanding the existing patterns and knowing that the
effort needs to be made.
However, I'm on the fence about whether this proposal is the way forward
for that problem. On the one hand, many developers (including me) have an
expectation when they first encounter ARIA that it will magically affect
behaviour, so it seems like a good "path of desire" to go ahead and fulfill
that expectation.
On the other hand, as Dominic (with an i) pointed out, this has the
potential to break existing sites. We would need to experiment carefully to
figure out the interactions between existing code and the new behaviour.
Additionally, as it stands today ARIA is a useful tool for explaining the
the semantics side of HTML - we would need to solve a couple of problems
(semantics missing from ARIA and currently only available to native
elements, which should be straightforward to fix, and the issue of
"sprouting" ARIA described below), but overall it's a good starting point.
If we were to modify ARIA to be more than just purely semantic, we would
need to come up with a new mechanism to explain the semantic piece when
developing new patterns.
On Fri, May 8, 2015 at 5:53 AM, Domenic Denicola wrote:
> From: Patrick H. Lauke
>
> > Isn't that, in a way, what we currently have already?
>
> No, not quite.
>
> > - default focusable: add tabindex=0
>
> This isn't default-focusable; this is just focusable. Default focusable
> means that, in the absence of a tabindex attribute, it is focusable---like
> and , and unlike or .
>
> > - activatable with certain key commands: define key command handlers
> yourself in JS
>
> This has a few issues. Notably, it doesn't accomodate different platform
> conventions for activation, and it doesn't correctly hook up default
> actions: if you do myAnchor.addEventListener("click", function (e) {
> e.preventDefault(); }), navigation will not occur, whereas if you hook up
> key command handlers to , myCustomAnchor.addEventListener(...)
> will not have the same effect.
>
> > - announced by AT as a button: role="button"
>
> The problem here is similar to that with tabindex. The attributes
> (tabindex, role, aria-description, etc.) are meant to allow web app authors
> to override the default values that a given component might have. A
> component author, on the other hand, should be able to set the default way
> in which their component is announced to screenreaders, even when there is
> no role attribute present. In other words, should be announced
> as a button; we shouldn't require .
>
We should clarify that adding a role/state/value attributes in lifecycle
callbacks approximates the original intention - yes, it sprouts some ugly
attributes, but it doesn't require the web page author to type .
One potential solution to the "sprouting attributes" problem which has been
discussed elsewhere is to use some variant of the Cascading Attribute
Sheets idea (http://www.xanthir.com/blog/b4K_0) - although that proposal
seems to just apply attributes directly on to the element; I'd prefer to
see it more like CSS where instead of sprouting "style" attributes
everywhere, matched rules affect only the *computed style* of the element,
which is overridden by explicit attributes.
Re: Custom Elements: insert/remove callbacks
On May 9, 2015 9:41 AM, "Anne van Kesteren" wrote: > > On Fri, May 8, 2015 at 2:50 PM, Boris Zbarsky wrote: > > On 5/8/15 1:42 AM, Elliott Sprehn wrote: > >> That actually seems pretty similar to what we have, ours is in the form > >> of: > >> > >> Node#insertedInto(Node insertionPoint) > >> Node#removedFrom(Node insertionPoint) > > > > To be clear, ours is also in the form of two methods > > (BindToTree/UnbindFromTree) that take various arguments. > > The DOM only has insert/remove hooks: > > https://dom.spec.whatwg.org/#concept-node-insert-ext > https://dom.spec.whatwg.org/#concept-node-remove-ext > > So that seems clearly wrong (in the specification)... Are descendants > notified in tree order? Yes, and anything that can run script is notified in a second pass. So for example if you create a script, put it in a subtree, then append the subtree, the script runs after all insertedInto notifications have been sent to the subtree. - E
Re: Custom Elements: insert/remove callbacks
On Fri, May 8, 2015 at 2:50 PM, Boris Zbarsky wrote: > On 5/8/15 1:42 AM, Elliott Sprehn wrote: >> That actually seems pretty similar to what we have, ours is in the form >> of: >> >> Node#insertedInto(Node insertionPoint) >> Node#removedFrom(Node insertionPoint) > > To be clear, ours is also in the form of two methods > (BindToTree/UnbindFromTree) that take various arguments. The DOM only has insert/remove hooks: https://dom.spec.whatwg.org/#concept-node-insert-ext https://dom.spec.whatwg.org/#concept-node-remove-ext So that seems clearly wrong (in the specification)... Are descendants notified in tree order? I filed https://github.com/whatwg/dom/issues/34 to track this. -- https://annevankesteren.nl/
