* Redefinition of HTML mime type * Conformance requirements ("musts") that are not testable. Larry points to IETF experience with interoperability reports. - See Noah notes at http://www.w3.org/2001/tag/2009/09/TagHTMLIssues.html#informalMust * Error handling - See Noah list at http://www.w3.org/2001/tag/2009/09/TagHTMLIssues.html#errror (spec does not correctly distinguish processing of success case from error recovery) * Distributed extensibility - Relationship to other specifications is not always clear * Data facilities * Sniffing * Relationship between the DOM and its HTML serializations * Lack of RFC 2119 normative language * Consider with HTML innovations (in style, philosophy, goals, etc.): to what extent should W3C carry some of these to work other than HTML? * Use of algorithms to express normative constraints vs. stating the constraints. Appears to have the risk that otherwise unnecessary characteristics of the algorithm become mandatory. (Larry has commented to the HTML WG on this). HST hypothesis on impact of script and document.write(). * Drag n drop and bibtex and vcard * Presentation of datatypes in prose rather than BNF. * The spec seems to decouple "user agent conformance" and "document conformance". Stipulate that's a good goal. There's a question of whether the spec. actually achieves this. Was it a good goal in the first place? * The outline section has no exhibited behavior in other parts of the spec. It seems to be there to give semantics for computing an outline. (JAR notes that the OWL spec has some things in this spirit.) * (W3C-wide issue) References to "versioned" specs (XML, DOM, etc.) The existing references aren't clear in their meaning; they don't seem to follow the precedent suggested by Michael Sperberg-McQueen (most support at least version X; may support version Y, etc.) * There seems to be an assumption that a working group will remain active for the indefinite future to update the specification as references change, etc. * The TAG should decide whether to (further) involve itself in the choice of terminology for URL/URI. * Ping attribute * "Willful violations" of existing specifications. E.g. Charset override. * Registries: public suffix list, rel values, etc. * document.write() not supported from XML serialization * Scripting execution * Does HTML 5 establish appropriate policies for extensibility? * javascript URI scheme is in the spec needs to be registered * explicit version indicators: doctypes, etc. * Use of Web mechanisms and abstractions for: 1) public Web, I.e. as crawlable by Google; 2) the Web that additionally includes password-protected Web; 3) the private Web as deployed in intranets and controlled environments; 4) use of bits of W3C technology in non-Web contexts, such as HTML or HTML fragments in email, help system, instant messaging, etc. Example: use of as a graphics paradigm, e.g. for email, but use of scripting limits applicability. 5) creation tool change * (mostly editorial) Level of informality is inconsistent. See Noah's notes at http://www.w3.org/2001/tag/2009/09/TagHTMLIssues.html#informality. * Cross-organizational division of responsibility (W3C vs. IETF, HTML 5 vs other WG's, etc.) URI schemes, original header, Content-type sniffing. * Look for positive feedback * Larry has expressed the concern that the HTML draft is, in some cases, intentionally provocative, e.g. the statement that "A DOCTYPE is a mostly useless, but required, header." There is a perception that this is disruptive.