XHTML

Roedy Green wrote:

does converting the XHTML make matters better or worse vis a vis CSS
not behaving the way you expect?

Well ... it makes them different (such as stuff being applied, by default,
to <html> instead of <body> in some browsers).

It also introduces a host of issues with browser support (e.g. Lynx,
GoogleBot and Internet Explorer don't support it), unless you treat it as
tag soup - in which case what's the point of converting?

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

Jul 21 '05 #2

Arne

Once upon a time *David Dorward* wrote:

Roedy Green wrote:
does converting the XHTML make matters better or worse vis a vis CSS
not behaving the way you expect?

Well ... it makes them different (such as stuff being applied, by default,
to <html> instead of <body> in some browsers).

It also introduces a host of issues with browser support (e.g. Lynx,
GoogleBot and Internet Explorer don't support it), unless you treat it as
tag soup - in which case what's the point of converting?

With "treat it as tag soup" I assume you mean serve the page as
text/html insted of application/xhtml+xml ? What makes it "tag soap"
if I change a particular page correct served content type to the
"wrong" type in this matter. Serving CSS as text I understand, but the
web page probably looks the same in those browser that support both
text/html and application/xhtml+xml ?

I may be wrong, since I never yet used a server configured to serve
XHTML/XML correctly, and I understand it's no point converting HTML
pages to XHTML if the server can't do that. But I also have a differet
view about what "tag soap" is, as I have learn it only in the HTML
environment :)

--
/Arne

Top posters will be ignored. Quote the part you
are replying to, no more and no less! And don't
quote signatures, thank you.

Jul 21 '05 #3

Arne wrote:

With "treat it as tag soup" I assume you mean serve the page as
text/html insted of application/xhtml+xml ?
Indeed.
What makes it "tag soap"
if I change a particular page correct served content type to the
"wrong" type in this matter.
It goes through the browser's tag soup parser instead of an XML parser.
Serving CSS as text I understand, but the
web page probably looks the same in those browser that support both
text/html and application/xhtml+xml ?

No. CSS has special rules for how it is treated when applied to HTML
documents. That don't apply to XHTML documents.

http://www.mozilla.org/docs/web-deve...html#xhtmldiff describes some
of the differences for Mozilla.

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

Jul 21 '05 #4

On Sat, 09 Jul 2005 08:09:51 -0300, Arne <in*****@domain.invalid> wrote:

I may be wrong, since I never yet used a server configured to serve
XHTML/XML correctly, and I understand it's no point converting HTML
pages to XHTML if the server can't do that.

Any server that has server-side scripting such as PHP or JSP can serve web
pages as application/xhtml+xml.

--
Thanks,

Justin.
http://www.opera.com/mail/

Jul 21 '05 #5

Arne

Once upon a time *David Dorward* wrote:

Arne wrote:
With "treat it as tag soup" I assume you mean serve the page as
text/html insted of application/xhtml+xml ?
Indeed.
What makes it "tag soap"
if I change a particular page correct served content type to the
"wrong" type in this matter.

It goes through the browser's tag soup parser instead of an XML parser.

So the SGML parser is a "tag soap" parser? With all respect, if a page
is valid HTML then it's not tag soap. The tag soap is what's not
valid, in my opinion. But that's only my two cents of course.

But since everybody (not only in this group) advice others to code in
HTML before XHTML (and do so themself), I wonder why picking on some
others for coding tag soap only when the page don't validate and
render wrongly in some browsers? No mentioning about tag soap when the
page validates? :)

Serving CSS as text I understand, but the
web page probably looks the same in those browser that support both
text/html and application/xhtml+xml ?

No. CSS has special rules for how it is treated when applied to HTML
documents. That don't apply to XHTML documents.

When saying "the same", I was thinking about the HTML/XHTML coding
that don't involve CSS. Using <br> in HTML and </br> in XHTML will not
change the look of the page where no styling is used.

http://www.mozilla.org/docs/web-deve...html#xhtmldiff describes some
of the differences for Mozilla.

I have lost my respect for the Foundation since the decided to drop
development of the Suite :/

