|
|
Posted by Alan J. Flavell on 04/16/06 13:50
On Sun, 16 Apr 2006, Thomas Jollans wrote:
> Els wrote:
>
> >> <?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">
> >
> > Take out the <?xml ... line and IE will be in Standards mode and it
> > will center your page like it does in Firefox.
> > That line throws it in Quirksmode. If you want to center it in
> > Quirksmode, use old IE5 method for centering:
> > http://locusmeus.com/html-css/centeringpage.html
>
> you mean a line that has a rightful place in every *standard* XHTML
> document
But (even if that were true), you're not sending *standard* XHTML when
you send it as text/html; you're sending bad HTML, which just happens
to resemble XHTML/1.0 subject to Appendix C, and relying on known
browser (mis)behaviour to fix up the deliberate HTML errors.
IE has no idea what to do with real XHTML (application/xhtml+xml).
Well, I've taught my IE to pass real XHTML across to Seamonkey for
rendering. Not ideal, but better than merely offering to download it.
But the <?xml...> thingy is optional under certain circumstances, and
the present situation (where utf-8 is used) is surely one of those
circumstances.
That's fine for utf-8; now see what it says in section C.1:
http://www.w3.org/TR/2002/REC-xhtml1-20020801/#C_1
- which is almost correct. But this sentence:
|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.
is inaccurate, and incompatible with the explanation in section C.9:
http://www.w3.org/TR/2002/REC-xhtml1-20020801/#C_9
When sending via HTTP with a character encoding specified on the HTTP
Content-type header, then the HTTP value takes precedence (as section
C.9 rightly says), and there's no need to specify the encoding via the
<?xml...> thingy. It doesn't /have/ to be utf-8 or utf-16. However,
this can lead to problems when saving the page, unmodified, to file,
and then attempting to browse it from file, by which time the HTTP
character encoding specification has been lost.
In short, it's safer to use utf-8 everywhere, rather than trying to
use one of the 8-bit encodings (such as iso-8859-1 for Latin-1
languages).
> throws a browser into quirks mode ?! that makes no sence...
IE does what it does. It's your choice whether to adjust to that, or
just design for www-compatible browsers, and leave IE to its own
non-conforming behaviour. In the current situation, the content *is*
still accessible (unlike some of the other IE faults, e.g the peekaboo
bug); a few cosmetic faults are only to be expected on a browser with
such a notorious history of non-conformance to the www interworking
specifications. Your choice, really.
People are finally taking a deliberate decision about which browser to
use, instead of just plugging along with the operating system
component which came with their pee-cee. Maybe you want to author for
discerning readers who were willing to make their own choice; maybe
you want to author for the unthinking masses who know nothing more
than "Open The Internet"; maybe you want to do your best for both - in
the end, it's your choice; we can't tell you what to want.
Personally, I'd recommend staying with HTML/4.01(strict) until it's
feasible to deploy real XHTML and get any real benefits from it.
XHTML/1.0 Appendix C brings essentially no benefits (since it was
designed to be functionally identical to HTML/4.01, expressed in XHTML
syntax), and several problems. Your internal process can perfectly
well be XML-based if you want to use XML-based tools, but for general
WWW purposes I would recommend publishing the result as valid
HTML/4.01(strict).
have fun
Navigation:
[Reply to this message]
|