So we would be in a case where it's impossible to warranty full
compatiblity or interoperability between the two concurrent standards from
the same standard body, and promissing the best interoperoperability with
past flavors of HTML (those past flavors are still not in the past
given that two of
Philippe Verdy, Thu, 29 Nov 2012 10:11:13 +0100:
So we would be in a case where it's impossible to warranty full
compatiblity or interoperability between the two concurrent standards from
the same standard body, and promissing the best interoperoperability with
past flavors of HTML (those
You're wrong. XHTML1 is integrated in the W3C validator and recognized
automatically.
The document you cite in the XHTML1 specs has just not been updated.
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.xn--elqus623b.net%2FXKCD%2F1137.htmlcharset=%28detect+automatically%29doctype=Inlinegroup=0
Philippe Verdy, Thu, 29 Nov 2012 13:26:28 +0100:
You're wrong. XHTML1 is integrated in the W3C validator and
recognized automatically.
Indeed, yes. What I meant by doesn't integrate XHTML1' was that
Unicorn doesn't 100% adhere to the two sections of XHTML1 that I
quoted.[1][2]
The document
And you forget the important part of Appendix A:
*Consequence*: Remember, however, that when the XML declaration is not
included in a document, AND the character encoding is not specified by a
higher level protocol such as HTTP, the document can only use the default
character encodings UTF-8 or
Philippe Verdy, Thu, 29 Nov 2012 14:24:29 +0100:
And you forget the important part of Appendix A:
*Consequence*: Remember, however, that when the XML declaration is not
included in a document, AND the character encoding is not specified by a
higher level protocol such as HTTP, the document
2012/11/29 Leif Halvard Silli xn--mlform-...@xn--mlform-iua.no
Philippe Verdy, Thu, 29 Nov 2012 14:24:29 +0100:
...
But why ? Isn't UTF-8 (or alternatively UTF-16) already the default
encoding of XHTML?
If not, then we should file a bug in the W3C Validator for not honoring
the
In my opinion, from HTML5, and not XHTML5, there should also exist a
leading prolog like
?html version=5.0 encoding=utf-8
For XHTML5, we will continue using the XML prolog ; but it *may* be
followed by the html prolog, without needing to repeat the optional
encoding pseudo-attribute, which XML
Philippe Verdy, Thu, 29 Nov 2012 16:10:14 +0100:
Thanks a lot, this was really hard to see and understand, because I
was only reading the XHTML specs, and the Validator did not complain.
Glad to find we are no the same page!
Philippe Verdy, Thu, 29 Nov 2012 16:27:13 +0100:
?html version=5.0
- Method 1 (the BOM) is only goof for UTF-16. not reliable for UTF-8 whuch
is still the default for XHTML (and where the BOM is not always present).
- Method 2 is working sometimes, but is not practicle for many servers that
you can't configure to change their content-type for specific pages all
Philippe Verdy, Thu, 29 Nov 2012 19:11:42 +0100:
2012/11/29 Leif Halvard Silli:
Philippe Verdy, Thu, 29 Nov 2012 16:27:13 +0100:
?html version=5.0 encoding=utf-8
Thus I can guarantee you that your idea about at method number 9, is
not going to be met with enthusiasm.
- Method 5 is where ?
Note that I challenge the term conforming you use, given that HTML5 is
still not released, so its conformance is still not formally defined. The
nu validator is still expliitly marked by the W3C as experimental.
2012/11/29 Leif Halvard Silli xn--mlform-...@xn--mlform-iua.no
HTML5 already have
Philippe Verdy, Wed, 28 Nov 2012 11:02:45 +0100:
In this case, Firefox and IE should not even be able to render
*any* XHTML page because it violates the HTML5 standard.
(1) The page in question (http://www.xn--elqus623b.net/XKCD/1137.html)
is (from a source code point of view) a pure XHTML
13 matches
Mail list logo
