XHTML Strict vs Basic Madness

[Philipp Lenssen]

I've tested some of the new Nokia 6600 functionality. It ships with
WAP2 and XHTML Support (it says). What it does is check the Doctype --
if it's not the XHTML Mobile Profile Doctype, but a XHTML1.0 Strict
one, the media-handheld CSS is _ignored_. Only with the Nokia Doctype,
the CSS is used. I find this really annoying as it goes against the
whole idea of media-independent XHTML Strict along with stylesheets.

On the good side, WML seems to be running but only for
backwards-compatibility, and pretty much any HTML can be rendered --
and XHTML1 Strict using CSS2 naturally fares much better than most
pages here.

Still, if I want to style my already working pages, I need to make a
redundant copy, or change to XHTML Basic Doctype, which would probably
confuse half dozen Doctype-sniffers on the desktop-platform. It's the
Netscape 4 desaster all over again.
Samples I used:

Mobile DTD (uses handheld-CSS with Nokia):
<http://outer-court.com/mobile/index.html>

1.0 Strict DTD (lacks CSS support with Nokia)
<http://outer-court.com/mobile/test.html>

[Anne van Kesteren]

Philipp Lenssen wrote:

I've tested some of the new Nokia 6600 functionality. It ships with
WAP2 and XHTML Support (it says). What it does is check the Doctype --
if it's not the XHTML Mobile Profile Doctype, but a XHTML1.0 Strict
one, the media-handheld CSS is _ignored_. Only with the Nokia Doctype,
the CSS is used. I find this really annoying as it goes against the
whole idea of media-independent XHTML Strict along with stylesheets.
Another DOCTYPE, means other elements. There is something to say for
Nokia's behavior.
On the good side, WML seems to be running but only for
backwards-compatibility, and pretty much any HTML can be rendered --
and XHTML1 Strict using CSS2 naturally fares much better than most
pages here.

Still, if I want to style my already working pages, I need to make a
redundant copy, or change to XHTML Basic Doctype, which would probably
confuse half dozen Doctype-sniffers on the desktop-platform. It's the
Netscape 4 desaster all over again.
XHTML Basic doesn't support scripting and derives (sp?) from the XHTML
modularization which means that it's content-type should be
application/xhtml+xml, a Internet Explorer disaster as well ;-).

Samples I used:

Mobile DTD (uses handheld-CSS with Nokia):
<http://outer-court.com/mobile/index.html>

1.0 Strict DTD (lacks CSS support with Nokia)
<http://outer-court.com/mobile/test.html>

--
Anne van Kesteren
<http://www.annevankesteren.nl/>

[Philipp Lenssen]

Anne van Kesteren wrote:

Philipp Lenssen wrote:

I've tested some of the new Nokia 6600 functionality. It ships with
WAP2 and XHTML Support (it says). What it does is check the Doctype
-- if it's not the XHTML Mobile Profile Doctype, but a XHTML1.0
Strict one, the media-handheld CSS is ignored. Only with the Nokia
Doctype, the CSS is used. I find this really annoying as it goes
against the whole idea of media-independent XHTML Strict along with
stylesheets.
Another DOCTYPE, means other elements. There is something to say for
Nokia's behavior.

But XHTML Basic is just a Subset of XHTML Strict...
They should just render Strict and ignore what they want to ignore...

XHTML Basic doesn't support scripting and derives (sp?) from the
XHTML modularization which means that it's content-type should be
application/xhtml+xml, a Internet Explorer disaster as well ;-).

Theoretically yes, though actually Nokia doesn't seem to care about the
content-type. I serve HTML. (I wonder how that is connected to the
situation.)

Actually, I should check if it works with the Basic Doctype at all --
what I was serving the first time to test was the Nokia Mobile Profile
Doctype.

I wonder does anybody know problems with XHTML Basic Doctype and
popular doctype-sniffing?

[Anne van Kesteren]

Philipp Lenssen wrote:

But XHTML Basic is just a Subset of XHTML Strict...
They should just render Strict and ignore what they want to ignore...
I'm not sure if a browser is supposed to do that. But if you are not
serving it as XML, the browser probably is.
Theoretically yes, though actually Nokia doesn't seem to care about the
content-type. I serve HTML. (I wonder how that is connected to the
situation.)

Actually, I should check if it works with the Basic Doctype at all --
what I was serving the first time to test was the Nokia Mobile Profile
Doctype.
That would indeed come in handy.
I wonder does anybody know problems with XHTML Basic Doctype and
popular doctype-sniffing?

Mozilla will stay in standard mode and I think Internet Explorer 6 will
as well (older IE's didn't check the doctype). Not sure about Opera and
Mac browsers though.
--
Anne van Kesteren
<http://www.annevankesteren.nl/>

[Philipp Lenssen]

Anne van Kesteren wrote:

Philipp Lenssen wrote:

Actually, I should check if it works with the Basic Doctype at all
-- what I was serving the first time to test was the Nokia Mobile
Profile Doctype.

That would indeed come in handy.

OK, Nokia 6600 with Symbian OS 7/ WAP2 XHTML1 Support does handle the
XHTML Basic Doctype good as well (it will load the handheld CSS -- e.g.
<http://outer-court.com/mobile/basic.html>).
It doesn't care much about the content-type (it doesn't need the XML
content-type).

[Henri Sivonen]

In article <bt************@ID-203055.news.uni-berlin.de>,
"Philipp Lenssen" <in**@outer-court.com> wrote:

I've tested some of the new Nokia 6600 functionality. It ships with
WAP2 and XHTML Support (it says). What it does is check the Doctype --
if it's not the XHTML Mobile Profile Doctype, but a XHTML1.0 Strict
one, the media-handheld CSS is _ignored_. Only with the Nokia Doctype,
the CSS is used. I find this really annoying as it goes against the
whole idea of media-independent XHTML Strict along with stylesheets.
If that's really what happens, it is very, very wrong. :-(

