- From: Shane McCarron <shane@aptest.com>
- Date: Tue, 23 Dec 2008 10:55:54 -0600
- To: Tina Holmboe <tina@greytower.net>
- CC: XHTML WG <public-xhtml2@w3.org>
Tina, Thanks very much for your detailed comments. The working group discussed these comments, and I have incorporated the results of that discussion into the latest (22 December) draft. My notes are scattered below: Tina Holmboe wrote: > > > Regarding "XHTML Media Types - Second Edition", specifically the "W3C > Editor's Draft 21 November 2008". > > Section 1 - Introduction > > "explcitly" is misspelt. Fixed > 1. Introduction > > Paragraph four links to "#summary" (as do a number of other links in > the document), but no element has the id summary in the document. Fixed. > Appendix A. Compatibility Guidelines > > "It contains no absolute requirements, and should NEVER be used as > the basis for creating conformance nor validation rules of any sort. > Period." > > I believe the second part of this should be struck or reworded. We reworded this. > A.3. Elements that have no content > > Elements that are empty but which may have content are usually used > for styling purposes. Could a generic element such as div or span be > used for this example rather than p, which should rarely, if ever, be > free of content? Done > A.4. Embedded Style Sheets and Scripts > > Avoiding ]]> in a script or style sheet has no effect unless you > use CDATA in a script element, but that is only necessary if the < > or & is used (and the rest of the guideline says to use external > scripts in that case). > > Avoiding -- in a script or style sheet has no effect unless you > are wrapping the contents of the script or style element with <!-- > and --> (which you should not do since ...) > > The recommendation doesn't mention the old hiding script with comment > method, but the rationale does. > > The rationale starts out talking about said comments, and then > blends into CDATA without explaining why CDATA is needed or > really covering the comment issue in detail. We tried to harmonize your comments with other comment on the same part of the document. The result is not exactly what you suggested, but I hope that it covers the important points. > A.5. > > This sounds like generic advice for writing markup, rather then > something relevant to the differences between XHTML and HTML. I could > be mistaken and would welcome pointers to the relevant parts of the > specifications if so. The XML specification has normalization rules for attribute contents that are inconsistent with the SGML rules. In particular, multiple whitespace is collapsed to a single whitespace and all the various whitespace-type characters are translated into regular "space" characters. The HTML 4 spec does not call for this type of normalization. > > A.11. > > Perhaps an example showing how to convert to lower case before > checking would help clarify this for some people? Added. > A.25. > > This is a new one on me. How is the content of the element treated > differently? It is PCDATA in one context, and CDATA in another. Or something like that. Anne van Kestren pointed it out to the working group recently. > > A.26. > > The content of an iframe element should be alternative content for user > agents > that do not support, or have disabled, iframes. > > What differences are there between how it is handled in HTML and XHTML? To > justify removing an accessibility feature I would expect them to be very > significant. Same as above. They are parsed differently depending on whether frames are disabled or not. > Appendix B. An Example Document > > Until an update to RFC 2854 is published, I suggest not using XHTML > 1.1 for examples of documents that may be served as text/html. We changed this > There is no "bad stuff" to escape in the <style> element. I suggest > removing the CDATA markers and placing that comment before the <script> > element. Done. > I suggest using a grouping selector to apply the background colour, > not a copy and paste of the rule-set. Done -- Shane P. McCarron Phone: +1 763 786-8160 x120 Managing Director Fax: +1 763 786-8180 ApTest Minnesota Inet: shane@aptest.com
Received on Tuesday, 23 December 2008 16:56:35 UTC