Newbie's CSS not having an effect.

[Beauregard T. Shagnasty]

That is pretty much what I am complaining you are doing. I have said
why.


It does not make it clear that it is *perfectly OK*. And no one is
saying it is *perfectly bad* to use xhtml and serve it some way.

My recollection is that when Internet Explorer receives XHTML served as
text/html, the browser goes into Quirks Mode. Still true?

Let's see ...
http://www.w3.org/International/articles/serving-xhtml/ (2007-07-13)

Apparently, the Quirks Mode thing was fixed with IE7, so if you don't
care about visitors still using IE6 or less, go ahead and use
"text/html". And if you do use "application/xhtml+xml", all IE versions
will just offer to "download the file." Still true with IE8? I have no
IE (Windows) computers to test it anymore.

 

[Doug Miller]

That is pretty much what I am complaining you are doing. I have said
why.


It does not make it clear that it is *perfectly OK*.

Perhaps you need to read that quote from the W3C again.

And no one is
saying it is *perfectly bad* to use xhtml and serve it some way.

Perhaps you need to read Jonathon's post again.

 

[C A Upsdell]

dorayme wrote:
My recollection is that when Internet Explorer receives XHTML served as
text/html, the browser goes into Quirks Mode. Still true?

Never true, exactly. There was a problem if the DOCTYPE was not on the
first line, and it might not be on the first line if the encoding was
neither UTF-8 nor UTF-16 and if the encoding could not be determined by
a higher level protocol, since in such cases an XML declaration was
necessary prior to the DOCTYPE to specify the encoding. But if the
DOCTYPE was on the first line, IE correctly set the mode appropriate to
the DOCTYPE.

 

[dorayme]

Perhaps you need to read that quote from the W3C again.

This one: "XHTML 1.0 can be served as HTML or XML. If you serve it as
XML, use the MIME type application/xhtml+xml." ?

Note that this is a *summary remark* for what went before it.

I don't see any use of the word "proper" in this, nor do I see any heavy
leaning on some particular meaning of it. So it is a matter of your
deductions and interpretations. JL was interested in pointing out a few
things where it would have been inappropriate to use the word "proper"
when he thinks so poorly of the practice for good reasons.

Perhaps you need to read Jonathon's post again.

I have it framed. It is one of the most beautiful things on my wall now.
I see no implication in it that serving it as html is perfectly bad as
opposed to just bad or not very practical at the moment.

 

[Jonathan N. Little]

You made a general statement that XHTML is properly served only as XML. That's
not true.

And that's what I objected to.

Sure your *can* send any XHTML as text/html but unless you parse as xml
your lose the features of XHTML that were to make it "better" than HTML.
And as an added bonus it will typically throws IE in to quirks mode
usually blowing your layout![*] So putting the word games aside, if you
are not using the features of XHTML that require XML parsing there is no
advantage of using XHTML over HTML, and may be a disadvantage.


[*] Plenty of examples online of "experts" that bork their layouts using
XHTML throwing IE in to quirks mode. Then the "fix" it by tweaking their
stylesheets only to find it then borks their layout for "modern"
browsers, and then they "fix" everything with CSS hacks and conditional
comments...

 

[Jonathan N. Little]

Never true, exactly. There was a problem if the DOCTYPE was not on the
first line, and it might not be on the first line if the encoding was
neither UTF-8 nor UTF-16 and if the encoding could not be determined by
a higher level protocol, since in such cases an XML declaration was
necessary prior to the DOCTYPE to specify the encoding. But if the
DOCTYPE was on the first line, IE correctly set the mode appropriate to
the DOCTYPE.

But doesn't the XML declaration, e.g.,

<?xml version="1.0" encoding="UTF-8"?>

have to precede the DOCTYPE in order to be a valid XML document?

 

[C A Upsdell]

But doesn't the XML declaration, e.g.,

<?xml version="1.0" encoding="UTF-8"?>

have to precede the DOCTYPE in order to be a valid XML document?

