XHTML 1.0 Second Edition Open Issues

25 May 2009

This version:

http://www.w3.org/MarkUp/2009/xhtml1-issues-20090525.html

Editors:

Shane McCarron, Applied Testing and Technology, Inc.

Copyright © 2009 W3C^® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.

Abstract

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.

Status of this document

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.

Table of Contents

1. XHTML-1.0-SE

1.1 XHTML1: What is an "isindex element"?

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--
  

1.2 XHTML1: XML Namespaces compliance

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.
  

1.3 [ERRATA] xhtml 1.0 strict dtd: onmouseover

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"
    >

1.4 An error in XHTML 1.0 SE

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
  
  

1.5 XHTML1: What's wrong with -- in script/style?

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--
  

1.6 name attribute on img and form in XHTML 1.0 Strict

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.
  

1.7 XHTML1: Appendix C.12 seems misplaced

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., &reg; 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., &reg; 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!
  

1.8 XHTML1: Appendix C.10 seems misplaced

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.
  

1.9 [XHTML 1.0] C.12 Using Ampersands in Attribute Values (and Elsewhere)

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., &reg; 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
  

1.10 XHTML1: What are "white space characters"?

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.
  

1.11 HTML 4.01 no <ins> in <pre>?

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 />
        &amp;&amp; notcorrupt(rcvpkt)<br />
        <ins>getacknum(rcvpkt)&gt;=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)&gt;=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 />
         &amp;&amp; notcorrupt(rcvpkt)<br />
         <ins>getacknum(rcvpkt)&gt;=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 &amp; 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) &gt;
          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 />
          &amp;&amp; notcorrupt(rcvpkt)<br />
          <ins>getacknum(rcvpkt)&gt;=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 />
  >     &amp;&amp; notcorrupt(rcvpkt)<br />
  >     <ins>getacknum(rcvpkt)&gt;=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)&gt;=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 />
  >      &amp;&amp; notcorrupt(rcvpkt)<br />
  >      <ins>getacknum(rcvpkt)&gt;=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 &amp; 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) &gt;
  >       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 />
  >       &amp;&amp; notcorrupt(rcvpkt)<br />
  >       <ins>getacknum(rcvpkt)&gt;=base</ins>
  >       </pre>
  >     </dd>
  >  </dl>
  > <p>[Blah blah blah]</p>
  > </body>
  > </html>
  > - - - >8 - - - [enclosure ends] - - - >8 - - -
  > 
  > 
  > 
  > 
  > 
  

1.12 XHTML1: Clarification of Appendix C.9

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.
  

1.13 XHTML1: Suggested improvements to Appendix C

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
  
  

1.14 XHTML1: Implementability of Appendix C

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.
  

1.15 Difference of UI events' attributes in XHTML 1.0 Strict DTD

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
  >
  >
  >
  

1.16 XHTML1: Appendix C.6 seems misplaced

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
  

1.17 XHTML1: Appendix C.8 seems misplaced

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.
  

1.18 Misleading passage in xhtml reccomendation

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
  

1.19 XHTML1: Appendix C.15 seems misplaced

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.&nbsp; However, remember that from a validation perspective this change
  to the specification will have no effect.&nbsp; 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!
  

1.20 typo in a comment in the DTD (sup/sub)

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/

1.21 Re: XHTML 1.0 2nd ed. Sect. 4.3 and non-declared-EMPTY empty elements (PR#724)

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
  
  

1.22 XHTML 1.0: Normative References

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
  
  

1.23 XHTML 1.0: Comment processing

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.
  

1.24 XHTML1: Appendix C.11 seems misplaced

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.
  

1.25 [XHTML 1 and 1.1] Activating links within Object.

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
  

1.26 XHTML1: (Consistency of) Language Information

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.
  

1.27 Is zero width space white-space?

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&#x200b;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&#x200b;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&#x200b;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 &#x200b; (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&#x200b;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?
  > 
  > 
  > 

1.28 XHTML1: What is an "XML document"?

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.
  

1.29 [xhtml1-schema] Problem arising from XML Schema erratum

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
  

1.30 XHTML1: Appendix C.13 seems misplaced/flawed

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.
  

1.31 Re: [xhtml1] Frameset DTD inconsistent with Transitional DTD

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

1.32 Re: XHTML 1.0, section C14

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
  
  

1.33 XHTML1: Appendix C.14 seems misplaced and flawed

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.
  

1.34 Ambiguity in section 4.7 of XHTML 1.0 (2nd ed)

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.