- From: Larry Masinter <LMM@acm.org>
- Date: Tue, 30 Mar 2010 15:59:25 -0700
- To: "'HTML WG'" <public-html@w3.org>
This is a little terse, so please don't take too much out of context, but I've been thinking about how to deal with some of the authoring/document conformance issues: What I'd suggest is a clearer separation of conformance classes, which seem to me to be mixed in this spec (and, for what it is worth, in other web specs too.) (a) document conformance: defining what is or isn't a "valid" document, with some features added, some features changed, some "deprecated", and some "removed" compared to HTML4. (b) authoring conformance: defining expected, preferable, best practices for authoring tools or author behavior (c) validator conformance: defining expected, preferable, best practices for tools that might be used for evaluating (a) as well as being clearer about the distinction between: (d) document processor conformance: defining expected, preferable, best practices for any component that reads, scans, interpreters documents (e) user agent conformance: defining expected, preferable, best practices for document processors that are interacting with a user (f) browser conformance: defining expected, perferable, best practices for user agents whose primary purpose is to browse the (primarily HTTP-based) web. Some opinions (to be turned into more concrete edits or bug reports, if anyone agrees with these): (a) I would argue against making any previously valid content invalid unless (1) it was never implemented as specified (2) there is demonstrable harm to others that making the feature invalid will repair. For "interoperability", documents (a) need to be accepted by all document processors (d). Conforming documents should be conservative (robustness principle) even though document processors are liberal. I would argue that presentational markup don't meet these criteria. (b) I think there should be few conformance requirements on authoring tools, with exceptions made when justified for general good of issues around security, privacy, internationalization, accessibility. There are such a wide variety of authoring and creation tools and content management system generation of HTML that "authoring" requirements that are generally applicable will be rare. (c) I think way too much empahsis has been put on validators. There are many kinds of validation and tools and checkers that implement not only determining "valid" content as far as this specification, but also deal with legacy systems, text-only systems, screen readers, etc. and each delivery context probably requires a different validator. I'm not sure there should be any conformance requirements on validators per se -- they should most likely be requirements on (a). (d) I think far too many of the requirements currently actually only apply to (f) but the spec is written as if they apply to (d). I think way too many things that should be "best practices" and at best a MAY are instead couched as mandatory for (d). Larry -- http://larry.masinter.net
Received on Tuesday, 30 March 2010 23:00:03 UTC