I don't have a Nokia phone to test with, but feedback about the light
version of Macsanomat (http://macsanomat.com/lite/) can be summarized as
follows:
* T68i works except proper quotes and dashes show up as rectangles
* P800 (default browser--not Opera) is reported to work
* 3650 breaks non-ASCII (Why? According to Nokia, UTF-8 is supported.
And regardless of what Nokia says, every XML processor MUST support
UTF-8. Some blame the gateways.)
* Some other Nokia phone doesn't work (details not specified)
* No feedback about Opera, yet
Still, if I want to style my already working pages, I need to make a
redundant copy, or change to XHTML Basic Doctype, which would probably
confuse half dozen Doctype-sniffers on the desktop-platform.
You shouldn't be serving XHTML Basic as text/html and doctype sniffing
is supposed to only apply to text/html in desktop browsers. (Do you have
proof to the contrary?)
Mobile DTD (uses handheld-CSS with Nokia):
<http://outer-court.com/mobile/index.html>

1.0 Strict DTD (lacks CSS support with Nokia)
<http://outer-court.com/mobile/test.html>

FWIW, my tests are at http://iki.fi/hsivonen/test/mobile/

--
Henri Sivonen
hs******@iki.fi
http://iki.fi/hsivonen/
Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html

[Henri Sivonen]

In article <bt**********@reader11.wxs.nl>,
Anne van Kesteren <ma**@annevankesteren.nl> wrote:

Another DOCTYPE, means other elements.

No. The identity of the element should be bound to the XHTML namespace.
Paying attention to the doctype is bogus.

In practical terms, if an app needs to know something about an XML
document that isn't exposed via the ContentHandler interface in SAX, the
app is highly likely broken in some way.

--
Henri Sivonen
hs******@iki.fi
http://iki.fi/hsivonen/
Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html

[Henri Sivonen]

In article <bt************@ID-203055.news.uni-berlin.de>,
"Philipp Lenssen" <in**@outer-court.com> wrote:

OK, Nokia 6600 with Symbian OS 7/ WAP2 XHTML1 Support does handle the
XHTML Basic Doctype good as well (it will load the handheld CSS -- e.g.
<http://outer-court.com/mobile/basic.html>).

What about DTDless XHTML?

--
Henri Sivonen
hs******@iki.fi
http://iki.fi/hsivonen/
Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html

[Philipp Lenssen]

Henri Sivonen wrote:

You shouldn't be serving XHTML Basic as text/html and doctype
sniffing is supposed to only apply to text/html in desktop browsers.
(Do you have proof to the contrary?)

But I must serve XHTML as text/html for downwards-compatibility, right?!

So what to do to serve both my phone (and similar ones) plus common
browsers?

In any case, the WWW and its HTML at whole is almost unusable on this
phone, even though Nokia manages interprets all sorts of HTML (it
breaks up tables etc.). But then you'll end up with lots of useless
content clutter still. Or servers don't serve at all (tested with
German Spiegel Online). So I decided that I'll write a simple RSS to
XHTML Basic converter which will also try to convert the follow-up
linked pages. I need to program and upload scripts to my server to make
this Nokia XHTML really useful, and then only for the world of RSS.
That's a bad situation. Same goes for Google content. I posted the
summary to my blog:
<http://blog.outer-court.com/archive/...#1073293481655
73660>

[Philipp Lenssen]

Henri Sivonen wrote:

In article <bt************@ID-203055.news.uni-berlin.de>,
"Philipp Lenssen" <in**@outer-court.com> wrote:

OK, Nokia 6600 with Symbian OS 7/ WAP2 XHTML1 Support does handle
the XHTML Basic Doctype good as well (it will load the handheld CSS
-- e.g. <http://outer-court.com/mobile/basic.html>).

What about DTDless XHTML?

That didn't work either.

However... I just found a workaround...

If I include the XHTML Basic DTD within comments inside the
body-element of the XHTML-Strict document, Nokia handles it as XHTML
Basic! They just check if the Doctype-string occurrs somewhere...

XHTML 1.0 Strict, served as text/html:
<http://outer-court.com/mobile/comment.html>
(The CSS handheld is used on my Nokia!)

[Jim Ley]

On 5 Jan 2004 10:31:37 GMT, "Philipp Lenssen" <in**@outer-court.com>
wrote:

It doesn't care much about the content-type (it doesn't need the XML
content-type).

XHTML basic sent as text/html would be (most likely) invalid tag-soup,
any other parsing would be wrong by the parser.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Jim Ley]

On 5 Jan 2004 12:23:41 GMT, "Philipp Lenssen" <in**@outer-court.com>
wrote:

Henri Sivonen wrote:

You shouldn't be serving XHTML Basic as text/html and doctype
sniffing is supposed to only apply to text/html in desktop browsers.
(Do you have proof to the contrary?)

But I must serve XHTML as text/html for downwards-compatibility, right?!

You have no authority to serve it as text/html, XHTML 1.0
transitional/script/frameset are the only types of XHTML allowed to be
served as that (and do that you have to follow condratictory
requirements, but we're told they're non-normative so you can ignore
them.)

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Philipp Lenssen]

Jim Ley wrote:

On 5 Jan 2004 12:23:41 GMT, "Philipp Lenssen" <in**@outer-court.com>
wrote:

But I must serve XHTML as text/html for downwards-compatibility,
right?!

You have no authority to serve it as text/html, XHTML 1.0
transitional/script/frameset are the only types of XHTML allowed to be
served as that (and do that you have to follow condratictory
requirements, but we're told they're non-normative so you can ignore
them.)

Well, it all works now (valid and all), thanks to the comment-hack: I
use XHTML1.0 Strict, serve as text/html, and include a comment with the
XHTML1.0 Basic doctype. Enough to please Nokia and doesn't cause
troubles in other browsers I suppose.

[Henri Sivonen]

In article <bt************@ID-203055.news.uni-berlin.de>,
"Philipp Lenssen" <in**@outer-court.com> wrote:

Henri Sivonen wrote:

In article <bt************@ID-203055.news.uni-berlin.de>,
"Philipp Lenssen" <in**@outer-court.com> wrote:

