- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Mon, 20 Mar 2006 12:59:33 +0200
Based on the 2006-02-24 version. 1.14.1. The style and script elements in XHTML have a potentially anything goes content model. Would it be appropriate for a conformance checker to only pass style and script types it knows about (with the proper content model for each type)? 2.14.1.1. The spec should probably mention http://www.ietf.org/internet-drafts/ draft-hoehrmann-script-types-03.txt or its successor around here. 2.17. & 2.18. Are calendars and cards expected to be unstylable replaced elements in rendering? 2.20.1. When I read this, I had trouble organizing (in my mind) what I was reading because I had no prior understanding of where the spec was going. Up to this point, I had had prior hypotheses that were confirmed or disconfirmed by the spec. This section would be a lot easier to read if it had an introductionary paragraph stating the relationship of rendering, the DOM, the data model object and data submission. (Is the DOM being rendered or is a replaced widget element being rendered? Is it stylable? Is the data model reflected back to the DOM? What's the expected way of serializing the data model and sending it back to the server?) 2.20.1. Also, I wondered whether this functionality is best specced as part of the UA or whether it would be better to ship it as a MIT/expat- licensed pure-JS library for running on top of the lower-level JS/DOM APIs. (Note: Considering what I wrote above, I don't really understand what the aims are, so I may be totally missing the point.) 2.20.1.3. I had trouble trying to extract markup-level conformance requirements for stuff that can occur inside the datagrid. 2.20.1.3. Is select allowed to occur in the block context only here or anywhere? 2.20.2. Is command in head conforming in the XHTML serialization only? (It is a phasing element in the tree construction section.) 2.20.3. It why not use type="context" for declaring a context menu? 3.1. "We could make this into a string value that acts as a Hint for why the command is disabled." I suspect that to be trouble, because general purpose code for dealing with boolean attributes would need to take that special case into account. Using another attribute for a hint would be fine, though. 4.4.1. "Since all HTML elements can thus be focused and unfocusd" unfocused 4.5. Is onerror only a DOM attribute or is it a markup attribute as well? Whose attribute is it? -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/
Received on Monday, 20 March 2006 02:59:33 UTC