--
/Arne

Top posters will be ignored. Quote the part you
are replying to, no more and no less! And don't
quote signatures, thank you.

Jul 21 '05 #6

Arne

Once upon a time *Justin Sane* wrote:

On Sat, 09 Jul 2005 08:09:51 -0300, Arne <in*****@domain.invalid> wrote:
I may be wrong, since I never yet used a server configured to serve
XHTML/XML correctly, and I understand it's no point converting HTML
pages to XHTML if the server can't do that.

Any server that has server-side scripting such as PHP or JSP can serve web
pages as application/xhtml+xml.

Without any configuration?

--
/Arne

Top posters will be ignored. Quote the part you
are replying to, no more and no less! And don't
quote signatures, thank you.

Jul 21 '05 #7

On 09/07/2005 15:57, Arne wrote:

Once upon a time *David Dorward* wrote:
[snip]

It goes through the browser's tag soup parser instead of an XML parser.

So the SGML parser is a "tag soap" parser?

Perhaps very early browsers used proper SGML parsers, but modern ones
certainly don't.
With all respect, if a page is valid HTML then it's not tag soap.
That's true, of course. However, the only difference it will make to a
browser is that no error correction is necessary (so hopefully quicker
parsing), and that that browser can faithfully reproduce the document
tree the author expects (sometimes vital when scripting, and to a lesser
extent with CSS).

[snip]
When saying "the same", I was thinking about the HTML/XHTML coding
that don't involve CSS. Using <br> in HTML and </br> in XHTML will not
change the look of the page where no styling is used.

I assume you meant <br/>?

Yes, because a browser, when told to parse XHTML as text/html, looks at
XHTML constructs as very poor HTML (this is where the tag soup term
comes into play). It is this behaviour that allows XHTML 1.0 - Appendix
C to be at all workable. If browsers actually employed SGML parsers, an
Appendix C document would fall apart.

[snip]

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

Jul 21 '05 #8

Darin McGrew

Arne <in*****@domain.invalid> wrote:

So the SGML parser is a "tag soap" parser?

That's "tag soup", but yes. Actually, serving XHTML as text/html *relies*
upon browsers treating it as tag soup, and not following HTML/SGML syntax
rules accurately.

The few browsers that do have real SGML parsers have problems with XHTML
served as text/html. Then end up finding extraneous ">" characters after
every empty element.
--
Darin McGrew, mc****@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, da***@htmlhelp.com, http://www.HTMLHelp.com/

"Predictions are difficult, especially about the future." - Casey Stengel

Jul 21 '05 #9

On Sat, 09 Jul 2005 11:58:50 -0300, Arne <in*****@domain.invalid> wrote:

Any server that has server-side scripting such as PHP or JSP can serve
web
pages as application/xhtml+xml.

Without any configuration?

Yes :)

Try this PHP code:

<?php
if (stristr($_SERVER['HTTP_ACCEPT'], "application/xhtml+xml") ||
stristr($_SERVER["HTTP_USER_AGENT"],"W3C_Validator"))
{
header("Content-Type: application/xhtml+xml; charset=utf-8");
header("Vary: Accept");
echo("<?xml version=\"1.0\" encoding=\"utf-8\"?>\n");
}
else
{
header("Content-Type: text/html; charset=utf-8");
header("Vary: Accept");
}
?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="application/xhtml+xml;
charset=utf-8" />
<style type="text/css">
@import url(c/c.css);
</style>
<title></title>
</head>
<body>
</body>
</html>
Save it as .php, and open it on your web site. Now add a </p> tag
somewhere in the page, save it and re-open the page in your browser, the
browser is going to give a debug error message showing where the XML
synthax error is located.

PS: Doesn't work in IE.
--

Justin.
http://www.opera.com/mail/

Jul 21 '05 #10

Justin Sane wrote:

if (stristr($_SERVER['HTTP_ACCEPT'], "application/xhtml+xml") ||
stristr($_SERVER["HTTP_USER_AGENT"],"W3C_Validator"))

So ...

Accept: application/xhtml+xml;q=0,text/html

