XHTML support?

[kaeli]

Hey all,

Does anyone know if all the newer browsers support XHTML? My main target is
IE6/NN6+(firefox/mozilla/etc), but I'd like to know if Safari, Opera,
Konqueror, and other browsers also support it.
Anyone know of any major compatibility problems with XHTML?
How do older browsers, such as Netscape 4, react to the doctype?

TIA

--
--
~kaeli~
Murphy's Law #2000: If enough data is collected, anything
may be proven by statistical methods.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

[kaeli]

In article <op************ **@news.individ ual.net>, ne*****@yahoo.c om
enlightened us with...

On Tue, 17 Aug 2004 14:51:21 -0500, kaeli <ti******@NOSPA M.comcast.net>
wrote:

Wow, you know, for such a popular browser, (IE) doesn't seem to support
much of
the new stuff.

As the old Lily Tomlin line goes, "We don't have to care. We're the Phone
Company."

*snort*

--
--
~kaeli~
Why did kamikaze pilots wear helmets?
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

[Jukka K. Korpela]

Spartanicus <[e-mail] > wrote:

Real XHTML?

- -

* Opera - I think has XHTML support.

In a sense. Some people might say it has too good support: it does not
recognize predefined entities like &auml;

Incorrect.

What would you like to characterize as incorrect? My description, or the
behavior described? On which grounds would you call either of them as
incorrect? The behavior is inadequate, especially for a WWW browser, but
not incorrect by the specifications.

and it refuses to display the page at all if there is a single
"well-formedness" error like missing end tag.

Also incorrect, that's the way Gecko based UAs work.

Again, _what_ is incorrect, in your opinion?

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

[Spartanicus]

"Jukka K. Korpela" <jk******@cs.tu t.fi> wrote:

Real XHTML?
- -
* Opera - I think has XHTML support.

In a sense. Some people might say it has too good support: it does not
recognize predefined entities like &auml;

Incorrect.

What would you like to characterize as incorrect?

Your statement that Opera doesn't recognize entities like &auml; in
XHTML mode. Do try to keep up: http://www.opera.com/download (entity
support in XHTML mode was added in 7.50)

and it refuses to display the page at all if there is a single
"well-formedness" error like missing end tag.

Also incorrect, that's the way Gecko based UAs work.

Again, _what_ is incorrect, in your opinion?

Your statement again. Opera does not "refuse to display the page at
all", it renders what it can and tacks on the mandatory parsing error at
the end, demo: http://www.spartanicus.utvinternet.ie/xhtml11.xhtml

--
Spartanicus

[Jukka K. Korpela]

Spartanicus <[e-mail] > wrote:

What would you like to characterize as incorrect?

Your statement that Opera doesn't recognize entities like &auml; in
XHTML mode. Do try to keep up: http://www.opera.com/download (entity
support in XHTML mode was added in 7.50)

Thank you. Why didn't you say that in the first place?

The fact still is that there are versions of Opera around that support
XHTML and treat references to predefined entities as nonexistent (that
is, display &auml; as null and void, not even as &auml; literally).

But genuine XHTML isn't suitable for practical authoring for the WWW
anyway, of course. Some people think that it's possible to detect the
browser's capabilities and send XHTML or classic HTML depending on them.
It's hard to see what that would achieve even if it were reliably
possible, but how would one sniff, for example, whether a browser that
claims XHTML support in the HTTP headers will ignore entity references or
not?

and it refuses to display the page at all if there is a single
"well-formedness" error like missing end tag.

Also incorrect, that's the way Gecko based UAs work.

Again, _what_ is incorrect, in your opinion?

Your statement again. Opera does not "refuse to display the page at
all", it renders what it can and tacks on the mandatory parsing error
at the end, demo: http://www.spartanicus.utvinternet.ie/xhtml11.xhtml

Again, thank you. My statement was exaggerated. The effects depend on the
location and kind of syntax errors. If you wrote, e.g.,
<title Spartanicus' Web tips</title>
then Opera would report "XML-jäsennys epäonnistui: ei oikeinmuodostet tu
(Rivi: 6, Merkki: 18)" or something similar, depending on the browser's
language, followed by a copy of the XHTML source code. My point is that
this is really bad to usability. When server as classic HTML, a browser
renders the page normally despite the error - just without showing the
title anywhere since it did not get it.

This is more or less what XML and XHTML are _supposed_ to mean. How many
authors can really organize things so that their XHTML documents never
get edited in a manner that creates a tiny syntax error? (Even if could
guarantee that, you could still play with classic HTML for a couple of
years. After all, contrary to the tone of many statements about XHTML and
HTML, it _is_ possible to write valid code in classic HTML too. And even
use redundant tags.)

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

[Spartanicus]

"Jukka K. Korpela" <jk******@cs.tu t.fi> wrote:

Do try to keep up: http://www.opera.com/download (entity
support in XHTML mode was added in 7.50)
Thank you. Why didn't you say that in the first place?

