- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 25 Jul 2008 22:44:11 +0000 (UTC)
I have not included the various typos you pointed out in this response. Where the spec has changed since the review 18 months ago, I've asked if the new text is ok. For the cases where it is, there is no need to respond. Thanks! On Fri, 17 Mar 2006, Henri Sivonen wrote: > > 2.2.5. > 'Should textContent be defined differently for dir="" and <bdo>? Should we > come up with an alternative to textContent that handles those and other > things, like alt=""?' > > Messing with the Core API seems like a bad idea. Having an alternative > that handles alt would be useful to have, though. Not good enough. I dropped the note. If people want this, hopefully they'll reraise it. > 2.2.7. > "For example, if an HTML implementation also supports SVG, then the Document > object must implement HTMLDocument and SVGDocument." > > For text/html? Yes. > 2.2.7. > What does "when used as global attributes" mean in this foreign namespace > context? Removed that whole bit, it was redundant and overstepping its bounds. > 2.2.8. > "The nodes representing HTML elements in the DOM must implement, and expose to > scripts, the interfaces listed for them in the relevant sections of this > specification. This includes XHTML elements in XML documents, even when those > documents are in another context (e.g. inside an XSLT transform)." > > I can see why implementing the interfaces in XSLT transforms is allowed but > why required? So that moving the node from an XSLT style sheet into an HTML document works. > 2.2.8. > Is localName supposed to return in lower case? Would make sense. I've removed localName from the list of attributes that do case-fixing. > 2.3.1. > Since blockquote is so abused that it is useless for AI, allowing > attribution within the blockquote would be practical. Attribution isn't part of a quote. How would you distinguish quoting an attribution from quoting text with an attribution from quoting text that happens to have its attribution? > 2.3.2. > I suggest making the allowed inter-element whitespace consistent with the > definition in XML and adding tab. This changed somewhat since you sent that comment. > 2.3.2. > "The SVG specification defines the SVG foreignObject element as allowing > foreign namespaces to be included, thus allowing compound documents to be > created by inserting subdocument content under that element. This > specification defines the XHTML html element as being allowed where > subdocument fragments are allowed in a compound document." > > What about Atom-style fragments without the html element? What about them? > 2.3.3.2. > The spec should probably say here that structured inline content is mostly > incompatible with the HTML serialization. n/a > 2.3.4. > "When an element has an ID set through multiple methods (for example, if it > has both id and xml:id attributes simultaneously [XMLID]), then the element > has multiple identifiers. User agents must use all of an HTML element's > identifiers (including those that are in error according to their relevant > specification) for the purposes of ID matching." > > What does this mean in terms of document conformance? n/a (is the current text ok?) > 2.3.4. > "The value must be a list of zero or more words (consisting of one or more > non-space characters) separated by one or more spaces." > > Firefox and Opera allow any whitespace (space, tab, CR and LF). Are spaces > before and after allowed (works in Safari, too)? Anyway, considering all > non-space characters part of the class names is not interoperable. > http://hsivonen.iki.fi/test/wa10/datatypes/class.html > > I'd prefer separated by one or more whitespace characters with zero or more > whitespace characters before and after allowed. (In general, whenever there's > a list of something in an attribute value, this kind of conventional > separation would be preferable from my point of view. Less need for custom > datatypes. :-) Assuming this is referring to the class attribute, this is now n/a. > 2.4. > "The profile attribute must, if specified, contain a list of zero or more URIs > (or IRIs) representing definitions of classes, metadata names, and link > relations." > > Separated how? Do the URIs/IRIs have to be absolute? n/a, profile is gone. > 2.4. > Is the whole profile thing useful? Wouldn't it be enough to go with class > names that are announced at microformats.org, tantek.com, etc. and do away > with namespace-esque profiles that authors don't seem to care to use anyway? Yes. > 2.4. > Do hCal and hCard class names require a profile if used inside the calendar > and card elements? That's up to the Microformats crowd. > 2.4. > "So as to avoid this problem, authors are encouraged to avoid using multiple > profiles." > > That doesn't look like practical advice. n/a > 2.4.4. > "One element can create multiple links (of which some might be external > resource links and some might be hyperlinks). User agents should process the > links on a per-link basis, not a per-element basis." > > Does that refer to multiple rel values? Added "; exactly which and how many links are created depends on the keywords given in the rel attribute". > 2.4.5. > "To set metadata with meta elements, authors must first specify a profile that > defines metadata names, using the profile attribute." > > In my opinion, it would be useful to predefine the traditional names and > Dublin Core. This can now be done in the wiki. > 2.4.5. > "and the http-equiv attribute must be listed first in the source." > > That requirement violates the general convention that the source order of > attributes does not matter. Firefox, Safari and Opera work either way. (Can't > test IE.) > http://hsivonen.iki.fi/test/wa10/encoding-detection/c-iso-8859-2-with- > reversed-attribute-order.htm This all got changed around and should now be ok. > 2.4.5. > "In XHTML, the XML declaration should be used for inline character encoding > information, if necessary. > > Authors should avoid including inline character encoding information. > Character encoding information should instead be included at the transport > level (e.g. using the HTTP Content-Type header)." > > Since XML is mentioned, it would be good to mention that on the XML side, > using an application/* type without the charset parameter and leaving the > detection to the XML level is the best practice. I've since removed the best practice comments for text/html. > 2.4.6. > Is rel='alternate stylesheet' without a title non-conforming? No longer. > 2.5.9. > Are header and footer required to be the first and last element child of > section if present? No. > 2.9.1. > Just noting that media, type and hreflang that are pertain the resource > identified by href are specced to be allowed without href. 'href' must be present, so that doesn't matter. > 2.9.1. > If the server sends an entity body in response to a ping, the UA may > close the connection, right? Allowed. > 2.9.2. > Should probably say something about the default rendering of q. The default rendering of everything will be defined later. > 2.9.3. > In my opinion, marking up names of people and works in the same does not fit > conventional presentational practice. On the other hand, using cite only for > source citations causes different titles of works to be marked up differently. > Using <cite> as a generic "title of work" could be marginally useful for > styling. Is there any evidence that the way <cite> is currently defined is > useful for any application? > > I still think <cite> fails the "explaining to mother" test. > http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005- > August/004649.html Is the new text better? > 2.9.5. > "Changing the importance of a piece of text with the strong element does not > change the meaning of the sentence." > > This looks a bit weird after reading the examples for <em>. Is the new text ok? > 2.9.6. > "The small element does not "de-emphasise" or lower the importance of text > emphasised by the em element or marked as important with the strong element." > > How does that relate to practice? Reasonably well, insofar as any of these elements were ever used correctly, and given that this is a new semantic for <small>. > 2.9.7. > "Should we just repurpose u or b for this semantic instead? What would they > stand for?" > > I think u would suit the purpose. It could stand for underline. :-) The UA > style sheet rule could be prescribed so that authors would know how to turn > the underline off and use another kind of highlight. Is the current spec ok? (using <mark>) > 2.9.10. > I suggest the definition of i be changed to "The i element represents anything > that is italicized in conventional typography." That's pretty much the only > real world-compatible definition. > > Also, I suggest b be included in the spec and defined as "The b element > represents anything (except headings) that is set in bold face in conventional > typography." Is the current text ok? > 2.9.11. > What's the use case of the t element? n/a. > 2.9.18. > "For example, it would be inappropriate for the sup and sub elements to be > used in the name of the LaTeX document preparation system." > > I have a CSS implementation of the LaTeX logo that could be used as an > in-prose example in that sentence. See the footer of > http://hsivonen.iki.fi/os-x-browsers/ I'm not sure that would really help, but thanks for the offer. :-) > 2.9.18. > "Mathematical expressions often use subscripts and superscripts. Authors are > encouraged to use MathML for marking up mathematics, but authors may opt to > use sub and sup if detailed mathematical markup is not desired. [MathML]" > > It would be useful to have some guidance for XHTML5 and MathML integration. > Should the math element in the http://www.w3.org/1998/Math/MathML namespace be > considered strictly inline content regardless of the mode or display > attribute? It probably should. (It would be semi-plausible to consider display > math block and structural inline content, but the MathML spec implies that > those attributes are presentational and CSS can be used instead.) Is the current text ok? > 1.14.1. > "When the src attribute is set, the script element refers to an external > file, which must (if it uses a supported scripting language) be downloaded and > executed." > > Does disabling scripting make the scripting language unsupported for the > purposes of conformance requirements or should the spec state the obvious > here? I'm glad to say that the spec at this point requires the user agent to not fetch the script if scripting is disabled. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 25 July 2008 15:44:11 UTC