- From: Michael(tm) Smith <mike@w3.org>
- Date: Thu, 20 Nov 2008 17:09:51 +0900
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: "public-html@w3.org" <public-html@w3.org>
Maciej Stachowiak <mjs@apple.com>, 2008-11-19 17:45 -0800: > 2) Mike's document is explicitly only for producers. But a conformance > checker is a content consumer. Currently the main HTML5 spec includes > conformance requirements for conformance checkers. It can't do this without > defining what is a document conformance error and which are mandatory for a > conformance checker to diagnose. It's conceivable that it (or another spec) could in fact define requirements for conformance checkers while normatively referencing another spec that normatively defines what a conformant document is (and so what a document conformance error is). > 3) Mike's document seems to have the implied premise that content producers, > unlike consumers, won't be interested in the scripting interfaces. It's certainly not meant to imply that. The only reason it currently doesn't explicitly discuss scripting interfaces is because it seems like they are completely orthogonal to what the definition of what a conformant document instance is -- and because it's not clear that it's necessary for content producers to know anything about them at all in the case where their only needs is to be able to check whether a particular document matches the definition of what a conformant document is, or to know what the rules are for putting a document together in such a way that it matches the definition of what a conformant document is. It also does not seem necessary for an implementor of an HTML5 conformance-checking tool to know anything about the associated scripting interfaces, nor to have their applications do any kind of conformance checking related to scripting interfaces. > But a > large proportion of Web content, especially content on the most popular > sites, includes some script, and correctness of that content depends on > scripting behavior. Some elements, such as <canvas>, <event-source>, or to a > lesser extend <video>, don't even make sense without their scripting > interfaces. It's clear that <canvas> isn't actually useful to anybody in practice without some associated scripting. But among the needs that someone writing a canvas application has is simply to know things like what attributes <canvas> can and cannot have, and to know, say, that the "hieght" attribute they tried to use on canvas is not conformant, and the conformant way to write it is "height". > So it seems to me it is not even very useful as an authoring > guide. To be clear, it's not meant to be useful on its own as an authoring guide. In the context we're discussing now, it's meant just to be a definition of what the document-conformance rules are, not a guide to how to best follow the rules. At the risk of making a simple-minded analogy, I guess I could compare it to the difference between the set of rules that are printed on the inside cover of a board game, and third-party strategy guide that tells you how to win the game. The draft just attempts to be the most succinct possible definition of what a conformant document is, along with defining the semantics of each of the elements and attributes. --Mike -- Michael(tm) Smith http://people.w3.org/mike/
Received on Thursday, 20 November 2008 08:10:27 UTC