Only after posting my first reply did I remember that previous versions
had a shortcoming there.
But genuine XHTML isn't suitable for practical authoring for the WWW
anyway, of course.
Agreed for the time being.
Some people think that it's possible to detect the
browser's capabilities and send XHTML or classic HTML depending on them.
It's hard to see what that would achieve even if it were reliably
possible, but how would one sniff, for example, whether a browser that
claims XHTML support in the HTTP headers will ignore entity references or
not?
No such guarantees for text/html either.

Opera does not "refuse to display the page at
all", it renders what it can and tacks on the mandatory parsing error
at the end, demo: http://www.spartanicus.utvinternet.ie/xhtml11.xhtml

Again, thank you. My statement was exaggerated. The effects depend on the
location and kind of syntax errors. If you wrote, e.g.,
<title Spartanicus' Web tips</title>
then Opera would report "XML-jäsennys epäonnistui: ei oikeinmuodostet tu
(Rivi: 6, Merkki: 18)" or something similar, depending on the browser's
language, followed by a copy of the XHTML source code.

Use that if you want as an argument against XHTML, but it doesn't form
an argument against Opera's handling of it. A standard compliant XHTML
parser is required to stop parsing after it has encountered malformed
code.
My point is that
this is really bad to usability. When server as classic HTML, a browser
renders the page normally despite the error - just without showing the
title anywhere since it did not get it.

This is more or less what XML and XHTML are _supposed_ to mean. How many
authors can really organize things so that their XHTML documents never
get edited in a manner that creates a tiny syntax error?
XHTML only renderers could shed the error correcting mechanisms that
weigh down current tag soup slurpers. Currently alternative UAs struggle
to emulate IE's error recovery mechanism, something that has to be done
by process of trial and error, and it will never be perfect.

I can't see XHTML only renderers on the desktop for decades, but I can
imagine web content created for other platforms like cellphones, wrist
watches etc. taking off in the near future. These devices and their
renderers would almost require well formed code, incorporating a classic
tag soup slurper is difficult on these resource strapped devices.

Since it's impossible to prevent malformed XHTML code being created, a
step in the right direction is if parsers clearly show malformedness
errors, assuming that most authors check their work in a UA before
publishing. And if they don't, every user that accesses the document
will be made aware of the error(s), making it far more likely that the
author will be informed.

That could result in a significant reduction of published malformed
code.
After all, contrary to the tone of many statements about XHTML and
HTML, it _is_ possible to write valid code in classic HTML too. And even
use redundant tags.)

Best not mention validity and well formedness in such close proximity of
each other so as not to give the impression to lurkers that the 2 are
the same.

--
Spartanicus

[Rijk van Geijtenbeek]

On Wed, 18 Aug 2004 10:47:07 +0000 (UTC), Jukka K. Korpela
<jk******@cs.tu t.fi> wrote:

...

This is more or less what XML and XHTML are _supposed_ to mean. How many
authors can really organize things so that their XHTML documents never
get edited in a manner that creates a tiny syntax error?
If they use XML-based publishing systems, it shouldn't be too hard. And
that is of course, IMHO, also the only reason currently to even try using
XHTML :)

There are a lot of webloggers that try to write valid strict (X)HTML
nowadays. And as soon as they turn on the 'comment' capability of their
blogging tools, they run into trouble, as those tools are not XML based
and not very good at handling invalid or variosuly encoded input.
(Even if could
guarantee that, you could still play with classic HTML for a couple of
years. After all, contrary to the tone of many statements about XHTML and
HTML, it _is_ possible to write valid code in classic HTML too. And even
use redundant tags.)

Agreed. Everyone who is handcoding can just as well stick to HTML 4.01 and
save a few bytes and headaches in the process. Example of someone who
understands this:

http://diveintomark.org/archives/2004/08/16/specs

The content of the article is also nice :)

--
Rijk van Geijtenbeek

The Web is a procrastination apparatus:
It can absorb as much time as is required to ensure that you
won't get any real work done. - J.Nielsen

[Rijk van Geijtenbeek]

On Wed, 18 Aug 2004 14:05:25 +0100, Spartanicus <[e-mail] > wrote:

...

XHTML only renderers could shed the error correcting mechanisms that
weigh down current tag soup slurpers. Currently alternative UAs struggle
to emulate IE's error recovery mechanism, something that has to be done
by process of trial and error, and it will never be perfect.

I can't see XHTML only renderers on the desktop for decades, but I can
imagine web content created for other platforms like cellphones, wrist
watches etc. taking off in the near future. These devices and their
renderers would almost require well formed code, incorporating a classic
tag soup slurper is difficult on these resource strapped devices.

Since it's impossible to prevent malformed XHTML code being created, a
step in the right direction is if parsers clearly show malformedness
errors, assuming that most authors check their work in a UA before
publishing. And if they don't, every user that accesses the document
will be made aware of the error(s), making it far more likely that the
author will be informed.

That could result in a significant reduction of published malformed
code.