If you read the XHTML 1.0 spec, section 3.1.1, you will find that what I
said is correct. The XML declaration may be omitted if the encoding is
UTF-8 or UTF-16, or if the encoding can be specified by a higher level
protocol.

 

[C A Upsdell]

Sure your *can* send any XHTML as text/html but unless you parse as xml
your lose the features of XHTML that were to make it "better" than HTML.

There is another, unrelated benefit from using XHTML. XHTML must be
well formed to be valid: HTML need not be. Unpleasant problems can
lurk when the code is not well formed.

And as an added bonus it will typically throws IE in to quirks mode

"Typically"? Not true, as is discussed elsewhere in this thread: it
only threw *old* versions of IE into quirks mode, and only when it was
necessary to precede the DOCTYPE with an XML declaration. I use XHTML
for all but one of my sites, and none throws IE into quirks mode unless
it is IE 4 or 5, which *have* no standards mode. IE 4 is extinct; IE 5
is extinct except for a few sites which attract a disproportionate
number of IE 5 users.

 

[Doug Miller]

This one: "XHTML 1.0 can be served as HTML or XML. If you serve it as
XML, use the MIME type application/xhtml+xml." ?

Note that this is a *summary remark* for what went before it.

I don't see any use of the word "proper" in this, nor do I see any heavy
leaning on some particular meaning of it. So it is a matter of your
deductions and interpretations. JL was interested in pointing out a few
things where it would have been inappropriate to use the word "proper"
when he thinks so poorly of the practice for good reasons.


I have it framed. It is one of the most beautiful things on my wall now.

I see no implication in it that serving it as html is perfectly bad as
opposed to just bad or not very practical at the moment.

In that case, I think you need to read it yet *again*. It certainly did imply
that serving XHTML as HTML was improper -- and that's not correct.

 

[dorayme]

In that case, I think you need to read it yet *again*. It certainly did imply
that serving XHTML as HTML was improper -- and that's not correct.

You will succeed in the end. I will see what he says as incorrect by a
process called Lassitudo Ignoratum. There are some benefits to authors
using XHTML. But if you look at the present state of affairs, roundly at
everything relevant, I am saying it may be too heavy to insist too
loudly on the properness of the practice. I admire your tenacity though.
The heat in Sydney is sapping my will.

(btw, I like the business of XHTML (served as whatever) not supporting
deprecated things. See how I am trying to end on a nice note? Never mind
that I have an ulterior motive. Sharks have been seen and I am about to
go for a swim and I want to build up brownie points with any Higher
Powers that might exist).

 

[Jonathan N. Little]

There is another, unrelated benefit from using XHTML. XHTML must be well
formed to be valid: HTML need not be. Unpleasant problems can lurk when
the code is not well formed.

Ah that would be true IF it was parsed as XML, (you get that ugly yellow
error page in Firefox), but since you cannot with IE, IE just sees bad
HTML not well formed or otherwise.

"Typically"? Not true, as is discussed elsewhere in this thread: it only
threw *old* versions of IE into quirks mode, and only when it was
necessary to precede the DOCTYPE with an XML declaration. I use XHTML
for all but one of my sites, and none throws IE into quirks mode unless
it is IE 4 or 5, which *have* no standards mode. IE 4 is extinct; IE 5
is extinct except for a few sites which attract a disproportionate
number of IE 5 users.

Okay, but still as as text/html you cannot use the XML features so again
I say why bother? Just use HTML, make it valid and be done with it! When
either MS decides to have IE support XHTML, or it dwindles to
insignificance, there is not much benefit in using XHTML.

 

[C A Upsdell]

Ah that would be true IF it was parsed as XML, (you get that ugly yellow
error page in Firefox), but since you cannot with IE, IE just sees bad
HTML not well formed or otherwise.

You say that IE just sees bad HTML: but it correctly processes what it
sees if Appendix C of the XHTML specification is observed, hence calling
the code "bad" is pointless and misleading.

Okay, but still as as text/html you cannot use the XML features so again
I say why bother?

Because, as I pointed out earlier, use of XHTML guarantees that the
validated code will be well formed, and this eliminates certain classes
of coding errors and browser bugs, and this helps make it possible to
produce better pages in less time.

 