OK, Nokia 6600 with Symbian OS 7/ WAP2 XHTML1 Support does handle
the XHTML Basic Doctype good as well (it will load the handheld CSS
-- e.g. <http://outer-court.com/mobile/basic.html>).
What about DTDless XHTML?

That didn't work either.

As application/xhtml+xml or text/html?
However... I just found a workaround...

If I include the XHTML Basic DTD within comments inside the
body-element of the XHTML-Strict document, Nokia handles it as XHTML
Basic! They just check if the Doctype-string occurrs somewhere...

That's strange. Scanning for particular string before parsing is not
something browser implementors want to do. Even when they do it, they
tend to limit the scanning to the first n bytes.

Are you sure your gateway isn't doing the sniffing?

--
Henri Sivonen
hs******@iki.fi
http://iki.fi/hsivonen/
Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html

[Henri Sivonen]

In article <bt************@ID-203055.news.uni-berlin.de>,
"Philipp Lenssen" <in**@outer-court.com> wrote:

Henri Sivonen wrote:

You shouldn't be serving XHTML Basic as text/html and doctype
sniffing is supposed to only apply to text/html in desktop browsers.
(Do you have proof to the contrary?)

But I must serve XHTML as text/html for downwards-compatibility, right?!

Assuming you consider IE being downwards compared to phones and you want
to be compatible with it, you need to serve text/html (the payload
doesn't have to pretend to be XHTML) to IE.

In my first post to this thread I was assuming we were discussing real
XHTML (served as application/xhtml+xml). I'm interested in how Nokia
6600 handles DTDless XHTML (not "strictly conforming") served as
application/xhtml+xml.

I'm not sympathetic to labeling XML as tag soup and then complaining
when weirdness ensues.
So what to do to serve both my phone (and similar ones) plus common
browsers?

1) Serve HTML 4.01 Strict as text/html and require Opera on the phone.
2) Serve text/html pages to desktop browsers and separate
application/xhtml+xml pages to phones.

--
Henri Sivonen
hs******@iki.fi
http://iki.fi/hsivonen/
Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html

[Philipp Lenssen]

Henri Sivonen wrote:

In article <bt************@ID-203055.news.uni-berlin.de>,
"Philipp Lenssen" <in**@outer-court.com> wrote:

Henri Sivonen wrote:

You shouldn't be serving XHTML Basic as text/html and doctype
sniffing is supposed to only apply to text/html in desktop
browsers. (Do you have proof to the contrary?)

But I must serve XHTML as text/html for downwards-compatibility,
right?!

Assuming you consider IE being downwards compared to phones and you
want to be compatible with it, you need to serve text/html (the
payload doesn't have to pretend to be XHTML) to IE.

In my first post to this thread I was assuming we were discussing
real XHTML (served as application/xhtml+xml). I'm interested in how
Nokia 6600 handles DTDless XHTML (not "strictly conforming") served
as application/xhtml+xml.

I'm not sympathetic to labeling XML as tag soup and then complaining
when weirdness ensues.

It's perfectly valid to label XHTML1.0 Strict as content-type
text/html, as you know from the W3C recommendation. Since when is
perfectly valid HTML Strict tag-soup?

In any case, Internet Explorer 6 has problems when I serve XHTML as
XML. It sometimes offers a file download to the user.

So what to do to serve both my phone (and similar ones) plus common
browsers?

1) Serve HTML 4.01 Strict as text/html and require Opera on the phone.
2) Serve text/html pages to desktop browsers and separate
application/xhtml+xml pages to phones.

There is an Opera on my phone, though I'm sure it's a messed one.
Separation should be via CSS, not HTML.

Anyway, I solved the problem by including a comment with the "Basic"
doctype.

[Bertilo Wennergren]

Philipp Lenssen:

1) Serve HTML 4.01 Strict as text/html and require Opera on the phone.
2) Serve text/html pages to desktop browsers and separate
application/xhtml+xml pages to phones.

There is an Opera on my phone, though I'm sure it's a messed one.
Separation should be via CSS, not HTML. Anyway, I solved the problem by including a comment with the "Basic"
doctype.

If you're serious, you had better serve different versions according
to the Accept header sent by the user agent.

--
Bertilo Wennergren <be******@gmx.net> <http://www.bertilow.com>

[Jim Ley]

On 12 Jan 2004 08:57:27 GMT, "Philipp Lenssen" <in**@outer-court.com>
wrote:

It's perfectly valid to label XHTML1.0 Strict as content-type
text/html, as you know from the W3C recommendation. Since when is
perfectly valid HTML Strict tag-soup?

According to the XHTML WG:

|The HTML WG has discussed this issue: the intention was to allow old
|(HTML-only) browsers to accept XHTML 1.0 documents by following the
|guidelines, and serving them as text/html. Therefore, documents served as
|text/html should be treated as HTML and not as XHTML. There should be no
|sniffing of text/html documents to see if they are really XHTML.

http://lists.w3.org/Archives/Public/...0Sep/0024.html

It's not yet made it into the errata or 2nd edition as would be
expected, but I'm sure it will one day, the XHTML WG are extremely
slow at responding to issues.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Philipp Lenssen]

Jim Ley wrote:

On 12 Jan 2004 08:57:27 GMT, "Philipp Lenssen" <in**@outer-court.com>
wrote:

It's perfectly valid to label XHTML1.0 Strict as content-type
text/html, as you know from the W3C recommendation. Since when is
perfectly valid HTML Strict tag-soup?
According to the XHTML WG:

The HTML WG has discussed this issue: the intention was to allow old
(HTML-only) browsers to accept XHTML 1.0 documents by following the
guidelines, and serving them as text/html. Therefore, documents
served as text/html should be treated as HTML and not as XHTML.
There should be no sniffing of text/html documents to see if they
are really XHTML.

XHTML should be treated as HTML? That would mean the page invalid by
definition if you're writing XHTML and serving as text/html, as is
valid? <br /> anyone? That can't be HTML-SGML or is it.
http://lists.w3.org/Archives/Public/...0Sep/0024.html

It's not yet made it into the errata or 2nd edition as would be
expected, but I'm sure it will one day, the XHTML WG are extremely
slow at responding to issues.