See the XHTML-MP guide fromm one of the leading WAP 2.0 browser
manufacturers.. .
<URL:http://developer.openw ave.com/dvl/support/documentation/guides_and_refe rences/xhtml-mp_style_guide/chapter2.htm>
.... for evidence that this is not what will happen. A few quotes:

"In this regard, the Openwave browser is very forgiving when it comes to
mark-up. If you avoid adding the XML processing instruction and the DTD,
your code will still work. Unrecognized tags and CSS properties will be
ignored and tags without a closure won't break your page (e.g. <br>
instead of <br/> and <p> without a matching </p> )."

"If, for whatever reason, you want your code to make it through a
validating parser (the one at W3C, for example http://validator.w3.org/ ),
your application must comply with whichever DTD you declare.

It is important to note that we are not advocating that developers write
sloppy mark-up; we simply wanted to make sure that the previous chapter
did not scare you."
--
Rijk van Geijtenbeek

The Web is a procrastination apparatus:
It can absorb as much time as is required to ensure that you
won't get any real work done. - J.Nielsen

[Henri Sivonen]

In article <kr************ *************** **@news1.news.x s4all.nl>,
Kris <kr*******@xs4a ll.netherlands> wrote:

In article <cf************ *******@news.de mon.co.uk>,
David Dorward <do*****@yahoo. com> wrote:

Real XHTML?
* Safari - I think it fakes XHTML by treating application/xhtml+xml as
text/html.

It throws up a fatal error when the XHTML is not well-formed, for all it
is worth.

The current Safari uses expat. An upcoming version will use libxml.

(The behavior mentioned by David Dorward was in an early beta a long
time ago.)

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

[Spartanicus]

"Rijk van Geijtenbeek" <ri**@opera.com > wrote:

XHTML only renderers could shed the error correcting mechanisms that
weigh down current tag soup slurpers. Currently alternative UAs struggle
to emulate IE's error recovery mechanism, something that has to be done
by process of trial and error, and it will never be perfect.

I can't see XHTML only renderers on the desktop for decades, but I can
imagine web content created for other platforms like cellphones, wrist
watches etc. taking off in the near future. These devices and their
renderers would almost require well formed code, incorporating a classic
tag soup slurper is difficult on these resource strapped devices.

Since it's impossible to prevent malformed XHTML code being created, a
step in the right direction is if parsers clearly show malformedness
errors, assuming that most authors check their work in a UA before
publishing. And if they don't, every user that accesses the document
will be made aware of the error(s), making it far more likely that the
author will be informed.

That could result in a significant reduction of published malformed
code.
See the XHTML-MP guide fromm one of the leading WAP 2.0 browser
manufacturers. ..
<URL:http://developer.openw ave.com/dvl/support/documentation/guides_and_refe rences/xhtml-mp_style_guide/chapter2.htm>
... for evidence that this is not what will happen. A few quotes:

It's impossible to disprove a statement of something that *could*
happen, unless you've found a way to time travel. Stating that the above
url amounts to "evidence" for this is silly.
"In this regard, the Openwave browser is very forgiving when it comes to
mark-up. If you avoid adding the XML processing instruction and the DTD,
your code will still work.

I really don't see your point here, sure it's possible for a xhtml
parser to ignore the w3c requirements, it's therefore automatically not
a standard compliant xhtml renderer.

Let's hypothesise and assume that we will end up with a mix of standard
and non standard compliant xhtml renderers, in that situation it's fair
to expect that some content will still be better formed due to some
people using standard compliant renderers.

Don't take what I wrote as some sort of dreamy prediction of what I
think will happen, I haven't got a clue. What I wrote only intended to
argue that there is some logic and potential benefit to client side well
formedness checking.

You can take a cynical view and assume that it will never happen, and
for all I know you could be right, but that's a separate discussion.

There might also be an argument to say that there are drawbacks to
client side well formedness checking, but again that is a separate
discussion, and drawbacks usually coexist with benefits.

--
Spartanicus

[I V]

On Wed, 18 Aug 2004 14:05:25 +0100, Spartanicus wrote:

I can't see XHTML only renderers on the desktop for decades, but I can
imagine web content created for other platforms like cellphones, wrist
watches etc. taking off in the near future. These devices and their
renderers would almost require well formed code, incorporating a classic
tag soup slurper is difficult on these resource strapped devices.

This is already the case. The browser that comes with Ericsson and
(I think, but haven't tested extensively) Nokia phones will only render
well-formed XML.

That being said, the newest mobile phones are capable of running Opera's
mobile version, complete with tag-soup parser, so it may be that
XHTML-only mobiles will turn out to be a short-lived phenomenon

--
" - Penny, I worry that you are loosing heart... You are not the sweet little
girl I once knew. Where's your sense of wonder?
- Currently flowing into a sanitary napkin... Guess where my childlike
innocence and idle dreams are currently wedged. Come on, I dare you."
http://www.huh.34sp.com/