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 11 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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: 6227
STATE: Closed
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: 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: 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: 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: 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.
REPLY 1:
From: Shane McCarron <voyager-issues@mn.aptest.com> Date: Thu May 28 00:48:57 2009 We believe you have 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. Moreover, appendix C has been removed from the recommendation. > > 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: 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.