Whatever happens I hope for IExplorer to catch up. Just as important
(of not more so) than any W3C effort. But also, I still think it's
important for older browser to serve as HTML. I like new standards if
they make sense but so far the W3C has been able to make things
backwards-compatible. Not so with serving XML. Just doesn't work in
older browsers, right. And I thought HTML documents are supposed to
have a long life. I guess plain ASCII will survive HTML if they keep
coming up with the next best thing, unless it's downwards-compatible.
Hmmm.

[Alan J. Flavell]

On Mon, 12 Jan 2004, Philipp Lenssen wrote:

It's perfectly valid to label XHTML1.0 Strict as content-type
text/html, as you know from the W3C recommendation.
The XHTML/1.0 recommendation makes a concession that XHTML/1.0 can
be served out as text/html under certain restrictive compatibility
conditions. It would be objectively false to describe that feature as
"perfectly valid" (the term "valid" in an SGML context has a precise
formal meaning).

Be aware that the XHTML/1.0 specification explicitly does NOT define
the meaning of the text/html content type: for that definition, it
refers directly to RFC2854, which itself says:

The text/html media type is now defined by W3C Recommendations;
the latest published version is [HTML401]. In addition, [XHTML1]
defines a profile of use of XHTML which is compatible with HTML
4.01 and which may also be labeled as text/html.

They're using the term "compatible" in a fairly generous sense!
Since when is perfectly valid HTML Strict tag-soup?
"When it is served out as text/html" HTH.
In any case, Internet Explorer 6 has problems when I serve XHTML as
XML.

This is old news. IE is not a WWW-compatible browser, except
sometimes by accident.

[Bertilo Wennergren]

Philipp Lenssen:

XHTML should be treated as HTML? That would mean the page invalid by
definition if you're writing XHTML and serving as text/html, as is
valid? <br /> anyone? That can't be HTML-SGML or is it.

"<br />" is not invalid in HTML. Try it in a validator. It just
doesn't mean the same thing as it does in XHTML.

"<meta ... />" can be a different matter however.

--
Bertilo Wennergren <be******@gmx.net> <http://www.bertilow.com>

[Philipp Lenssen]

Alan J. Flavell wrote:

On Mon, 12 Jan 2004, Philipp Lenssen wrote:

It's perfectly valid to label XHTML1.0 Strict as content-type
text/html, as you know from the W3C recommendation.
The XHTML/1.0 recommendation makes a concession that XHTML/1.0 can
be served out as text/html under certain restrictive compatibility
conditions. It would be objectively false to describe that feature as
"perfectly valid" (the term "valid" in an SGML context has a precise
formal meaning).

So the W3C validator must be wrong then. Who do I trust now?

Since when is perfectly valid HTML Strict tag-soup?

"When it is served out as text/html" HTH.

Tag-soupish is when the browser renders invalid HTML, right? So it all
comes down to whether or not XHTML as text/html is valid.

[Alan J. Flavell]

On Mon, 12 Jan 2004, Philipp Lenssen wrote:

The XHTML/1.0 recommendation makes a concession that XHTML/1.0 can
be served out as text/html under certain restrictive compatibility
conditions. It would be objectively false to describe that feature as
"perfectly valid" (the term "valid" in an SGML context has a precise
formal meaning).
So the W3C validator must be wrong then.

Must it? Perhaps you owe us a test case, if you really want to
dispute this.

The W3C validator does have some heuristics in it, so it's not just a
formal SGML validator. And where do you suppose it gets its SGML
Declaration from (and how would it know which one to choose?).
So it all comes down to whether or not XHTML as text/html is valid.

If you're using the term "valid" in the SGML sense, then I disagree.
Formal validity in that sense is only part of the issue. It's
possible to devise XHTML documents that parse valid as HTML: some
of them even mean the same under both interpretations (though others
mean something different - but presumably you know this already).

Appendix C in general *relies* on defective interpretation of SGML in
most browsers, in order to achieve its apparent compatibility.

[Philipp Lenssen]

Alan J. Flavell wrote:

On Mon, 12 Jan 2004, Philipp Lenssen wrote:

The XHTML/1.0 recommendation makes a concession that XHTML/1.0 can
be served out as text/html under certain restrictive compatibility
conditions. It would be objectively false to describe that
feature as "perfectly valid" (the term "valid" in an SGML context
has a precise formal meaning).
So the W3C validator must be wrong then.

Must it? Perhaps you owe us a test case, if you really want to
dispute this.

On my XHTML pages served as text/html the W3C validator will say: "This
Page Is Valid XHTML 1.0
<http://www.w3.org/TR/2000/REC-xhtml1-20000126/> Strict!""

E.g. <http://validator.w3.org/check?uri=http://outer-court.com/>

And in the W3C recommendation it says XHTML1.0 documents may be served
as text/html.

So now you can construct a tag-soup out of this if you want, but I will
still say that then tag-soup covers valid W3C XHTML, and that means the
term becomes useless.
The W3C validator does have some heuristics in it, so it's not just a
formal SGML validator. And where do you suppose it gets its SGML
Declaration from (and how would it know which one to choose?).

So it all comes down to whether or not XHTML as text/html is valid.

If you're using the term "valid" in the SGML sense, then I disagree.

What I got from the book of the inventor of HTML, it was just based on
SGML for political reasons (to please a certain lobby). SGML was never
a serious issue. But then again, I might be wrong. All I care about is
having a pragmatic document type. If I would have the choice between
"it works" and "it's valid", I would choose the first (fortunately, I
can have both).

In any case I think it's a political issue nowadays and here especially
as well. I get the strong feeling some people don't like XHTML. I find
it much easier to explain, write and use, simply because of it's syntax
restrictions.

And besides all that, you can't have perfect validation. I think it's a
Godel problem. So I'm happy with a bit of fuzzyness as well :)

[Jukka K. Korpela]

ji*@jibbering.com (Jim Ley) wrote:

|The HTML WG has discussed this issue: the intention was to allow
|old (HTML-only) browsers to accept XHTML 1.0 documents by following
|the guidelines, and serving them as text/html. Therefore, documents
|served as text/html should be treated as HTML and not as XHTML.
So when a browser receives an XHTML 1.0 document served as text/html,
it should render <br /> as a line break followed by a solidus "/"
character, should it not? Does anyone seriously expect this to happen?
If not, what's the point in making such a requirement?

