- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Tue, 4 Aug 2009 18:04:00 -0700
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: HTML WG <public-html@w3.org>
On Aug 4, 2009, at 3:45 PM, Maciej Stachowiak wrote: > On Aug 4, 2009, at 3:29 PM, Roy T. Fielding wrote: >> But the same people said that they would be satisfied by a reasoned >> argument that shows it is useful and distinct from other HTML5 >> mark-up. > > Can you cite a reference for someone saying that? Yes, but I won't waste my time with denial-of-service questions. > I think the case against summary is not that it fails to have any > use whatsoever, but rather that there is some evidence that, on > balance, as practiced, it does not promote good accessibility > outcomes. Same with canvas, video, and script. The evidence supplied was selected to support a particular opinion and does nothing other than demonstrate that some unskilled authors will misuse any given element or attribute. Moreover, the folks who are actual experts on accessibility disagree with both the "evidence" and the assumed outcomes, so all you are doing is restating a poorly motivated opinion that is held by a very small minority of HTML implementors. We all have opinions. The @summary attribute has a purpose which is not satisfied by any of the alternatives. Case closed. >> So either there is no need for a compromise or those people intend to >> stand by their personal opinion in spite of both the reasoned >> argument >> and the actual needs of others. In either case, the appropriate >> action >> by the editor is to make no change to the existing HTML language, >> since WG consensus only necessary to make a change to the previously >> agreed definition of the language in HTML4. > > WG consensus (or valid decision process if consensus can't be > found) is needed for any decision. There is no "default to old spec > version" exception in the W3C Process. I said "the appropriate action by the editor", not what is written into W3C process. There are a lot of things in W3C process that are just assumed because they are inherent in the definition of "editor". If Ian wants to claim that he can change anything in HTML for which no WG consensus has been obtained, then I'd like to see him do so in writing to this list. >>>> The opinion that summary is not usefully distinct from all other >>>> forms of caption mark-up has been proven wrong. Do you disagree? >>>> If so, then refute my argument. If not, then there is no need to >>>> find a compromise of opinions and Ian should fix the offending text >>>> before it is published as a WD. >>> >>> I think your example is a plausible use case, and I have no wish >>> to argue against it. My proposal doesn't take the position that >>> summary is never useful. It takes the position that authors >>> should be advised to consider alternatives to what we have >>> learned is an error-prone construct. I don't think your use case >>> refutes that position. >> >> My use case refuted that position because it demonstrates that >> there are no alternatives. > > I don't believe you have demonstrated that. Even in your example, a > <caption> that's hidden from visual but not UAs via CSS would > satisfy the use case. No, because the use case requires that the solution be backwards compatible with deployed browsers that do not support CSS and deployed authoring tools that already support @summary for the defined purpose. > Further, even if you demonstrated that there are no alternatives in > one particular use case, this would not demonstrate there are no > alternatives for any use case, nor would it refute the case that > the construct is error-prone. Why would I need to demonstrate that there are no alternatives for any use case? What kind of logic is that? And I certainly don't need to refute that the construct is error-prone, since proneness to error is only a rational design concern when there is more than one alternative satisfying solution. In any case, none of the solutions offered by Ian were less error-prone aside from the fact that they would be displayed to visual users and thus subject to more "eyes" on the bugs. > That being said, maybe a lot of the people who find summary > problematic will see your example and reverse their position. > Personally, I'm not holding my breath. I am not holding my breath, either. I will take note of their hypocrisy, however. >> It would therefore be an ERROR for a >> validator to warn that the author should seek out alternatives >> when those alternatives clearly do not exist. > > Is it an error to advise authors to use CSS layout instead of > layout tables, even though CSS can't necessarily replicate every > layout that is possible with tables? I don't follow what you mean here. A table that has no substantive content could certainly be replaced by CSS, but CSS is not a substitute for table in general. I think such warnings have nothing to do with validation (style tools like lint do not belong in standards). >> If the WG insists on placing a warning on the use of @summary, then >> I will insist on placing a warning for any use of javascript, >> canvas, and whatever-replaces object/embed. Those features offer >> far more potential for error-prone constructs that might be more >> accessibly implemented using other HTML elements. I don't think >> that's why we have validators, but if we are going to be pedantic >> about opinions regarding language features then at least >> we should be consistent. > > You're welcome to make such proposals separately. I'm not sure all > of those specific examples would get consensus. (I do think > <canvas> with no fallback should be a warning or error.) Why do my proposals require consensus but Ian's proposals do not? ....Roy
Received on Wednesday, 5 August 2009 01:04:36 UTC