Copyright © 2009 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This note contains issues submitted against the XHTML 1.0 Second Edition document that need to be addressed prior to updating it for Third Edition.
Since its release, a number of comments have been sent in against the XHTML 1.0 Second Edition document. This document contains those issues, as well as a recommended disposition for each. Once the working group has confirmed the dispositions, a Disposition of Comments document will be created and made available to reviewers of the XHTML 1.0 Third Edition Proposed Edited Recommendation. This document summarizes the information about 34 open issues in the issue tracking system at http://htmlwg.mn.aptest.com/voyager-issues.
Note that the majority of this document is automatically generated from the Working Group's database of comments. As such, it may contain typographical or stylistic errors. If so, these are contained in the original submissions, and the HTML Working Group elected to not change these submissions.
This document is a Note of the W3C's HTML Working Group. This Note may be updated, replaced or rendered obsolete by other W3C documents at any time. It is inappropriate to use W3C Notes as reference material or to cite them as other than "work in progress". This document is work in progress and does not imply endorsement by the W3C membership.
This document has been produced by the W3C XHTML 2 Working Group as part of the HTML Activity. The goals of the XHTML 2 Working Group are discussed in the XHTML 2 Working Group charter.
Please send detailed comments on this document to www-html-editor@w3.org. We cannot guarantee a personal response, but we will try when it is appropriate. Public discussion on HTML features takes place on the mailing list www-html@w3.org.
A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR.
Issue | Working Group Action | Commentor Position | Change Type | Notes |
---|---|---|---|---|
8407: XHTML1: What is an "isindex element"? | None | None | N/A | This was closed with a response to the submitted clarifying that all element names referred to in the spec are relevant to the local part. |
8413: XHTML1: XML Namespaces compliance | None | None | N/A | This appendix was removed from the recommendation. This clause in the xhtml media types document was changed slightly, but as far as we know ids are permitted to contain colon characters even in XML Namespace valid documents. To answer your basic question, of course XML Namespaces are required of XHTML 1.0 processors. |
6990: [ERRATA] xhtml 1.0 strict dtd: onmouseover | Accept | None | N/A | Fixed. |
6227: An error in XHTML 1.0 SE | Reject | None | N/A | Appendix C has been removed. However, to address the core of the comment, these are NOT in conflict. It just means that when you are serving XHTML to legacy user agents, you should do so in a way that ensures the content encoding is defined via a higher level protocol. |
8408: XHTML1: What's wrong with -- in script/style? | None | None | N/A | This was clarified and moved into the media types document. |
6504: name attribute on img and form in XHTML 1.0 Strict | Accept | None | N/A | I agree that the form element needs the name attribute - that's what the DOM uses to name a form array and lots of javascript libraries seem to count on there being a name on a form element. img DOES have a name attribute in the strict implementation of HTML4 - probably also for scripting since there is a JS array of images on a page. My recommendation is that we put @name back on both of these and update the prose. |
8410: XHTML1: Appendix C.12 seems misplaced | None | None | N/A | This comment was about the guidelines, which have been removed from the recommendation. |
8418: XHTML1: Appendix C.10 seems misplaced | None | None | N/A | Removed from the recommendation. |
8019: [XHTML 1.0] C.12 Using Ampersands in Attribute Values (and Elsewhere) | None | None | N/A | This appendix was removed from the spec. Moreover, we are talking about XML content and in XML validity, the content of attributes is entity processed and the entity rules are not the same as in SGML. So I don't think we need to do anything in the Media Types note either. |
8416: XHTML1: What are "white space characters"? | None | None | N/A | The XHTML 1 specification normatively references XML 1.0 and makes it clear what is interpreted as whitespace w.r.t. XML 1.0. Moreover, this section has been removed from the Recommendation. |
703: HTML 4.01 no <ins> in <pre>? | None | None | N/A | Fixed DTDs in XHTML 1.0 Second Edition so that they now include a new PE "misc.inline" and ensure that PE is included in the content model for the "pre" element. |
8419: XHTML1: Clarification of Appendix C.9 | None | None | N/A | This appendix was removed from the Recommendation. However, this appendix NEVER made any normative requirements for anything, so it would not have done so. |
6232: XHTML1: Suggested improvements to Appendix C | Reject | None | N/A | These changes were overcome by events, since the contents of Appendix C were removed. However, many of the points raised in this comment are now reflected in the XHTML Media Types document. |
8420: XHTML1: Implementability of Appendix C | None | None | N/A | This appendix was removed from the recommendation. |
8898: Difference of UI events' attributes in XHTML 1.0 Strict DTD | Accept | None | N/A | a description of the onmouseover was added to the DTDs. But yes, these comments are non-normative. |
8836: XHTML1: Appendix C.6 seems misplaced | Modify and Accept | None | N/A | Removed the isindex guidance from the xhtml media types document. Removed the whole appendix from this recommendation. |
8414: XHTML1: Appendix C.8 seems misplaced | None | None | N/A | This has been removed from the recommendation. |
8802: Misleading passage in xhtml reccomendation | None | None | N/A | The appendix removed from the Recommendation. |
8409: XHTML1: Appendix C.15 seems misplaced | None | None | N/A | The appendix has been removed from the specification. We updated the text of this clause so it is clear that the guidance is documents should not use formfeed characters because they are not portable. |
6303: typo in a comment in the DTD (sup/sub) | Accept | None | N/A | Fixed. |
6143: Re: XHTML 1.0 2nd ed. Sect. 4.3 and non-declared-EMPTY empty elements (PR#724) | None | None | N/A | |
6674: XHTML 1.0: Normative References | None | None | N/A | We forgot to deal with this one - we need to identify which references are normative and which are informative. I have taken a cut at it. |
8339: XHTML 1.0: Comment processing | Modify and Accept | None | N/A | Updated when moved into Media Types document. |
8417: XHTML1: Appendix C.11 seems misplaced | None | None | N/A | This section has been removed from the Recommendation. |
9110: [XHTML 1 and 1.1] Activating links within Object. | None | None | N/A | objects are independent entities within the page. Navigation is local to the object and its own processing. This is defined in HTML 4. |
8411: XHTML1: (Consistency of) Language Information | None | None | N/A | This was removed in third edition. |
6593: Is zero width space white-space? | None | None | N/A | My recommendation is that we leave this as CDATA because that is compatible with HTML4 AND compatible with XHTML 1.1. I feel the submitter misunderstood the whitespace interpretation requirements of XHTML 1.0. Whitespace in that sense was not related to whitespace within attribute values. The original XHTML 1.0 Rec said that whitespace in attribute values is interpreted as per XML. |
8430: XHTML1: What is an "XML document"? | Accept | None | N/A | Reference to XML 1.0 updated to fourth edition and made normative. |
8285: [xhtml1-schema] Problem arising from XML Schema erratum | None | None | N/A | We could update the XML Schema implementation and include it in the third edition. It would be a work of moments. |
8415: XHTML1: Appendix C.13 seems misplaced/flawed | None | None | N/A | The commentor has misunderstood section 3.2 - the clause in question means that ONLY attributes of type ID can be used as fragment identifiers - not that such an attribute can ONLY have that meaning and no other. Perhaps we should reword the clause to reduce the change for confusion. Moreover, appendix C has been removed from the recommendation. |
6397: Re: [xhtml1] Frameset DTD inconsistent with Transitional DTD | Accept | None | N/A | These changes are all implemented. |
9681: Re: XHTML 1.0, section C14 | None | None | N/A | This appendix was removed from the Recommendation. |
8412: XHTML1: Appendix C.14 seems misplaced and flawed | None | None | N/A | This appendix was removed from the recommendation. In the media types document, this text was updated to make it clearer. |
7087: Ambiguity in section 4.7 of XHTML 1.0 (2nd ed) | None | None | N/A | My recommendation is that we remove the text that explains the algorithm from XHTML 1.0 because there is no point in duplicating content from XML. |
PROBLEM ID: 8407
STATE: Closed
EDIT: N/A
RESOLUTION: None
USER POSITION: None
NOTES:
This was closed with a response to the submitted clarifying that all element names referred to in the spec are relevant to the local part.
ORIGINAL MESSAGE:
Date: Mon, 12 Jul 2004 14:18:04 +0900 (JST) From: Bjoern Hoehrmann <derhoermi@gmx.net> From: Bjoern Hoehrmann <derhoermi@gmx.net> To: www-html-editor@w3.org Subject: XHTML1: What is an "isindex element"? Date: Mon, 12 Jul 2004 06:13:40 +0200 Message-ID: <41810ff2.1817818374@smtp.bjoern.hoehrmann.de> X-Archived-At: http://www.w3.org/mid/41810ff2.1817818374@smtp.bjoern.hoehrmann.de Dear HTML Working Group, Appendix C of the XHTML 1.0 Second Edition Recommendation refers several times to specific "elements". It is not clear to me how implementations are expected to determine whether an element in an XML document is such an element. For example, C.6 reads [...] Don't include more than one isindex element in the document head. [...] Does this refer to the "Name" production in production 40 in XML 1.0 Third Edition or does it refer to the local-name of the element as defined in the Namespaces in XML Recommendation in any namespace (or none) or does it refer to an element with that local-name in the namespace "http://www.w3.org/1999/xhtml" and in case of the latter, what if there is no declaration in the document but the document references an external subset that probably does declare a #FIXED namespace? regards.
FOLLOWUP 1:
Date: Fri, 23 Jul 2004 12:28:57 -0500 From: Shane McCarron <shane@aptest.com> This is a cryptographically signed message in MIME format. --------------ms010201060500000207080108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit It, and all element name references in XHTML 1, refer to the local-name. XHTML 1 requires there be an xmlns declaration on the root element - any document without one is not valid XHTML. derhoermi@gmx.net wrote: >From: Bjoern Hoehrmann <derhoermi@gmx.net> >To: www-html-editor@w3.org >Subject: XHTML1: What is an "isindex element"? >Date: Mon, 12 Jul 2004 06:13:40 +0200 >Message-ID: <41810ff2.1817818374@smtp.bjoern.hoehrmann.de> >X-Archived-At: http://www.w3.org/mid/41810ff2.1817818374@smtp.bjoern.hoehrmann.de > >Dear HTML Working Group, > > Appendix C of the XHTML 1.0 Second Edition Recommendation refers >several times to specific "elements". It is not clear to me how >implementations are expected to determine whether an element in an >XML document is such an element. For example, C.6 reads > >[...] > Don't include more than one isindex element in the document head. >[...] > >Does this refer to the "Name" production in production 40 in XML 1.0 >Third Edition or does it refer to the local-name of the element as >defined in the Namespaces in XML Recommendation in any namespace (or >none) or does it refer to an element with that local-name in the >namespace "http://www.w3.org/1999/xhtml" and in case of the latter, >what if there is no declaration in the document but the document >references an external subset that probably does declare a #FIXED >namespace? > >regards. > > > -- Shane P. McCarron Phone: +1 763 786-8160 x120 Managing Director Fax: +1 763 786-8180 ApTest Minnesota Inet: shane@aptest.com --------------ms010201060500000207080108 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINujCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBSYwggSPoAMCAQICEC2q5xHYEFYOCFS1iYWUmGEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTEwMDAw MDAwWhcNMDQwOTA5MjM1OTU5WjCCARQxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTEaMBgGA1UEAxQRU2hhbmUgUC4gTWNDYXJyb24xHzAd BgkqhkiG9w0BCQEWEHNoYW5lQGFwdGVzdC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQC3rA2lK8eY0hVkTUuZau05QxkrnWCgNKKZZplIJIMG2wwP+B15wWGMG4A7lOaz KamU/PDMuxomP+IKKLzRrsnPZ5nMoiu596CRqolUr5NZBSXtOJEKF6ce//UvaGHlRSqxVhVD qOaIn58BuCvugKExHfCEjWrl38JpQU/2BrqEFslPu+s5ba/q8ZlUj/2eeMuXLsa5b3MvBc5s GW16fdWisSZd/ZDlzg1aNPfTCR88aF0/QrR/fgUaBDh3jsKCq9blW261qoactbzjMKIOwVUn 2yvto+89hFHBiUOwwFt+ZIDc3eZSkjFuxA4aF3qvDEQdJc64PL8rGq8Gja0oiu1DAgMBAAGj ggE4MIIBNDAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYw FRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMAYK YIZIAYb4RQEGBwQiFiAyYjE5ZWRjZTZhOTQxZGFlZmMyN2ZiNDRlMjc3NjU2ZTAzBgNVHR8E LDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3 DQEBBAUAA4GBAKRKgqJM5b/kcoY7LLLdpxwD/Or1+XJIU34V6VTjSutg78lZyBsU9ufcesg/ Pd8iYsWJ19eknBuVO/enNbgv+BF5jxuveaAGoGvo7cIjcOMf0xUYTezGD0ur2jp3Pdk/ZPmW 0uCzBAQw4XJYP84pViI3VynAoDQH3MF8g35660TQMIIFJjCCBI+gAwIBAgIQLarnEdgQVg4I VLWJhZSYYTANBgkqhkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNV BAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEg Tm90IFZhbGlkYXRlZDAeFw0wMzA5MTAwMDAwMDBaFw0wNDA5MDkyMzU5NTlaMIIBFDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBS ZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEG A1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRowGAYD VQQDFBFTaGFuZSBQLiBNY0NhcnJvbjEfMB0GCSqGSIb3DQEJARYQc2hhbmVAYXB0ZXN0LmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALesDaUrx5jSFWRNS5lq7TlDGSud YKA0oplmmUgkgwbbDA/4HXnBYYwbgDuU5rMpqZT88My7GiY/4goovNGuyc9nmcyiK7n3oJGq iVSvk1kFJe04kQoXpx7/9S9oYeVFKrFWFUOo5oifnwG4K+6AoTEd8ISNauXfwmlBT/YGuoQW yU+76zltr+rxmVSP/Z54y5cuxrlvcy8FzmwZbXp91aKxJl39kOXODVo099MJHzxoXT9CtH9+ BRoEOHeOwoKr1uVbbrWqhpy1vOMwog7BVSfbK+2j7z2EUcGJQ7DAW35kgNzd5lKSMW7EDhoX eq8MRB0lzrg8vysarwaNrSiK7UMCAwEAAaOCATgwggE0MAkGA1UdEwQCMAAwgawGA1UdIASB pDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJp U2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlT aWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhFAQYHBCIWIDJiMTllZGNlNmE5NDFk YWVmYzI3ZmI0NGUyNzc2NTZlMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNp Z24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEApEqCokzlv+Ryhjssst2nHAP8 6vX5ckhTfhXpVONK62DvyVnIGxT259x6yD893yJixYnX16ScG5U796c1uC/4EXmPG695oAag a+jtwiNw4x/TFRhN7MYPS6vaOnc92T9k+ZbS4LMEBDDhclg/zilWIjdXKcCgNAfcwXyDfnrr RNAxggSqMIIEpgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw b3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1Zl cmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZh bGlkYXRlZAIQLarnEdgQVg4IVLWJhZSYYTAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA3MjMxNzI4NTdaMCMGCSqGSIb3DQEJ BDEWBBQNBx+T8Y94RhpGWvGMmnb/vMvHBDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB8gYJKwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkAhAtqucR2BBWDghUtYmFlJhhMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQLarnEdgQVg4I VLWJhZSYYTANBgkqhkiG9w0BAQEFAASCAQCSjKIYBebEIZ/x9lSSukgUFbUhtgnpcmPf+xKq QJxALdqoqVp/JYtKW3bwKLdJHNZD9Gqq+aNrX0XTQzgRdrcWCYrh1EnyTpFTEEVxDTJOBmYH 9ooMml4F0tn/FrO75REWnqdgyfNP0iNg35pbe2eowiibnl86P9GLEyOer+u5Bnc7yjpWWFD3 dqMBMZGZnlZxU3MLr/dVK1i3FSw4LBMUGIh0u5X8Zyt9YXo+2GheRiNHh0QRQ0e0wxncmyKl VmoEslIH9Taz4sTtNjXgp5ZVmVHz8QYxmjP2lShOpJH/TlkiU9cI92SpMb2W0VM/q+vprZWL dp2ZB98sh3aQ3xl+AAAAAAAA --------------ms010201060500000207080108--
PROBLEM ID: 8413
STATE: Needs Approval
EDIT: N/A
RESOLUTION: None
USER POSITION: None
NOTES:
This appendix was removed from the recommendation. This clause in the xhtml media types document was changed slightly, but as far as we know ids are permitted to contain colon characters even in XML Namespace valid documents. To answer your basic question, of course XML Namespaces are required of XHTML 1.0 processors.
ORIGINAL MESSAGE:
Date: Mon, 12 Jul 2004 14:26:33 +0900 (JST) From: Bjoern Hoehrmann <derhoermi@gmx.net> From: Bjoern Hoehrmann <derhoermi@gmx.net> To: www-html-editor@w3.org Subject: XHTML1: XML Namespaces compliance Date: Mon, 12 Jul 2004 06:14:01 +0200 Message-ID: <41881008.1817840346@smtp.bjoern.hoehrmann.de> X-Archived-At: http://www.w3.org/mid/41881008.1817840346@smtp.bjoern.hoehrmann.de Dear HTML Working Group, Neither section 3.2 nor section 3.1.1 of the XHTML 1.0 Second Edition Recommendation state whether strictly conforming documents are required to be namespace-well-formed or namespace-valid and whether user agents are required to evaluate XHTML 1.0 documents for namespace-well-formed- ness or -validity. Could you please clarify whether they are in those sections and in case they are, change appendix C.8 to reflect this, i.e. remove the colon from the regular expression for legal ID values? If they are not required to conform to the Namespaces in XML Recommendation it seems there should be a warning for authors that due to the uncertain situation some user agents do evaluate documents to this effect and might fail to process documents that are not; and that general purpose XML tools that support XML namespaces might fail to process such documents, too. That said, there does not seem to be a good reason why XHTML should be liberal in this regard. Appendix C.8 further states [...] Further, since the set of legal values for attributes of type ID is much smaller than for those of type CDATA, the type of the name attribute has been changed to NMTOKEN. This attribute is constrained such that it can only have the same values as type ID, or as the Name production in XML 1.0 Section 2.3, production 5. [...] This would also need to be changed if you change the Recommendation to require namespace-validity as NMTOKEN attributes may contain colons while ID attributes may not. regards.
PROBLEM ID: 6990
STATE: Approved
EDIT: N/A
RESOLUTION: Accept
USER POSITION: None
NOTES:
Fixed.
ORIGINAL MESSAGE:
Date: Sat, 20 Sep 2003 02:08:42 +0900 (JST) From: Paul Arzul <patricka@mkdoc.com> From: Paul Arzul <patricka@mkdoc.com> To: www-html-editor@w3.org Subject: [ERRATA] xhtml 1.0 strict dtd: onmouseover Date: Fri, 19 Sep 2003 16:38:07 +0100 Message-ID: <20030919153807.GE1303@mkdoc.com> X-Archived-At: http://www.w3.org/mid/20030919153807.GE1303@mkdoc.com hi all, somebody punish me -- i'm trying to *read* a dtd[1]. :) the comments that precede "events" omits[2] one: onmouseover - p 1. http://www.w3.org/TR/xhtml1/dtds.html#a_dtd_XHTML-1.0-Strict 2. <!-- attributes for common UI events onclick a pointer button was clicked ondblclick a pointer button was double clicked onmousedown a pointer button was pressed down onmouseup a pointer button was released onmousemove a pointer was moved onto the element onmouseout a pointer was moved away from the element onkeypress a key was pressed and released onkeydown a key was pressed down onkeyup a key was released --> <!ENTITY % events "onclick %Script; #IMPLIED ondblclick %Script; #IMPLIED onmousedown %Script; #IMPLIED onmouseup %Script; #IMPLIED onmouseover %Script; #IMPLIED onmousemove %Script; #IMPLIED onmouseout %Script; #IMPLIED onkeypress %Script; #IMPLIED onkeydown %Script; #IMPLIED onkeyup %Script; #IMPLIED" >
PROBLEM ID: 6227
STATE: Needs Approval
EDIT: N/A
RESOLUTION: Reject
USER POSITION: None
NOTES:
Appendix C has been removed. However, to address the core of the comment, these are NOT in conflict. It just means that when you are serving XHTML to legacy user agents, you should do so in a way that ensures the content encoding is defined via a higher level protocol.
ORIGINAL MESSAGE:
Date: Tue, 14 Jan 2003 22:20:12 +0900 (JST) From: Satoshi ISHIKAWA <satoshii@math.oheya.to> From: Satoshi ISHIKAWA <satoshii@math.oheya.to> To: <www-html-editor@w3.org> Subject: An error in XHTML 1.0 SE Date: Tue, 14 Jan 2003 10:04:15 +0900 Message-ID: <BA49911F.CFE%satoshii@math.oheya.to> X-Archived-At: http://www.w3.org/mid/BA49911F.CFE%satoshii@math.oheya.to Hi, XHTML 1.0 SE C.1. [1] notes as follows: > Remember, however, that when the XML declaration is > not included in a document, the document can only use > the default character encodings UTF-8 or UTF-16. But this is unsuitable to the new statement of 3.1.1.[2]: > Such a declaration is required when the character > encoding of the document is other than the default > UTF-8 or UTF-16 and no encoding was determined > by a higher-level protocol. [1] http://www.w3.org/TR/2002/REC-xhtml1-20020801/#C_1 [2] http://www.w3.org/TR/2002/REC-xhtml1-20020801/#strict Regards, -- Satoshi ISHIKAWA / satoshii@math.oheya.to http://math.oheya.to/markup/
FOLLOWUP 1:
From: "Steven Pemberton" <steven.pemberton@cwi.nl> Date: Wed, 15 Jan 2003 13:47:24 +0100 > From: Satoshi ISHIKAWA <satoshii@math.oheya.to> > XHTML 1.0 SE C.1. [1] notes as follows: > > > Remember, however, that when the XML declaration is > > not included in a document, the document can only use > > the default character encodings UTF-8 or UTF-16. > > But this is unsuitable to the new statement of 3.1.1.[2]: > > > Such a declaration is required when the character > > encoding of the document is other than the default > > UTF-8 or UTF-16 and no encoding was determined > > by a higher-level protocol. No, these are both compatible. If a document is to leave out the XML declaration it should use UTF-8 or UTF-16. If you want to use another encoding, either use a higher-level protocol (HTTP), or include an XML declaration. Best wishes, Steven Pemberton
PROBLEM ID: 8408
STATE: Needs Approval
EDIT: N/A
RESOLUTION: None
USER POSITION: None
NOTES:
This was clarified and moved into the media types document.
ORIGINAL MESSAGE:
Date: Mon, 12 Jul 2004 14:19:22 +0900 (JST) From: Bjoern Hoehrmann <derhoermi@gmx.net> From: Bjoern Hoehrmann <derhoermi@gmx.net> To: www-html-editor@w3.org Subject: XHTML1: What's wrong with -- in script/style? Date: Mon, 12 Jul 2004 06:13:48 +0200 Message-ID: <41830ffb.1817827367@smtp.bjoern.hoehrmann.de> X-Archived-At: http://www.w3.org/mid/41830ffb.1817827367@smtp.bjoern.hoehrmann.de Dear HTML Working Group, Appendix C.4 of the XHTML 1.0 Second Edition Recommendation states [...] Use external style sheets if your style sheet uses < or & or ]]> or --. Use external scripts if your script uses < or & or ]]> or --. [...] I do not understand what the problem with -- in those elements is, as far as I can tell, there is no difference for e.g. <style ...>/*--*/</style> or <p style="/*--*/">...</p> in HTML versus XHTML, the specification seems thus in error in this regard. regards.
FOLLOWUP 1:
Date: Fri, 23 Jul 2004 13:27:36 -0500 From: Shane McCarron <shane@aptest.com> This is a cryptographically signed message in MIME format. --------------ms010803000601080903060600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit With the understanding that appendix C is informative... derhoermi@gmx.net wrote: > Appendix C.4 of the XHTML 1.0 Second Edition Recommendation states > >[...] > Use external style sheets if your style sheet uses < or & or ]]> or > --. Use external scripts if your script uses < or & or ]]> or --. >[...] > >I do not understand what the problem with -- in those elements is, as >far as I can tell, there is no difference for e.g. > > <style ...>/*--*/</style> > >or > > <p style="/*--*/">...</p> > >in HTML versus XHTML, the specification seems thus in error in this >regard. > I think there is some context missing in the specification. What this is alluding to is that, when you embed a style sheet or a script in an HTML 4 document, you traditionally wrap the CDATA contents with a <!-- and --> . The problem is that it is possible for an older browser to incorrectly interpret the contents if it encounters any of the proscribed characters in the embedded script or style sheet. Including "--", which could mean end of comment. Nothing in appendix C is a conformance requirement. It is just a collection of hints for document developers to help them write XHTML 1.0 code that will work in (then) existing browsers. -- Shane P. McCarron Phone: +1 763 786-8160 x120 Managing Director Fax: +1 763 786-8180 ApTest Minnesota Inet: shane@aptest.com --------------ms010803000601080903060600 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINujCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBSYwggSPoAMCAQICEC2q5xHYEFYOCFS1iYWUmGEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTEwMDAw MDAwWhcNMDQwOTA5MjM1OTU5WjCCARQxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTEaMBgGA1UEAxQRU2hhbmUgUC4gTWNDYXJyb24xHzAd BgkqhkiG9w0BCQEWEHNoYW5lQGFwdGVzdC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQC3rA2lK8eY0hVkTUuZau05QxkrnWCgNKKZZplIJIMG2wwP+B15wWGMG4A7lOaz KamU/PDMuxomP+IKKLzRrsnPZ5nMoiu596CRqolUr5NZBSXtOJEKF6ce//UvaGHlRSqxVhVD qOaIn58BuCvugKExHfCEjWrl38JpQU/2BrqEFslPu+s5ba/q8ZlUj/2eeMuXLsa5b3MvBc5s GW16fdWisSZd/ZDlzg1aNPfTCR88aF0/QrR/fgUaBDh3jsKCq9blW261qoactbzjMKIOwVUn 2yvto+89hFHBiUOwwFt+ZIDc3eZSkjFuxA4aF3qvDEQdJc64PL8rGq8Gja0oiu1DAgMBAAGj ggE4MIIBNDAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYw FRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMAYK YIZIAYb4RQEGBwQiFiAyYjE5ZWRjZTZhOTQxZGFlZmMyN2ZiNDRlMjc3NjU2ZTAzBgNVHR8E LDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3 DQEBBAUAA4GBAKRKgqJM5b/kcoY7LLLdpxwD/Or1+XJIU34V6VTjSutg78lZyBsU9ufcesg/ Pd8iYsWJ19eknBuVO/enNbgv+BF5jxuveaAGoGvo7cIjcOMf0xUYTezGD0ur2jp3Pdk/ZPmW 0uCzBAQw4XJYP84pViI3VynAoDQH3MF8g35660TQMIIFJjCCBI+gAwIBAgIQLarnEdgQVg4I VLWJhZSYYTANBgkqhkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNV BAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEg Tm90IFZhbGlkYXRlZDAeFw0wMzA5MTAwMDAwMDBaFw0wNDA5MDkyMzU5NTlaMIIBFDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBS ZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEG A1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRowGAYD VQQDFBFTaGFuZSBQLiBNY0NhcnJvbjEfMB0GCSqGSIb3DQEJARYQc2hhbmVAYXB0ZXN0LmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALesDaUrx5jSFWRNS5lq7TlDGSud YKA0oplmmUgkgwbbDA/4HXnBYYwbgDuU5rMpqZT88My7GiY/4goovNGuyc9nmcyiK7n3oJGq iVSvk1kFJe04kQoXpx7/9S9oYeVFKrFWFUOo5oifnwG4K+6AoTEd8ISNauXfwmlBT/YGuoQW yU+76zltr+rxmVSP/Z54y5cuxrlvcy8FzmwZbXp91aKxJl39kOXODVo099MJHzxoXT9CtH9+ BRoEOHeOwoKr1uVbbrWqhpy1vOMwog7BVSfbK+2j7z2EUcGJQ7DAW35kgNzd5lKSMW7EDhoX eq8MRB0lzrg8vysarwaNrSiK7UMCAwEAAaOCATgwggE0MAkGA1UdEwQCMAAwgawGA1UdIASB pDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJp U2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlT aWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhFAQYHBCIWIDJiMTllZGNlNmE5NDFk YWVmYzI3ZmI0NGUyNzc2NTZlMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNp Z24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEApEqCokzlv+Ryhjssst2nHAP8 6vX5ckhTfhXpVONK62DvyVnIGxT259x6yD893yJixYnX16ScG5U796c1uC/4EXmPG695oAag a+jtwiNw4x/TFRhN7MYPS6vaOnc92T9k+ZbS4LMEBDDhclg/zilWIjdXKcCgNAfcwXyDfnrr RNAxggSqMIIEpgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw b3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1Zl cmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZh bGlkYXRlZAIQLarnEdgQVg4IVLWJhZSYYTAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA3MjMxODI3MzZaMCMGCSqGSIb3DQEJ BDEWBBSL4G5PbkFwpCeN/pTYtsshAam4NjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB8gYJKwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkAhAtqucR2BBWDghUtYmFlJhhMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQLarnEdgQVg4I VLWJhZSYYTANBgkqhkiG9w0BAQEFAASCAQAaPw/IIJiMReRzGZZYbsL+es382vjUY56Y1MGn mBF3WtqLKJuulkV2Q3mnzGpw+aGDRGvPLtoM9ckTb90xvPiLHRHrczYIoVWMi7TcGgKh8BUU csbyE8No9hP3ii6U/vgJfoW4HKoeYTsJgumG+ff6MN9iE8PJ6F8kwWDzzWdpHQ0V9JA7OC6y 4X7wupKgQS7RFsPODfh6Tf47vcvcrfOVHGovaEZZIzjRbN8nWTinU9ybJ9zAzBWYIUPOcB9D H4Wh11erySGnFzEeH/7O/4CxdPZMBh5xtyHS1jXEgtq7FBosQPLTxf/uxP0XJ07Ya7onGRKR vO1OtXE4x9Ec9a50AAAAAAAA --------------ms010803000601080903060600--
PROBLEM ID: 6504
STATE: Needs Approval
EDIT: N/A
RESOLUTION: Accept
USER POSITION: None
NOTES:
I agree that the form element needs the name attribute - that's what the DOM uses to name a form array and lots of javascript libraries seem to count on there being a name on a form element. img DOES have a name attribute in the strict implementation of HTML4 - probably also for scripting since there is a JS array of images on a page. My recommendation is that we put @name back on both of these and update the prose.
ORIGINAL MESSAGE:
Date: Sun, 27 Jul 2003 16:37:09 +0900 (JST) From: Bjoern Hoehrmann <derhoermi@gmx.net> From: Bjoern Hoehrmann <derhoermi@gmx.net> To: www-html-editor@w3.org Subject: name attribute on img and form in XHTML 1.0 Strict Date: Sun, 27 Jul 2003 02:55:21 +0200 Message-ID: <3f4a2211.377098258@smtp.bjoern.hoehrmann.de> X-Archived-At: http://www.w3.org/mid/3f4a2211.377098258@smtp.bjoern.hoehrmann.de Dear HTML WG, HTML 4.01 Strict includes the name attribute for form and img but XHTML 1.0 Strict does not. It neither lists this as change from HTML 4.01, I thus suppose this is an error in the specification. Could you confirm this and add something about it in the errata? regards.
FOLLOWUP 1:
Date: Sun, 27 Jul 2003 02:37:18 -0500 From: derhoermi@gmx.net From: Bjoern Hoehrmann <derhoermi@gmx.net> To: www-html-editor@w3.org Subject: name attribute on img and form in XHTML 1.0 Strict Date: Sun, 27 Jul 2003 02:55:21 +0200 Message-ID: <3f4a2211.377098258@smtp.bjoern.hoehrmann.de> X-Archived-At: http://www.w3.org/mid/3f4a2211.377098258@smtp.bjoern.hoehrmann.de Dear HTML WG, HTML 4.01 Strict includes the name attribute for form and img but XHTML 1.0 Strict does not. It neither lists this as change from HTML 4.01, I thus suppose this is an error in the specification. Could you confirm this and add something about it in the errata? regards.
PROBLEM ID: 8410
STATE: Needs Approval
EDIT: N/A
RESOLUTION: None
USER POSITION: None
NOTES:
This comment was about the guidelines, which have been removed from the recommendation.
ORIGINAL MESSAGE:
Date: Mon, 12 Jul 2004 14:23:10 +0900 (JST) From: Bjoern Hoehrmann <derhoermi@gmx.net> From: Bjoern Hoehrmann <derhoermi@gmx.net> To: www-html-editor@w3.org Subject: XHTML1: Appendix C.12 seems misplaced Date: Mon, 12 Jul 2004 06:13:53 +0200 Message-ID: <41851000.1817832154@smtp.bjoern.hoehrmann.de> X-Archived-At: http://www.w3.org/mid/41851000.1817832154@smtp.bjoern.hoehrmann.de Dear HTML Working Group, Appendix C.12 in the XHTML 1.0 Second Edition discusses the use of ampersands in HTML and XHTML, it says [...] In both SGML and XML, the ampersand character ("&") declares the beginning of an entity reference (e.g., ® for the registered trademark symbol "=AE"). [...] This seems to be an error, in HTML 4.01 the ampersand introduces an entity reference if and only if it is followed by a name start character, for example <p>&</p> is perfectly legal in HTML 4.01. Further the entire section seems misplaced as it seems that it does not define any guideline for XHTML authors who wish to deliver their XHTML documents to legacy user agents. It seems the proper section for this text would be Section 4, "Differences with HTML 4". Could you please confirm that this is an error in the specification, or, if it is intentionally placed there, state what the actual requirement is? regards.
FOLLOWUP 1:
Date: Fri, 23 Jul 2004 13:56:11 -0500 From: Shane McCarron <shane@aptest.com> This is a cryptographically signed message in MIME format. --------------ms080007060509040806010201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Again, there is no requirement here. Your example of an ampersand not followed by a name character is interesting. I could not find that exclusion my SGML references nor in HTML 4, but I didn't look too hard. Regardless, for the most part historical HTML browsers were very loose in their interpretation of ampersands - XML processors are not. This could have been in chapter 4, but in that case it would have been a conformance requirement that is already enforced by our reference to XML. derhoermi@gmx.net wrote: >From: Bjoern Hoehrmann <derhoermi@gmx.net> >To: www-html-editor@w3.org >Subject: XHTML1: Appendix C.12 seems misplaced >Date: Mon, 12 Jul 2004 06:13:53 +0200 >Message-ID: <41851000.1817832154@smtp.bjoern.hoehrmann.de> >X-Archived-At: http://www.w3.org/mid/41851000.1817832154@smtp.bjoern.hoehrmann.de > >Dear HTML Working Group, > > Appendix C.12 in the XHTML 1.0 Second Edition discusses the use of >ampersands in HTML and XHTML, it says > >[...] > In both SGML and XML, the ampersand character ("&") declares the > beginning of an entity reference (e.g., ® for the registered > trademark symbol "=AE"). >[...] > >This seems to be an error, in HTML 4.01 the ampersand introduces an >entity reference if and only if it is followed by a name start >character, for example <p>&</p> is perfectly legal in HTML 4.01. > >Further the entire section seems misplaced as it seems that it does >not define any guideline for XHTML authors who wish to deliver their >XHTML documents to legacy user agents. It seems the proper section for >this text would be Section 4, "Differences with HTML 4". Could you >please confirm that this is an error in the specification, or, if it >is intentionally placed there, state what the actual requirement is? > >regards. > > > -- Shane P. McCarron Phone: +1 763 786-8160 x120 Managing Director Fax: +1 763 786-8180 ApTest Minnesota Inet: shane@aptest.com --------------ms080007060509040806010201 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINujCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBSYwggSPoAMCAQICEC2q5xHYEFYOCFS1iYWUmGEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTEwMDAw MDAwWhcNMDQwOTA5MjM1OTU5WjCCARQxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTEaMBgGA1UEAxQRU2hhbmUgUC4gTWNDYXJyb24xHzAd BgkqhkiG9w0BCQEWEHNoYW5lQGFwdGVzdC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQC3rA2lK8eY0hVkTUuZau05QxkrnWCgNKKZZplIJIMG2wwP+B15wWGMG4A7lOaz KamU/PDMuxomP+IKKLzRrsnPZ5nMoiu596CRqolUr5NZBSXtOJEKF6ce//UvaGHlRSqxVhVD qOaIn58BuCvugKExHfCEjWrl38JpQU/2BrqEFslPu+s5ba/q8ZlUj/2eeMuXLsa5b3MvBc5s GW16fdWisSZd/ZDlzg1aNPfTCR88aF0/QrR/fgUaBDh3jsKCq9blW261qoactbzjMKIOwVUn 2yvto+89hFHBiUOwwFt+ZIDc3eZSkjFuxA4aF3qvDEQdJc64PL8rGq8Gja0oiu1DAgMBAAGj ggE4MIIBNDAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYw FRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMAYK YIZIAYb4RQEGBwQiFiAyYjE5ZWRjZTZhOTQxZGFlZmMyN2ZiNDRlMjc3NjU2ZTAzBgNVHR8E LDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3 DQEBBAUAA4GBAKRKgqJM5b/kcoY7LLLdpxwD/Or1+XJIU34V6VTjSutg78lZyBsU9ufcesg/ Pd8iYsWJ19eknBuVO/enNbgv+BF5jxuveaAGoGvo7cIjcOMf0xUYTezGD0ur2jp3Pdk/ZPmW 0uCzBAQw4XJYP84pViI3VynAoDQH3MF8g35660TQMIIFJjCCBI+gAwIBAgIQLarnEdgQVg4I VLWJhZSYYTANBgkqhkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNV BAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEg Tm90IFZhbGlkYXRlZDAeFw0wMzA5MTAwMDAwMDBaFw0wNDA5MDkyMzU5NTlaMIIBFDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBS ZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEG A1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRowGAYD VQQDFBFTaGFuZSBQLiBNY0NhcnJvbjEfMB0GCSqGSIb3DQEJARYQc2hhbmVAYXB0ZXN0LmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALesDaUrx5jSFWRNS5lq7TlDGSud YKA0oplmmUgkgwbbDA/4HXnBYYwbgDuU5rMpqZT88My7GiY/4goovNGuyc9nmcyiK7n3oJGq iVSvk1kFJe04kQoXpx7/9S9oYeVFKrFWFUOo5oifnwG4K+6AoTEd8ISNauXfwmlBT/YGuoQW yU+76zltr+rxmVSP/Z54y5cuxrlvcy8FzmwZbXp91aKxJl39kOXODVo099MJHzxoXT9CtH9+ BRoEOHeOwoKr1uVbbrWqhpy1vOMwog7BVSfbK+2j7z2EUcGJQ7DAW35kgNzd5lKSMW7EDhoX eq8MRB0lzrg8vysarwaNrSiK7UMCAwEAAaOCATgwggE0MAkGA1UdEwQCMAAwgawGA1UdIASB pDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJp U2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlT aWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhFAQYHBCIWIDJiMTllZGNlNmE5NDFk YWVmYzI3ZmI0NGUyNzc2NTZlMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNp Z24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEApEqCokzlv+Ryhjssst2nHAP8 6vX5ckhTfhXpVONK62DvyVnIGxT259x6yD893yJixYnX16ScG5U796c1uC/4EXmPG695oAag a+jtwiNw4x/TFRhN7MYPS6vaOnc92T9k+ZbS4LMEBDDhclg/zilWIjdXKcCgNAfcwXyDfnrr RNAxggSqMIIEpgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw b3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1Zl cmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZh bGlkYXRlZAIQLarnEdgQVg4IVLWJhZSYYTAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA3MjMxODU2MTFaMCMGCSqGSIb3DQEJ BDEWBBRRPn83LAVklX3km9tCyigA2iGUfTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB8gYJKwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkAhAtqucR2BBWDghUtYmFlJhhMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQLarnEdgQVg4I VLWJhZSYYTANBgkqhkiG9w0BAQEFAASCAQCay31Bm8U5BWnJqP1p/K8oVuBAHKtogRVqJOBv TxV9YTU2/dP+3yMaItLedLK9kGDhoqGG9xFcpHhrXMBffii6NqaZXm8xJAIQ/vWnkh/VrjmS 0W69Qb1Ftnr6v8h6mXLJvhUcO8VYZKks0S24sY1LsgpsBY13pk4FAULLAdbt8JyOJE7SBwKY muWB03YMbbluJLZr35kZnQtnVquJs9AiZl90sH7d2zi2THdVBE2LVhB+FAscgURhkD2OYnkb oPz084oLtmmmnHl/PVgL+oAROlCdYmsv38HqgER3r1ELK6Krq4leAOh72Vb+jmTj9YUMdFPO OhzvwpAJt9QKgETkAAAAAAAA --------------ms080007060509040806010201--
FOLLOWUP 2:
From: Bjoern Hoehrmann <derhoermi@gmx.net> Date: Fri, 23 Jul 2004 21:46:41 +0200 * Shane McCarron wrote: >Again, there is no requirement here. Your example of an ampersand not >followed by a name character is interesting. I could not find that >exclusion my SGML references nor in HTML 4, but I didn't look too hard. HTML 4 uses this e.g. for "Script Macros", see Appendix B.7.1 of the HTML 4.01 Recommendation. >Regardless, for the most part historical HTML browsers were very loose >in their interpretation of ampersands - XML processors are not. This >could have been in chapter 4, but in that case it would have been a >conformance requirement that is already enforced by our reference to XML. Section 4 is correctly marked as informative; it is true that this is already indirectly spelled out by the (incorrectly marked informative) reference to XML 1.0, but the intent of section 4 is to list differences hence we seem to be in agreement that section 4 is a better place for it, so, please move this section to section 4 in the third edition of the specification. You would ideally also note that in the errata document... Thanks for your time, Shane!
PROBLEM ID: 8418
STATE: Needs Approval
EDIT: N/A
RESOLUTION: None
USER POSITION: None
NOTES:
Removed from the recommendation.
ORIGINAL MESSAGE:
Date: Mon, 12 Jul 2004 14:32:42 +0900 (JST) From: Bjoern Hoehrmann <derhoermi@gmx.net> From: Bjoern Hoehrmann <derhoermi@gmx.net> To: www-html-editor@w3.org Subject: XHTML1: Appendix C.10 seems misplaced Date: Mon, 12 Jul 2004 06:14:13 +0200 Message-ID: <418d1014.1817852063@smtp.bjoern.hoehrmann.de> X-Archived-At: http://www.w3.org/mid/418d1014.1817852063@smtp.bjoern.hoehrmann.de Dear HTML Working Group, Appendix C.10 in the XHTML 1.0 Second Edition Recommendation seems misplaced in Appendix C as it does not seem to provide guidelines for XHTML authors who wish to deliver XHTML documents to legacy user agents. Could you please clarify what requirements you had in mind here for XHTML authors or their documents? You point out that some legacy user agents do not comply with the HTML 4.01 Recommendation, that seems to be a far more general consideration for both HTML and XHTML authors, and probably warrants a section on its own right, but unless you know of a workaround for this particular problem for XHTML authors, it would seem more appropriate to file this under section 4, "Differences with HTML 4". regards.
PROBLEM ID: 8019
STATE: Needs Approval
EDIT: N/A
RESOLUTION: None
USER POSITION: None
NOTES:
This appendix was removed from the spec. Moreover, we are talking about XML content and in XML validity, the content of attributes is entity processed and the entity rules are not the same as in SGML. So I don't think we need to do anything in the Media Types note either.
ORIGINAL MESSAGE:
Date: Wed, 14 Jan 2004 19:31:41 +0900 (JST) From: Kevin Rodgers <kevin.rodgers@ihs.com> From: Kevin Rodgers <kevin.rodgers@ihs.com> To: www-html-editor@w3.org Subject: [XHTML 1.0] C.12 Using Ampersands in Attribute Values (and Elsewhere) Date: Tue, 13 Jan 2004 16:10:41 -0700 Message-ID: <16388.31473.775174.632157@ihs.com> X-Archived-At: http://www.w3.org/mid/16388.31473.775174.632157@ihs.com I would just like to add my voice to Björn Höhrmann's regarding entity references: http://lists.w3.org/Archives/Public/www-html-editor/2001OctDec/0084.html My complaint is with the following: | In both SGML and XML, the ampersand character ("&") declares the | beginning of an entity reference (e.g., ® for the registered | trademark symbol "?"). Unfortunately, many HTML user agents have | silently ignored incorrect usage of the ampersand character in HTML | documents - treating ampersands that do not look like entity | references as literal ampersands. HTML 2.0 - 4.01 are all defined as SGML applications, and the SGML spec clearly states that "&" is not recognized as an entity reference open delimiter in element content and attribute value literals unless it is immediately followed by a name start character (see ISO 8879:1986 [9.6] Delimiter Recognition and [Figure 3] Reference Delimiter Set: General). So "&" not immediately followed by a name start character should indeed be treated as a literal ampersand by HTML user agents (and "&#" not immediately followed by a name start character or a digit should be treated as a literal ampersand-octothorpe sequence). The example in [XHTML 1.0] C.12 is a URL for a CGI script invocation in which "&" is actually followed by a name start character: | http://my.site.dom/cgi-bin/myscript.pl?class=guest&name=user So that ampersand must be expressed as an entity reference as claimed. But in general that claim is not true, and this incompatibility between HTML and XHTML is due to the facts that [1] XML requires "&" to be interpreted as a markup delimiter (except within comments, processing instructions, and CDATA sections) and [2] XML adds "_" and ":" to the set of name start characters anyway. [1] http://www.w3.org/TR/REC-xml#syntax [2] http://www.w3.org/TR/REC-xml#NT-Name Thanks, -- Kevin Rodgers
PROBLEM ID: 8416
STATE: Needs Approval
EDIT: N/A
RESOLUTION: None
USER POSITION: None
NOTES:
The XHTML 1 specification normatively references XML 1.0 and makes it clear what is interpreted as whitespace w.r.t. XML 1.0. Moreover, this section has been removed from the Recommendation.
ORIGINAL MESSAGE:
Date: Mon, 12 Jul 2004 14:30:20 +0900 (JST) From: Bjoern Hoehrmann <derhoermi@gmx.net> From: Bjoern Hoehrmann <derhoermi@gmx.net> To: www-html-editor@w3.org Subject: XHTML1: What are "white space characters"? Date: Mon, 12 Jul 2004 06:13:46 +0200 Message-ID: <41820ff8.1817824303@smtp.bjoern.hoehrmann.de> X-Archived-At: http://www.w3.org/mid/41820ff8.1817824303@smtp.bjoern.hoehrmann.de Dear HTML Working Group, Appendix C.5 of the XHTML 1.0 Second Edition Recommendation states: [...] Avoid line breaks and multiple white space characters within attribute values. [...] It is not clear to me what this refers to. What is a "white space character" in this context? It seems that one can choose from the definition in XML 1.0, XML 1.1, Unicode or one of the definitions in HTML 4.01 and further differentiate between white-space characters in the source code and white-space as character references and even further differentiate between the white-space pre and post attribute value normalization as defined in the XML Recommendations. Could you, in order to remove this confusion, please provide an exact algorithm that software could use to determine whether a document meets that constraint? Could you also please clarify what the exact difference between HTML and XHTML is in this regard? This seems to be a more general consideration for either language and thus misplaced in Appendix C. regards.
PROBLEM ID: 703
STATE: Needs Approval
EDIT: N/A
RESOLUTION: None
USER POSITION: None
NOTES:
Fixed DTDs in XHTML 1.0 Second Edition so that they now include a new PE "misc.inline" and ensure that PE is included in the content model for the "pre" element.
ORIGINAL MESSAGE:
Date: Wed, 10 Jul 2002 10:34:39 +0900 (JST) From: jamie@cs.dal.ca (J. Blustein) From: jamie@cs.dal.ca (J. Blustein) To: www-html-editor@w3.org Cc: gerald@w3.org Subject: HTML 4.01 no <ins> in <pre>? Date: Wed, 10 Jul 2002 10:21:40 +0900 (JST) Message-Id: <20020710.102140.104026748.mimasa@w3.org> I'm not sure if I've found a mistake or just something that I don't understand the reason for. I am using XHTML 1.0 and referring to the HTML 4.01 spec for guidance. I get an error from the validator at W3C but it sounds to me (from the spec, not the DTD) that I am correct. Here is what I am trying to represent in markup: I am updating an errata list for a textbook that contains pseudocode. Because the formatting of the pseudocode is significant I'm using <pre> to maintain the formatting and because I am showing insertions I'm using <ins>. But the validator says something is wrong A small but complete example is enclosed at the end of this e-mail. Here is part of the example I'm having trouble with: <dd> The event part (above the line) should read: <pre class="code"> rdt_rcv(rcv_pkt)<br /> && notcorrupt(rcvpkt)<br /> <ins>getacknum(rcvpkt)>=base</ins> </pre> </dd> The validator says: > Below are the results of checking this document for XML > well-formedness and validity. > > Line 120, column 12: > > <ins>getacknum(rcvpkt)>=base</ins> > ^ > > Error: element "ins" not allowed here; possible cause is an > inline element containing a block-level element When I remove the <ins> (and </ins>) then the document is reported as valid. But when they are present inside <pre> (and </pre>) the document is reported as invalid. It seems strange to me that <dd> The event part (above the line) should read: <blockquote> <p> <code> rdt_rcv(rcv_pkt)<br /> && notcorrupt(rcvpkt)<br /> <ins>getacknum(rcvpkt)>=base</ins> </code> </p> </blockquote> </dd> is valid because I don't think of it as having the same semantics. But it passes a validation check. Please tell me if there really is a problem with the DTD or validator. Otherwise I will appreciate it if you would explain to me why <ins> is not allowed inside <pre> (or <blockquote>). Much obliged, -- Jamie Blustein <jamie@cs.dal.ca> - - - 8< - - - [enclosure begins] - - - 8< - - - <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <title> Misprint Corrections for Kurose & Ross </title> </head> <body> <p>[Blah blah blah]</p> <dl> <dt>Page 198, Figure 3.19, left-hand side</dt> <dd> The window should not be advanced for just any non-corrupted <abbr title="acknowledgment packet">ACK</abbr>. The window should only advance if the <abbr>ACK</abbr> is for a packet that is in the current window, <abbr title="that is">i.e.</abbr> if <code>(acknum(rcvpkt) == base) || (acknum(rcvpkt) > base)</code>. If the <abbr>ACK</abbr> is for a packet with sequence number less than <code>base</code> then the packet should be ignored. </dd> <dd> The event part (above the line) should read: <pre class="code"> rdt_rcv(rcv_pkt)<br /> && notcorrupt(rcvpkt)<br /> <ins>getacknum(rcvpkt)>=base</ins> </pre> </dd> </dl> <p>[Blah blah blah]</p> </body> </html> - - - >8 - - - [enclosure ends] - - - >8 - - -
FOLLOWUP 1:
Date: Wed, 10 Jul 2002 10:33:03 -0500 From: "Shane P. McCarron" <shane@aptest.com> Jamie, It turns out that you have uncovered a problem in the DTDs for XHTML 1.0. Basically, the ins and del (and script) elements should be included in the content model for the "pre" element, and they are not. Along the way, we also noticed that noscript had gotten incorrectly bundled into this group, so it was being included in some places we had not meant it to be. We are planning to address both problems in an update to XHTML 1.0 scheduled for release any day now. Thanks for your comments! -- Shane P. McCarron Phone: +1 763 786-8160 x120 Managing Director Fax: +1 763 786-8180 ApTest Minnesota Inet: shane@aptest.com
FOLLOWUP 2:
Date: Tue, 09 Jul 2002 19:49:32 -0700 From: Tantek =?ISO-8859-1?B?xw==?=elik <tantek@cs.stanford.edu> On 7/9/02 6:43 PM, "jamie@cs.dal.ca" <jamie@cs.dal.ca> wrote: > > From: jamie@cs.dal.ca (J. Blustein) > To: www-html-editor@w3.org > Cc: gerald@w3.org > Subject: HTML 4.01 no <ins> in <pre>? > Date: Wed, 10 Jul 2002 10:21:40 +0900 (JST) > Message-Id: <20020710.102140.104026748.mimasa@w3.org> > > I'm not sure if I've found a mistake or just something that I don't > understand the reason for. I am using XHTML 1.0 and referring to the > HTML 4.01 spec for guidance. I get an error from the validator at W3C > but it sounds to me (from the spec, not the DTD) that I am correct. > > Here is what I am trying to represent in markup: I am updating an > errata list for a textbook that contains pseudocode. Because the > formatting of the pseudocode is significant I'm using <pre> to > maintain the formatting and because I am showing insertions I'm using > <ins>. But the validator says something is wrong > > A small but complete example is enclosed at the end of this e-mail. > Here is part of the example I'm having trouble with: > > <dd> > The event part (above the line) should read: > <pre class="code"> The fact that XHTML 1.0 has a <code> element and that you are using class by the same name should indicate that markup could be improved. You demonstrate this (for the most part) in your second example. It is poor form to use HTML (and markup in general for that matter) for primarily presentational purposes. The reasons are numerous not least of which is accessibility. Better is to mark up content semantically using HTML (or whatever appropriate semantic markup language), and then use style sheets to suggest a default presentation for the content. > rdt_rcv(rcv_pkt)<br /> > && notcorrupt(rcvpkt)<br /> > <ins>getacknum(rcvpkt)>=base</ins> > </pre> > </dd> > > The validator says: > >> Below are the results of checking this document for XML >> well-formedness and validity. >> >> Line 120, column 12: >> >> <ins>getacknum(rcvpkt)>=base</ins> >> ^ >> >> Error: element "ins" not allowed here; possible cause is an >> inline element containing a block-level element > > > When I remove the <ins> (and </ins>) then the document is reported > as valid. But when they are present inside <pre> (and </pre>) the > document is reported as invalid. > > It seems strange to me that > > <dd> > The event part (above the line) should read: > <blockquote> > <p> > <code> > rdt_rcv(rcv_pkt)<br /> > && notcorrupt(rcvpkt)<br /> > <ins>getacknum(rcvpkt)>=base</ins> > </code> > </p> > </blockquote> > </dd> > > is valid because I don't think of it as having the same semantics. It doesn't have the same semantics. It has much more well defined, and for that matter, _better_ semantics. Now all you need to do is add the following rules to a style sheet for the document: code { display:block; white-space:pre } code br { display:none } and the <code> element will display just as your <pre> did in your first example. In fact, you really don't need the <br /> elements either, since "white-space:pre" will properly preserve and present the carriage returns (as well as the rest of the white space) in your <code> element. > But it passes a validation check. > > Please tell me if there really is a problem with the DTD or > validator. Otherwise I will appreciate it if you would explain to me > why <ins> is not allowed inside <pre> (or <blockquote>). That being said, I do agree that <ins> and <del> are quite difficult to use in HTML4 (and XHTML for that matter) due to bizarre and inexplicable restrictions on their use. IMHO they should be valid pretty much anywhere, because you can insert/delete content anywhere from a document and should be able to mark it up as such. Hope that helps, Tantek > > Much obliged, > -- > Jamie Blustein <jamie@cs.dal.ca> > > > - - - 8< - - - [enclosure begins] - - - 8< - - - > <?xml version="1.0" encoding="UTF-8"?> > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> > <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> > <head> > <title> > Misprint Corrections for Kurose & Ross > </title> > </head> > <body> > <p>[Blah blah blah]</p> > <dl> > <dt>Page 198, Figure 3.19, left-hand side</dt> > <dd> > The window should not be advanced for just any non-corrupted <abbr > title="acknowledgment packet">ACK</abbr>. The window should only > advance if the <abbr>ACK</abbr> is for a packet that is in the > current window, <abbr title="that is">i.e.</abbr> if > <code>(acknum(rcvpkt) == base) || (acknum(rcvpkt) > > base)</code>. If the <abbr>ACK</abbr> is for a packet with > sequence number less than <code>base</code> then the packet should be > ignored. > </dd> > <dd> > The event part (above the line) should read: > <pre class="code"> > rdt_rcv(rcv_pkt)<br /> > && notcorrupt(rcvpkt)<br /> > <ins>getacknum(rcvpkt)>=base</ins> > </pre> > </dd> > </dl> > <p>[Blah blah blah]</p> > </body> > </html> > - - - >8 - - - [enclosure ends] - - - >8 - - - > > > > >
PROBLEM ID: 8419
STATE: Needs Approval
EDIT: N/A
RESOLUTION: None
USER POSITION: None
NOTES:
This appendix was removed from the Recommendation. However, this appendix NEVER made any normative requirements for anything, so it would not have done so.
ORIGINAL MESSAGE:
Date: Mon, 12 Jul 2004 14:33:41 +0900 (JST) From: Bjoern Hoehrmann <derhoermi@gmx.net> From: Bjoern Hoehrmann <derhoermi@gmx.net> To: www-html-editor@w3.org Subject: XHTML1: Clarification of Appendix C.9 Date: Mon, 12 Jul 2004 06:14:15 +0200 Message-ID: <418e1016.1817854276@smtp.bjoern.hoehrmann.de> X-Archived-At: http://www.w3.org/mid/418e1016.1817854276@smtp.bjoern.hoehrmann.de Dear HTML Working Group, Appendix C.9 of the XHTML 1.0 Second Edition Recommendation states: [...] If this is not possible, a document that wants to set its character encoding explicitly must include both the XML declaration an encoding declaration and a meta http-equiv statement (e.g., <meta http-equiv="Content-type" content="text/html; charset=EUC-JP" />). In XHTML-conforming user agents, the value of the encoding declaration of the XML declaration takes precedence. [...] The meaning of the last sentence is not clear to me. You have, as far as I can see, refrained to make any normative statements on how user agents are expected to process XHTML documents delivered as text/html, yet the above statement suggests such behavioral expectations. Could you please clarify to what situation the above informative statement applies? This further seems to be erroneous, as far as I can tell, XHTML user agents are expected to ignore such meta http-equiv statements entirely, so, what information has less precedence than the encoding declaration? The only information I can reasonably think of would be XML's defaulting rules. But referring to precedence rules would then be rather confusing. Also, there are a number of other things that take precedence over the encoding declaration, like the byte order mark, mime type defaulting rules or general higher level encoding information. So, what does this mean exactly? The section further states [...] Note: be aware that if a document must include the character encoding declaration in a meta http-equiv statement, that document may always be interpreted by HTTP servers and/or user agents as being of the internet media type defined in that statement. [...] I do not quite understand where HTML 4.01 allows HTML 4.01 user agents to do such a thing. My understanding is that in order to apply such semantics to such an element, the user agent must already have chosen to consider the document HTML or XHTML, e.g. because the HTTP server responded with a corresponding Content-Type header which is as far as I understand authoritative metadata which clients must not ignore, at least not without the consent of the user. So do you mean here that XHTML user agents may consider an XHTML document delivered with an XHTML media type containing e.g. <meta http-equiv="Content-type" content="text/html" /> text/html and thus e.g. show the > as textual content as required by the HTML 4.01 Recommendation? That seems like a very bad idea, but I am also not entirely certain where you state this (or prohibe this). The section continues: [...] If a document is to be served as multiple media types, the HTTP server must be used to set the encoding of the document. [...] I am not sure what you mean here exactly. It seems that you mean that if a document is delivered e.g. as outlined in http://www.w3.org/2003/01/xhtml-mimetype/content-negotiation that regardless of the MIME Type, the Content-Type header must have a charset parameter. That however makes not all that much sense, could you please clarify what you had in mind here exactly? regards.
PROBLEM ID: 6232
STATE: Needs Approval
EDIT: N/A
RESOLUTION: Reject
USER POSITION: None
NOTES:
These changes were overcome by events, since the contents of Appendix C were removed. However, many of the points raised in this comment are now reflected in the XHTML Media Types document.
ORIGINAL MESSAGE:
Date: Wed, 15 Jan 2003 16:25:05 +0900 (JST) From: Ian Hickson <ian@hixie.ch> From: Ian Hickson <ian@hixie.ch> To: www-html-editor@w3.org Subject: XHTML1: Suggested improvements to Appendix C Date: Wed, 15 Jan 2003 00:24:51 +0000 (GMT) Message-ID: <Pine.LNX.4.21.0301140809510.31777-100000@dhalsim.dreamhost.com> X-Archived-At: http://www.w3.org/mid/Pine.LNX.4.21.0301140809510.31777-100000@dhalsim.dreamhost.com Hi, I believe the XHTML1 spec is wrong to allow XHTML to be sent as text/html. While in theory XHTML1 can be made compatible with Tag Soup UAs while still being valid and correct, the reality is that few authors are able to do so. I recommend that the working group consider releasing another edition of XHTML1, that removes the ability to send XHTML as text/html. However, if the working group does not wish to do this, I believe the following changes need to be made to appendix C: 1. Make the appendix normative. 2. Change "on existing HTML user agents" to "on legacy Tag Soup user agents" or some similar wording that admits that XHTML cannot be made compatible with HTML, only with the error handling code of existing user agents. 3. Change the suggestion that XML declarations should be omitted to a more strongly worded recommendation, as XML PIs trigger quirks mode in WinIE6 and are displayed verbatim on PocketIE. 4. Remove one of the duplicated sentences in "C.4. Embedded Style Sheets and Scripts", and require that script and style blocks be neither "commented out" (with <!--/-->), nor enclosed in CDATA blocks, nor include any entities. 5. Add a section requiring that <tbody> not be omitted. 6. Change the "C.11. Document Object Model and XHTML" section slightly so that it requires that scripts be aware that when treated as XML, they should use the namespace-aware Core APIs, and when treated as HTML, it should use the DOM1 Core APIs; similarly, that all script compare tagNames and attributes by lowercasing them first. 7. Require that stylesheets style the HTML element rather than the BODY element. 8. Documents should not use the <meta http-equiv="Content-Type"> element. (Actually this applies to all XHTML.) 9. There should be no use of namespaces other than the XHTML one. (This is true of all valid XHTML elements anyway.) 10. There should be no XML Stylesheet PIs anywhere. (See 3) Overall, I think the language should be made more strict ("MUST"s rather than "SHOULD" or "MAY"). Stricter requirements are a great help when evangelising the use of correct markup. Cheers, -- Ian Hickson )\._.,--....,'``. fL "meow" /, _.. \ _\ ;`._ ,. http://index.hixie.ch/ `._.-(,_..'--(,_..'`-.;.'
FOLLOWUP 1:
Date: Wed, 29 Jan 2003 15:39:59 +0900 (JST) From: Satoshi ISHIKAWA <satoshii@math.oheya.to> From: Satoshi ISHIKAWA <satoshii@math.oheya.to> To: <www-html-editor@w3.org> Subject: Re: XHTML1: Suggested improvements to Appendix C Date: Wed, 29 Jan 2003 15:24:52 +0900 Message-ID: <BA5DA2C4.DEF%satoshii@math.oheya.to> X-Archived-At: http://www.w3.org/mid/BA5DA2C4.DEF%satoshii@math.oheya.to Hi, I'll add the 11th item to your list: 11. Colons (:) should not be used in "id" attribute because of namespace-validity. XHTML 1.0 SE Appendix C.8 [1]: > When defining fragment identifiers to be > backward-compatible, only strings matching > the pattern [A-Za-z][A-Za-z0-9:_.-]* should be used. Namespace in XML errata [2]: > It follows that in a namespace-valid document > > * No attributes with a declared type of ID, IDREF(S), > ENTITY(IES) or NOTATION contain any colons. [1] http://www.w3.org/TR/2002/REC-xhtml1-20020801/#C_8 [2] http://www.w3.org/XML/xml-names-19990114-errata#NE08 Regards, -- Satoshi ISHIKAWA http://math.oheya.to/markup/
FOLLOWUP 2:
Date: Wed, 15 Jan 2003 13:50:54 +0000 (GMT) From: Ian Hickson <ian@hixie.ch> On Wed, 15 Jan 2003, Steven Pemberton wrote: > > > > I believe the XHTML1 spec is wrong to allow XHTML to be sent as > > text/html. While in theory XHTML1 can be made compatible with Tag > > Soup UAs while still being valid and correct, the reality is that > > few authors are able to do so. > > It doesn't allow it. The text/html RFC is what defines what may be > sent with text/html. True. Maybe that RFC should be changed to not allow it then. :-) > All XHTML 1 does is observe that if you follow appendix C existing > user agents process documents fairly reasonably. It doesn't > guarantee compatibility and it is not normative. > > > 1. Make the appendix normative. > > How could we do that? We can normatively have an effect on exiting > user agents. The appendix is a set of guidelines for authors, not user agents. By making the appendix normative, you require that XHTML 1.0 documents sent as text/html comply to the letter of the appendix, rather than just the spirit of the appendix. > > 5. Add a section requiring that <tbody> not be omitted. > > This does indeed change the DOM tree, but you can still > programatically check which you have, so there is no reason to > enforce it. The reason to enforce it is that authors don't check, and it is easier to simply require it than to require that authors make allowances for <tbody>'s dual existence. > > 7. Require that stylesheets style the HTML element rather than the > > BODY element. > > Why? CSS requires HTML documents to style the body, not the html element. In text/html, the BODY element background covers the canvas, in text/xml, it only covers the <body> element. To style the canvas background in XML-based languages, you have to style the root element. > > 8. Documents should not use the <meta http-equiv="Content-Type"> > > element. (Actually this applies to all XHTML.) > > Agree. I noticed, after writing that e-mail, that XHTML2 still has the http-equiv attribute. May I suggest that it be removed? In practice, few, if any, servers process <meta> elements, and those that do provide much more convenient ways of affecting the headers. UAs, though, sniff for <meta> elements in a very unpredictable way. It would be nice if XHTML2 put an end to the <meta http-equiv> problem. As far as I know only two headers are commonly used with this element, "Content-Type" and "Refresh". The former is better handled using the XML declaration, the second is IMHO better handled using HTTP redirects or XLink/HLink. Cheers, -- Ian Hickson )\._.,--....,'``. fL "meow" /, _.. \ _\ ;`._ ,. http://index.hixie.ch/ `._.-(,_..'--(,_..'`-.;.'
FOLLOWUP 3:
From: "Steven Pemberton" <steven.pemberton@cwi.nl> Date: Wed, 15 Jan 2003 13:55:34 +0100 From: <ian@hixie.ch> > I believe the XHTML1 spec is wrong to allow XHTML to be sent as > text/html. While in theory XHTML1 can be made compatible with Tag > Soup > UAs while still being valid and correct, the reality is that few > authors are able to do so. It doesn't allow it. The text/html RFC is what defines what may be sent with text/html. All XHTML 1 does is observe that if you follow appendix C existing user agents process documents fairly reasonably. It doesn't guarantee compatibility and it is not normative. > 1. Make the appendix normative. How could we do that? We can normatively have an effect on exiting user agents. > 5. Add a section requiring that <tbody> not be omitted. This does indeed change the DOM tree, but you can still programatically check which you have, so there is no reason to enforce it. > 7. Require that stylesheets style the HTML element rather than the > BODY element. Why? CSS requires HTML documents to style the body, not the html element. > 8. Documents should not use the <meta http-equiv="Content-Type"> > element. (Actually this applies to all XHTML.) Agree. Best wishes, Steven Pemberton
PROBLEM ID: 8420
STATE: Needs Approval
EDIT: N/A
RESOLUTION: None
USER POSITION: None
NOTES:
This appendix was removed from the recommendation.
ORIGINAL MESSAGE:
Date: Mon, 12 Jul 2004 14:36:05 +0900 (JST) From: Bjoern Hoehrmann <derhoermi@gmx.net> From: Bjoern Hoehrmann <derhoermi@gmx.net> To: www-html-editor@w3.org Subject: XHTML1: Implementability of Appendix C Date: Mon, 12 Jul 2004 06:14:18 +0200 Message-ID: <418f1019.1817856930@smtp.bjoern.hoehrmann.de> X-Archived-At: http://www.w3.org/mid/418f1019.1817856930@smtp.bjoern.ho= ehrmann.de Dear HTML Working Group, RFC 2854 states in section 2, [...] The text/html media type is now defined by W3C Recommendations; the latest published version is [HTML401]. In addition, [XHTML1] defines a profile of use of XHTML which is compatible with HTML 4.01 and whic= h may also be labeled as text/html. [...] Section 5.1 of the XHTML 1.0 Second Edition Recommendation states: [...] XHTML Documents which follow the guidelines set forth in Appendix C, "HTML Compatibility Guidelines" may be labeled with the Internet Medi= a Type "text/html" [RFC2854], as they are compatible with most HTML browsers. [...] Section 3.1 of the XHTML Media Types Note states: [...] [XHTML1], Appendix C "HTML Compatibility Guidelines" summarizes desig= n guidelines for authors who wish their XHTML documents to render on existing HTML user agents. The use of 'text/html' for XHTML SHOULD be= limited for the purpose of rendering on existing HTML user agents, an= d SHOULD be limited to [XHTML1] documents which follow the HTML Compatibility Guidelines. [...] So it seems crystal clear to me that this Appendix C of the XHTML 1.0 Second Edition Recommendation defines clear conformance criteria for data objects which I would expect to be reliably machine-testable. It however turns out that a number of sections of this appendix does not deal with such conformance criteria, starting with Appendix C.1 [...] Be aware that processing instructions are rendered on some user agents. Also, some user agents interpret the XML declaration to mean that the document is unrecognized XML rather than HTML, and therefore= may not render the document as expected. For compatibility with these= types of legacy browsers, you may want to avoid using processing instructions and XML declarations. Remember, however, that when the XML declaration is not included in a document, the document can only use the default character encodings UTF-8 or UTF-16. [...] These appear to be at best criteria for authors, i.e., only authors aware of this problem may deliver XHTML documents to legacy user agents= .= So it seems I might misunderstand the purpose of the Appendix and all the documents that refer to it. Which seems a bit odd. Ignoring the sections that seem misplaced, the remaining sections are often not clea= r about what the actual requirements are, or what the exact requirement level is. Some sections use RFC 2119 keywords such as SHOULD and MUST, some use loose imperative statements such as "avoid". It is not clear to me how to map these statements into a precise error report, i.e., what maps into clear errors, warnings or something looser such as an informational hint. It also seems inconsistent that you reference the appendix as defining a profile, and yet state that the appendix is informative. It also seems that many requirements are missing from this "profile", for example XHTML documents that use an internal subset will most likel= y break in a legacy user agent as it would show the end delimiter ]> as textual content, rather than hide it as I think would be required for both compliant HTML and XHTML user agents. So I am not even sure what the actual scope of the Appendix is to correct such flaws, if there is actually anything wrong with it omitting such issues, myself. So it seems close to impossible to write a good software tool that checks whether a data object meets the constraints "defined" in that "profile". Such a tools is however an often requested feature for the W3C MarkUp Validator, as it, at least apparently, concerns the compliance of documents. There is even special interest for authors who wish to make their content accessible. One problem here that gets more common every day is that documents are created using XML tools that create things like <a name=3D"x" id=3D"x" /> for which visual inspection does not necessarily reveal any difference,= but A11y tools that rely on the internal document object model representation of the document will likely note it as it would likely break the document to some extend, see e.g. the Usenet discussion aroun= d =A0 http://groups.google.com/groups?selm=3D7n13605024figsokutl2qdsncpdf= bk2g3a@4ax.com where in =A0 http://groups.google.com/groups?selm=3D40649cb1.16491112@news.indiv= idual.net we were able to identify the actual issue, after quite some effort that= was necessary due to the lack of a tool that properly checks for such problems. I do not want to rely on wild guesses to write such a tool properly and later waste time to fix problems I introduced for this reasons, and take the blame for it once you clarify the unclear parts. Hence I chose for the moment to wait until you clarify the issues I hav= e raised in the XHTML 1.0 Errata and a later XHTML 1.0 Third Edition. I hope this will happen soon. regards.
FOLLOWUP 1:
From: "Steven Pemberton" <steven.pemberton@cwi.nl> Date: Wed, 21 Jul 2004 17:54:38 +0200 > From: Bjoern Hoehrmann <derhoermi@gmx.net> > So it seems crystal clear to me that this Appendix C of the XHTML 1.0 > Second Edition Recommendation defines clear conformance criteria for > data objects which I would expect to be reliably machine-testable. Let us be absolutely clear about this. At the top of Appendix C it states "This appendix is informative." This means that it introduces no conformance criteria. XHTML 1.0 is an XML application. So, for instance <br/> and <br /> are both completely acceptable XHTML 1.0 constructs, as are <a/> and <a><a/>. Strictly speaking, XHTML 1.0 is not suitable for legacy HTML user agents. But what Appendix C says is: it has been noted that if you do the following things, that some valid XHTML 1.0 documents can be made to perform identically on existing HTML user agents. It is no more than a series of observations. There are probably other observations that could be added. Now I realise this makes life tough for the writer of a validator, since people would like to know if their documents will 'work' with existing user agents. However, <br /> is incorrect HTML, so an HTML validator should strictly speaking report it as an error. It just happens to work with existing browsers. Therefore, we have no intention of making appendix C normative, because it would defeat the object of the appendix. I hope this helps you interpret Appendix C. So what people need is not a 'validator' in the strict sense of the word, but more a 'lint' like tool that reports things that may not work. Your example of "<a />" causing a problem is a good example. In XHTML "<a/>" and "<a></a>" are (pretty much) equivalent. In legacy HTML browsers "<a />" will be seen as a start tag, with some ignored junk at the end, and the browser will expect to see the end tag somewhere, which it won't find. That is why the observation "C.3. Element Minimization and Empty Element Content" is there, to warn people about it. > So it seems close to impossible to write a good software tool that > checks whether a data object meets the constraints "defined" in that > "profile". So as you see, there are no constraints defined in Appendix C. Just observations. A lint tool would then have to warn about things like "<a />", but it is not incorrect XHTML 1.0, it will just not work compatibly in HTML browsers. Hope this helps. Best wishes, Steven Pemberton
FOLLOWUP 2:
From: Bjoern Hoehrmann <derhoermi@gmx.net> Date: Fri, 23 Jul 2004 00:59:40 +0200 * Steven Pemberton wrote: >But what Appendix C says is: it has been noted that if you do the following >things, that some valid XHTML 1.0 documents can be made to perform >identically on existing HTML user agents. It is no more than a series of >observations. There are probably other observations that could be added. http://www.w3.org/TR/2002/NOTE-xhtml-media-types-20020801 differentiates between XHTML 1.0 documents that are "HTML-compatible" and other XHTML documents when discussing best current practise for using text/html. It refers to the "HTML Compatibility Guidelines" which are Appendix C of the XHTML 1.0 Second Edition Recommendation, for what the Note considers "HTML-compatible". Appendix C is thus relevant in order to tell whether specific practise is consistent with best current practise. Do you disagree with that conclusion? If you disagree, could you please explain why it would be unreasonable to come to that conclusion? If you agree, could you please explain how that is consistent with your statement above? >Now I realise this makes life tough for the writer of a validator, since >people would like to know if their documents will 'work' with existing user >agents. Users of a "Validator" are primarily concerned about whether their stuff is consistent with the relevant standards and best current practise. It is certainly useful to get further information about compatibility, but users do not commonly expect such functionality from a Validator. >However, <br /> is incorrect HTML, so an HTML validator should >strictly speaking report it as an error. It just happens to work with >existing browsers. This is very unhelpful. If the HTML Working Group thinks the W3C MarkUp Validator should report an error for <br /> in text/html documents, then you should communicate that to the W3C Validator Team through one of the relevant mailing lists or the W3C Staff involved. I would further like to direct the attention of the HTML Working Group to section 20.1 of the HTML 4.01 Recommendation which makes <br /> legal for HTML documents; this is explained in more detail in Appendix B.3.7 of the same specification. I invite you to join the www-validator@w3.org mailing list, where the W3C Validator Team and other volunteers spend considerable time and energy to explain such issues to authors, most of the time because these authors confuse HTML and XHTML syntax, because they consider XHTML syntax to be HTML-compatible... The HTML Working Group can easily disallow <br /> for HTML documents by changing section 20.1 as suggested in http://lists.w3.org/Archives/Public/www-html-editor/2002OctDec/0023 I think Terje is still waiting for a response to his comment... Anyway, a better example would have been whether <p title=foo>...</p> is in- correct or not, as that depends on whether the document is considered HTML or XHTML; the HTML Working Group unfortunately refused any guidance on how to determine that, resulting in the W3C Validator Team wasting resources on discussions on what the "right" or "best" way to do that would be. >I hope this helps you interpret Appendix C. I am looking forward to your responses to my other related comments, as those point out a number of inconsistencies with what you wrote about the intent of Appendix C, at least as far as I can see. regards.
PROBLEM ID: 8898
STATE: Approved and Implemented
EDIT: N/A
RESOLUTION: Accept
USER POSITION: None
NOTES:
a description of the onmouseover was added to the DTDs. But yes, these comments are non-normative.
ORIGINAL MESSAGE:
Date: Wed, 15 Dec 2004 19:34:32 +0900 (JST) From: TANAKA Satoko <sako-t@aprico.fujitsu.com> From: TANAKA Satoko <sako-t@aprico.fujitsu.com> To: www-html-editor@w3.org Cc: sako-t@aprico.fujitsu.com Subject: Difference of UI events' attributes in XHTML 1.0 Strict DTD Date: Mon, 29 Nov 2004 20:25:15 +0900 Message-Id: <200411291123.iATBNtqK020325@aprico.aprico.fujitsu.com> X-Archived-At: http://www.w3.org/mid/200411291123.iATBNtqK020325@aprico.aprico.fujitsu.com Dear Mr/Ms; I have a question about XHTML 1.0 Strict/Transitional DTD. The description of UI events' attributes in XHTML 1.0 Strict DTD is different from HTML 4.01. Could you let me know why they are different? In XHTML 1.0 Strict DTD http://www.w3.org/TR/xhtml1/dtds.html#a_dtd_XHTML-1.0-Strict ------------------------------------------------------- <!-- attributes for common UI events onclick a pointer button was clicked ondblclick a pointer button was double clicked onmousedown a pointer button was pressed down onmouseup a pointer button was released onmousemove a pointer was moved onto the element onmouseout a pointer was moved away from the element onkeypress a key was pressed and released onkeydown a key was pressed down onkeyup a key was released --> <!ENTITY % events "onclick %Script; #IMPLIED ondblclick %Script; #IMPLIED onmousedown %Script; #IMPLIED onmouseup %Script; #IMPLIED onmouseover %Script; #IMPLIED onmousemove %Script; #IMPLIED onmouseout %Script; #IMPLIED onkeypress %Script; #IMPLIED onkeydown %Script; #IMPLIED onkeyup %Script; #IMPLIED" > ------------------------------------------------------- In the XHTML 1.0 Strict DTD, there is no description of "onmouseover". Also the description of "onmousemove" is different from HTML 4.01's. ======================================================= In XHTML 1.0 Strict DTD http://www.w3.org/TR/xhtml1/dtds.html#a_dtd_XHTML-1.0-Strict ------------------------------------------------------- onmousemove a pointer was moved onto the element *There is no description of "onmouseover". ------------------------------------------------------- ======================================================= In HTML 4.01 http://www.w3.org/TR/html401/interact/scripts.html#adef-onmouseover ------------------------------------------------------- onmouseover = script [CT] The onmouseover event occurs when the pointing device is moved onto an element. This attribute may be used with most elements. onmousemove = script [CT] The onmousemove event occurs when the pointing device is moved while it is over an element. This attribute may be used with most elements. ------------------------------------------------------- I'll be very pleased, if you answer my question. Thanks, Satoko Tanaka
FOLLOWUP 1:
Date: Wed, 19 Jan 2005 14:24:52 +0100 From: "Steven Pemberton" <steven.pemberton@cwi.nl> Many thanks for your report. Comments in the DTD are non-normative. You should use the HTML 4.01 specification as the definition of the meaning of all elements and attributes. Best wishes, Steven Pemberton Chair, HTML Working Group On Wed, 15 Dec 2004 04:34:43 -0600 (CST), <sako-t@aprico.fujitsu.com> wrote: > > From: TANAKA Satoko <sako-t@aprico.fujitsu.com> > To: www-html-editor@w3.org > Cc: sako-t@aprico.fujitsu.com > Subject: Difference of UI events' attributes in XHTML 1.0 Strict DTD > Date: Mon, 29 Nov 2004 20:25:15 +0900 > Message-Id: <200411291123.iATBNtqK020325@aprico.aprico.fujitsu.com> > X-Archived-At: > http://www.w3.org/mid/200411291123.iATBNtqK020325@aprico.aprico.fujitsu.com > > Dear Mr/Ms; > > I have a question about XHTML 1.0 Strict/Transitional DTD. > > The description of UI events' attributes in XHTML 1.0 Strict DTD is > different from HTML 4.01. > Could you let me know why they are different? > > In XHTML 1.0 Strict DTD > http://www.w3.org/TR/xhtml1/dtds.html#a_dtd_XHTML-1.0-Strict > ------------------------------------------------------- > <!-- attributes for common UI events > onclick a pointer button was clicked > ondblclick a pointer button was double clicked > onmousedown a pointer button was pressed down > onmouseup a pointer button was released > onmousemove a pointer was moved onto the element > onmouseout a pointer was moved away from the element > onkeypress a key was pressed and released > onkeydown a key was pressed down > onkeyup a key was released > --> > <!ENTITY % events > "onclick %Script; #IMPLIED > ondblclick %Script; #IMPLIED > onmousedown %Script; #IMPLIED > onmouseup %Script; #IMPLIED > onmouseover %Script; #IMPLIED > onmousemove %Script; #IMPLIED > onmouseout %Script; #IMPLIED > onkeypress %Script; #IMPLIED > onkeydown %Script; #IMPLIED > onkeyup %Script; #IMPLIED" > > > ------------------------------------------------------- > > In the XHTML 1.0 Strict DTD, there is no description of > "onmouseover". Also the description of "onmousemove" is different > from HTML 4.01's. > > ======================================================= > In XHTML 1.0 Strict DTD > http://www.w3.org/TR/xhtml1/dtds.html#a_dtd_XHTML-1.0-Strict > ------------------------------------------------------- > onmousemove a pointer was moved onto the element > *There is no description of "onmouseover". > ------------------------------------------------------- > > ======================================================= > In HTML 4.01 > http://www.w3.org/TR/html401/interact/scripts.html#adef-onmouseover > ------------------------------------------------------- > onmouseover = script [CT] > The onmouseover event occurs when the pointing device is moved onto an > element. This attribute may be used with most elements. > > onmousemove = script [CT] > The onmousemove event occurs when the pointing device is moved while it > is over an element. This attribute may be used with most elements. > ------------------------------------------------------- > > I'll be very pleased, if you answer my question. > > Thanks, > > Satoko Tanaka > > >
PROBLEM ID: 8836
STATE: Approved
EDIT: N/A
RESOLUTION: Modify and Accept
USER POSITION: None
NOTES:
Removed the isindex guidance from the xhtml media types document. Removed the whole appendix from this recommendation.
ORIGINAL MESSAGE:
Date: Sat, 20 Nov 2004 12:36:27 +0900 (JST) From: Bjoern Hoehrmann <derhoermi@gmx.net> From: Bjoern Hoehrmann <derhoermi@gmx.net> To: www-html-editor@w3.org Subject: XHTML1: Appendix C.6 seems misplaced Date: Sat, 20 Nov 2004 02:35:13 +0100 Message-ID: <41a59d20.15234328@smtp.bjoern.hoehrmann.de> X-Archived-At: http://www.w3.org/mid/41a59d20.15234328@smtp.bjoern.hoehrmann.de Dear HyperText Markup Language Working Group, Appendix C.6 of the XHTML 1.0 Second Edition Recommendation seems to be misplaced in Appendix C as it does not seem to discuss guidelines for XHTML authors who wish to deliver XHTML documents to legacy user agents, but rather notes a difference from HTML 4.01 or a limitation of XML DTDs as HTML 4.01 did not allow more than one isindex element in the head element (except in <head><object><isindex> or similar). The item should be removed and a new section should be added to state that in XHTML 1.0 documents the <head> element must not have more than one <isindex> child. regards.
FOLLOWUP 1:
From: Bjoern Hoehrmann <derhoermi@gmx.net> Date: Mon, 22 Nov 2004 14:17:50 +0100 * Steven Pemberton wrote: >> Appendix C.6 of the XHTML 1.0 Second Edition Recommendation seems to >> be misplaced in Appendix C as it does not seem to discuss guidelines for >> XHTML authors who wish to deliver XHTML documents to legacy user agents, >> but rather notes a difference from HTML 4.01 or a limitation of XML DTDs >> as HTML 4.01 did not allow more than one isindex element in the head >> element (except in <head><object><isindex> or similar). The item should >> be removed and a new section should be added to state that in XHTML 1.0 >> documents the <head> element must not have more than one <isindex> >> child. > >HTML4 says there must be at most one <isindex> in the head; XHTML1 says >there can be more than one; C.6 is an informative section that says if you >want interoperability, only include one <isindex> in the head, but you're >better off not using it since it is deprecated. XHTML 1.0 does not say it allows that, only the DTDs allow it and the DTDs allow many things that are not allowed in HTML 4.01, for example <p><ins><div><table>...</table></div></ins></p> is not allowed in HTML 4.01 even though both the HTML 4.01 DTDs and the XHTML 1.0 DTDs allow it. Are you saying that XHTML 1.0 does not inherit such conformance criteria from HTML 4.01 and that everything the XHTML 1.0 DTDs allow is actually allowed in e.g. strictly conforming XHTML 1.0 documents? If not, how do you arrive at the conclusion that XHTML 1.0 actually allows multiple isindex elements as head children?
FOLLOWUP 2:
Date: Mon, 22 Nov 2004 10:29:28 +0100 From: "Steven Pemberton" <steven.pemberton@cwi.nl> > Appendix C.6 of the XHTML 1.0 Second Edition Recommendation seems to > be misplaced in Appendix C as it does not seem to discuss guidelines for > XHTML authors who wish to deliver XHTML documents to legacy user agents, > but rather notes a difference from HTML 4.01 or a limitation of XML DTDs > as HTML 4.01 did not allow more than one isindex element in the head > element (except in <head><object><isindex> or similar). The item should > be removed and a new section should be added to state that in XHTML 1.0 > documents the <head> element must not have more than one <isindex> > child. HTML4 says there must be at most one <isindex> in the head; XHTML1 says there can be more than one; C.6 is an informative section that says if you want interoperability, only include one <isindex> in the head, but you're better off not using it since it is deprecated. Sounds acceptable to me; I don't think anybody is being misled. Best wishes, Steven Pemberton
PROBLEM ID: 8414
STATE: Needs Approval
EDIT: N/A
RESOLUTION: None
USER POSITION: None
NOTES:
This has been removed from the recommendation.
ORIGINAL MESSAGE:
Date: Mon, 12 Jul 2004 14:27:12 +0900 (JST) From: Bjoern Hoehrmann <derhoermi@gmx.net> From: Bjoern Hoehrmann <derhoermi@gmx.net> To: www-html-editor@w3.org Subject: XHTML1: Appendix C.8 seems misplaced Date: Mon, 12 Jul 2004 06:14:04 +0200 Message-ID: <4189100a.1817842509@smtp.bjoern.hoehrmann.de> X-Archived-At: http://www.w3.org/mid/4189100a.1817842509@smtp.bjoern.hoehrmann.de Dear HTML Working Group, Appendix C.8 of the XHTML 1.0 Second Edition Recommendation seems misplaced in Appendix C as it does not seem to give any guidance to XHTML authors who wish to deliver XHTML documents to legacy clients, it rather discusses differnces between HTML and XHTML in this regard and cites general considerations for authors. Could you plase clarify what the exact requirements are for XHTML authors who wish to deliver XHTML documents to legacy clients? It might make some limited sense to require that documents that use either the id or the name attribute on one of the relevant elements must use both attributes specifying the same value, but as the specification does not do this, it seems to be better to move the entire section to section 4, "Differences with HTML 4". regards.
PROBLEM ID: 8802
STATE: Needs Approval
EDIT: N/A
RESOLUTION: None
USER POSITION: None
NOTES:
The appendix removed from the Recommendation.
ORIGINAL MESSAGE:
Date: Tue, 26 Oct 2004 19:00:29 +0900 (JST) From: "GVE" <gve@altervista.org> From: "GVE" <gve@altervista.org> To: www-html-editor@w3.org Subject: Misleading passage in xhtml reccomendation Date: Thu, 21 Oct 2004 11:55:51 +0200 Message-ID: <200410211155510620.00556FB7@smtp.tiscali.it> X-Archived-At: http://www.w3.org/mid/200410211155510620.00556FB7@smtp.tiscali.it Please read these four message in the validator ML: http://lists.w3.org/Archives/Public/www-validator/2004Oct/0127.html http://lists.w3.org/Archives/Public/www-validator/2004Oct/0128.html http://lists.w3.org/Archives/Public/www-validator/2004Oct/0129.html http://lists.w3.org/Archives/Public/www-validator/2004Oct/0130.html From the discussion results that the passage http://www.w3.org/TR/xhtml1/#h-4.3 is at least misleading.
FOLLOWUP 1:
Date: Wed, 27 Oct 2004 17:18:10 +0200 From: "Steven Pemberton" <steven.pemberton@cwi.nl> On Tue, 26 Oct 2004 05:00:49 -0500 (CDT), <gve@altervista.org> wrote: > > From: "GVE" <gve@altervista.org> > To: www-html-editor@w3.org > Subject: Misleading passage in xhtml reccomendation > Date: Thu, 21 Oct 2004 11:55:51 +0200 > Message-ID: <200410211155510620.00556FB7@smtp.tiscali.it> > X-Archived-At: > http://www.w3.org/mid/200410211155510620.00556FB7@smtp.tiscali.it > > Please read these four message in the validator ML: > http://lists.w3.org/Archives/Public/www-validator/2004Oct/0127.html > http://lists.w3.org/Archives/Public/www-validator/2004Oct/0128.html > http://lists.w3.org/Archives/Public/www-validator/2004Oct/0129.html > http://lists.w3.org/Archives/Public/www-validator/2004Oct/0130.html > >> From the discussion results that the passage > http://www.w3.org/TR/xhtml1/#h-4.3 is at least misleading. You are right: "All elements other than those declared in the DTD as EMPTY must have an end tag." should read "All elements other than those declared in the DTD as EMPTY should have an end tag." since this section is meant to point out what XML requires of XHTML, and XML says "For interoperability, the empty-element tag SHOULD be used, and SHOULD only be used, for elements which are declared EMPTY." (Last sentence of http://www.w3.org/TR/REC-xml/#sec-starttags) Note, that since this section is informative, this change makes no normative change to XHTML1. Thanks for spotting it. Steven Pemberton Chair, W3C HTML WG
PROBLEM ID: 8409
STATE: Needs Approval
EDIT: N/A
RESOLUTION: None
USER POSITION: None
NOTES:
The appendix has been removed from the specification. We updated the text of this clause so it is clear that the guidance is documents should not use formfeed characters because they are not portable.
ORIGINAL MESSAGE:
Date: Mon, 12 Jul 2004 14:20:22 +0900 (JST) From: Bjoern Hoehrmann <derhoermi@gmx.net> From: Bjoern Hoehrmann <derhoermi@gmx.net> To: www-html-editor@w3.org Subject: XHTML1: Appendix C.15 seems misplaced Date: Mon, 12 Jul 2004 06:13:51 +0200 Message-ID: <41840ffe.1817830061@smtp.bjoern.hoehrmann.de> X-Archived-At: http://www.w3.org/mid/41840ffe.1817830061@smtp.bjoern.hoehrmann.de Dear HTML Working Group, Appendix C.15 refers to the differences between the sets of characters allowed in HTML and XHTML. The section seems misplaced in Appendix C as there does not seem to be any guideline for XHTML authors who wish to deliver their XHTML documents to legacy user agents, authors cannot use such characters in XHTML documents and thus no further action on their side would be required. It seems the proper section for this text would be Section 4, "Differences with HTML 4". Could you please confirm that this is an error in the specification, or, if it is intentional, what the actual requirement is? regards.
FOLLOWUP 1:
Date: Fri, 23 Jul 2004 15:06:50 -0500 From: Shane McCarron <shane@aptest.com> This is a cryptographically signed message in MIME format. --------------ms080709030700000006090107 Content-Type: multipart/alternative; boundary="------------020208090508080707040106" This is a multi-part message in MIME format. --------------020208090508080707040106 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sure. However, remember that from a validation perspective this change to the specification will have no effect. The requirements was already in place from XML. Bjoern Hoehrmann wrote: >* Shane McCarron wrote: > > >>C.15 is 1) very poorly written, and 2) could be in section 4. It does >>not, however, represent an HTML conformance requirement. XML defines >>the conformance requirements for characters that can appear in a >>document - and this specific character is excluded. >> >> > >So we seem to be in agreement that this should be moved to section 4 >in the next edition of the specification, that would satisfy me. > >Thanks for your time, Shane! > > -- Shane P. McCarron Phone: +1 763 786-8160 x120 Managing Director Fax: +1 763 786-8180 ApTest Minnesota Inet: shane@aptest.com --------------020208090508080707040106 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Sure. However, remember that from a validation perspective this change to the specification will have no effect. The requirements was already in place from XML.<br> <br> Bjoern Hoehrmann wrote:<br> <blockquote cite="mid41176b3b.571023959@smtp.bjoern.hoehrmann.de" type="cite"> <pre wrap="">* Shane McCarron wrote: </pre> <blockquote type="cite"> <pre wrap="">C.15 is 1) very poorly written, and 2) could be in section 4. It does not, however, represent an HTML conformance requirement. XML defines the conformance requirements for characters that can appear in a document - and this specific character is excluded. </pre> </blockquote> <pre wrap=""><!----> So we seem to be in agreement that this should be moved to section 4 in the next edition of the specification, that would satisfy me. Thanks for your time, Shane! </pre> </blockquote> <br> <pre class="moz-signature" cols="72">-- Shane P. McCarron Phone: +1 763 786-8160 x120 Managing Director Fax: +1 763 786-8180 ApTest Minnesota Inet: <a class="moz-txt-link-abbreviated" href="mailto:shane@aptest.com">shane@aptest.com</a> </pre> </body> </html> --------------020208090508080707040106-- --------------ms080709030700000006090107 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINujCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBSYwggSPoAMCAQICEC2q5xHYEFYOCFS1iYWUmGEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTEwMDAw MDAwWhcNMDQwOTA5MjM1OTU5WjCCARQxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTEaMBgGA1UEAxQRU2hhbmUgUC4gTWNDYXJyb24xHzAd BgkqhkiG9w0BCQEWEHNoYW5lQGFwdGVzdC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQC3rA2lK8eY0hVkTUuZau05QxkrnWCgNKKZZplIJIMG2wwP+B15wWGMG4A7lOaz KamU/PDMuxomP+IKKLzRrsnPZ5nMoiu596CRqolUr5NZBSXtOJEKF6ce//UvaGHlRSqxVhVD qOaIn58BuCvugKExHfCEjWrl38JpQU/2BrqEFslPu+s5ba/q8ZlUj/2eeMuXLsa5b3MvBc5s GW16fdWisSZd/ZDlzg1aNPfTCR88aF0/QrR/fgUaBDh3jsKCq9blW261qoactbzjMKIOwVUn 2yvto+89hFHBiUOwwFt+ZIDc3eZSkjFuxA4aF3qvDEQdJc64PL8rGq8Gja0oiu1DAgMBAAGj ggE4MIIBNDAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYw FRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMAYK YIZIAYb4RQEGBwQiFiAyYjE5ZWRjZTZhOTQxZGFlZmMyN2ZiNDRlMjc3NjU2ZTAzBgNVHR8E LDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3 DQEBBAUAA4GBAKRKgqJM5b/kcoY7LLLdpxwD/Or1+XJIU34V6VTjSutg78lZyBsU9ufcesg/ Pd8iYsWJ19eknBuVO/enNbgv+BF5jxuveaAGoGvo7cIjcOMf0xUYTezGD0ur2jp3Pdk/ZPmW 0uCzBAQw4XJYP84pViI3VynAoDQH3MF8g35660TQMIIFJjCCBI+gAwIBAgIQLarnEdgQVg4I VLWJhZSYYTANBgkqhkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNV BAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEg Tm90IFZhbGlkYXRlZDAeFw0wMzA5MTAwMDAwMDBaFw0wNDA5MDkyMzU5NTlaMIIBFDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBS ZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEG A1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRowGAYD VQQDFBFTaGFuZSBQLiBNY0NhcnJvbjEfMB0GCSqGSIb3DQEJARYQc2hhbmVAYXB0ZXN0LmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALesDaUrx5jSFWRNS5lq7TlDGSud YKA0oplmmUgkgwbbDA/4HXnBYYwbgDuU5rMpqZT88My7GiY/4goovNGuyc9nmcyiK7n3oJGq iVSvk1kFJe04kQoXpx7/9S9oYeVFKrFWFUOo5oifnwG4K+6AoTEd8ISNauXfwmlBT/YGuoQW yU+76zltr+rxmVSP/Z54y5cuxrlvcy8FzmwZbXp91aKxJl39kOXODVo099MJHzxoXT9CtH9+ BRoEOHeOwoKr1uVbbrWqhpy1vOMwog7BVSfbK+2j7z2EUcGJQ7DAW35kgNzd5lKSMW7EDhoX eq8MRB0lzrg8vysarwaNrSiK7UMCAwEAAaOCATgwggE0MAkGA1UdEwQCMAAwgawGA1UdIASB pDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJp U2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlT aWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhFAQYHBCIWIDJiMTllZGNlNmE5NDFk YWVmYzI3ZmI0NGUyNzc2NTZlMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNp Z24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEApEqCokzlv+Ryhjssst2nHAP8 6vX5ckhTfhXpVONK62DvyVnIGxT259x6yD893yJixYnX16ScG5U796c1uC/4EXmPG695oAag a+jtwiNw4x/TFRhN7MYPS6vaOnc92T9k+ZbS4LMEBDDhclg/zilWIjdXKcCgNAfcwXyDfnrr RNAxggSqMIIEpgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw b3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1Zl cmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZh bGlkYXRlZAIQLarnEdgQVg4IVLWJhZSYYTAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA3MjMyMDA2NTBaMCMGCSqGSIb3DQEJ BDEWBBR4bmxs0FbUsCGEn2j5ynAB8JTeqTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB8gYJKwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkAhAtqucR2BBWDghUtYmFlJhhMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQLarnEdgQVg4I VLWJhZSYYTANBgkqhkiG9w0BAQEFAASCAQAZazWhZRFrmzqZAQMF6XhfsuhvklONVTF7RK5f tqIB47CqYkrU3tpFoqvQUGh+q/Gi/EYQ7QB0XpQ88+sHgFEiZLiqwlT+W06o2QjjHJmFt9/b vXMvR85j0Vf6gti/sQFIC3SCs2Yi99WVz4HgTcpE8ZsUohCXgARpX7SzPiMaayqN5aRjIXva fGJvCV94gjzrrxHd655yS5KnUEaxMLQbgSz7Ou2sSJWGw1hW/O68PH2cw0mzwvHDCVRPaGVN h4GY0QHugHRme5Z82dr/z+ldUmJHblIUxj6bAUsYhJOdGyFMLg2/2LBJ15IGfA8ywHs+6bhL qDgz7z0WoYx36nluAAAAAAAA --------------ms080709030700000006090107--
FOLLOWUP 2:
Date: Fri, 23 Jul 2004 13:32:22 -0500 From: Shane McCarron <shane@aptest.com> This is a cryptographically signed message in MIME format. --------------ms040705080003040901080808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit C.15 is 1) very poorly written, and 2) could be in section 4. It does not, however, represent an HTML conformance requirement. XML defines the conformance requirements for characters that can appear in a document - and this specific character is excluded. derhoermi@gmx.net wrote: >From: Bjoern Hoehrmann <derhoermi@gmx.net> >To: www-html-editor@w3.org >Subject: XHTML1: Appendix C.15 seems misplaced >Date: Mon, 12 Jul 2004 06:13:51 +0200 >Message-ID: <41840ffe.1817830061@smtp.bjoern.hoehrmann.de> >X-Archived-At: http://www.w3.org/mid/41840ffe.1817830061@smtp.bjoern.hoehrmann.de > >Dear HTML Working Group, > > Appendix C.15 refers to the differences between the sets of characters >allowed in HTML and XHTML. The section seems misplaced in Appendix C as >there does not seem to be any guideline for XHTML authors who wish to >deliver their XHTML documents to legacy user agents, authors cannot use >such characters in XHTML documents and thus no further action on their >side would be required. It seems the proper section for this text would >be Section 4, "Differences with HTML 4". Could you please confirm that >this is an error in the specification, or, if it is intentional, what >the actual requirement is? > >regards. > > > -- Shane P. McCarron Phone: +1 763 786-8160 x120 Managing Director Fax: +1 763 786-8180 ApTest Minnesota Inet: shane@aptest.com --------------ms040705080003040901080808 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINujCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBSYwggSPoAMCAQICEC2q5xHYEFYOCFS1iYWUmGEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTEwMDAw MDAwWhcNMDQwOTA5MjM1OTU5WjCCARQxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTEaMBgGA1UEAxQRU2hhbmUgUC4gTWNDYXJyb24xHzAd BgkqhkiG9w0BCQEWEHNoYW5lQGFwdGVzdC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQC3rA2lK8eY0hVkTUuZau05QxkrnWCgNKKZZplIJIMG2wwP+B15wWGMG4A7lOaz KamU/PDMuxomP+IKKLzRrsnPZ5nMoiu596CRqolUr5NZBSXtOJEKF6ce//UvaGHlRSqxVhVD qOaIn58BuCvugKExHfCEjWrl38JpQU/2BrqEFslPu+s5ba/q8ZlUj/2eeMuXLsa5b3MvBc5s GW16fdWisSZd/ZDlzg1aNPfTCR88aF0/QrR/fgUaBDh3jsKCq9blW261qoactbzjMKIOwVUn 2yvto+89hFHBiUOwwFt+ZIDc3eZSkjFuxA4aF3qvDEQdJc64PL8rGq8Gja0oiu1DAgMBAAGj ggE4MIIBNDAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYw FRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMAYK YIZIAYb4RQEGBwQiFiAyYjE5ZWRjZTZhOTQxZGFlZmMyN2ZiNDRlMjc3NjU2ZTAzBgNVHR8E LDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3 DQEBBAUAA4GBAKRKgqJM5b/kcoY7LLLdpxwD/Or1+XJIU34V6VTjSutg78lZyBsU9ufcesg/ Pd8iYsWJ19eknBuVO/enNbgv+BF5jxuveaAGoGvo7cIjcOMf0xUYTezGD0ur2jp3Pdk/ZPmW 0uCzBAQw4XJYP84pViI3VynAoDQH3MF8g35660TQMIIFJjCCBI+gAwIBAgIQLarnEdgQVg4I VLWJhZSYYTANBgkqhkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNV BAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEg Tm90IFZhbGlkYXRlZDAeFw0wMzA5MTAwMDAwMDBaFw0wNDA5MDkyMzU5NTlaMIIBFDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBS ZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEG A1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRowGAYD VQQDFBFTaGFuZSBQLiBNY0NhcnJvbjEfMB0GCSqGSIb3DQEJARYQc2hhbmVAYXB0ZXN0LmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALesDaUrx5jSFWRNS5lq7TlDGSud YKA0oplmmUgkgwbbDA/4HXnBYYwbgDuU5rMpqZT88My7GiY/4goovNGuyc9nmcyiK7n3oJGq iVSvk1kFJe04kQoXpx7/9S9oYeVFKrFWFUOo5oifnwG4K+6AoTEd8ISNauXfwmlBT/YGuoQW yU+76zltr+rxmVSP/Z54y5cuxrlvcy8FzmwZbXp91aKxJl39kOXODVo099MJHzxoXT9CtH9+ BRoEOHeOwoKr1uVbbrWqhpy1vOMwog7BVSfbK+2j7z2EUcGJQ7DAW35kgNzd5lKSMW7EDhoX eq8MRB0lzrg8vysarwaNrSiK7UMCAwEAAaOCATgwggE0MAkGA1UdEwQCMAAwgawGA1UdIASB pDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJp U2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlT aWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhFAQYHBCIWIDJiMTllZGNlNmE5NDFk YWVmYzI3ZmI0NGUyNzc2NTZlMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNp Z24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEApEqCokzlv+Ryhjssst2nHAP8 6vX5ckhTfhXpVONK62DvyVnIGxT259x6yD893yJixYnX16ScG5U796c1uC/4EXmPG695oAag a+jtwiNw4x/TFRhN7MYPS6vaOnc92T9k+ZbS4LMEBDDhclg/zilWIjdXKcCgNAfcwXyDfnrr RNAxggSqMIIEpgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw b3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1Zl cmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZh bGlkYXRlZAIQLarnEdgQVg4IVLWJhZSYYTAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA3MjMxODMyMjJaMCMGCSqGSIb3DQEJ BDEWBBTEKJ8jjyv0jPU3aAEhQWynBRU54TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB8gYJKwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkAhAtqucR2BBWDghUtYmFlJhhMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQLarnEdgQVg4I VLWJhZSYYTANBgkqhkiG9w0BAQEFAASCAQA6L4cTF9dU2Ul7lhAw3BOzgyGL45SopMuszgQ7 yARJFxJqDt5asTEIR0dcv5wqpA6qsDfcqA8G92fUQwUVLx3hPiKywcRGWXbRC5y48oCYMo2S Md3ZDGATzJj7MSOa0FQut0QMF4wInh57QrJ3/V1yHsYETyNgpOx9xbkfqoM2oTFUy57r1jO5 +IFjABvR58Cq/kYyfchecovluP8+SvM/rbI13O1hhi/kgLkN5Y9pHb5j/4jrQ+2buzLzdyk1 BzKzRldfkDDsP+/cKlkWnw+WcaoB8z/iMfv5QC7/JWpga3ME8xJyNG3kPbGynn3aNRs7SBPD LgKgNyDc7i0mEoXLAAAAAAAA --------------ms040705080003040901080808--
FOLLOWUP 3:
From: Bjoern Hoehrmann <derhoermi@gmx.net> Date: Fri, 23 Jul 2004 21:48:59 +0200 * Shane McCarron wrote: >C.15 is 1) very poorly written, and 2) could be in section 4. It does >not, however, represent an HTML conformance requirement. XML defines >the conformance requirements for characters that can appear in a >document - and this specific character is excluded. So we seem to be in agreement that this should be moved to section 4 in the next edition of the specification, that would satisfy me. Thanks for your time, Shane!
PROBLEM ID: 6303
STATE: Approved and Implemented
EDIT: N/A
RESOLUTION: Accept
USER POSITION: None
NOTES:
Fixed.
ORIGINAL MESSAGE:
Date: Sun, 16 Mar 2003 11:42:03 +0900 (JST) From: Tobias Reif <tobiasreif@pinkjuice.com> From: Tobias Reif <tobiasreif@pinkjuice.com> To: www-html-editor@w3.org Subject: typo in a comment in the DTD (sup/sub) Date: Sun, 16 Mar 2003 00:41:37 +0100 Message-ID: <3E73BA31.1040505@pinkjuice.com> X-Archived-At: http://www.w3.org/mid/3E73BA31.1040505@pinkjuice.com Hi there is a typo in http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd line 217: <!-- pre uses %Inline excluding big, small, sup or sup --> should probably be ^ <!-- pre uses %Inline excluding big, small, sub or sup --> ^ Tobi -- http://www.pinkjuice.com/
PROBLEM ID: 6143
STATE: Open
EDIT: N/A
RESOLUTION: None
USER POSITION: None
ORIGINAL MESSAGE:
From: "Steven Pemberton" <steven.pemberton@cwi.nl> Date: Wed, 16 Oct 2002 13:34:35 +0200 > The problem with Section 4.3 of XHTML 1.0 Specification I reported is > not corrected in Second Edition which has been recently published. This was an oversight. > You once agreed that the wording in Section 4.3 is confusing. If it > is left unchanged on purpose, please tell me the reason for it. It wasn't on purpose. Nevertheless, the section is informative, not normative, so it is not an error in the spec. XML allows <span/>, thus so does XHTML, and nothing in this section can or does change that. Thank you for your interest. Best wishes, Steven Pemberton
PROBLEM ID: 6674
STATE: Needs Approval
EDIT: N/A
RESOLUTION: None
USER POSITION: None
NOTES:
We forgot to deal with this one - we need to identify which references are normative and which are informative. I have taken a cut at it.
ORIGINAL MESSAGE:
Date: Tue, 26 Aug 2003 16:10:22 +0900 (JST) From: Bjoern Hoehrmann <derhoermi@gmx.net> From: Bjoern Hoehrmann <derhoermi@gmx.net> To: www-html-editor@w3.org Subject: XHTML 1.0: Normative References Date: Tue, 26 Aug 2003 08:41:39 +0200 Message-ID: <3f63fe0d.196882572@smtp.bjoern.hoehrmann.de> X-Archived-At: http://www.w3.org/mid/3f63fe0d.196882572@smtp.bjoern.hoehrmann.de Hi, Section 3.2 of XHTML 1.0 item 2: [...] When the user agent claims to support facilities defined within this specification or required by this specification through normative reference, it must do so in ways consistent with the facilities' definition. [...] XHTML 1.0 does not define it's own facilities, it only includes facilities from other specificiations (HTML 4.01, XML Namespaces, XHTML 1.0) but these specifications are not normative but rather informative references as Appendix E is informative. XHTML 1.0 does not make sense without most of the references in Appendix E beeing normative.
FOLLOWUP 1:
Date: Wed, 03 Sep 2003 09:59:46 -0500 From: Shane McCarron <shane@aptest.com> The working group recognizes that all of Appendix E is labeled as informative. This is an error. We will be working to classify the references as normative or informative in the near future. derhoermi@gmx.net wrote: >From: Bjoern Hoehrmann <derhoermi@gmx.net> >To: www-html-editor@w3.org >Subject: XHTML 1.0: Normative References >Date: Tue, 26 Aug 2003 08:41:39 +0200 >Message-ID: <3f63fe0d.196882572@smtp.bjoern.hoehrmann.de> >X-Archived-At: http://www.w3.org/mid/3f63fe0d.196882572@smtp.bjoern.hoehrmann.de > >Hi, > > Section 3.2 of XHTML 1.0 item 2: > >[...] > When the user agent claims to support facilities defined within this > specification or required by this specification through normative > reference, it must do so in ways consistent with the facilities' > definition. >[...] > >XHTML 1.0 does not define it's own facilities, it only includes >facilities from other specificiations (HTML 4.01, XML Namespaces, XHTML >1.0) but these specifications are not normative but rather informative >references as Appendix E is informative. XHTML 1.0 does not make sense >without most of the references in Appendix E beeing normative. > > -- Shane P. McCarron Phone: +1 763 786-8160 x120 Managing Director Fax: +1 763 786-8180 ApTest Minnesota Inet: shane@aptest.com
PROBLEM ID: 8339
STATE: Approved and Implemented
EDIT: N/A
RESOLUTION: Modify and Accept
USER POSITION: None
NOTES:
Updated when moved into Media Types document.
ORIGINAL MESSAGE:
Date: Wed, 02 Jun 2004 15:42:16 +0900 (JST) From: Bjoern Hoehrmann <derhoermi@gmx.net> From: Bjoern Hoehrmann <derhoermi@gmx.net> To: www-html-editor@w3.org Subject: XHTML 1.0: Comment processing Date: Fri, 28 May 2004 19:46:39 +0200 Message-ID: <40b876e2.530189311@smtp.bjoern.hoehrmann.de> X-Archived-At: http://www.w3.org/mid/40b876e2.530189311@smtp.bjoern.hoehrmann.de Dear HTML Working Group, Appendix C.4 of XHTML 1.0 Second Edition reads [...] Use external style sheets if your style sheet uses < or & or ]]> or --. Use external scripts if your script uses < or & or ]]> or --. Note that XML parsers are permitted to silently remove the contents of comments. Therefore, the historical practice of "hiding" scripts and style sheets within "comments" to make the documents backward compatible is likely to not work as expected in XML-based user agents. [...] Section 3.2 of the First Edition additionally contained [...] In elements where the 'xml:space' attribute is set to 'preserve', the user agent must leave all whitespace characters intact (with the exception of leading and trailing whitespace characters, which should be removed). Otherwise, whitespace is handled according to the following rules: [...] * Comments are removed entirely and do not affect whitespace handling. One whitespace character on either side of a comment is treated as two white space characters. [...] This suggests that comments like in e.g. <p><!--...--></p> would not be available in the DOM or to other means, while <style type="text/css"><!--...--></style> would be available. Could you please clarify whether this is the intention of the text and if, whether this still holds true under the second edition and if not why this has been changed? It appears that the requirement is misplaced in the first edition as it seems a more general rule... But then I would question the utility of mandating the removal of comment nodes at parse time... I am not sure how to understand Appendix C.4, I would expect that XHTML 1.0 is defined so that the content of comments is not to be processed in any way other than described in the XML 1.0 Recommendation, which means that XHTML 1.0 User Agents must not make scripts or style sheets "hidden" in such a way "work as expected". Could you please clarify under what circumstances other than non-conformance of a user agent a style sheet inside a comment inside a <style> element would be applied to the document? regards.
PROBLEM ID: 8417
STATE: Needs Approval
EDIT: N/A
RESOLUTION: None
USER POSITION: None
NOTES:
This section has been removed from the Recommendation.
ORIGINAL MESSAGE:
Date: Mon, 12 Jul 2004 14:31:31 +0900 (JST) From: Bjoern Hoehrmann <derhoermi@gmx.net> From: Bjoern Hoehrmann <derhoermi@gmx.net> To: www-html-editor@w3.org Subject: XHTML1: Appendix C.11 seems misplaced Date: Mon, 12 Jul 2004 06:14:11 +0200 Message-ID: <418c1011.1817849409@smtp.bjoern.hoehrmann.de> X-Archived-At: http://www.w3.org/mid/418c1011.1817849409@smtp.bjoern.hoehrmann.de Dear HTML Working Group, Appendix C.11 of the XHTML 1.0 Second Edition Recommendation seems to be misplaced in Appendix C as it does not seem to discuss guidelines for XHTML authors who wish to deliver XHTML documents to legacy user agents. Could you please clarify what, if any, the requirements are for such authors? It seems that the appropriate section would be section 4, "Differences with HTML 4". regards.
PROBLEM ID: 9110
STATE: Needs Approval
EDIT: N/A
RESOLUTION: None
USER POSITION: None
NOTES:
objects are independent entities within the page. Navigation is local to the object and its own processing. This is defined in HTML 4.
ORIGINAL MESSAGE:
Date: Wed, 01 Jun 2005 19:29:40 +0900 (JST) From: "Jim Ley" <jim@jibbering.com> From: "Jim Ley" <jim@jibbering.com> To: <www-html-editor@w3.org> Cc: <mimasa@w3.org> Subject: [XHTML 1 and 1.1] Activating links within Object. Date: Sun, 29 May 2005 09:45:54 +0100 Message-ID: <030501c5642a$d34e5f60$0a00000a@Snufkin> X-Archived-At: http://www.w3.org/mid/030501c5642a$d34e5f60$0a00000a@Snufkin Dear HTML Working Group, If an embedded resources contain links, what happens when they're activated, does the parent resource navigate to the new resource, or does only the child resource navigate? i.e. if we have a document containing: <object data="chicken"></object> and chicken containing a hyperlink to donkey.html, does the paragraph get replaced or does the parent document? Is the behaviour dependant on the content-type of the resource returned by chicken? Implemented behaviour differs between user agents and there is no interopability in XHTML user agents, please provide clarification. I understand this to be substantially the same as an Issue raised by Tobias Reif in 2002, which is yet to be formally addressed.[1] Which is why I have not previously explicitly raised the issue. The Advisory Board recently advised me to alert the Activity lead if groups were being delinquent in their requiment to formally address issues in a timely fashion, so I have cc'd the Activity lead on this, as I believe the time elapsed since that issue was raised is not appropriately maintaining the XHTML specifications as is required by the W3 Process. Regards, Jim Ley. [1] http://lists.w3.org/Archives/Public/www-html-editor/2002OctDec/0050.html
PROBLEM ID: 8411
STATE: Needs Approval
EDIT: N/A
RESOLUTION: None
USER POSITION: None
NOTES:
This was removed in third edition.
ORIGINAL MESSAGE:
Date: Mon, 12 Jul 2004 14:24:03 +0900 (JST) From: Bjoern Hoehrmann <derhoermi@gmx.net> From: Bjoern Hoehrmann <derhoermi@gmx.net> To: www-html-editor@w3.org Subject: XHTML1: (Consistency of) Language Information Date: Mon, 12 Jul 2004 06:13:55 +0200 Message-ID: <41861002.1817834427@smtp.bjoern.hoehrmann.de> X-Archived-At: http://www.w3.org/mid/41861002.1817834427@smtp.bjoern.hoehrmann.de Dear HTML Working Group, Appendix C.7 of the XHTML 1.0 Second Edition Recommendation states: [...] Use both the lang and xml:lang attributes when specifying the language of an element. The value of the xml:lang attribute takes precedence. [...] The second sentence seems misplaced in the informative Appendix C but rather seems to be a normative requirement for XHTML user agents. The specification apparently does not discuss xml:lang versus lang in any other place, which makes me wonder how a XHTML user agent is supposed to handle them. Are XHTML 1.0 user agents required to derive the language of an element from the lang attribute even if there is no additional xml:lang attribute? That would then seem inconsistent with the id versus name attribute discussion where XHTML user agents are required to ignore the "legacy" attribute. So is it actually that the xml:lang attribute does not take precedence but rather is the sole indicator for language information? Please clarify this in a normative section of the specification. It also seems that for compatibility both attributes must specify the same value as you would otherwise get inconsistent behavior across such user agents. Could you please clarify whether this omission is intentional? If it is intentional, could you please clarify why exactly? regards.
PROBLEM ID: 6593
STATE: Needs Approval
EDIT: N/A
RESOLUTION: None
USER POSITION: None
NOTES:
My recommendation is that we leave this as CDATA because that is compatible with HTML4 AND compatible with XHTML 1.1. I feel the submitter misunderstood the whitespace interpretation requirements of XHTML 1.0. Whitespace in that sense was not related to whitespace within attribute values. The original XHTML 1.0 Rec said that whitespace in attribute values is interpreted as per XML.
ORIGINAL MESSAGE:
Date: Sat, 09 Aug 2003 09:53:16 +0900 (JST) From: Bjoern Hoehrmann <derhoermi@gmx.net> From: Bjoern Hoehrmann <derhoermi@gmx.net> To: www-html-editor@w3.org Subject: Is zero width space white-space? Date: Sat, 09 Aug 2003 02:34:20 +0200 Message-ID: <3f513dd7.667901421@smtp.bjoern.hoehrmann.de> X-Archived-At: http://www.w3.org/mid/3f513dd7.667901421@smtp.bjoern.hoehrmann.de Dear HTML WG, XHTML 1.0 First Edition required user agents to treat the zero width space character (U+200B) as white space character. This requirement has been removed in XHTML 1.0 Second Edition. This raises the question whether <p class="foo​bar">...</p> belongs to the classes foo and bar (as in HTML 4 and XHTML 1.0 First Edition) or to a single class foo<U+200B>bar. Could you please clarify this in the errata for XHTML 1.0 Second Edition and XHTML M12N? Thanks. regards.
FOLLOWUP 1:
From: Bjoern Hoehrmann <derhoermi@gmx.net> Date: Fri, 22 Aug 2003 06:50:29 +0200 * Steven Pemberton wrote: >Second edition was silent on white space because we have deferred input >white space issues to whatever XML demands, and output whitespace issues to >whatever CSS demands. That is to say, we are trying to be a good XML citizen >and use XML rules for whitespace. > >So the answer to your example below (which is about input whitespace) is: >whatever XML says. XML does not define the class attribute, HTML 4 and XHTML M12N do. HTML 4 says it is abitrary strings separated by Tab, CR, LF, FF, SP and ZWS characters, M12N says it is XML NMTOKENS. If XHTML 1.0 SE is meant to say the class attribute is abitrary strings separated by XML 1.0 white space characters (Tab, CR, LF, SP) <p class="foo​bar">...</p> would be .foo.bar in HTML 4, .foo\00200bbar in XHTML 1.0 and invalid in e.g. XHTML 1.1. Is this the intent?
FOLLOWUP 2:
From: Bjoern Hoehrmann <derhoermi@gmx.net> Date: Sun, 24 Aug 2003 07:05:45 +0200 * Glenn A. Adams wrote: >So the answer is you can't use ZWSP at all in the class >attribute in XHTML if class is defined as NMTOKENS. I notice, >however, that the declared type of the class attribute changed >from XHTML 1.0 to XHTML MOD (and, thence, to XHTML 1.1). In >XHTML 1.0 is was defined as CDATA, while in XHTML MODULARIZATION >it is defined as NMTOKENS. That's the problem, yes. >I believe the use of NMTOKENS is correct, and that CDATA should >not be used. I'd be fine with a XHTML 1.0 SE errata that changes the type of the class attribute to NMTOKENS.
FOLLOWUP 3:
From: "Steven Pemberton" <steven.pemberton@cwi.nl> Date: Wed, 20 Aug 2003 17:12:58 +0200 Hi Bjoern, Second edition was silent on white space because we have deferred input white space issues to whatever XML demands, and output whitespace issues to whatever CSS demands. That is to say, we are trying to be a good XML citizen and use XML rules for whitespace. So the answer to your example below (which is about input whitespace) is: whatever XML says. Best wishes, Steven ----- Original Message ----- From: <derhoermi@gmx.net> To: <w3c-html-wg@w3.org> Cc: <voyager-issues@mn.aptest.com> Sent: Saturday, August 09, 2003 2:53 AM Subject: Is zero width space white-space? (PR#6593) > > From: Bjoern Hoehrmann <derhoermi@gmx.net> > To: www-html-editor@w3.org > Subject: Is zero width space white-space? > Date: Sat, 09 Aug 2003 02:34:20 +0200 > Message-ID: <3f513dd7.667901421@smtp.bjoern.hoehrmann.de> > X-Archived-At: http://www.w3.org/mid/3f513dd7.667901421@smtp.bjoern.hoehrmann.de > > Dear HTML WG, > > XHTML 1.0 First Edition required user agents to treat the zero width > space character (U+200B) as white space character. This requirement has > been removed in XHTML 1.0 Second Edition. This raises the question > whether > > <p class="foo​bar">...</p> > > belongs to the classes foo and bar (as in HTML 4 and XHTML 1.0 First > Edition) or to a single class foo<U+200B>bar. Could you please clarify > this in the errata for XHTML 1.0 Second Edition and XHTML M12N? Thanks. > > regards. > >
FOLLOWUP 4:
From: Bjoern Hoehrmann <derhoermi@gmx.net> Date: Wed, 27 Aug 2003 16:11:09 +0200 * Steven Pemberton wrote: >> >So the answer is you can't use ZWSP at all in the class >> >attribute in XHTML if class is defined as NMTOKENS. I notice, >> >however, that the declared type of the class attribute changed >> >from XHTML 1.0 to XHTML MOD (and, thence, to XHTML 1.1). In >> >XHTML 1.0 is was defined as CDATA, while in XHTML >> >MODULARIZATION >> >it is defined as NMTOKENS. > >If I recall, that is because of the rule we had to minimise the changes >between HTML 4 and XHTML 1 to those necessary to make XHTML 1 XML-compliant, >and HTML4 used datatype CDATA. XHTML 1.0 is not modularisation-based. It's quite hard to follow these decisions. For example, <meta name> is NAME in HTML 4, CDATA in XHTML 1.0 and NMTOKEN in XHTML 1.1 - while <a lang> is NAME in HTML 4 and NMTOKEN in XHTML 1.0/1.1. <a name> has also been changed from CDATA in HTML 4 to NMTOKEN in XHTML 1.0. >> I'd be fine with a XHTML 1.0 SE errata that changes the type of the >> class attribute to NMTOKENS. > >I'm not sure we'd be willing to make such a change, but I will schedule it >for a discussion. Well, I am probably fine with any decision as long as I know how to implement it, i.e., whether ZWS is allowed in the class attribute and if it is whether it separates classes.
FOLLOWUP 5:
From: "Steven Pemberton" <steven.pemberton@cwi.nl> Date: Wed, 27 Aug 2003 15:03:12 +0200 > >So the answer is you can't use ZWSP at all in the class > >attribute in XHTML if class is defined as NMTOKENS. I notice, > >however, that the declared type of the class attribute changed > >from XHTML 1.0 to XHTML MOD (and, thence, to XHTML 1.1). In > >XHTML 1.0 is was defined as CDATA, while in XHTML > >MODULARIZATION > >it is defined as NMTOKENS. If I recall, that is because of the rule we had to minimise the changes between HTML 4 and XHTML 1 to those necessary to make XHTML 1 XML-compliant, and HTML4 used datatype CDATA. XHTML 1.0 is not modularisation-based. On the other hand, modularisation does not have that requirement, and so more useful types were used where they were available. > I'd be fine with a XHTML 1.0 SE errata that changes the type of the > class attribute to NMTOKENS. I'm not sure we'd be willing to make such a change, but I will schedule it for a discussion. Thanks! Steven Pemberton
FOLLOWUP 6:
Date: Sat, 23 Aug 2003 16:02:14 -0400 From: "Glenn A. Adams" <glenn@xfsi.com> The data type of the class attribute is NMTOKENS, which is defined by production [8] of XML 1.0 as: [8] Nmtokens ::= Nmtoken (S Nmtoken)* The S token is defined as by XML 1.0: [3] S ::= (#x20 | #x9 | #xD | #xA)+ Now, Nmtoken is defined as follows: [7] Nmtoken ::= (NameChar)+ [4] NameChar ::= Letter | Digit | '.' | '-' | '_' | ':' | CombiningChar | Extender Since ​ (ZWSP) does not appear any Letter, Digit, CombiningChar, Extender or S, it cannot appear in the class attribute at all in XML 1.0. The current draft of XML 1.1 does not change this situation either. So the answer is you can't use ZWSP at all in the class attribute in XHTML if class is defined as NMTOKENS. I notice, however, that the declared type of the class attribute changed from XHTML 1.0 to XHTML MOD (and, thence, to XHTML 1.1). In XHTML 1.0 is was defined as CDATA, while in XHTML MODULARIZATION it is defined as NMTOKENS. I believe the use of NMTOKENS is correct, and that CDATA should not be used. Regards, Glenn Adams > > -----Original Message----- > From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net] > Sent: Friday, August 22, 2003 12:50 AM > To: Steven Pemberton > Cc: w3c-html-wg@w3.org; voyager-issues@mn.aptest.com > > > * Steven Pemberton wrote: > >Second edition was silent on white space because we have > deferred input > >white space issues to whatever XML demands, and output > whitespace issues to > >whatever CSS demands. That is to say, we are trying to be a > good XML citizen > >and use XML rules for whitespace. > > > >So the answer to your example below (which is about input > whitespace) is: > >whatever XML says. > > XML does not define the class attribute, HTML 4 and XHTML > M12N do. HTML > 4 says it is abitrary strings separated by Tab, CR, LF, FF, SP and ZWS > characters, M12N says it is XML NMTOKENS. If XHTML 1.0 SE is meant to > say the class attribute is abitrary strings separated by XML 1.0 white > space characters (Tab, CR, LF, SP) > > <p class="foo​bar">...</p> > > would be .foo.bar in HTML 4, .foo\00200bbar in XHTML 1.0 and > invalid in > e.g. XHTML 1.1. Is this the intent? > > >
PROBLEM ID: 8430
STATE: Approved
EDIT: N/A
RESOLUTION: Accept
USER POSITION: None
NOTES:
Reference to XML 1.0 updated to fourth edition and made normative.
ORIGINAL MESSAGE:
Date: Thu, 15 Jul 2004 10:32:53 +0900 (JST) From: Bjoern Hoehrmann <derhoermi@gmx.net> From: Bjoern Hoehrmann <derhoermi@gmx.net> To: www-html-editor@w3.org Subject: XHTML1: What is an "XML document"? Date: Thu, 15 Jul 2004 03:27:07 +0200 Message-ID: <40fadc1f.65569433@smtp.bjoern.hoehrmann.de> X-Archived-At: http://www.w3.org/mid/40fadc1f.65569433@smtp.bjoern.hoehrmann.de Dear HTML Working Group, Section 3.1 of the XHTML 1.0 Second Edition Recommendation states: [...] A Strictly Conforming XHTML Document is an XML document that requires only the facilities described as mandatory in this specification. [...] There does not seem to be a definition of "XML document" and the XML 1.0 Recommendation does not seem to be a normative reference, hence it is by no means clear for example whether strictly conforming documents may be authored using XML 1.1 or any future XML versions. If you mean that only XML 1.0 can be used to author XHTML 1.0 documents, please state this in the relevant section and make the XML 1.0 Recommendation in its latest version a normative reference of the specification. regards.
PROBLEM ID: 8285
STATE: Needs Approval
EDIT: N/A
RESOLUTION: None
USER POSITION: None
NOTES:
We could update the XML Schema implementation and include it in the third edition. It would be a work of moments.
ORIGINAL MESSAGE:
Date: Wed, 24 Mar 2004 22:20:47 +0900 (JST) From: Masayasu Ishikawa <mimasa@w3.org> Henry Thompson informed me that the schemas included in "XHTML 1.0 in XML Schema" [1] become broken per an erratum introduced by XML Schema 1.0 Specification Errata E2-18 [2], which is now published in the XML Schema Second Edition PER [3]. The problem is that the schemas included patterns like this: <xs:simpleType name="Length"> <xs:annotation> <xs:documentation> nn for pixels or nn% for percentage length </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:pattern value="[-+]?(\d+|\d+(\.\d+)?%)"/> </xs:restriction> </xs:simpleType> "[-+]" was legal in the first edition, as there was the following rule: A single XML character is a character range that identifies the set of characters containing only itself. All XML characters are valid character ranges, except as follows: <snip/> - The - character is a valid character range only at the beginning or end of a positive character group. However, this has been removed from the second edition and thus it should be changed to "[\-+]". Fortunately machine-readable schemas were put outside of the TR space, so we could change all occurrences of "[-+]" to "[\-+]" in those schemas if we agree to make this fix, without republishing the Note. Does anyone disagree with this fix? As far as I can see, XML Schemas in XHTML M12N 2E didn't use such pattern (which implies inconsistency of datatyping between XHTML1 schemas and M12N schemas), and RELAX NG schemas in XHTML2 used "[\-+]". Maybe at some point, we should republish the Note to make our XHTML schemas consistent, or we could possibly incorporate updated XHTML1 schemas into XHTML 1.0 3rd Edition, some time in the future. [1] http://www.w3.org/TR/2002/NOTE-xhtml1-schema-20020902/#schemas [2] http://www.w3.org/2001/05/xmlschema-errata.html#e2-18 [3] http://www.w3.org/TR/2004/PER-xmlschema-2-20040318/datatypes-with-errata.html#charcter-classes Regards, -- Masayasu Ishikawa / mimasa@w3.org W3C - World Wide Web Consortium
PROBLEM ID: 8415
STATE: Needs Approval
EDIT: N/A
RESOLUTION: None
USER POSITION: None
NOTES:
The commentor has misunderstood section 3.2 - the clause in question means that ONLY attributes of type ID can be used as fragment identifiers - not that such an attribute can ONLY have that meaning and no other. Perhaps we should reword the clause to reduce the change for confusion. Moreover, appendix C has been removed from the recommendation.
ORIGINAL MESSAGE:
Date: Mon, 12 Jul 2004 14:29:22 +0900 (JST) From: Bjoern Hoehrmann <derhoermi@gmx.net> From: Bjoern Hoehrmann <derhoermi@gmx.net> To: www-html-editor@w3.org Subject: XHTML1: Appendix C.13 seems misplaced/flawed Date: Mon, 12 Jul 2004 06:14:06 +0200 Message-ID: <418a100d.1817845062@smtp.bjoern.hoehrmann.de> X-Archived-At: http://www.w3.org/mid/418a100d.1817845062@smtp.bjoern.hoehrmann.de Dear HTML Working Group, Appendix C.13 of the XHTML 1.0 Second Edition Recommendation states: [...] 3. Within the XHTML namespace, user agents are expected to recognize the "id" attribute as an attribute of type ID. Therefore, style sheets should be able to continue using the shorthand "#" selector syntax even if the user agent does not read the DTD. 4. Within the XHTML namespace, user agents are expected to recognize the "class" attribute. Therefore, style sheets should be able to continue using the shorthand "." selector syntax. [...] It is not clear to me what you mean by "Within the XHTML namespace". Do you mean on elements in the XHTML namespace as defined in section 3.1.1 or do you mean attributes in the XHTML namesapce as defined in section 3.1.1 on arbitrary elements? It is also not clear to me why user agents are expected to do as the section suggests, section 3.2 does not cite such a requirement. Do you mean that e.g. if an XHTML 1.0 user agent encounters an XHTML 1.1 document that uses ruby elements, it must not only process the content of the unrecognized attributes, but also process id, class, xml:lang attributes? That would seem inconsistent with section 3.2 which clearly states [...] When a user agent processes an XHTML document as generic XML, it shall only recognize attributes of type ID (i.e. the id attribute on most XHTML elements) as fragment identifiers. [...] as it does not know whether such attributes are ID attributes unless it processes the document type definition which it is not required to do, as far as I understand. But then, this part of section 3.2 does not make much sense to me. I cannot think of a situation where an XHTML user agent would process an XHTML document as "generic XML" and still be considered an XHTML user agent. It seems that XHTML user agents would always process XHTML documents as XHTML documents or they are not XHTML user agents. But then, maybe my confusion is caused by the lack of definition for "generic XML". In either case, if there is such an expectation, you need to clearly state this somewhere, not in the informative Appendix C. That said, it seems that the entire Appendix C.13 seems misplaced in Appendix C as it does not seem to contain guidelines for XHTML authors who wish to deliver their documents to legacy user agents. Could you please clarify what requirements they have to meet in order to do so? If there is no requirement, the appropriate section for the section seems to be section 4, "Differences with HTML 4". regards.
PROBLEM ID: 6397
STATE: Needs Approval
EDIT: N/A
RESOLUTION: Accept
USER POSITION: None
NOTES:
These changes are all implemented.
ORIGINAL MESSAGE:
Date: Wed, 11 Jun 2003 18:31:28 +0900 (JST) From: Masayasu Ishikawa <mimasa@w3.org> Once upon a time, on Mon, 26 Aug 2002 22:08:24 -0500, I wrote: > While working on translating XHTML 1.0 DTDs to XML Schemas, I realized > that the Frameset DTD is not consistent with the Transitional DTD in > some cases. In other words, we've fixed the Transitional DTD but > forgot to fix the Frameset DTD. For example, we've changed the attribute > value for the width/height attributes from %Pixels; to %Length; in > the Transitional DTD, but the Frameset DTD still defines that those > are %Pixels;. In practice those are both CDATA and doesn't really > affect DTD validation, but we'd better issue errata. > > In the Framset Schema I would use intended values. While checking unresolved issues, I realized that PR#748 seems to have disappeared from voyager-issues, together with many other bounced messages last summer. For the record, the issues were as follows: 1) comment for %pre.content; In Transitional DTD: <!-- pre uses %Inline excluding img, object, applet, big, small, font, or basefont --> In Frameset DTD: <!-- pre uses %Inline excluding img, object, applet, big, small, sub, sup, font, or basefont --> We adjusted the content model to exclude sub and sup, so the Frameset DTD is correct here. 2) ATTLIST declaration for img In Transitional DTD: border %Length; #IMPLIED In Frameset DTD: border %Pixels; #IMPLIED It was %Pixels; in HTML4, and back to 1998 we did confirm that it should be %Pixels; rather than %Length; [1]. It's %Pixels; in M12N as well. The Transitional DTD needs to be fixed. 3) ATTLIST declaration for map In Transitional DTD: name CDATA #IMPLIED In Frameset DTD: name NMTOKEN #IMPLIED Although it was CDATA in HTML4, I think NMTOKEN is more appropriate, and the Strict DTD also defined it as NMTOKEN. The Transitional DTD should be changed. 4) ATTLIST declaration for th/td In Transitional DTD: width %Length; #IMPLIED height %Length; #IMPLIED In Frameset DTD: width %Pixels; #IMPLIED height %Pixels; #IMPLIED The Transitional DTD is correct, the Frameset DTD needs to be fixed. There are several other minor differences that don't affect the definition, but I don't bother to issue errata for them. We could adjust them when we publish updated DTDs. [1] http://lists.w3.org/Archives/Member/w3c-html-wg/1998OctDec/0307 Regards, -- Masayasu Ishikawa / mimasa@w3.org W3C - World Wide Web Consortium
PROBLEM ID: 9681
STATE: Needs Approval
EDIT: N/A
RESOLUTION: None
USER POSITION: None
NOTES:
This appendix was removed from the Recommendation.
ORIGINAL MESSAGE:
Date: Tue, 21 Nov 2006 11:19:30 -0600 From: Shane McCarron <shane@aptest.com> David, First, I want to apologize for the delay in responding to your question. I see that some others have chimed in, and that's great! However, since I was one of the people who put C1 and C14 into the spec, I guess I should comment on this and the nature of Appendix C in general. Remember that appendix C is *informative*, not *normative*. It does not specify any requirements at all. It is a collection of suggestions based upon real world experience. Think of it as hints for creating well-formed, valid XML that should work in HTML user agents. If you have content that uses the features of XHTML described in the Appendix, using those features in the manner described should give you the best success rate in the real world. Appendix C *is* referenced from section 5.1, but this does not make the contents of Appendix C requirements. Rather, it says that you can use the text/html document type when serving XHTML 1.0 documents, and if you do following the guidelines in Appendix C will increase the possibility that your document will be processed correctly by HTML user agents - to the extent that HTML user agents ever processing anything correctly, anyway ;-). The XML PI suggestion in C1, for example, is there because certain broken user agents do stupid things when they see a PI. An old user agent on the Mac, for example, would lose its little mind. Another on Windows goes into "quirks" mode if it sees an XML processing instruction. Yet another does content sniffing, so if there are too many PIs (or even whitespace!) at the front of a document before the DOCTYPE it has no idea how to process the document. It is up to you whether these risks are something you and your users are willing to live with or not. To answer your real question though, the purpose of C14 is to demonstrate a mechanism that, if you choose to use it, can provide a pointer to your internal stylesheets that a generic XML processor will correctly interpret. If you care about having your content processed as generic XML, then you can take advantage of this feature and still continue to use internal style sheets in your documents. I would agree that this begs the question "what do I do about external stylesheets?" It is unfortunate that we did not touch on that, but the xml-stylesheet PI is certainly the correct way to reference external stylesheets as well if you need your documents to be processed by a generic XML processor. You are correct that these two suggestions are at odds with one another. This isn't intentional so much as it is a consequence of attempting to serve two very different audiences. As a content author, you need to decide which audience you are dealing with. You are also correct that having this advice in Appendix C is somewhat confusing. It is really there because it is not normative, and also because it is a hint as to how to bridge the gap between XML processors and HTML processors. Thanks for taking the time to present the issue. I think this merits an errata just to clear up the purpose of Appendix C in general. I have copied www-html-editor on this so that it will bet into the HTML Working Group issue tracking system and addressed. Thanks again! -- Shane P. McCarron Phone: +1 763 786-8160 x120 Managing Director Fax: +1 763 786-8180 ApTest Minnesota Inet: shane@aptest.com
PROBLEM ID: 8412
STATE: Needs Approval
EDIT: N/A
RESOLUTION: None
USER POSITION: None
NOTES:
This appendix was removed from the recommendation. In the media types document, this text was updated to make it clearer.
ORIGINAL MESSAGE:
Date: Mon, 12 Jul 2004 14:25:10 +0900 (JST) From: Bjoern Hoehrmann <derhoermi@gmx.net> From: Bjoern Hoehrmann <derhoermi@gmx.net> To: www-html-editor@w3.org Subject: XHTML1: Appendix C.14 seems misplaced and flawed Date: Mon, 12 Jul 2004 06:13:59 +0200 Message-ID: <41871005.1817837411@smtp.bjoern.hoehrmann.de> X-Archived-At: http://www.w3.org/mid/41871005.1817837411@smtp.bjoern.hoehrmann.de Dear HTML Working Group, I told you at least twice already, but I will say it again. Appendix C.14 in the XHTML 1.0 Second Edition Recomendation seems misplaced, it states already in the heading [...] C.14. Referencing Style Elements when serving as XML [...] While the entire appendix is about *serving as HTML*. So what is the section doing there? What is the actual requirement for authors who wish to deliver their XHTML documents to legacy user agents? I am unable to work that out. It seems that this should be mentioned in section 3.1, "Document Conformance". But before you do that let me point out again why this section makes no sense at all. If there is some kind of user agent that does not support <link> to reference style sheets, the <style> element or the style attribute, it is most certainly not a XHTML user agent and would thus most likely not support other XHTML features like hyperlinks, scripts or forms which already makes it a rather questionable effort to introduce redundant markup to somehow improve a completly broken presentation of the document. The user agent would further most likely lack a default style sheet for XHTML documents so that the presentation is likely a broken mess of the possibly colored concatenated character data of the document as the initial value for the 'display' property in CSS 2.0 is 'inline'. I thus completly fail to see how this could possibly add considerable value to a considerable percentage of existing XHTML documents. It does not even make sense for XHTML user agents as those are not required to support the xml-stylesheet processing instruction. And that is just the most significant flaw of the section. regards.
PROBLEM ID: 7087
STATE: Needs Approval
EDIT: N/A
RESOLUTION: None
USER POSITION: None
NOTES:
My recommendation is that we remove the text that explains the algorithm from XHTML 1.0 because there is no point in duplicating content from XML.
ORIGINAL MESSAGE:
Date: Thu, 02 Oct 2003 13:02:24 +0900 (JST) From: Jeff Jackson <jackson@mathcs.duq.edu> From: Jeff Jackson <jackson@mathcs.duq.edu> To: www-html-editor@w3.org Subject: Ambiguity in section 4.7 of XHTML 1.0 (2nd ed) Date: Tue, 30 Sep 2003 17:14:23 -0400 Message-ID: <3F79F22F.20102@mathcs.duq.edu> X-Archived-At: http://www.w3.org/mid/3F79F22F.20102@mathcs.duq.edu Hi, Section 4.7 of the XHTML 1.0 spec (2e) says this: 4.7. White Space handling in attribute values When user agents process attributes, they do so according to Section 3.3.3 <http://www.w3.org/TR/REC-xml#AVNormalize> of [XML <http://www.w3.org/TR/xhtml1/#ref-xml>]: * Strip leading and trailing white space. * Map sequences of one or more white space characters (including line breaks) to a single inter-word space. This seems to be ambiguous, since the XML reference specifies different treatment for CDATA attributes than is specified in the bullets of Section 4.7 above. Thought you might be interested. Jeff Jackson PS For what it's worth, Mozilla 1.4 seems to have followed the XML spec regarding white space in CDATA attribute values.