- From: James Graham <jg307@cam.ac.uk>
- Date: Mon, 12 May 2008 23:51:46 +0100
- To: Dan Connolly <connolly@w3.org>
- CC: Dave Singer <singer@apple.com>, "public-html@w3.org" <public-html@w3.org>, W3C WAI-XTECH <wai-xtech@w3.org>, wai-liaison@w3.org, Chris Wilson <Chris.Wilson@microsoft.com>, "Michael(tm) Smith" <mike@w3.org>
Dan Connolly wrote: > On the other hand, I don't think that the most useful definition > of conformance for HTML 5 documents is limited to accessible documents. > > As I said a while back, I do think the most useful definition > of conformance is objective... > > keep conformance objective (detailed review of section 1. > Introduction) > http://lists.w3.org/Archives/Public/public-html/2007Aug/1187.html > > I'm still getting my head around the notion of conformance > in the current HTML 5 draft. Making conformance depend > on whether markup is used per semantics of <h1> and such > seems like making grammatical correctness of English > sentences depend on whether they're true or not. I suppose > there's some value in it, but it's so different from what > I'm used that I have trouble making sense of the discussion. I don't think making a big deal of the distinction between machine checkable and non-machine checkable conformance requirements is very useful in the context of HTML. Since HTML parsers are error-recovering and HTML 5 specifies that error recovery, there is no such thing as input that will not lead to some defined behavior in UAs. This means that conformance is not needed to ensure that the document functions much less that it functions as expected. Given this, two reasons for setting conformance requirements in HTML come to mind: a) QA assistance for authors. By making only a subset of all possible ways of achieving a particular DOM legal, and even by making certain DOMs illegal, we can help authors to identify likely errors in their documents that will lead to unexpected behavior. b) Exerting social pressure on authors to construct their documents in a way that is beneficial to consumers, even if it is not of immediate benefit to the authors themselves. Neither a nor b is helped exclusively by requiring that all conformance requirements be machine checkable. For the QA case (a), non-machine checkable requirements are still likely to make it into textbooks and tutorials, so authors are more likely to be aware of the requirement and are therefore more likely to avoid the issue in the first place. If they hit the issue, they are more likely to find a solution quickly. However case (b) — social pressure — is the really interesting case. By phrasing certain things as conformance requirements, there is presumably an increase in the number of people who will conform with that requirement compared with the case where there is no conformance requirement but some sort of implicit suggestion. This can be good for all sorts of reasons. For example if there are a large class of users who are known to suffer in some situation — when tables are used for layout, for example — then making it a conformance requirement to not do that can be helpful to those users. Promoting certain behavior also helps certain classes of UA. For example making it conformance requirement that only headings appear in heading elements and all headings appear in heading elements increases the probability that a UA with a navigate-by-headers function will work acceptably well on the web. By their nature this type of scenario tends to lead to non-machine-checkable conformance requirements. But trying to remove such requirements just because they are not machine checkable not only means that we have to give up the benefits they bring but also adds temptation to proxy fundamentally non-machine-checkable requirements with beguilingly similar-looking machine checkable requirements. Doing so is likely to be bad as people optimize for the proxy rather than the underlying requirement; a phenomenon that can be observed in many fields e.g. education where teachers (and pupils) often optimize for passing exams rather than for learning. (as an aside, my understanding is that modern linguistics is generally not able to machine check for grammatical correctness but instead uses value judgments provided by a human being to assess whether sentences are grammatical or not. If a sentence is deemed grammatical by a human but cannot be derived from the supposed formal grammar of the language that merely indicates that the formal grammar is incomplete.) -- "Mixed up signals Bullet train People snuffed out in the brutal rain" --Conner Oberst
Received on Monday, 12 May 2008 22:52:36 UTC