[Jonathan N. Little]

Jonathan N. Little wrote:

You say that IE just sees bad HTML: but it correctly processes what it
sees if Appendix C of the XHTML specification is observed, hence calling
the code "bad" is pointless and misleading.

But if it is seeing it as HTML and there is an error it will not fail as
it would as XML, right?

Because, as I pointed out earlier, use of XHTML guarantees that the
validated code will be well formed, and this eliminates certain classes
of coding errors and browser bugs, and this helps make it possible to
produce better pages in less time.

And this is somehow better than just validating your code?

 

[dorayme]

Because, as I pointed out earlier, use of XHTML guarantees that the
validated code will be well formed, and this eliminates certain classes
of coding errors and browser bugs, and this helps make it possible to
produce better pages in less time.

This is not very convincing to those of us who simply out of habit,
mostly:

1. Validate HTML 4.01 Strict.

2. Avoid deprecated markup and use CSS with what is not deprecated.

3. Close our elements assisted ably by a quality text editor like BBEDit
(I have an older version already) that when I command control Y not only
validates but refuses to let me get away with not closing such as
paragraph elements.

As for browser bugs, I will be happy to be informed/reminded which ones
I am running a risk with after following the last three numbered points.

 

[C A Upsdell]

But if it is seeing it as HTML and there is an error it will not fail as
it would as XML, right?
???


And this is somehow better than just validating your code?

Yes

 

[C A Upsdell]

3. Close our elements assisted ably by a quality text editor like BBEDit
(I have an older version already) that when I command control Y not only
validates but refuses to let me get away with not closing such as
paragraph elements.

Sadly, my editor has no option to force the code to be well formed, the
lint program I have demands well formed code only for XHTML, and of
course validators demand well formed code only for XHTML.

As for browser bugs, I will be happy to be informed/reminded which ones
I am running a risk with after following the last three numbered points.

Your methodology achieves the same results as mine, so the risks are
comparable. But your methodology is not available to me.

 

[Jonathan N. Little]

???

When a UA is handling a document XML if it encounters an error, it is
not supports to "guess" error handling and display the document, but
rather fail with an error. The well-formed requirement of XML and XHTML.
But HTML which is SGML-based has a more flexible syntax. When it
encounters an error, contrary to XML with HTML UA's are encouraged to
"try" display document

<http://www.w3.org/TR/html4/appendix/notes.html#notes-invalid-docs>

So if an XHTML documents is not parsed as XML and instead handled as
HTML what happens with an invalid document?

To illustrate my point, as text/html:

<http://www.littleworksstudio.com/temp/usenet/xhtml1.0-invalid?text/html>

As application/xhtml+xml:
<http://www.littleworksstudio.com/temp/usenet/xhtml1.0-invalid?application/xhtml+xml>

As application/xml:
<http://www.littleworksstudio.com/temp/usenet/xhtml1.0-invalid?application/xml>

As test/xml:
<http://www.littleworksstudio.com/temp/usenet/xhtml1.0-invalid?text/xml>

So if you are not using XML features and just going to send well-formed
HTML anyway, then just use well formed HTML.

 

[Neredbojias]

To illustrate my point, as text/html:

<http://www.littleworksstudio.com/temp/usenet/xhtml1.0-invalid?text/ht
ml>

As application/xhtml+xml:
<http://www.littleworksstudio.com/temp/usenet/xhtml1.0-invalid?applica
tion/xhtml+xml>

As application/xml:
<http://www.littleworksstudio.com/temp/usenet/xhtml1.0-invalid?applica
tion/xml>

As test/xml:
<http://www.littleworksstudio.com/temp/usenet/xhtml1.0-invalid?text/xm
l>

So if you are not using XML features and just going to send
well-formed HTML anyway, then just use well formed HTML.

Checkout this *HTML* page:

http://www.neredbojias.net/babesX.php

(-which I find particularly interesting in Safari.)

It's served as application/xhtml+xml to all but ie via server-side
script, and the w3c validator handles it fine. (Unerrored page without
the "X".)