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
> HTML5 already have 4 *conforming* methods for
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:
>>>
>> 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 ?
Sorry. So your metho
- 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
ha
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:
>
HTML5 already
In my opinion, from HTML5, and not XHTML5, there should also exist a
leading prolog like
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 parsers will treat as a parsing
in
2012/11/29 Leif Halvard Silli
> 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
> > Guideline 9 (even though
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 docume
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 UT
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 docum
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.html&charset=%28detect+automatically%29&doctype=Inline&group
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 (thos
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
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 pa
13 matches
Mail list logo