(Note that I don't even raise the question "And how should they render
<em/Hello world/ if it is a _serious_ recommendation that they treat
the data as HTML?")
It's not yet made it into the errata or 2nd edition as would be
expected,

Into the _errata_? You mean we should expect the W3C change the factual
and most important content of a specification, without prior or
posterior notice, by putting something into an _errata_? Yeah, I'm
afraid you might be right.

If they just wanted to abolish the use of text/html for XHTML 1.0
documents, they should say that. That might not be a wise decision, but
at least it would not be self-contradictory or outright absurd.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Alan J. Flavell]

On Mon, 12 Jan 2004, Philipp Lenssen wrote:

And in the W3C recommendation it says XHTML1.0 documents may be served
as text/html.
We've done this already. XHTML/1.0 Appendix C describes compatibility
guidelines whereby existing "HTML" agents may be served with a fairly
generous subset of XHTML/1.0 using a content-type of text/html. The
appendix is informational, and explicitly does NOT provide a normative
definition of the text/html content-type.

Summarising that complex state of affairs with your words "it says
XHTML1.0 documents may be served as text/html" is far too simplistic
for a discussion at this level, IMNSHO.
What I got from the book of the inventor of HTML, it was just based on
SGML for political reasons (to please a certain lobby). SGML was never
a serious issue.
Hmmm. That's one way of describing the mess they got themselves
into...
All I care about is having a pragmatic document type.
That's OK - your prerogative; but then it seems to me it's better if
you don't try to tart it up as a discussion about formal validity and
conformance to published specifications.
I get the strong feeling some people don't like XHTML

That's as may be, but I don't believe that question is germane to the
principles which we were discussing.

all the best

[Jim Ley]

On Mon, 12 Jan 2004 22:41:48 +0000 (UTC), "Jukka K. Korpela"
<jk******@cs.tut.fi> wrote:

ji*@jibbering.com (Jim Ley) wrote:

|The HTML WG has discussed this issue: the intention was to allow
|old (HTML-only) browsers to accept XHTML 1.0 documents by following
|the guidelines, and serving them as text/html. Therefore, documents
|served as text/html should be treated as HTML and not as XHTML.
So when a browser receives an XHTML 1.0 document served as text/html,
it should render <br /> as a line break followed by a solidus "/"
character, should it not? Does anyone seriously expect this to happen?
If not, what's the point in making such a requirement?

Don't ask me, ask the XHTML WG, they're the people who stated that was
their opinion on allowing XHTML to be served as XHTML.

It's not yet made it into the errata or 2nd edition as would be
expected,

Into the _errata_?

Yes, seen as they've stated that the intention of their specification
was that it be treated as HTML, it's been poor interpretation that
people have been believing otherwise, there is no substantive change
to the specification, they would be purely clarifying the point.
You mean we should expect the W3C change the factual
and most important content of a specification,
Where does the current XHTML 1.0 spec state how XHTML 1.0 served as
text/html should be interpreted?
If they just wanted to abolish the use of text/html for XHTML 1.0
documents, they should say that. That might not be a wise decision, but
at least it would not be self-contradictory or outright absurd.

The XHTML WG don't want to do that, I think it is those of us who
complain about the ridiculousness who want that.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Jim Ley]

On Mon, 12 Jan 2004 15:58:44 +0000, "Alan J. Flavell"
<fl*****@ph.gla.ac.uk> wrote:

Appendix C in general *relies* on defective interpretation of SGML in
most browsers, in order to achieve its apparent compatibility.

Those guidelines are informative, they are also contradictory.

Informative guidelines cannot give the authority, the authority is
there for all XHTML 1.0 content.

(According to the XHTML WG)

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Alan J. Flavell]

On Tue, 13 Jan 2004, Jim Ley wrote:

On Mon, 12 Jan 2004 15:58:44 +0000, "Alan J. Flavell"
<fl*****@ph.gla.ac.uk> wrote:

Appendix C in general *relies* on defective interpretation of SGML in
most browsers, in order to achieve its apparent compatibility.

Those guidelines are informative, they are also contradictory.

OK, let me re-word what I was trying to say:

"the concept of feeding XHTML to client agents that were designed to
parse HTML relies on their defective interpretation of SGML in order
to achieve apparent compatibility."

I'm thinking specifically, of course, about the meaning of something
like <meta ... />

That concept is the underlying thought for what went into Appendix C,
but as you rightly point out, it's not Appendix C itself that's the
root cause of the problem: appendix C merely documents some of the
problems and shows pragmatic ways to avoid them.

In a sense it's the HTML specification that's at fault, since on the
one hand it claims HTML to be an application of SGML, while on the
other hand ruling-out some usages which SGML would not allow to be
ruled-out. Ho hum...

[Jukka K. Korpela]

ji*@jibbering.com (Jim Ley) wrote:

Where does the current XHTML 1.0 spec state how XHTML 1.0 served as
text/html should be interpreted?

The specification defines XHTML 1.0. When it says that XHTML 1.0
documents may, under some conditions, be served as text/html, it says
nothing that would change the meaning of XHTML 1.0 documents.

If they added tomorrow an "Errata" statement that says that on
Thursdays browsers should ignore deprecated markup, wouldn't that be a
change in the specification? Would it be relevant to ask where the old
spec stated what browsers should do on Thursdays?

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Henri Sivonen]

In article <bt************@ID-203055.news.uni-berlin.de>,
"Philipp Lenssen" <in**@outer-court.com> wrote:

Henri Sivonen wrote:

I'm not sympathetic to labeling XML as tag soup and then complaining
when weirdness ensues.

It's perfectly valid to label XHTML1.0 Strict as content-type
text/html, as you know from the W3C recommendation. Since when is
perfectly valid HTML Strict tag-soup?

My point was the that text/html is a label for tag soup. That's how the
label is taken even if you put to the label on something that isn't tag
soup.
There is an Opera on my phone, though I'm sure it's a messed one.

In what way?