.... would end up getting XHTML? Very bad.

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

Jul 21 '05 #11

On Sat, 09 Jul 2005 19:11:35 -0300, David Dorward <do*****@yahoo.com>
wrote:

... would end up getting XHTML? Very bad.

Why? It's a W3C recommendation, nothing bad to follow the trend.

--
Thanks,

Justin.
http://www.opera.com/mail/

Jul 21 '05 #12

Justin Sane wrote:

On Sat, 09 Jul 2005 19:11:35 -0300, David Dorward <do*****@yahoo.com>
wrote:
... would end up getting XHTML? Very bad.
Why?

Well you cunningly snipped the Accept line which would cause your code to
give XHTML to a browser which explicitly said it did not accept XHTML. But
I thought it would be obvious why that was bad.
It's a W3C recommendation, nothing bad to follow the trend.

That's what the lemmings said.

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

Jul 21 '05 #13

"David Dorward" <do*****@yahoo.com> wrote in message
news:da*******************@news.demon.co.uk...

Roedy Green wrote:
does converting the XHTML make matters better or worse vis a vis CSS
not behaving the way you expect?
Well ... it makes them different (such as stuff being applied, by default,
to <html> instead of <body> in some browsers).

It also introduces a host of issues with browser support (e.g. Lynx,
GoogleBot and Internet Explorer don't support it),

Absolute crap! I have pages which are XHTML 1.0 strict, and not only do they
render perfectly in IE (and Firefox, and Opera) they also validate as XHTML
strict in the W3C validator service.

--
Tony Marston

http://www.tonymarston.net
unless you treat it as
tag soup - in which case what's the point of converting?

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

Jul 21 '05 #14

On 10/07/2005 01:54, Justin Sane wrote:

On Sat, 09 Jul 2005 19:11:35 -0300, David Dorward <do*****@yahoo.com>
wrote:
[restoring full quote:]

So ...

Accept: application/xhtml+xml;q=0,text/html

... would end up getting XHTML? Very bad.

Why?

In that particular example, the client is stating that
application/xhtml+xml is completely unacceptable, and the server should
send text/html. That's extreme, but your suggestion would also fail if
application/xhtml+xml was marked with a lower relative quality value, too.
It's a W3C recommendation, nothing bad to follow the trend.

Poor support across many user agents, and problems even in browsers that
do support it. For the moment, it's not a good trend to follow at all.

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

Jul 21 '05 #15

Tony Marston wrote:

It also introduces a host of issues with browser support (e.g. Lynx,
GoogleBot and Internet Explorer don't support it),

Yes, go on. Snip the most important bit of the material you are responding
to why don't you?

"unless you treat it as tag soup - in which case what's the point of
converting?"
Absolute crap! I have pages which are XHTML 1.0 strict, and not only do
they render perfectly in IE
So you are serving them as text/html then? What's the point of using XHTML
if you are going to serve it as text/html?
(and Firefox, and Opera) they also validate as XHTML strict in the W3C
validator service.

Eye halve a spelling chequer
It came with my pea sea
It plainly marques four my revue
Miss steaks eye kin knot sea.

Valid code is important, but quality control needs more then just validity.

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

Jul 21 '05 #16

On Sun, 10 Jul 2005 06:22:35 -0300, Michael Winter
<m.******@blueyonder.co.uk> wrote:

Poor support across many user agents, and problems even in browsers that
do support it. For the moment, it's not a good trend to follow at all.

But if you look closely at my snippet, you'll see that it sends the
application/xhtml+xml header only to the user-agents that accept it. It
sends text/html to others such as IE for instance. What do you think?

--
Thanks,

Justin.
http://www.opera.com/mail/

Jul 21 '05 #17

On Sun, 10 Jul 2005 06:06:55 -0300, David Dorward <do*****@yahoo.com>
wrote:

Well you cunningly snipped the Accept line which would cause your code to
give XHTML to a browser which explicitly said it did not accept XHTML.
But
I thought it would be obvious why that was bad.

No it doesn't. It sends text/html to the user-agents that don't accept
application/xhtml+xml
I don't see anything bad.

--
Thanks,

Justin.
http://www.opera.com/mail/

Jul 21 '05 #18

On Sun, 10 Jul 2005 08:31:26 -0300, David Dorward <do*****@yahoo.com>
wrote:

So you are serving them as text/html then? What's the point of using
XHTML
if you are going to serve it as text/html?

Compatibility with IE. Send as application/xhtml+xml for those that accept
it ; send as text/html for the others.
XHTML is cleaner code, it is based on XML, and it's a good practice to
start using it for the future. We don't know how the web will be 10 years
from now. We don't know either how we'll be accessing web pages by then.

--
Thanks,

Justin.
http://www.opera.com/mail/

Jul 21 '05 #19

Justin Sane wrote:

So you are serving them as text/html then? What's the point of using
XHTML if you are going to serve it as text/html?
Compatibility with IE. Send as application/xhtml+xml for those that accept
it ; send as text/html for the others.
So you get to jump through lots of hoops to decide what content type to use.
XHTML is cleaner code,
That is debatable.
it is based on XML,
So what?
and it's a good practice to start using it for the future.

Why?

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

Jul 21 '05 #20

Justin Sane wrote:

On Sun, 10 Jul 2005 06:06:55 -0300, David Dorward <do*****@yahoo.com>
wrote:
Well you cunningly snipped the Accept line which would cause your code to
give XHTML to a browser which explicitly said it did not accept XHTML.
But I thought it would be obvious why that was bad.
No it doesn't. It sends text/html to the user-agents that don't accept
application/xhtml+xml
I don't see anything bad.

No, it sends it to any user agent with application/xhtml+xml in the Accept
header - irrespective of the quality value given to it - even if that
quality value is 0 (meaning DO NOT send me this content type).

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

Jul 21 '05 #21

On 10/07/2005 17:55, Justin Sane wrote:

[snip]

But if you look closely at my snippet
I looked close enough, let me assure you.
you'll see that it sends the application/xhtml+xml header only to the
user-agents that accept it. [...]

No, it sends an application/xhtml+xml content type to any user agent
that has the same in its Accept header. That isn't the same thing - read
my post again. It also seems you should read sections 3.9 Quality Values
and 14.1 Accept in RFC 2616 - Hypertext Transfer Protocol, and then
rewrite that code.

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

Jul 21 '05 #22

On Sun, 10 Jul 2005 14:17:36 -0300, David Dorward <do*****@yahoo.com>
wrote:

and it's a good practice to start using it for the future.

Why?

The future will tell us :)
--
Thanks,

Justin.
http://www.opera.com/mail/

Jul 21 '05 #23

On Sun, 10 Jul 2005 14:18:47 -0300, David Dorward <do*****@yahoo.com>
wrote:

No, it sends it to any user agent with application/xhtml+xml in the
Accept
header - irrespective of the quality value given to it - even if that
quality value is 0 (meaning DO NOT send me this content type).

David, do you mean one shouldn't send the pages as application/xhtml+xml
to standard-complient user-agents such as Opera and Mozilla?

--
Thanks,

Justin.
http://www.opera.com/mail/

Jul 21 '05 #24

Justin Sane wrote:

No, it sends it to any user agent with application/xhtml+xml in the
Accept
header - irrespective of the quality value given to it - even if that
quality value is 0 (meaning DO NOT send me this content type).
David, do you mean one shouldn't send the pages as application/xhtml+xml
to standard-complient user-agents such as Opera and Mozilla?

I mean that you shouldn't send pages as application/xhtml+xml to browsers
which explicitly say they do not accept it (your code does send pages as
application/xhtml+xml to pages which explicitly say they do not accept it).

Opera, IIRC, sets a lower quality value on application/xhtml+xml then it
does on text/html, so you shouldn't usually send pages as
application/xhtml+xml to it.

Mozilla is debatable because we're getting right back to the what's the
point of using XHTML in the first place and is it worth doing this sniffing
and processing just for the sake of picking a content-type?

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

Jul 21 '05 #25

Spartanicus

David Dorward <do*****@yahoo.com> wrote:

David, do you mean one shouldn't send the pages as application/xhtml+xml
to standard-complient user-agents such as Opera and Mozilla?

[snip]
Mozilla is debatable because we're getting right back to the what's the
point of using XHTML in the first place and is it worth doing this sniffing
and processing just for the sake of picking a content-type?

Plus Mozilla isn't capable of rendering application/xhtml+xml
incrementally, incremental rendering is an undervalued feature.

For Justin: http://www.spartanicus.utvinternet.ie/no-xhtml.htm

--
Spartanicus

Jul 21 '05 #26

"David Dorward" <do*****@yahoo.com> wrote in message
news:da*******************@news.demon.co.uk...

Tony Marston wrote:
It also introduces a host of issues with browser support (e.g. Lynx,
GoogleBot and Internet Explorer don't support it),
Yes, go on. Snip the most important bit of the material you are responding
to why don't you?
You are saying that IE does not support XHTML, which implies that it cannot
render it correctly. I am saying that you are talking out of the wrong end
of your alimentary canal. I have produced a page which is XHTML strict, it
validates as such with the W3C validator service, and it renders exactly the
same in various browsers (including IE). IE does not choke on the XHTML
doctype, nor does it make any mistakes when rendering the page.

Therefore you are wrong when you say that IE does not support XHTML. Exactly
HOW it renders XHTML is irrelevant as long as it renders it correctly, which
it does.
"unless you treat it as tag soup - in which case what's the point of
converting?"
Absolute crap! I have pages which are XHTML 1.0 strict, and not only do
they render perfectly in IE

So you are serving them as text/html then? What's the point of using XHTML
if you are going to serve it as text/html?

The content type is irrelevant. It is the DOCTYPE which is important.
(and Firefox, and Opera) they also validate as XHTML strict in the W3C
validator service.

Eye halve a spelling chequer
It came with my pea sea
It plainly marques four my revue
Miss steaks eye kin knot sea.

Valid code is important, but quality control needs more then just
validity.

Such as what? If the code passes through the W3C validator and is rendered
correctly in the browser then that is all that matters. Everything else is
irrelevant.

--
Tony Marston

http://www.tonymarston.net

Jul 21 '05 #27

On Mon, 11 Jul 2005 03:48:43 -0300, David Dorward <do*****@yahoo.com>
wrote:

I mean that you shouldn't send pages as application/xhtml+xml to browsers
which explicitly say they do not accept it (your code does send pages as
application/xhtml+xml to pages which explicitly say they do not accept
it).

Ok, but my code doesn't send pages as application/xhtml+xml to browsers
that don't accept it. IE for instance opens my pages just fines because
they're served as text/html to it. If I don't use this script and send a
header with application/xhtml+xml, IE doesn't display the page but prompts
to download the page instead.

<?php
if (stristr($_SERVER['HTTP_ACCEPT'], "application/xhtml+xml") ||
stristr($_SERVER["HTTP_USER_AGENT"],"W3C_Validator"))
{
header("Content-Type: application/xhtml+xml; charset=utf-8");
header("Vary: Accept");
echo("<?xml version=\"1.0\" encoding=\"utf-8\"?>\n");
}
else
{
header("Content-Type: text/html; charset=utf-8");
header("Vary: Accept");
}

--

Justin.
http://www.opera.com/mail/

Jul 21 '05 #28

On Mon, 11 Jul 2005 05:19:22 -0300, Tony Marston <to**@NOSPAM.demon.co.uk>
wrote:

The content type is irrelevant. It is the DOCTYPE which is important.

Both.

--
Thanks,

Justin.
http://www.opera.com/mail/

Jul 21 '05 #29

Jim Ley

On Mon, 11 Jul 2005 09:04:50 -0300, "Justin Sane" <me@privacy.net>
wrote:

Ok, but my code doesn't send pages as application/xhtml+xml to browsers
that don't accept it.
As David was aying, the below is not sufficient for idenfying browsers
that don't accept it, and you should read the relevant RFC's
<?php
if (stristr($_SERVER['HTTP_ACCEPT'], "application/xhtml+xml") ||

This says "does the accept string contain application/xhtml+xml,
that's not enough, it could fail with

x-chicken-application/xhtml+xml+stuff, or indeed anything else
similar, or more realisitically something like:

Accept: application/xhtml+xml; q=0, text/html

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

Jul 21 '05 #30

Tony Marston wrote:

Yes, go on. Snip the most important bit of the material you are responding
to why don't you?
You are saying that IE does not support XHTML, which implies that it cannot
render it correctly.

You've snipped it again!

As far as the browser is concerned, XHTML isn't XHTML if its served as
text/html - its HTML with some errors in it.
So you are serving them as text/html then? What's the point of using XHTML
if you are going to serve it as text/html?

The content type is irrelevant. It is the DOCTYPE which is important.

Since the content-type influences how the data is handled, it is not
irrelevent - it is far more relevent than the Doctype.

Valid code is important, but quality control needs more then just
validity.

Such as what? If the code passes through the W3C validator and is rendered
correctly in the browser then that is all that matters. Everything else is
irrelevant.

The browser? What is "The" browser? There are many different browsers
out there.

I could write a page which consisted of a table with one row and each
paragraph in a table heading cell of its own. Then I could use a style
sheet to make it render as I wanted.

The markup would still be absolute rubbish though.

Jul 21 '05 #31

Christoph Päper

Justin Sane:

Compatibility with IE. Send as application/xhtml+xml for those that
accept it ; send as text/html for the others.
Do only so, if you know what you are doing and how. You have
demonstrated repeatedly, that you don't. You are in large company.
XHTML is cleaner code,
It's more verbose, yes. Redundant or clumsy are other words that spring
to mind. At least XML should have /allowed/ empty end tags ('</>') for
they are unambiguous with it. *I* like other SHORTTAG features, too.

Extensibility is a good idea, implemented badly. Namespaces are an ugly
hack. Well-formedness is a good idea, too.

XHTML 1.0 was never intended to be seriously used by anyone, but just a
proof of concept. Strict doctypes were, though. What do people do? They
write malformed XHTML 1.0 Transitional. Elsewhere 'div' is used like the
guillotine in 1790s France.
it is based on XML,
<q cite="simpsons/smithers">But she's got a new hat!</>
and it's a good practice to start using it for the future.
I just read the worst article on XHTML2, which is still a working draft
and hopefully will be improved a lot, in one of the most respected
(German) computer magazines. I'm traumatized. I hate hypes. People will
start using it (too) soon and call the better-knowing old-fashioned. I
hate people. I hate fashion.
We don't know how the web will be 10 years from now.
There. Huge. Less American. Flashy here, informative there. With tons of
HTML. Also search tools whose analysing AIs will better understand the
texts than the usual HIs writing them, and the M still with only minor
influence.

Only the narrow-minded care about such a short timeframe anyhow.
(Includes many W3C members of course and most people. At least for RL it
includes me, too.)
We don't know either how we'll be accessing web pages by then.

Direct computer to brain interfaces are unlikely to have been invented
(save introduced on the market and affordable) by then. Anything else
cannot beat plain old text to be skimmed or even read, if desired or
necessary, (and typed or written) for the average human being. I'll hate
vocal/aural HMIs (in public) just as much as (mobile) phones and (car)
stereos now.

PS: I maybe hate everyone, but I cannot hate someone.

Jul 21 '05 #32

"Justin Sane" <me@privacy.net> wrote in message
news:op.stqzw7gsgl9owm@charles...

On Mon, 11 Jul 2005 05:19:22 -0300, Tony Marston <to**@NOSPAM.demon.co.uk>
wrote:
The content type is irrelevant. It is the DOCTYPE which is important.

Both.

WRONG! The W3C validator service says that my page is valid XHTML even
though the content type does not say "application/xhtml+xml". Therefore the
content type is NOT as important as you seem to make out.

--
Tony Marston

http://www.tonymarston.net

Jul 21 '05 #33

"David Dorward" <do*****@gmail.com> wrote in message
news:11*********************@g49g2000cwa.googlegro ups.com...

Tony Marston wrote:
> Yes, go on. Snip the most important bit of the material you are
> responding
> to why don't you?
You are saying that IE does not support XHTML, which implies that it
cannot
render it correctly.
You've snipped it again!

As far as the browser is concerned, XHTML isn't XHTML if its served as
text/html - its HTML with some errors in it.

There are no errors in it, otherwise the W3C validator service would report
them.

> So you are serving them as text/html then? What's the point of using
> XHTML
> if you are going to serve it as text/html?

The content type is irrelevant. It is the DOCTYPE which is important.

Since the content-type influences how the data is handled, it is not
irrelevent - it is far more relevent than the Doctype.

Not to the W3C validator service - it uses the DOCTYPE and ignores the
content-type.

> Valid code is important, but quality control needs more then just
> validity.

Such as what? If the code passes through the W3C validator and is
rendered
correctly in the browser then that is all that matters. Everything else
is
irrelevant.

The browser? What is "The" browser? There are many different browsers
out there.

When I say "the" browser I mean whatever browser that is installed on the
client machine.
I could write a page which consisted of a table with one row and each
paragraph in a table heading cell of its own. Then I could use a style
sheet to make it render as I wanted.

The markup would still be absolute rubbish though.

Your opinion of what is or is not valid XHTML is totally irrelevant. The
definitive answer is supplied by the W3C validator service. If it determines
that a page is valid XHTML then who the hell are you to argue?

--
Tony Marston

http://www.tonymarston.net

Jul 21 '05 #34

On 12/07/2005 09:46, Tony Marston wrote:

"Justin Sane" <me@privacy.net> wrote in message
news:op.stqzw7gsgl9owm@charles...
[Both DOCTYPE and content type are important]
WRONG! The W3C validator service says that my page is valid XHTML
The validator is a tool, and indicates nothing more than basic syntactic
adherence to whatever document type you claim to be writing towards. The
prose of the specification describes additional constraints for a valid
document that the DTD cannot. Your claim (elsewhere) to the contrary:

"The definitive answer is supplied by the W3C validator service."

is fallacious and might serve to demonstrate your lack of understanding.
even though the content type does not say "application/xhtml+xml".
The validator isn't really bothered (though it will reject stupid
types). You can serve XHTML 1.1 to it as text/html - even though there
are no provisions for doing so - and it will still state that it is
valid if the document is marked-up in agreement with the DTD.
Therefore the content type is NOT as important as you seem to make
out.

Yes, it is. It doesn't matter whether the validator respects the
Content-Type header or not. Browsers do, and a browser will treat XHTML
served as text/html as very badly written HTML. This is the only reason
why IE renders your document - it has a very high tolerance for garbage.

If you want to continue arguing this, would you kindly join one of the
threads in ciwah. This has nothing to do with style sheets. Follow-ups
set accordingly.

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

Jul 21 '05 #35

On Tue, 12 Jul 2005 05:46:28 -0300, Tony Marston <to**@NOSPAM.demon.co.uk>
wrote:

The content type is irrelevant. It is the DOCTYPE which is important.

Both.

WRONG! The W3C validator service says that my page is valid XHTML even
though the content type does not say "application/xhtml+xml". Therefore
the
content type is NOT as important as you seem to make out.

Then how do you explain that:

- If you send a valid xhtml page as application/xhtml+xml:
- to IE, the page isn't displayed but IE prompts for download
- to standard-compliants browsers, the browser opens the page, but the
bottom boundary is limited to the document boundary instead of the browser
window

- If you send an invalid xhtml page as application/xhtml+xml:
- to IE, the page isn't displayed but IE prompts for download
- to standard-compliants browsers, the browser opens a debug screen
instead of opening the page

- If you send an xhtml page (valid or not) as text/html:
- to IE, the page is displayed properly
- to standard-compliants browsers the page is also displayed properly,
but the bottom boundary is not limited to the document boundary anymore
and bleeds all the way down to the bottom of the browser window

?

--
Thanks,

Justin.
Want to buy me a book? http://tinyurl.com/78xzb :)

Jul 21 '05 #36