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
2012/11/28 Leif Halvard Silli xn--mlform-...@xn--mlform-iua.no
Philippe Verdy, Wed, 28 Nov 2012 04:50:06 +0100:
detects a violation of the required
extended prolog (sorry, the HTML5 document declaration, which is not
a
valid document declaration for XHTML or for HTML4 or before or even
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
On 11/26/2012 08:42 PM, Marc Durdin wrote:
Somewhat ironically, both Firefox and Internet Explorer, on my machine
at least, detect this page is encoded with ISO-8859-1 and cp-1252
respectively, instead of UTF-8. It seems they both ignore the XML
prolog which is the only place where the encoding
Simon,
There's no sign of HTML5 on that page. The head of the file matches all
XHTML 1.1 requirements and passes all checks on validator.w3.org. Now, why
would Firefox follow anything from HTML5 spec here?
-Behnam
On Tue, Nov 27, 2012 at 3:37 AM, Simon Montagu smont...@smontagu.orgwrote:
On
On 11/27/2012 11:19 AM, Behnam Esfahbod ZWNJ wrote:
Simon,
There's no sign of HTML5 on that page. The head of the file matches all
XHTML 1.1 requirements and passes all checks on validator.w3.org
http://validator.w3.org. Now, why would Firefox follow anything from
HTML5 spec here?
As I
HTML5 does not reference the Content-Type: text/html header as enough to
qualify as meaning HTML5.
HTML5 **requires** its own prolog (i.e. its basic document declaration
**within** the document itself, for the HTML syntax, or its FULL document
declaration for the XML/XHTML syntax).
So Firefox is
I've never said that user agents had to 'write the prolog. It's the
reverse: yes authors have to write a prolog (but the prolog is perfect here
so this is not the fault of the author). Why do have to use this prolog,
it's exactly because user agents will have to read it (not write it),
as it is
Also you make a confusion in the sense that HTML5 must be able to parse
HTML4.
This is true, but this does not mean that they will be able to render it
fully. HTML5 is not fully upward compatible with past versions (and the
case of the identification of encodings is an example where it is
Philippe Verdy, Tue, 27 Nov 2012 15:39:43 +0100:
I've never said that user agents had to 'write the prolog. It's the
reverse: yes authors have to write a prolog (but the prolog is perfect here
so this is not the fault of the author).
XML has (or more correctly: can have) a prolog. HTML does
Looks OK here, but that is probably FreeType doing its magic as usual.
Regards,
Khaled
On Tue, Nov 27, 2012 at 02:29:45AM +0100, Philippe Verdy wrote:
Also I really don't like the Deseret font:
{font-family: CMU; src: url(CMUSerif-Roman.ttf) format(truetype);}
that you have inserted in your
A ! I see now the problem: the XHTML file is being served as HTML
instead of XHTML (but this is not invalid for XHTML 1).
But anyway you're also right that the XML prolog found is NOT valid for
HTML5 when the file is served as HTML instead of XHTML. This should
immediately trigger the fact
No. Freetype is not involved here for the ugly rendering (on screen) under
Windows of the unhinted CMU font provided by the page. May be this looks
OK on Mac (if Safari is autohinting the font itself, despite the font is
not autohinted itself ; I'm not sure that Safari on MacOS processes TTF
fonts
Philippe Verdy, Tue, 27 Nov 2012 21:07:31 +0100:
A ! I see now the problem: the XHTML file is being served as HTML
instead of XHTML (but this is not invalid for XHTML 1).
Both SGML-based HTML4 and XML-based XHTML 1 operate with syntax rules
that are not - and has never been - compatible
On 11/27/2012 5:39 AM, Masatoshi Kimura wrote:
(2012/11/27 20:27), Philippe Verdy wrote:
Could you please stop spreading an unfounded rumor such as Firefox is
wrong because it ignores the lacking of HTML5 prolog?
Getting Philippe to stop spreading unfounded anything is a near
impossible
2012/11/27 Leif Halvard Silli xn--mlform-...@xn--mlform-iua.no
The fact that XHTML 1 permits the XML prolog regardless how the
document is served, is just a shortcoming of the XHTML 1 specification.
No, it was by design. Making HTML an application of XML. Only XML but
with all rules of XML.
Philippe Verdy, Wed, 28 Nov 2012 01:10:45 +0100:
2012/11/27 Leif Halvard Silli
The fact that XHTML 1 permits the XML prolog regardless how the
document is served, is just a shortcoming of the XHTML 1 specification.
No, it was by design. Making HTML an application of XML. Only XML but
with
2012/11/28 Leif Halvard Silli xn--mlform-...@xn--mlform-iua.no
For
a new version of the validator, that ask more of those questions,
please try http://validator.w3.org/nu/ - it happens to for the most
part be developed by one of the Firefox developers, btw. And it allows
you to check
detects a violation of the required
extended prolog (sorry, the HTML5 document declaration, which is not a
valid document declaration for XHTML or for HTML4 or before or even for
SGML, due to the unspecified schema after the shema short name), it
should
catch this exception to try
Philippe Verdy, Wed, 28 Nov 2012 04:23:10 +0100:
2012/11/28 Leif Halvard Silli xn--mlform-...@xn--mlform-iua.no
For
a new version of the validator, that ask more of those questions,
please try http://validator.w3.org/nu/ - it happens to for the most
part be developed by one of the Firefox
Philippe Verdy, Wed, 28 Nov 2012 04:50:06 +0100:
detects a violation of the required
extended prolog (sorry, the HTML5 document declaration, which is not a
valid document declaration for XHTML or for HTML4 or before or even for
SGML, due to the unspecified schema after the shema short name),
Or, if one prefers:
http://www.井作恆.net/XKCD/1137.html
On 2012年11月21日, at 上午10:22, Deborah Goldsmith golds...@apple.com wrote:
http://xkcd.com/1137/
Finally, an xkcd for Unicoders. :-)
Debbie
...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of John H. Jenkins
Sent: Tuesday, 27 November 2012 1:15 AM
To: Unicode Mailing List
Subject: Re: xkcd: LTR
Or, if one prefers:
http://www.井作恆.net/XKCD/1137.html
On 2012年11月21日, at 上午10:22, Deborah Goldsmith
golds...@apple.commailto:golds
I wonder why this IDN link appears to me using sinograms in its domain
name, instead of Deseret letters. The link works, but my browser cannot
display it and its displays the Punycoded name instead without decoding it.
This is strange because I do have Deseret fonts installed and I can
view
] *On
Behalf Of *John H. Jenkins
*Sent:* Tuesday, 27 November 2012 1:15 AM
*To:* Unicode Mailing List
*Subject:* Re: xkcd: LTR
** **
Or, if one prefers:
** **
http://www.井作恆.net/XKCD/1137.html
** **
On 2012年11月21日, at 上午10:22, Deborah Goldsmith golds...@apple.com wrote
That's because the domain does, in fact, use sinograms and not Deseret. (It's
my Chinese name.)
On 2012年11月26日, at 下午1:54, Philippe Verdy verd...@wanadoo.fr wrote:
I wonder why this IDN link appears to me using sinograms in its domain name,
instead of Deseret letters. The link works, but my
Of Philippe Verdy
Sent: Tuesday, 27 November 2012 7:49 AM
To: Marc Durdin
Cc: John H. Jenkins; Unicode Mailing List
Subject: Re: xkcd: LTR
Not a bug of your machine or browser; this is a problem of the webserver in its
metadata.
The transport layer indicates to the client another encoding in HTTP
Also I really don't like the Deseret font:
{font-family: CMU; src: url(CMUSerif-Roman.ttf) format(truetype);}
that you have inserted in your stylesheet (da.css) which is used to display
the whole text content of the page, including the English Latin text at the
bottom part. This downloaded font is
Did you try add the xml:lang=en-Dsrt pseudo-attribute to the html
element, as suggested by the W3C Unicorn validator ?
http://validator.w3.org/unicorn/check?ucn_uri=www.xn--elqus623b.net%2FXKCD%2F1138.htmlucn_lang=frucn_task=conformance#
May be this could help IE and Firefox that can't figure
Anyway, you could at least use Segoe UI before your CMU font, even if Segoe
UI works only in Windows, but it has a decent support for Deseret. May be
there's a good font also on your Mac that ships with some recent version of
Mac OS, which you could list too. Leaving your CMU after them, only for
http://xkcd.com/1137/
Finally, an xkcd for Unicoders. :-)
Debbie
42 matches
Mail list logo