--
Henri Sivonen
hs******@iki.fi
http://iki.fi/hsivonen/
Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html

[Henri Sivonen]

In article <bt************@ID-203055.news.uni-berlin.de>,
"Philipp Lenssen" <in**@outer-court.com> wrote:

Alan J. Flavell wrote:

On Mon, 12 Jan 2004, Philipp Lenssen wrote:

It's perfectly valid to label XHTML1.0 Strict as content-type
text/html, as you know from the W3C recommendation.

The XHTML/1.0 recommendation makes a concession that XHTML/1.0 can
be served out as text/html under certain restrictive compatibility
conditions. It would be objectively false to describe that feature as
"perfectly valid" (the term "valid" in an SGML context has a precise
formal meaning).

So the W3C validator must be wrong then. Who do I trust now?

The W3C validator doesn't check every aspect of conformance with the
Specs. It just checks for the requirements of a particular SGML
formalism.

--
Henri Sivonen
hs******@iki.fi
http://iki.fi/hsivonen/
Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html

[Jim Ley]

On Tue, 13 Jan 2004 23:16:01 +0000 (UTC), "Jukka K. Korpela"
<jk******@cs.tut.fi> wrote:

ji*@jibbering.com (Jim Ley) wrote:

Where does the current XHTML 1.0 spec state how XHTML 1.0 served as
text/html should be interpreted?
The specification defines XHTML 1.0. When it says that XHTML 1.0
documents may, under some conditions, be served as text/html, it says
nothing that would change the meaning of XHTML 1.0 documents.

but according to RFC 2854, any tag-soup can be served as that
mime-type, the XHTML 1.0 specification does not have any mandate to
change that, and XHTML 1.0 purely drawing your attention to that
mime-type doesn't actually dictate what a conforming XHTML user agent
should do with it.
If they added tomorrow an "Errata" statement that says that on
Thursdays browsers should ignore deprecated markup, wouldn't that be a
change in the specification?
That would, yes, but I do not see where in the specification it says
how XHTML served as text/html should be rendered, and the WG have
clarified in response to such an issue that it should not be handled
as XHTML. You can argue that it isn't an errata, you can argue that
their clarification was no such thing, but that is their current
opinion.
Would it be relevant to ask where the old
spec stated what browsers should do on Thursdays?

If the spec discussed what should happen on a thursday but in an
ambigous manner, then yes it would be relevant, and an errata
clarifying that ambiguity would be appropriate, if there was no
mention of what should happen on thursdays then no it wouldn't.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Philipp Lenssen]

Henri Sivonen wrote:

In article <bt************@ID-203055.news.uni-berlin.de>,
"Philipp Lenssen" <in**@outer-court.com> wrote:

Henri Sivonen wrote:

I'm not sympathetic to labeling XML as tag soup and then
complaining when weirdness ensues.

It's perfectly valid to label XHTML1.0 Strict as content-type
text/html, as you know from the W3C recommendation. Since when is
perfectly valid HTML Strict tag-soup?

My point was the that text/html is a label for tag soup. That's how
the label is taken even if you put to the label on something that
isn't tag soup.

Point taken.

There is an Opera on my phone, though I'm sure it's a messed one.

In what way?

I believe someone took it and messed with it. First of all, it's not
exactly the Opera that you can install when going to the Opera site.
Second, nowhere can you see it's Opera. Third, I get annoyed by several
things, one of them that I can't have images show as text-only without
nasty borders. Anyway, it still does some incredible things to garbage
HTML (not enough to browse the web, but it's a start).

[Jukka K. Korpela]

ji*@jibbering.com (Jim Ley) wrote:

but according to RFC 2854, any tag-soup can be served as that
mime-type,
RFC 2854 has status "Informational". Thus, it should not even try to
purport to specify anything presented as pseudo-quasi-normative.

Given its topic, the text/html media type, it is not surprising that it
is confused, confusing, and self-contradictory. For example, it says:
Published specification:
The text/html media type is now defined by W3C Recommendations;
the latest published version is [HTML401]. In addition, [XHTML1]
defines a profile of use of XHTML which is compatible with HTML
4.01 and which may also be labeled as text/html.
the XHTML 1.0 specification does not have any mandate to
change that,
Well, to the extent it can mandate anything, RFC 2854 explicitly
mandates the W3C in general and XHTML 1.0 in particular to specify
whatever they wish to say about the meaning of text/html.

It _also_ favors doctype sniffing, and tries to explain it as an
established and sound practice.
and XHTML 1.0 purely drawing your attention to that
mime-type doesn't actually dictate what a conforming XHTML user
agent should do with it.
Really? It failed to draw my attention.
- - I do not see where in the specification it
says how XHTML served as text/html should be rendered,
The XHTML 1.0 specification specifies XHTML 1.0. It's really beyond its
scope to specify how a program that is able to process data in other
formats as well decides whether it tries to interpret data as XHTML 1.0
or as something else. And it would be really absurd to specify the
XHTML 1.0 data format, then proceed to telling that if served in a
particular way (say, on Thursdays, or with sallad, or with a specific
accompanying Content-Type header), it should be treated in a different
way, according to another specification or (to be honest) according to
unspecified "industry standards" for dealing with HTML.
and the WG
have clarified in response to such an issue that it should not be
handled as XHTML.
How would that be a clarification? It means a change. The current
wording in the document labelled as XHTML 1.0 specification says no
such thing. It would be a clarification to state that existing user
agents do not actually process an XHTML 1.0 document according to the
XHTML 1.0 specification if it is sent as text/html.

Besides, the wording that it should be handled as HTML says much more
than "it should not be handled as XHTML", and opens a new can of worms.
We are supposed to imply that XHTML is or is not HTML depending on the
context, and here it is not. But what is HTML then, in this context?
The most natural interpretation is HTML 4.01. So the XHTML 1.0
specification would say that user agents, when receiving an XHTML 1.0
document served as text/html, should handle it by another
specification. This in turn would be a null statement, since the
HTML 4.01 specification does not specify error processing, i.e. it
does not say what a user agent should do if the document does not
comply with the HTML 4.01 specification (as XHTML 1.0 documents do
not).

To make any sense, we would need to imply quite some extra statements,
which involve an implicit transformation from XHTML 1.0 to HTML 4.01.
Now _that_ could be useful, since it would mean listing down the actual
differences.
You can argue that it isn't an errata, you can
argue that their clarification was no such thing, but that is their
current opinion.

I know that it is the W3C's policy to label any changes that a WG
wishes to make as "errata", and this illustrates the practical side of
the fact that the W3C is not a standards organization, and not even an
organization that produces real specifications.

It's one thing to clarify a statement, a wording, and to say something
quite different from what you have said before - even if this meant
saying what you actually wanted to say. Moreover, _adding_ a statement
(e.g., about what user agents should do in some circumstances) is
different from correcting typing errors or rewording a statement for
clarity or fixing a descriptive statement of facts to correspond to
reality, which is what an errata normally (i.e., outside the W3C
process) does.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Alan J. Flavell]

