- From: Charles Pritchard <chuck@jumis.com>
- Date: Fri, 10 Feb 2012 11:25:02 -0800
- To: Maciej Stachowiak <mjs@apple.com>
- CC: Laura Carlson <laura.lee.carlson@gmail.com>, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, public-html@w3.org
On 2/10/2012 10:48 AM, Maciej Stachowiak wrote: > On Feb 10, 2012, at 9:43 AM, Laura Carlson wrote: > >> Hi Leif, >> >>> Well, OK, to the Chairs, then unique use cases for >>> @longdesc seems to be crucial. >> I reject the notion that providing unique use cases that *only* >> longdesc can fulfill is to be the deciding factor for including >> longdesc in the language. >> >> If I misunderstood the original decision and this is the intent and >> will be the determining factor, perhaps a Formal Objection should have >> been made after the first decision on that basis instead of the >> reopen. > That was indeed the original basis for the decision. While I do not want to prejudge the reopened issue before it goes to survey, I expect there are at least two paths to making a strong case for longdesc: > > (1) Show that some valid use cases can *only* be fulfilled by longdesc. > (2) Show that for some valid use cases, longdesc has significant benefits over other possible solutions, even if it is not the only solution; these claimed benefits would then be weighed against the claimed harmful effects of longdesc. Why was the large list of valid use cases included in the Change Proposal insufficient? Not only did the longdesc CP include dozens of use cases, active uses, and other blocks of information, the other two proposals were analyzed and found to be distinct and different from the longdesc semantic. We are dealing with arbitrary language here. I can claim that my new feature "<ItsAllAboutMe arbitrary-attribute=http://url.com>" can fulfill the longdesc use case. I can just take longdesc and rename it, and fulfill the longdesc use case. I can say that, well gosh, if we just change the way the anchor tag is processed in CSS, and add new css directives, then gosh, longdesc isn't needed. Here: '<a rel="longdesc" href="page.html" style="css-ignore-this-tag-in-all-css-selectors: true">'. I've fixed it! Here: '<img rel="page.html" />'. I fixed it again! Here: '<img aria-label="My really long description with <em>embedded html</em>">'. Yet another fix! Here: '<img aria-describedby="iframe" /><iframe defer id="iframe" src="page.html" />'. I am amazing at this! Maciej, what you're saying is valid, but it was valid prior to the long list of documented reasons for keeping londesc. Now it seems to ignore the content presently available in the wiki, and the discussion presented on this list. The reason my four examples don't work has been covered repeatedly on this list. If we allow for re-invention, we're going to keep going in circles. It's been established that longdesc's current functionality is not met by any other existing semantics. There are some close ones, certainly. Because that's been established, the conversation has turned toward improving existing semantics so that longdesc can be deprecated. That's circular reasoning. It's maddening Maciej, and I am afraid this kind of crazy-making leads to hostility and grief in what should be an otherwise clean and cooperative process. -Charles
Received on Friday, 10 February 2012 19:25:29 UTC