- From: Adrian Roselli <Roselli@algonquinstudios.com>
- Date: Thu, 20 Sep 2012 19:14:07 +0000
- To: Sam Ruby <rubys@intertwingly.net>
- CC: "public-html@w3.org" <public-html@w3.org>
> From: Sam Ruby [mailto:rubys@intertwingly.net] [...] > >>> After some time doing other things (ok, deciding on lunch) another > >>> idea > >> occurred to me... > >>> > >>> This Plan 2014 document is just a proposal and it's up for > >>> discussion now > >> with an indeterminate agreement date. > >>> > >>> Can we just move ahead on the issue 30 survey? If that was the last > >>> step to resolving it, it might close (one way or the other) one of > >>> the 10 remaining open items for moving HTML5 along-- the only item > >>> that has a date on it and which has also passed. > >> > >> The Chairs expect that a decision in favor of any ISSUE-30 Change > >> Proposal is likely to lead to a Formal Objection. We believe the > >> approach outlined in the plan may be able to avoid a Formal > >> Objection. This will save time on net, if we can get everyone's > >> buy-in. We also think treating the remaining issues equally is > >> important to getting people to agree with this approach for their own > >> pet issues, which is why we did not suggest singling any out for different > treatment. > > > > I'm not buying into that for three reasons: > > > > 1. This proposed process is just a discussion, it may not pan out or it may go > > differently, but all other activity appears to be coming to a halt. I don't see > > any reason why anything should come to a halt when there is no deliverable > > date for this new process. If the current process is fundamentally and > > demonstrably broken then I'd reconsider (which then calls into question all > > other related processes). > > I encourage you to scan the A11y TF list: > > http://lists.w3.org/Archives/Public/public-html-a11y/2012Sep/ > > The key point is that there is continuing active discussion, and it is the > consensus of the HTML WG Chairs and the PFWG Chairs that this discussion > should be allowed to proceed. This was discussed on both the A11y and > HTML WG calls today. I encourage you to check the minutes. > > http://www.w3.org/2012/09/20-html-a11y-minutes.html > http://www.w3.org/2012/09/20-html-wg-minutes.html I'm not talking about the a11y TF. Though I appreciate activity is happening there (I also sent my request to join it). The HTML WG has essentially said issue 30 is not getting any more action here because there *may* be a new process at some later date that has not yet been set. The HTML WG and its chairs should not stop moving forward on any of these issues, especially when it comes to honoring existing commitments. I don't consider your feedback as a response to my first point. > > 2. Not acting because there *may* be a Formal Objection isn't a reason. > Granted, I don't know the players, who might object or how complex that > process is. If I tell a client I'm not going to follow the agreed scope of work > (the existing committed process and deadline, in this analogy) because he or > she may object, I'd expect to be fired. I'd continue to move ahead and follow > the expectations that have already been set. A Formal Objection will be dealt > with, but at least there will be *movement*. > > There is no "may" about it. We have people making such statements without > having even seen a decision. We have every reason to believe that they will > follow through. And that resolving such FOs will delay our entry to CR. Now you have me in a process knowledge-gap. Will a Formal Objection to an attribute that isn't even in the spec really delay an end of 2014 CR date? Is the process that complex? Is it likely that there may be other Formal Objections to other aspects of the spec? Should we toss those aspects aside if someone threatens a Formal Objection? Yes, those are rhetorical, but it seems to me this approach enables anyone who wants to threaten a Formal Objection as a way to strong-arm an action (or lack of action). To me, that isn't a reason to stop moving ahead on this or other issues that are already in play. > > 3. The remaining issues are equally important. I also happen to see a > > deadline on this CP [1] when none of the others have one, which implies to > > me that it *should* be treated differently (it already is different). So don't > > single it out, just follow through on the commitment already made to it. > > *Not* following through (and allowing the missed deadline to continue to > > get older) means that this issue is, in fact, being singled out for different > > treatment (to use your words). > > We had a deadline that was moved at the request of the Interaction Domain > lead. It was then moved again while we worked through the issue with the > Director and CEO. The plan you now see is the outcome of that process. > Once we get consensus on the plan forward (and has been noted there is at > least one clear bug and undoubtedly are others), that entire page will need > to be updated. I refer you to point #1 of mine. You've circled back there and I've already addressed it. Is this acknowledgment that issue 30 has, in fact, been singled out as Maciej said she didn't want to do, or is this denial of that? My third point still seems unanswered. > But instead of looking backwards, I would encourage us to look forward. I am not looking backward (I really can't, I'm too new to know what the history is). In fact, I am trying to move this forward instead of allowing issue 30 to languish while this new process is discussed. For the rest of your note (below) you have switched from a discussion of why issue 30 isn't moving along as previously indicated to a discussion of the technical merits of longdesc. That's outside of the scope of my points and it feels like you are shifting gears to end this discussion. My points still haven't been addressed (ok, not to my satisfaction). I'll leave the below to someone who wants to discuss this and has more history in what's going on with longdesc. Failing that, I'd suggest a separate email thread so these conversations can happen in parallel without muddying each other. > In fact, there is also a point that I would like clarification on. I would like to > know if longdesc is only ever intended to be used in controlled educational > environments with significant copyright restrictions and for that usage > universal adoption by mainstream browsers is not a requirement? > > Or is there a universal need for "long textual descriptions" that is not > currently being met? If so, what changes are required in order to get > browser vendors to sign on? > > Key to this is the following data: > > http://lists.w3.org/Archives/Public/public-html-a11y/2012Sep/0295.html > > Possible answers include that usage on "top 10,000 web sites home pages" > is not a market that longdesc intends to serve, in which case that data is > irrelevant except to point out that the messaging on longdesc needs to be > updated to make it clear what the target market of this attribute indeed is. > > Another possible answer is that this is indeed a market that long descriptions > (by whatever the attribute is named) is a requirement for. > In which case, we need to take this data very seriously first the TF and > ultimately the HTML WG as a whole will need to determine what corrective > course corrections is needed. > > And I will note that these answers are not necessarily mutually exclusive. > Perhaps we need two separate attributes. > > I will note that it is not my intent to advocate any of these positions. > > - Sam Ruby > > > 1. http://dev.w3.org/html5/status/issue-status.html >
Received on Thursday, 20 September 2012 19:14:35 UTC