On Wed, 14 Jan 2004, Henri Sivonen wrote:

In article <bt************@ID-203055.news.uni-berlin.de>,
"Philipp Lenssen" <in**@outer-court.com> wrote:

Henri Sivonen wrote:

I'm not sympathetic to labeling XML as tag soup and then complaining
when weirdness ensues.

It's perfectly valid to label XHTML1.0 Strict as content-type
text/html, as you know from the W3C recommendation. Since when is
perfectly valid HTML Strict tag-soup?

My point was the that text/html is a label for tag soup.

Yes, that was the fundamental idea behind my earlier reply to P.L.
That's how the label is taken even if you put to the label on
something that isn't tag soup.

In addition to that point, though: the whole sense of Appendix C is
the idea of feeding an XHTML document to a menagerie of client agents
(browsers etc.) which have been designed to process - what shall I
call it without being accused of prejudice? - let's say "practical
HTML", shall we?

Feeding 100%-valid XHTML/1.0 to such a thing is no more commendable
than (let's say) feeding 100%-valid FORTRAN90 to a FORTRAN77 compiler:
it's an exercise in compatibility, not an exercise in validity "per
se".

There's nothing wrong with having valid XHTML/1.0 if you want
XHTML/1.0: it's certainly better than having invalid XHTML (hmmm, such
a thing seems to be a contradiction in terms - if it's not valid, then
it loses the right to call itself XHTML[tm]).

What I'm objecting to is not the preparation of valid XHTML/1.0 as
such - I hope that's obvious - but the apparent claim that it's
somehow a better food for client agents that were designed to cope
with HTML. And the whole point of Appendix C and its concession for
the use of content-type of text/html is the feeding of
designed-for-practical-HTML clients.

[tm]
http://www.w3.org/Consortium/Legal/2...cense-20021231

[Bertilo Wennergren]

Alan J. Flavell wrote:

What I'm objecting to is not the preparation of valid XHTML/1.0 as
such - I hope that's obvious - but the apparent claim that it's
somehow a better food for client agents that were designed to cope
with HTML.

That idea is indeed false. But who actually claims such a thing?
I hope the W3C doesn't.

My understanding is that if you want to move to XHTML, then that
transition can be made less complicated due to the fact that
XHTML served as "text/html" (in practical terms) works in older
user agents (designed for HTML), and due to the fact that we're
officially allowed to serve XHTML as if it were HTML. It's not better
(for those user agents) to be served XHMTL rather than HTML, but it
might be better for the one who serves the pages, if for some reason he
wants to move to XHTML, and if it's impractical for him to serve the
content in different forms to different user agents.

Anyway I'm glad that my pages are now served as HTML 4.01 Strict
(text/html) to those who can't handle XHTML, and as XHTML 1.1 to those
who claim they can. I've completely moved away from XHTML served
as "text/html".

--
Bertilo Wennergren <be******@gmx.net> <http://www.bertilow.com>

[Philipp Lenssen]

Alan J. Flavell wrote:

What I'm objecting to is not the preparation of valid XHTML/1.0 as
such - I hope that's obvious - but the apparent claim that it's
somehow a better food for client agents that were designed to cope
with HTML.

Can't remember anyone here saying that.

I will tell you that a newbie reading current blogs etc. will get the
feeling XHTML is superior (especially more accessible*), while someone
reading this newsgroup will get the feeling HTML is superior.

* I think it's a misunderstanding.
Better Living Through XHTML
http://www.alistapart.com/articles/betterliving/
For me it would be easier to parse, read, understand XHTML as it
follows XML rules. E.g. I wrote some color highlighting tools and
low-level parsers/ validators and I find it ultimately more complex to
understand whether or not something is correctly written when you got
something like optional end-tags, depending on the DTD, or optional
attribute quotes, depending on the attribute-value. XHTML is just
easier.
But then there are namespaces, XHTML1.1 modularization, XML Schema, so
I guess it will end up being just as complex as SGML is (as much as I
heard)... oh well. We still got HTML Tidy to move to whatever's best :)

[Henri Sivonen]

In article <bu*************@news.t-online.com>,
Bertilo Wennergren <be******@gmx.net> wrote:

Alan J. Flavell wrote:

What I'm objecting to is not the preparation of valid XHTML/1.0 as
such - I hope that's obvious - but the apparent claim that it's
somehow a better food for client agents that were designed to cope
with HTML.

That idea is indeed false. But who actually claims such a thing?

Zeldman's writings at least give that impression even if he actually
writes about supposed future UAs.

--
Henri Sivonen
hs******@iki.fi
http://iki.fi/hsivonen/
Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html

[Henri Sivonen]

In article <Pi*******************************@ppepc56.ph.gla. ac.uk>,
"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote:

invalid XHTML (hmmm, such
a thing seems to be a contradiction in terms - if it's not valid, then
it loses the right to call itself XHTML[tm])

Do you really mean "valid" in the XML 1.0 (DTD) sense?

--
Henri Sivonen
hs******@iki.fi
http://iki.fi/hsivonen/
Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html

[Alan J. Flavell]

On Thu, 15 Jan 2004, Henri Sivonen wrote:

In article <Pi*******************************@ppepc56.ph.gla. ac.uk>,
"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote:

