<Hixie> well then aria won’t make LC
<Hixie> we can always do it after LC
I must say, that’s just goofy. “Here’s a document, it is not functionally complete, but it is your last chance to provide input”.
Equally as busted: I’m told that the the PF WG has answers to the questions that are blocking Ian’s progress, but won’t share them.
And just to complete the insanity, I can get the relevant members of the PF WG to attend tomorrow’s call, but not Ian.
I’ve been told “has answers to” by multiple people. I’ve even seen and discussed what I think are constructive responses to Ian’s questions, but I’ve not been given permission to share them. What you think is dramatic, I think is rather understated.
We have people who, on principle, won’t share anything until they have a response to everything. And then we have people who, on principle, won’t discuss things in realtime on a phone.
From my perspective, the result is inevitable. Within 30 minutes after Ian gets to see the answers, I’ll bet that there will be a response along the lines of “that won’t work for the following reason”. I don’t know what that reason will be, but I am willing to bet that it will be a damn good one.
And then we get to start this cycle over again. And everybody ends up being losers in the process.
That’s precisely the reason PF is being so deliberative in addressing his issues. If there needs to be some discussion after that, then let’s hash it out in XTech where it belongs.
In fact, the worst-case scenario is that we produce incomplete responses that Ian dismisses out of hand. Then we’re back to a cycle.
It is possible to take a slippery slope argument and prove pretty much anything you wish to prove. The solution is not to avoid cycles, as that is impossible, but to reduce the cycle time instead. Even if that means that the initial answers aren’t perfect.
I’ve got Richard Schwerdtfeger willing to talk in realtime on tomorrows call. I don’t yet have Ian’s agreement to participate, but if he can’t or won’t attend, perhaps Henri or Maciej can ferry the answers back to Ian.
then let’s hash it out in XTech where it belongs.
There now is a proposal to create a joint task force. These silly turf wars must end.
For those who didn’t attend the conference (which once again was at capacity) but for some strange reason are interested in following the drama...
Richard Schwerdtfeger explained the direction the PF WG was heading, which I will summarize as they examined all of the aria attributes came to the conclusion that the host language (in this case HTML) semantics should take precedence in all cases save one: namely the role attribute, as there are cases where the role attribute is needed to refine the semantics provided by the host language.
Maciej Stachowiak was present, and it didn’t take 30 minutes for him to identify why that solution wasn’t sufficient. Coming at it from the HTML side, if you look at the various elements, there are some whose semantics are fixed, some whose semantics are loose, and some whose semantics completely mutable.
<h1>
is an example of an element that is fixed. It can’t be a checkbox no matter what a person puts on the role attribute. Doing so should be treated as a conformance error.<li>
is an example of an element that provides a default semantic (namely as a listitem
) but refining it to be a menuitem
is something that should definitely be possible. That being said, we need to work through whether such elements can ever reasonably be, for example, a checkbox.<div>
is an example of an element that provides virtually nothing in the way of semantics, and therefore has a wider range of freedom as to what roles it can play.This leads to two actions. In the short term (as in days), the ARIA spec needs to enable host languages to make these distinctions. In the longer term (as in weeks) somebody needs to work out a matrix of potential combinations; for examples rows can be html elements and columns can be aria roles, and for each determine if the combination makes sense. Some HTML elements, like <input>
may require multiple “rows” as what is possibly may vary based on the value of the type
attribute.
This work could be done jointly, or Ian could take a stab at it and the results reviewed.
Maciej: that’s a start!
My experience is that this working group has a lot of communication problems. Cynthia nailed it.
The group prides itself on being open. It tells everybody to post to the list so that everybody can participate. Nothing can be more open, right?
Wrong. Each and every day, I see instances of somebody who has the bandwidth to keep up with the list to send subtle but very clear messages to those that wish to participate that “your kind are not welcome here”. One such happened today, and I hope you know what I am talking about (no, I won’t link to it here, that would only make it worse).
The real story behind what caused today’s meeting to happen is that I had been trying to get the right people to participate on the list, and they saw the 700+ email threads on summary and told me flat out that I was out of my <bleeping> mind.
I will say that I run a tight meeting. We completed on time and got to everything on the agenda. As we did last week. And I will say that I am working on something that should make next week’s meeting worthwhile. To be fair, I didn’t invent the opportunity (just as I didn’t invent today’s), but I will say that I am very opportunistic. As we move to Last Call, these meetings will become more vital.