- From: Chockalingam <chockam@gmail.com>
- Date: Sat, 2 Aug 2014 20:03:53 +0530
- To: Sam Ruby <rubys@intertwingly.net>
- Cc: "public-html-admin@w3.org" <public-html-admin@w3.org>, Edward O'Connor <eoconnor@apple.com>
No Objection for the below. Regards Chockalingam Sent from my iPhone > On Aug 2, 2014, at 7:56 PM, Sam Ruby <rubys@intertwingly.net> wrote: > >> On 07/26/2014 01:19 AM, Paul Cotton wrote: >> In accordance with both the W3C process's requirement to record the group's decision to request advancement [1] and with the steps identified in the "Plan 2014" CfC [2], this is a Call for Consensus (CfC) to request transition to Candidate Recommendation for the following Image Description extension specification: >> >> https://dvcs.w3.org/hg/html-proposals/raw-file/217e6b995ac9/longdesc1/longdesc.html >> >> The A11Y TF has approved the transition of this document to CR status and requested both the HTML WG and the PF WG to approve the transition. See: >> >> http://lists.w3.org/Archives/Public/public-html-admin/2014Jul/0046.html >> >> Silence will be taken to mean there is no objection, but positive responses are encouraged. If there are no objections by Fri Aug 1, this resolution will carry. > > This CfC got a number of indications of support, an abstention, and a single objection. > > --- > > First some history. > > Original decision was to NOT include longdesc: > > http://lists.w3.org/Archives/Public/public-html/2010Aug/att-0112/issue-30-decision.html > > Key excerpt from that decision: > > "The strongest argument against inclusion was the lack of use cases that clearly and directly support this specific feature of the language" > > Later, this issue was reopened based on new evidence: > > http://lists.w3.org/Archives/Public/public-html/2011Mar/0037.html > > Key excerpt: > > "we feel that the New Formal Use Cases Requiring Longdesc [4] do in fact merit consideration by the wider work group." > > Those use cases themselves can be found here: > > http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc#User_and_Authoring_Requirements > > --- > > The current WG objection: > > http://lists.w3.org/Archives/Public/public-html-admin/2014Aug/0005.html > > Which refers to the following TF objection: > > http://lists.w3.org/Archives/Public/public-html-a11y/2014Jun/0115.html > > Here is the TF's response: > > http://lists.w3.org/Archives/Public/public-html-a11y/2014Jul/0048.html > > Key excerpt from that decision: > > "It also received one objection [4] which contained no new information and which was, therefore, not accepted on that basis [5]." > > --- > > The current state of longdesc: > > We have use cases. We have an exit criteria. We have multiple implementations that are in the process of being evaluated against that exit criteria. And we have a claim that longdesc is 'bolt-on', and therefore is an inferior approach. > > And we note that the objection that doesn't address the TF's response to this same objection that was raised previously. > > Meanwhile, let's agree for the sake of discussion to stipulate that longdesc is 'bolt-on' and that isn't optimal. And even to provisionally accept the negative consequences of this: namely that content pointed to by longdesc is less likely to be actively kept in sync with those documents that are volatile. > > Even if these items are conceded, it is still the case that we have user requirements and implementations. At at one time, Apple seemed to agree that Users trump Implementations trump Theoretical Purity.[1] > > So, consistent with the two prior decisions, this again comes down to use cases. On one hand, we have a set of documented use cases and a specified attribute that meets those use cases. On the other hand, we have a web page[2] that lists a set of purported replacements for longdesc. > > Of those, a standard link inside a figure caption does not address the stated use cases (example: No forced visual encumbrance), nor is there a rationale provided for challenging these use cases. > > Of the remainder, only a hidden iframe technique is general purpose. No mapping of this technique to the identified use cases has been made. In particular, how the user would chose to consume this information is not addressed, nor is that requirement challenged. > > Nor is there any explanation provided which would explain why a hidden iframe would not suffer from the same problem of providing content that would not naturally be kept in sync with the remainder of the page. > > --- > > Conclusion: given that the objection does not specifically address or challenge the use cases, the HTML WG chairs support the TF decision. If Ted or anybody else wants the chairs to revisit this, they will need to specifically address the provided User and Authoring Requirements as well Use Cases provided. > > Alternatively, if Ted or anybody else wishes to raise a Formal Objection with or without addressing the requirements and use cases, they are welcome to do so at this time. Be aware that the meeting with the Director on this subject is likely to occur early this week, most likely on Tuesday afternoon. > > --- > > [1] http://www.w3.org/TR/html-design-principles/#priority-of-constituencies > > [2] http://cookiecrook.com/longdesc/ > > - Sam Ruby, > on behalf of the W3C HTML WG co-chairs >
Received on Saturday, 2 August 2014 14:34:26 UTC