invalid XHTML (hmmm, such a thing seems to be a contradiction in
terms - if it's not valid, then it loses the right to call itself
XHTML[tm])

Do you really mean "valid" in the XML 1.0 (DTD) sense?

I think you'd need to ask the W3C lawyers about that ;-}

The point I was getting at is that XHTML is a registered trademark
controlled by the W3C. So presumably their specifications set the
limits of what is entitled to call itself XHTML, no?

Isn't it true to say that if it fails validation then it doesn't
conform to their specifications?

Sure, there are +additional+ ways of failing to conform to their
specifications, e.g using <blockquote> to mark up something that isn't
a block of quoted matter. I didn't mean to imply that everything that
passed XHTML validation was ipso facto in conformance with W3C
specifications, so don't get me wrong on that point!

[JustAnotherGuy]

Philipp Lenssen wrote:

I will tell you that a newbie reading current blogs etc. will get the
feeling XHTML is superior (especially more accessible*), while someone
reading this newsgroup will get the feeling HTML is superior.

I can confirm that... I'm thoroughly confused, because even though XHTML
seems to be the 'right' thing to do in various blogs, publications,
etc., Yukka et al's howling screeds against XHTML seem to hint at the
exact opposite. I'm still writing XHTML for the time being, though.
Doesn't seem to break anything.

[Brian]

JustAnotherGuy wrote:

Philipp Lenssen wrote:

I will tell you that a newbie reading current blogs etc. will get
the feeling XHTML is superior (especially more accessible*),
while someone reading this newsgroup will get the feeling HTML is
superior.

I can confirm that... I'm thoroughly confused, because even though
XHTML seems to be the 'right' thing to do

What does XHTML offer you that HTML does not? If the answer is
nothing, and given that HTML requires no tomfoolery for IE/Win, it
seems HTML is the 'right' thing to do.

--
Brian
follow the directions in my address to email me

[Nick Theodorakis]

On Thu, 15 Jan 2004 22:36:52 -0500, JustAnotherGuy
<Ju************@mailinator.com> wrote:

I can confirm that... I'm thoroughly confused, because even though XHTML
seems to be the 'right' thing to do in various blogs, publications,
etc., Yukka et al's howling screeds against XHTML seem to hint at the
exact opposite. I'm still writing XHTML for the time being, though.
Doesn't seem to break anything.

It's just that "x" is a kewl letter. If it was called EHTML then no
one would be using it.

xNick
--
Nick Theodorakis
ni**************@hotmail.com
nicholas_theodorakis [at] urmc [dot] rochester [dot] edu

[JustAnotherGuy]

Brian wrote:

JustAnotherGuy wrote:

Philipp Lenssen wrote:

I will tell you that a newbie reading current blogs etc. will get
the feeling XHTML is superior (especially more accessible*),
while someone reading this newsgroup will get the feeling HTML is
superior.

I can confirm that... I'm thoroughly confused, because even though
XHTML seems to be the 'right' thing to do

What does XHTML offer you that HTML does not?

Hm.. nothing really. Would validating as 4.01 strict catch nesting
errors etc.?

[Mark Parnell]

On Fri, 16 Jan 2004 05:47:47 GMT, ni**************@hotmail.com (Nick
Theodorakis) declared in comp.infosystems.www.authoring.html:

It's just that "x" is a kewl letter. If it was called EHTML then no
one would be using it.

That's so true. Other letters just don't have the same xappeal. ;-)

--
Mark Parnell
http://www.clarkecomputers.com.au

[Brian]

JustAnotherGuy wrote:

Would validating as 4.01 strict catch nesting errors etc.?

You mean like this?

<x>text <y>more</x> text</y>

If so, then yes.

--
Brian
follow the directions in my address to email me

[Philipp Lenssen]

JustAnotherGuy wrote:

Brian wrote:

JustAnotherGuy wrote:

Philipp Lenssen wrote:

I will tell you that a newbie reading current blogs etc. will get
the feeling XHTML is superior (especially more accessible*),
while someone reading this newsgroup will get the feeling HTML is
superior.
I can confirm that... I'm thoroughly confused, because even though
XHTML seems to be the 'right' thing to do

What does XHTML offer you that HTML does not?

Hm.. nothing really. Would validating as 4.01 strict catch nesting
errors etc.?

What about this:

<p>test
<p>test 2</p>
<p>test 3</p>

No, HTML4 won't catch that, because it's an optional end-tag in the
first place. Not so in XHTML. Which I find much better, so that's one
reason I use it. XHTML forces:

<p>test</p>
<p>test 2</p>
<p>test 3</p>

If that's how you want to write all pages in the first place, you'd
better go for XHTML. If you don't care about end-tags, always using
quotes for attributes, XML DOM parser etc., you might as well use
HTML4. (In both instances, the Strict version.)

--
Google Blogoscoped
http://blog.outer-court.com

[Brian]

Philipp Lenssen wrote:

JustAnotherGuy wrote:

Would validating as 4.01 strict catch nesting
errors etc.?
What about this:

<p>test
<p>test 2</p>
<p>test 3</p>

No, HTML4 won't catch that, because it's an optional end-tag in the
first place.

If you want to use end tags, use them. That's what optional means.
Not so in XHTML. Which I find much better, so that's one
reason I use it. XHTML forces:

<p>test</p>
<p>test 2</p>
<p>test 3</p>

If that's how you want to write all pages in the first place, you'd
better go for XHTML.

Or just use html and include optional closing tags, quote all
attributes, etc. That xhtml forces you to do what you can do in html
seems like a strange reason to put yourself through the difficulties
that xhtml raises re: MSIE and content type.

--
Brian
follow the directions in my address to email me

[Philipp Lenssen]

Brian wrote:

Or just use html and include optional closing tags, quote all
attributes, etc. That xhtml forces you to do what you can do in html
seems like a strange reason to put yourself through the difficulties
that xhtml raises re: MSIE and content type.

Not at all. Your argument would mean a validator would be useless. "If
you want to write valid code, why don't you just do so?" Because people
make errors. That's why it's nice to have a validator.