XHTML 1.0 / 1.1 / 2.0

In article <dg**********@phys-news1.kolumbus.fi>,
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote:

XHTML 1.1 is an exercise in futility, a dead end, and both practically
and theoretically useless.
Out of curiosity, do you consider Ruby both practically and
theoretically useless or do you consider the modularization of the DTD
practically and theoretically useless?

To me it seems that Ruby has at least theoretical merit. As for the DTD,
I am a proponent of DTDlessness in languages built on top XML.
XHTML 2.0 is being designed to be incompatible with every previous HTML
version, though similar enough to confuse people into thinking
otherwise.
I think the label "exercise in futility" is particularly appropriate for
XHTML 2.0.
If it will ever be released,
It will be interesting to see how they intend to come up with two
interoperable implementations. However, it seems unlikely that the HTML
WG would give up on its own initiative.
it will most probably be
advertized as a successor of XHTML 1.0, not of XHTML 1.1.

Well, the advertising does not need to be strictly reality-based, so
XHTML 2.0 could be advertised anything. It is already advertised that
"more than 95% of browsers in use, can process new markup languages
without having to be updated".

Bonus XHTML 2.0 link:
http://hades.mn.aptest.com/cgi-bin/x...ocType?id=7336

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

Sep 12 '05 #3

Guy Macon

Henri Sivonen wrote:

Bonus XHTML 2.0 link:
http://hades.mn.aptest.com/cgi-bin/x...ocType?id=7336

The snippet [ xml:lang="en-US" ] caught my eye. A Google search
( http://www.google.com/search?q=xml%3Alang%3D%22en-US%22 ) shows
different pages using en-us, en-US and EN-US. Is this case
sensitive in XHTML, and if so, which is correct?

Sep 12 '05 #4

On Mon, 12 Sep 2005, it was written:

different pages using en-us, en-US and EN-US. Is this case
sensitive in XHTML, and if so, which is correct?

Correct is only en-GB-King.

SCNR

Sep 12 '05 #5

Martin Honnen

Guy Macon wrote:

The snippet [ xml:lang="en-US" ] caught my eye. A Google search
( http://www.google.com/search?q=xml%3Alang%3D%22en-US%22 ) shows
different pages using en-us, en-US and EN-US. Is this case
sensitive in XHTML, and if so, which is correct?

xml:lang is an attribute the XML specification itself defines:
<http://www.w3.org/TR/2004/REC-xml-20040204/#sec-lang-tag>
For possible values it refers to this RFC
<http://www.ietf.org/rfc/rfc3066.txt>
and that says
"All tags are to be treated as case insensitive; there exist
conventions for capitalization of some of them, but these should not
be taken to carry meaning. For instance, [ISO 3166] recommends that
country codes are capitalized (MN Mongolia), while [ISO 639]
recommends that language codes are written in lower case (mn
Mongolian)."
So whether you use en-us or en-US or EN-US does not matter in terms of
the semantics but the conventions cited suggest en-US.

--

Martin Honnen
http://JavaScript.FAQTs.com/

Sep 12 '05 #6

Jukka K. Korpela

Henri Sivonen <hs******@iki.fi> wrote:

In article <dg**********@phys-news1.kolumbus.fi>,
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote:
XHTML 1.1 is an exercise in futility, a dead end, and both practically
and theoretically useless.

Out of curiosity, do you consider Ruby both practically and
theoretically useless or do you consider the modularization of the DTD
practically and theoretically useless?

I wasn't taking any position on those issues; they do not depend on
XHTML 1.1, which is just a pointless mix of "modularizing" XHTML 1.0,
throwing in the Ruby stuff, and making some silent changes, including
changes that make it impossible to use client-side image maps on current
browsers.

If I took a position on those matters, I'd probably say that Ruby looks OK,
except for its semantics, which is undefined. (Is it for East Asian
languages only, or is it generally for interlinear annotations? To say that
it's for both means really that it's not suitable for either purpose.)
And I'd say that modularization of XHTML is a misguided attempt at creating
order in tag soup. (By "tag soup", I mean tagwise thinking, not any
syntactic nuances or even the big picture of syntax. Invent tags, assign
meanings to them as you go, and shake well.)

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

Sep 12 '05 #7

mbstevens

Jukka K. Korpela wrote:

Henri Sivonen <hs******@iki.fi> wrote:

In article <dg**********@phys-news1.kolumbus.fi>,
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote:
I'd probably say that Ruby looks OK, except for its semantics, which is undefined. (Is it for East Asian
languages only, or is it generally for interlinear annotations? To say that
it's for both means really that it's not suitable for either purpose.)

Just as clarification for people not familiar with what's going
on here --

The Ruby _markup_ for Asian languages being spoken of here is
explained at:
http://www.w3.org/TR/ruby/#what

The _language_ Ruby coming out of Japan, is a scripting language
similar in some ways to Perl and Python, and is not the same
thing. You can find out about this at:
http://www.ruby-lang.org/en/20020101.html
--
mbstevens
http://www.mbstevens.com/

Sep 12 '05 #8

Jukka K. Korpela

mbstevens <NO***********@xmbstevensx.com> wrote:

Jukka K. Korpela wrote:
Henri Sivonen <hs******@iki.fi> wrote:

In article <dg**********@phys-news1.kolumbus.fi>,
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote: I'd probably say that
Ruby looks OK, except for its semantics, which is undefined. (Is it
for East Asian languages only, or is it generally for interlinear annotations? To say
that it's for both means really that it's not suitable for either
purpose.)

Just as clarification for people not familiar with what's going
on here --

The Ruby _markup_ for Asian languages being spoken of here is
explained at:
http://www.w3.org/TR/ruby/#what

The point in my question was whether Ruby markup is for (East) Asian
languages only. The Ruby specification, which you cite, does _not_ answer
this question appropriately. It describes Ruby vaguely, e.g.:

"Ruby is the term used for a run of text that is associated with another
run of text, referred to as the base text. Ruby text is used to provide a
short annotation of the associated base text. It is most often used to
provide a reading (pronunciation guide). Ruby annotations are used
frequently in Japan in many kinds of publications, including books and
magazines. Ruby is also used in China, especially in schoolbooks."

It goes on the explain the origin of the name "ruby" as denoting a font
size of 5.5 points, and later explains that ruby text normally appears
about half the font size of the base text.

Ruby looks _very_ much like an attempt to cover certain notational and
typographic usage of Chinese and Japanese, presenting examples using Latin
letters as artificial illustrations only, and with little or no concern
about the real applicability of Ruby markup for purposes outside
traditional Chinese and Japanese usage of ruby text.
The _language_ Ruby coming out of Japan, is a scripting language

I don't think there was much danger of confusion with that, but it's always
exciting to hear about new programming languages. :-)

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

Sep 13 '05 #9

Henri Sivonen wrote:

Out of curiosity, do you consider Ruby both practically and
theoretically useless or do you consider the modularization of the DTD
practically and theoretically useless?

Or the ditching of frames and a transitional DTD?

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

Sep 13 '05 #10

Buford Early wrote:

"A common misconception is that XHTML 1.1 is the latest version
of the XHTML series. And although it was released a bit more
than a year later then the first version of XHTML 1.0, the second
edition is actually newer. Furthermore, XHTML 1.1 is not really
the follow-up of XHTML 1.0"

The second edition of XHTML 1.0 is not a new standard. It is just a
rewritten, clarified version of the old XHTML 1.0.

XHTML 1.1 is newer as standards go. From an author's point of view it is
almost identical to XHTML 1.0 Strict, but with ruby added, and a handful
of attributes dropped (*@lang, a@name, map@name). Unless you need ruby,
there's not an awful lot of argument in favour of using it. OTOH, unless
you need to support truly ancient browsers, or need to use client-side
image maps, there's not an awful lot argument against it.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

Sep 13 '05 #11

Toby Inkster <us**********@tobyinkster.co.uk> wrote:

XHTML 1.1 is newer as standards go. From an author's point of view it is
almost identical to XHTML 1.0 Strict, but with ruby added, and a handful
of attributes dropped (*@lang, a@name, map@name). Unless you need ruby,
there's not an awful lot of argument in favour of using it. OTOH, unless
you need to support truly ancient browsers, or need to use client-side
image maps, there's not an awful lot argument against it.

So far I've not seen you produce an argument that would support ignoring
w3c's guideline not to serve XHTML 1.1 as text/html.

--
Spartanicus

Sep 13 '05 #12

zukisa86

You are not wrong the XHTML should be taken serious.

Sep 13 '05 #13

zukisa86

You are not wrong the XHTML should be taken serious.

Sep 13 '05 #14

zukisa86

You are not wrong the XHTML should be taken serious.

Sep 13 '05 #15

Guy Macon

Spartanicus wrote:

Toby Inkster wrote:
XHTML 1.1 is newer as standards go. From an author's point of view it is
almost identical to XHTML 1.0 Strict, but with ruby added, and a handful
of attributes dropped (*@lang, a@name, map@name). Unless you need ruby,
there's not an awful lot of argument in favour of using it. OTOH, unless
you need to support truly ancient browsers, or need to use client-side
image maps, there's not an awful lot argument against it.
So far I've not seen you produce an argument that would support ignoring
w3c's guideline not to serve XHTML 1.1 as text/html.

(Warning: I am by no means an expert on this, but I seem to muddle
through OK; be sure to check the replies for corrections...)

I cut and pasted this chart from somewhere:
application application
Media Type text/html /xhtml+xml /xml text/xml
HTML 4.01 SHOULD MUST NOT MUST NOT MUST NOT
XHTML 1.0 (HTML Compat.) MAY SHOULD MAY MAY
XHTML 1.0 (other) SHOULD NOT SHOULD MAY MAY
XHTML Basic SHOULD NOT SHOULD MAY MAY
XHTML 1.1 SHOULD NOT SHOULD MAY MAY

....so it seems to me that if you are willing to serve your pages as
application/xhtml+xml then there is no reason to avoid XHTML 1.1,
but if you decide to to serve your pages as text/html then there is
no good reason to use anything except HTML 4.01.

I have been redoing my webpages, and I have decided to have two copies
of each page: one is HTML 4.01 strict served as text/html with a filename
of *.html, and the other is XHTML 1.1 served as application/xhtml+xml
with a filename of *.xhtml - all with appropriatly labelled navigation
links to give the user a choice of versions.

As far as I can tell, if I am careful with my markup, the only
differences will be...

(.html)

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
(.xhtml)

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
(.htaccess)

DirectoryIndex index.html index.xhtml
AddType 'text/html; charset=US-ASCII' html
AddType 'application/xhtml+xml; charset=US-ASCII' xhtml

....and I already wrote a macro that makes the two versions.

Corrections/comments/ass-chewings welcome!)

****************************************

(...added later...)
I just did some Googling to see if he above is totally stupid,
and I found the following in an example document:

Example of an XHTML 2.0 document

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css"
href="http://www.w3.org/MarkUp/style/xhtml2.css"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 2.0//EN"
"http://www.w3.org/MarkUp/DTD/xhtml2.dtd">
<html xmlns="http://www.w3.org/2002/06/xhtml2/" xml:lang="en"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2002/06/xhtml2/
http://www.w3.org/MarkUp/SCHEMA/xhtml2.xsd"

Do I need any of the extra stuff above, or is my simpler version above
suitable for what I am doing? I do use CSS, but no tables, math, etc.
--
Guy Macon <http://www.guymacon.com/>

When it comes to web design, I am is a pretty
good assembly language programmer... :)

Sep 13 '05 #16

In article <11*************@corp.supernews.com>,
Guy Macon <http://www.guymacon.com/> wrote:

but if you decide to to serve your pages as text/html then there is
no good reason to use anything except HTML 4.01.

I have been redoing my webpages, and I have decided to have two copies
of each page: one is HTML 4.01 strict served as text/html with a filename
of *.html, and the other is XHTML 1.1 served as application/xhtml+xml
with a filename of *.xhtml - all with appropriatly labelled navigation
links to give the user a choice of versions.
Out of curiosity, what use case inspired you to expend the extra effort
the maintain two versions? (I have been making observations about the
subject matter for some time now, and I am always curious about motives
that I may have failed to consider myself.)

BTW, if you are referring to http://www.guymacon.com/ , the site shows
an Apache-generated directory listing.
Example of an XHTML 2.0 document

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css"
href="http://www.w3.org/MarkUp/style/xhtml2.css"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 2.0//EN"
"http://www.w3.org/MarkUp/DTD/xhtml2.dtd">
<html xmlns="http://www.w3.org/2002/06/xhtml2/" xml:lang="en"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2002/06/xhtml2/
http://www.w3.org/MarkUp/SCHEMA/xhtml2.xsd"

Do I need any of the extra stuff above, or is my simpler version above
suitable for what I am doing? I do use CSS, but no tables, math, etc.

That's from a XHTML 2.0 draft and, due to the draft status at the very
least, should not be deployed on the Web.

There's an awful lot of boilerplate cruft. The crux of the matter is
<html xmlns="http://www.w3.org/2002/06/xhtml2/" xml:lang="en">
The rest is some serious cruft. (And some people would categorize the
namespace declaration as cruft, too, along with the whole concept of
namespaces...)

See also
http://copia.ogbuji.net/blog/2005-08-10/Today_s_XM

The issue tracker page I already referred to provides some hints about
the world view of the HTML WG:
http://hades.mn.aptest.com/cgi-bin/x...ocType?id=7336

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

Sep 13 '05 #17

Guy Macon <http://www.guymacon.com/> wrote:

...so it seems to me that if you are willing to serve your pages as
application/xhtml+xml then there is no reason to avoid XHTML 1.1,
IE and certain other browsers can't handle it, bot compatibility is
questionable, and you are disadvantaging users who use a Gecko based
browser since it cannot render XHTML served as such incrementally.
I have been redoing my webpages, and I have decided to have two copies
of each page: one is HTML 4.01 strict served as text/html with a filename
of *.html, and the other is XHTML 1.1 served as application/xhtml+xml
with a filename of *.xhtml - all with appropriatly labelled navigation
links to give the user a choice of versions.
Users don't give a flying monkey for code versions, and you'd at least
need to request that SE bots do not index the xhtml pages. So what's the
point?
As far as I can tell, if I am careful with my markup, the only
differences will be...

(.html)

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
(.xhtml)

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
There are other differences such as mandatory attribute value quoting,
required closing of elements etc.
Example of an XHTML 2.0 document

XHTML 2.0 is not finished, and currently defined as being non backward
compatible.

--
Spartanicus

Sep 13 '05 #18

Guy Macon

Henri Sivonen wrote:

BTW, if you are referring to http://www.guymacon.com/ , the site shows
an Apache-generated directory listing.
I am in the middle of updating it, and I cleared everything out and
am redoing the entire structure (with 301 redirects so that the old
URLs still work, of course).
Guy Macon <http://www.guymacon.com/> wrote:
but if you decide to to serve your pages as text/html then there is
no good reason to use anything except HTML 4.01.

I have been redoing my webpages, and I have decided to have two copies
of each page: one is HTML 4.01 strict served as text/html with a filename
of *.html, and the other is XHTML 1.1 served as application/xhtml+xml
with a filename of *.xhtml - all with appropriatly labelled navigation
links to give the user a choice of versions.

Out of curiosity, what use case inspired you to expend the extra effort
the maintain two versions? (I have been making observations about the
subject matter for some time now, and I am always curious about motives
that I may have failed to consider myself.)

Mine is a special case.

My first motivation: I have a lot of engineers and engineering managers
who examine my markup for clues as to what kind of engineer I am.
Having a link to an XHTML 1.1 version is good PR for me.

My second motivation: I design products that use webpages as the user
interface. People love to be able to fire up the old browser to see
how the robotic assembly line is doing. This makes it important for
me to know about things like the difference between HTML and XHTML,
how to make pages work well with cellphone browsers, etc.

My third motivation; I am a geek and find playing with technology to
be relaxing.

Sep 13 '05 #19

Guy Macon

Spartanicus wrote:

Users don't give a flying monkey for code versions,
*Your* users don't give a flying monkey for code versions. *My* users
comment on things like my decision to switch from XHTML-Basic to XHTML
1.0.
There are other differences such as mandatory attribute value quoting,
required closing of elements etc.
I am unaware of any difference that makes it so that I cannot write
a simple webpage that works in XHTML 2.0 and HTML 4.01 strict.
XHTML 2.0 is not finished, and currently defined as being non backward
compatible.

That's the whole point of having a *.html version and a *.xhtml version.
*My* users will want to know whether their browsers will work with both
- especially when the browser in question is one I wrote to be part of
a children's toy...

Sep 13 '05 #20

In article
<l1********************************@news.spartanic us.utvinternet.ie>,
Spartanicus <in*****@invalid.invalid> wrote:

you'd at least
need to request that SE bots do not index the xhtml pages.

Are there SE bots that support application/xhtml+xml?

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

Sep 13 '05 #21

Henri Sivonen <hs******@iki.fi> wrote:

you'd at least
need to request that SE bots do not index the xhtml pages.

Are there SE bots that support application/xhtml+xml?

Hotbot/Ask Jeeves indexes pages served as such, although I suspect that
it parses as text/html. Google doesn't appear to index them, I haven't
tried any others but it seems likely that Hotbot isn't alone.

http://www.hotbot.com/default.asp?qu...+to+do+with+it
[first result]

--
Spartanicus

Sep 13 '05 #22

On Tue, 13 Sep 2005, Henri Sivonen wrote:

Are there SE bots that support application/xhtml+xml?

Do they follow the Content-Type header, in the first place?
Google, for example, does not:
http://ppewww.ph.gla.ac.uk/~flavell/...tent-type.html

Both Google's web search and Usenet interface ignore the
Content-Type header, including the charset parameter.

Sep 13 '05 #23

James Pickering

Guy Macon wrote:

I have been redoing my webpages, and I have decided to have two copies
of each page: one is HTML 4.01 strict served as text/html with a filename
of *.html, and the other is XHTML 1.1 served as application/xhtml+xml
with a filename of *.xhtml - all with appropriatly labelled navigation
links to give the user a choice of versions.

Instead of two copies of each page, why not compose individual pages
and serve them via content negotiation?

--
James Pickering
------------------------------------
http://jp29.org/indexbak.php
XHTML 1.0 page served via
content-negotiation with test
results of MIME type serving
to various Browsers
------------------------------------

Sep 13 '05 #24

dingbat

Guy Macon wrote:

Having a link to an XHTML 1.1 version is good PR for me.

Is it ? Anyone who cares and understands 1.1 vs 1.0, is (IMHO) likely
to regard 1.0 as the better choice.

Sep 13 '05 #25

James Pickering

James Pickering wrote:

Guy Macon wrote:
I have been redoing my webpages, and I have decided to have two copies
of each page: one is HTML 4.01 strict served as text/html with a filename
of *.html, and the other is XHTML 1.1 served as application/xhtml+xml
with a filename of *.xhtml - all with appropriatly labelled navigation
links to give the user a choice of versions.

Instead of two copies of each page, why not compose individual pages
and serve them via content negotiation?

BTW, Neil Crosby's page
http://www.workingwith.me.uk/article...ing/mimetypes/
offers PHP coding for serving pages as XHTML (any flavor) or HTML 4.01
via content neotiation.

--
James Pickering
------------------------------------
http://jp29.org/indexbak.php
XHTML 1.0 page served via
content-negotiation with test
results of MIME type serving
to various Browsers
------------------------------------

Sep 13 '05 #26

Guy Macon

James Pickering wrote:

Guy Macon wrote:
I have been redoing my webpages, and I have decided to have two copies
of each page: one is HTML 4.01 strict served as text/html with a filename
of *.html, and the other is XHTML 1.1 served as application/xhtml+xml
with a filename of *.xhtml - all with appropriatly labelled navigation
links to give the user a choice of versions.

Instead of two copies of each page, why not compose individual pages
and serve them via content negotiation?

I am not a big fan of content negotiation. Some folks like it, but
I don't trust all browsers to tell the truth about what they will and
will not accept and display

See http://norman.walsh.name/2003/07/02/conneg and
http://wellformedweb.org/news/WebSer...entNegotiation

Sep 13 '05 #27

Nick Kew

di*****@codesmiths.com wrote:

Guy Macon wrote:

Having a link to an XHTML 1.1 version is good PR for me.

Is it ? Anyone who cares and understands 1.1 vs 1.0, is (IMHO) likely
to regard 1.0 as the better choice.

Yeah, but anyone with a clue on the technical level isn't a "PR" target.

--
Not me guv

Sep 13 '05 #28

Spartanicus wrote:

So far I've not seen you produce an argument that would support ignoring
w3c's guideline not to serve XHTML 1.1 as text/html.

Here are four...
1. Browser support.
-------------------

If you ignore the XHTML Media Types note, you will be able to
achieve far greater browser support for your XHTML 1.1 documents.

The note states its intention:

| It documents a set of recommendations to maximize the
| interoperability of XHTML documents with regard to
| Internet media types

It fails. It should be ignored.
2. Chronology.
--------------

26 January 2000 - XHTML 1.0 Recommendation. Appendix C says it's
OK to serve XHTML as text/html.

31 May 2001 - XHTML 1.1 Recommendation. In Appendix A, lists
"Changes from XHTML 1.0 Strict". Reversing Appendix C is not listed
as a change. Thus, from May 2001, it is OK to serve XHTML 1.1 as
text/html.

1 August 2002 - XHTML Media Types note says that XHTML 1.1 should
not be served as text/html.

So from June 2001 until July 2002, it was OK to serve XHTML 1.1 as
text/html? But suddenly, on 1 August 2002, it became frowned upon?
3. The Status of the Note.
--------------------------

The W3C's note that says you SHOULD NOT use text/html for XHTML
1.1 does not have "Internet Standard" status, nor even the weaker
"W3C Recommendation" status. It's not even a "Candidate
Recommendation". In fact, it specifically states:

| Publication of this Note by W3C indicates no endorsement
| by W3C or the W3C Team, or any W3C Members. [...] This
| document is not intended to be a normative specification.

If the W3C itself refuses to endorse it, why should I?
4. Simple Logic.
----------------

The following is a valid XHTML 1.0 Strict document:

<!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">
<head>
<title>Example</title>
</head>
<body>
Example
</body>
</html>

The following is a valid XHTML 1.1 document:

<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Example</title>
</head>
<body>
Example
</body>
</html>

Notice there are only a few bytes of difference between these
two examples. Whatsmore, the differences are only in the DOCTYPE,
which is largely ignored by real user-agents, except for the
misguided practice of DOCTYPE-switching (but note also that all
browsers that employ that technique classify both the above
DOCTYPEs as "strict mode").

If the two files are *essentially* the same, why may one be served
as text/html, but the other never so?
Of the four arguments, the last is my favourite.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

Sep 13 '05 #29

Jukka K. Korpela wrote:

I don't think there was much danger of confusion with that, but it's always
exciting to hear about new programming languages. :-)

There is certainly potential for such confusion. Ruby has been becoming
rather popular of late, in particular for CGI, but also to an extend in
GUI programming on UNIX.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

Sep 13 '05 #30

On Tue, 13 Sep 2005, Toby Inkster wrote:

Spartanicus wrote:
So far I've not seen you produce an argument that would support ignoring ^^^ ^^^^^^^^ w3c's guideline not to serve XHTML 1.1 as text/html.
^^^
Here are four...

.... arguments in favour or against what?
Three negations in one sentence are too much!

Sep 14 '05 #31

On Wed, 14 Sep 2005, Andreas Prilop wrote:

On Tue, 13 Sep 2005, Toby Inkster wrote:
Spartanicus wrote:
So far I've not seen you produce an argument that would support ignoring ^^^ ^^^^^^^^ w3c's guideline not to serve XHTML 1.1 as text/html.

^^^

Here are four...

... arguments in favour or against what?
Three negations in one sentence are too much!

As I read it: the hon. Usenaut is trying to say that Appendix C of
XHTML/1.0 applies (or at least /had originally been intended to
apply/) also to future versions of XHTML in perpituity, until the W3C
say it's explicitly countermanded.

My understanding, on the other foot, was that Appendix C of XHTML/1.0
was always intended to be an informative comment about a partially
nobbled form of XHTML/1.0 - and only XHTML/1.0 - which was capable of
being served as text/html and would fool most (i.e non-SGML-aware)
then-available browsers.

Appendix C, being an informative comment about XHTML/1.0, was not part
of its definition, and so it came as no surprise that to me that it
wasn't mentioned in the list of changes (sc. of the definition of
XHTML) which appeared in /1.1. I don't believe this means it was
ever intended to apply to /1.1, nor indeed to later versions.

At any rate, whatever the count of angels on pinheads about the
history, I think the W3C's current stance is clear: the one and only
situation where they approve of XHTML being served temporarily as
text/html is XHTML/1.0-Appendix C. Any other usage is, at the least,
SHOULD NOT.

Not that I really care, since - for production purposes - I'm content
to stay with HTML/4.01 until XHTML is offering some genuinely
deployable benefits.

Sep 14 '05 #32

Toby Inkster <us**********@tobyinkster.co.uk> wrote:

So far I've not seen you produce an argument that would support ignoring
w3c's guideline not to serve XHTML 1.1 as text/html.
If you ignore the XHTML Media Types note, you will be able to
achieve far greater browser support for your XHTML 1.1 documents.

1) If client support is the aim then HTML is the answer.
2) The fact that a XHTML document served as text/html can probably be
rendered by HTML clients does not equate to support.
3) The purpose of porting HTML to XML is to enable parsing with an XML
parser. Serving XHTML as text/html causes it to be parsed with the HTML
parser who then has to use it's error correction mechanism to deal with
the invalid HTML that it is being fed.
The note states its intention:

| It documents a set of recommendations to maximize the
| interoperability of XHTML documents with regard to
| Internet media types

It fails. It should be ignored.
It fails if you consider the quote to mean "compatibility with HTML
UAs", but that is not what is written. As I read it the quote refers to
providing guidelines to restrict the use of the various media types with
the various document formats. The resulting better match between the
advertised content type and the actual document type results in better
interoperability.
2. Chronology.
--------------

26 January 2000 - XHTML 1.0 Recommendation. Appendix C says it's
OK to serve XHTML as text/html.
"5. Compatibility Issues

This section is normative.

Although there is no requirement for XHTML 1.0 documents to be
compatible with existing user agents, in practice this is easy to
accomplish. Guidelines for creating compatible documents can be found in
Appendix C."

Note that it says XHTML 1.0, Appendix C does not extend to all (then)
future versions of XHTML.
3. The Status of the Note.
--------------------------

The W3C's note that says you SHOULD NOT use text/html for XHTML
1.1 does not have "Internet Standard" status, nor even the weaker
"W3C Recommendation" status. It's not even a "Candidate
Recommendation". In fact, it specifically states:

| Publication of this Note by W3C indicates no endorsement
| by W3C or the W3C Team, or any W3C Members. [...] This
| document is not intended to be a normative specification.

If the W3C itself refuses to endorse it, why should I?
I'm not sure if w3c has the authority to declare content types as
normative. If as I suspect they don't, the only way they can deal with
the issue is by issuing guidelines in the form of non normative notes.
That should not be used to declare them irrelevant.
4. Simple Logic.
----------------

The following is a valid XHTML 1.0 Strict document:

<!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">
<head>
<title>Example</title>
</head>
<body>
Example
</body>
</html>

The following is a valid XHTML 1.1 document:

<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Example</title>
</head>
<body>
Example
</body>
</html>

Notice there are only a few bytes of difference between these
two examples. Whatsmore, the differences are only in the DOCTYPE,
which is largely ignored by real user-agents,
Browsers yes, a validator is no less a real UA.
except for the
misguided practice of DOCTYPE-switching (but note also that all
browsers that employ that technique classify both the above
DOCTYPEs as "strict mode").

If the two files are *essentially* the same, why may one be served
as text/html, but the other never so?

The differences between the two languages is not the issue, the question
remains: why ignore this particular w3c guideline?

--
Spartanicus

Sep 14 '05 #33

Stewart Gordon

Looks like my news server was faulty last time. Let's try again....

Jukka K. Korpela wrote:

Buford Early wrote:
I thought that XHTML 1.1 was the follow-up to XHTML 1.0 and that
XHTML 2.0 will someday be the follow-up to XHTML 1.1. Am I wrong?

Yes, you are.

XHTML 1.1 is an exercise in futility, a dead end, and both practically
and theoretically useless.

XHTML 2.0 is being designed to be incompatible with every previous HTML
version, though similar enough to confuse people into thinking
otherwise. If it will ever be released, it will most probably be
advertized as a successor of XHTML 1.0, not of XHTML 1.1.

I've just had a look at the W3C draft of XHTML 2.0. It has some things
in common with an HTML replacement I had envisioned:
- most of the design aims
- section elements
- navigation lists (my idea also included auto-generated TOCs that could
be rendered similarly)
- image elements having the alternative text as the content rather than
an attribute

It would appear that the src element of everything is designed to
support client-side include, something else that certainly should be
there. It would appear that the problem with adding it to HTML was
figuring how to support graceful degradation. But making a fresh start
would make this issue irrelevant.

However, if it really is meant to be a fresh start, it would seem silly
that W3C has decided to call it XHTML, rather than making a fresh start
with the name, MIME type and filename extension while at it. (FTM why
is it application/xhtml+xml not text/xhtml?)

Just remembered something else I thought of for my HTML replacement: a
uniform mechanism for conditional inclusion based on what browser
features are enabled.

Stewart.

--
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS-
PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox. Please keep replies on
the 'group where everyone may benefit.

Sep 14 '05 #34

Guy Macon

Alan J. Flavell wrote:

At any rate, whatever the count of angels on pinheads

Unlike most of the discussion here, angels on pinpoints
(points, not heads!) is a serious question...

http://www.straightdope.com/classics/a4_132.html
http://www.straightdope.com/columns/001110.html
http://www.nytimes.com/learning/stud...ve/971111.html
http://www.phrases.org.uk/bulletin_b...ages/1512.html
http://www.improb.com/airchives/pape...angels-7-3.htm

I hope this helps.

:)

Sep 14 '05 #35

Spartanicus wrote:

Toby Inkster <us**********@tobyinkster.co.uk> wrote:
So far I've not seen you produce an argument that would support ignoring
w3c's guideline not to serve XHTML 1.1 as text/html.
If you ignore the XHTML Media Types note, you will be able to
achieve far greater browser support for your XHTML 1.1 documents.

1) If client support is the aim then HTML is the answer.

I don't disagree there. But we're not talking about HTML, we're talking
about XHTML 1.1, and I'm assuming that the document being in XHTML 1.1 is
a given, and running from there...
2) The fact that a XHTML document served as text/html can probably be
rendered by HTML clients does not equate to support.
Perhaps not, but being rendered is closer to being supported than not
being rendered is.
3) The purpose of porting HTML to XML is to enable parsing with an XML
parser. Serving XHTML as text/html causes it to be parsed with the HTML
parser who then has to use it's error correction mechanism to deal with
the invalid HTML that it is being fed.
An XML parser should send "Accept: text/xml" or somesuch in its initial
HTTP request, so should get an XML-related Content-Type in return.

I would only advocate sending "Content-Type: text/html" to agents that
don't announce that they support XML via the Accept header.
I'm not sure if w3c has the authority to declare content types as
normative.
It doesn't. It's the realm of the IETF.
If as I suspect they don't, the only way they can deal with
the issue is by issuing guidelines in the form of non normative notes.

They can issue a recommendation though. The note doesn't even have that
status.

If the two files are *essentially* the same, why may one be served
as text/html, but the other never so?

The differences between the two languages is not the issue, the question
remains: why ignore this particular w3c guideline?

Because it's the only silly one.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

Sep 15 '05 #36

Toby Inkster <us**********@tobyinkster.co.uk> wrote:

If you ignore the XHTML Media Types note, you will be able to
achieve far greater browser support for your XHTML 1.1 documents.

1) If client support is the aim then HTML is the answer.

I don't disagree there. But we're not talking about HTML, we're talking
about XHTML 1.1, and I'm assuming that the document being in XHTML 1.1 is
a given, and running from there...

I can't imagine a situation where 1.1 is a given, it's a choice.

2) The fact that a XHTML document served as text/html can probably be
rendered by HTML clients does not equate to support.

Perhaps not, but being rendered is closer to being supported than not
being rendered is.

Forgive the repetition, but if not being rendered is a worry, then HTML
is the solution.

3) The purpose of porting HTML to XML is to enable parsing with an XML
parser. Serving XHTML as text/html causes it to be parsed with the HTML
parser who then has to use it's error correction mechanism to deal with
the invalid HTML that it is being fed.

An XML parser should send "Accept: text/xml" or somesuch in its initial
HTTP request, so should get an XML-related Content-Type in return.

I would only advocate sending "Content-Type: text/html" to agents that
don't announce that they support XML via the Accept header.

Content negotiation comes with it's own risks and issues. We know about
IE's broken accept string, and we can work around it. But who's to say
that there aren't any other clients with incorrect accept values? There
is the server overhead to consider, and the potential cache issues.

If content negotiation is to be used at all, then it's a small step to
generate HTML from the XHTML and feed that to clients who want HTML.

Then there is Gecko, it's happy to accept XHTML served as such, but
that's doing the user a disservice since Gecko currently cannot render
XHTML incrementally.

I'm not sure if w3c has the authority to declare content types as
normative.

It doesn't. It's the realm of the IETF.

I've lost track of who is in charge of that, I seem to remember that the
situation got messy, with some established types having been declared as
being under the patronage of the w3c.

--
Spartanicus

Sep 15 '05 #37

Stewart Gordon wrote:

filename extension

What's one of them? And what has it goe to do with the WWW?

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

Sep 15 '05 #38

Jan Roland Eriksson

On Thu, 15 Sep 2005 19:47:07 GMT, Spartanicus <in*****@invalid.invalid>
wrote:

Toby Inkster <us**********@tobyinkster.co.uk> wrote:
[quoting from previous source]

I'm not sure if w3c has the authority to declare content types as
normative.
It doesn't. It's the realm of the IETF.

Well; as I have understood it, there is an organization IANA that
handles, or at least registers, things around MIME types and stuff like
that.
I've lost track of who is in charge of that, I seem to remember that the
situation got messy, with some established types having been declared as
being under the patronage of the w3c.

You mean like the situation of...

http://www.ietf.org/rfc/rfc2854.txt

....where W3C is trying, in an IETF RFC (Request For Comments), to "burn
the books" (like some old Chinese Emperor) of what was created before
the "divine rise" of W3C, to make history start with W3C.

There is one very specific standards track document available here...

http://www.ietf.org/rfc/rfc1866.txt

....that at a technical level specifies the absolute best documented HTML
standard we have ever had. Dan Connolly worked his butt off to gather
all comments he got and to edit out what became the final edition of
that RFC, AND managed to get it into a "standards track" status at
IETF[1].

It's really sad to see Dan's name in RFC2854...

W3C shall be taken for what it is; a conglomerate of high buck companies
that do not allow ordinary human beings as members and that will shell
in money to operate W3C for as long as it primarily serves their own
purposes at an acceptable level.

--
Rex

Sep 16 '05 #39

In article <dg**********@sun-cc204.lut.ac.uk>,
Stewart Gordon <sm*******@yahoo.com> wrote:

(FTM why is it application/xhtml+xml not text/xhtml?)

+xml is the convention for MIME types for languages specified on top of
XML. The rules of text/* do not make sense for XML--hence application.

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

Sep 16 '05 #40

Stewart Gordon

Toby Inkster wrote:

Stewart Gordon wrote:
filename extension
What's one of them?

http://www.foldoc.org/?filename+extension

What do you call it?
And what has it goe to do with the WWW?

At least two things:

- Thousands, if not millions, of web servers determine the MIME type
from the filename extension in the default configuration (or at least
the configuration that a hosting provider presents to its customers as
the default).

- Thousands, if not millions, of website developers test their pages
locally before uploading them to the WWW. Except in the case of those
who need to test server-side processing and so have a staging server,
the filename extension is the only way the browser has of determining
the MIME type.

Stewart.

--
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS-
PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox. Please keep replies on
the 'group where everyone may benefit.

Sep 16 '05 #41

On Fri, 16 Sep 2005, Stewart Gordon wrote:

- Thousands, if not millions, of website developers test their pages
locally before uploading them to the WWW.
I'd rate browsing local files as suboptimal [1]
Except in the case of those who need to test server-side processing
and so have a staging server, the filename extension is the only way
the browser has of determining the MIME type.

I recommend that they, practically without exception, should run a
local web server (accessible only from 127.0.0.1 if they have no
reason to do otherwise) on their authoring platform, configured as
closely as possible to their production server (as to default
filename, as to media content type versus filename "extension", and so
on). Sooner or later they'd probably want PHP or CGI or SSI or
whatever, anyway, so it makes sense to start on the right foot.
They can also (taking Apache as a paradigm) develop their .htaccess
file in parallel.

And this has the side benefit, if the configuration is close enough to
the production server, of offering a decent chance of exposing any
mistakes with resulting HTTP headers - not only the obvious ones like
Content-type with its associated charset attribute, but also any
expires or cache-control headers that one wants to develop - I'd refer
you to Chris Pederick's web developer toolbar for Mozzi or Firefox for
a convenient way of viewing these while developing.

Installing win32 Apache on my laptop took only moments, to take just
one case in point.

good luck.

[1] By way of illustration, just one example. Wherever a natural web
author would code a local URL as e.g whatever/ , they are forced to
code e.g whatever/index.html , (replace "index.html" with what their
server uses as its default), otherwise their local testing fails.

Then they upload that, and the web is awash with URLs like
http://some.example/whatever/index.html , rather than the nicer
http://some.example/whatever/ - which, at least for some of us,
offends our sense of URL aesthetics - such internal details should
better not be exposed (and they might later change, e.g to index.shtml
or index.php, without any need for a visible external difference).

And coding "absolute local" URLs e.g /specimen/something tends cause
difficulties too.

Don't get me started on Win-based authors who code URLs with
backslashes. That too seems to be promoted by browsing files locally,
but will rightly result in errors if a proper server is used (and
browsed with a proper browser, I mean).

Sep 16 '05 #42

On Fri, 16 Sep 2005, Alan J. Flavell wrote:

Then they upload that, and the web is awash with URLs like
http://some.example/whatever/index.html , rather than the nicer
http://some.example/whatever/

I cannot resist ...
http://www.google.com/search?q=index.html
Note that Google lists most (all?) URLs without "index.html".
So we have an uncessary duplication (if not triplication)
of URLs.

Sep 16 '05 #43

Stewart Gordon

Alan J. Flavell wrote:

On Fri, 16 Sep 2005, Stewart Gordon wrote:
- Thousands, if not millions, of website developers test their pages
locally before uploading them to the WWW.
I'd rate browsing local files as suboptimal [1]

And I expect plenty of hobbyists who don't do server-side programming
either don't know where to start with finding/installing a staging
server or rate the idea as overkill.

Except in the case of those who need to test server-side processing
and so have a staging server, the filename extension is the only way
the browser has of determining the MIME type.

I recommend that they, practically without exception, should run a
local web server (accessible only from 127.0.0.1 if they have no
reason to do otherwise) on their authoring platform, configured as
closely as possible to their production server (as to default
filename, as to media content type versus filename "extension", and so
on). Sooner or later they'd probably want PHP or CGI or SSI or
whatever, anyway, so it makes sense to start on the right foot.
They can also (taking Apache as a paradigm) develop their .htaccess
file in parallel.

Is it possible/easy to get hold of a staging server for Windows that
emulates a Unix webserver, or vice versa? Stuff like case-sensitivity....
And this has the side benefit, if the configuration is close enough to
the production server, of offering a decent chance of exposing any
mistakes with resulting HTTP headers - not only the obvious ones like
Content-type with its associated charset attribute, but also any
expires or cache-control headers that one wants to develop - I'd refer
you to Chris Pederick's web developer toolbar for Mozzi or Firefox for
a convenient way of viewing these while developing.
I hate cache control. All too often it tends to break the back button.
Installing win32 Apache on my laptop took only moments, to take just
one case in point.

good luck.

[1] By way of illustration, just one example. Wherever a natural web
author would code a local URL as e.g whatever/ , they are forced to
code e.g whatever/index.html , (replace "index.html" with what their
server uses as its default), otherwise their local testing fails.
Yes, that's an issue that bugs many. However, that's different in that
it's straightforward for web browser developers to fix their products to
handle it.

Meanwhile, on those projects where I've grown out of linking to
index.html (yes, that was to help with local testing), I tweak the URL
bar after following such a link.
Then they upload that, and the web is awash with URLs like
http://some.example/whatever/index.html , rather than the nicer
http://some.example/whatever/ - which, at least for some of us,
offends our sense of URL aesthetics - such internal details should
better not be exposed (and they might later change, e.g to index.shtml
or index.php, without any need for a visible external difference).
You might later change non-index pages between .html, .shtml, .php,
..asp, etc. just the same.
And coding "absolute local" URLs e.g /specimen/something tends cause
difficulties too.

Don't get me started on Win-based authors who code URLs with
backslashes. That too seems to be promoted by browsing files locally,
but will rightly result in errors if a proper server is used (and
browsed with a proper browser, I mean).

I wasn't going to. Such people shouldn't be let loose on a webhost anyway.

Stewart.

--
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS-
PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox. Please keep replies on
the 'group where everyone may benefit.

Sep 16 '05 #44

On Fri, 16 Sep 2005, Stewart Gordon wrote:

Alan J. Flavell wrote: [...]
Is it possible/easy to get hold of a staging server for Windows that
emulates a Unix webserver, or vice versa?
see below re win32 Apache, close enough to the Apache-based servers
which most service providers seem to use. Certainly I've never had
any real problems relative to the linux-based production Apache server
which we run at our research group.
Stuff like case-sensitivity....
It's close enough to real life for me. If you insist on having two
URLs that differ only in letter case, then you'd probably have
difficulties, I suppose. I never tried it. Best read the
win32-specific release notes if you want to know the sordid details.

[...] I hate cache control. All too often it tends to break the back
button.

I didn't say you *have* to develop it. Just one of the many things
you /can/ do, once the local server is there. Nothing wrong with
Expires headers, and sensibly-chosen cache controls. I'm not talking
about crude cache-busting weapons!

I said:

Installing win32 Apache on my laptop took only moments, to take
just one case in point.
If you get Indigoperl, then you even get Apache and Perl bundled in
one convenient package. Personally, I already had Activestate Perl
installed, so I just installed the Win32 httpd download from Apache
HQ.
Then they upload that, and the web is awash with URLs like
http://some.example/whatever/index.html , rather than the nicer
http://some.example/whatever/ - which, at least for some of us,
offends our sense of URL aesthetics - such internal details should
better not be exposed (and they might later change, e.g to
index.shtml or index.php, without any need for a visible external
difference).

You might later change non-index pages between .html, .shtml, .php,
.asp, etc. just the same.

Indeed.

Which is why some folks promote the idea of activating MultiViews in
Apache. Even if there's only one "variant" (let's say example.html),
Apache will happily serve-out the URL "example" , and when you one day
change the .html to .php, the external URL won't need to change. Of
course MultiViews can do much more than that, if you have several
variants available (different languages, whatever), but that goes
beyond the present topic.

Confession: although I think that's a good idea, I've never done it
right across the server, although there are some places where it's
used to good effect.

hope that helps

Sep 16 '05 #45

Stewart Gordon wrote:

Toby Inkster wrote:
Stewart Gordon wrote:
filename extension

What's one of them?

http://www.foldoc.org/?filename+extension
What do you call it?

"Filename that happens to have a dot (which has no technical significance)
in it."

And what has it goe to do with the WWW?

At least two things:

They may effect the way some people use their web servers, but they're of
no real consequence to the way the WWW works. Some people may choose to
end their XHTML2 file names with ".xhtml", others with ".xhtml2" others
with ".page", others with ".doc" and others with nothing at all. Still
others may not keep their XHTML2 in files, but rather use some other
mechanism for looking up and serving XHTML content.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

Sep 16 '05 #46

Toby Inkster <us**********@tobyinkster.co.uk> wrote:

[file extensions]

They may effect the way some people use their web servers, but they're of
no real consequence to the way the WWW works.

But they may effect how web clients behave. Extension sniffing is a well
known phenomena, and it's not just IE that does that.

A recent example (told here IIRC) was that some versions of IE render
XHTML served as application/xml+xhtml if the file used an .html
"extension".

--
Spartanicus

Sep 16 '05 #47

Nick Kew

Spartanicus wrote:

Toby Inkster <us**********@tobyinkster.co.uk> wrote:

[file extensions]

They may effect the way some people use their web servers, but they're of
no real consequence to the way the WWW works.

But they may effect how web clients behave. Extension sniffing is a well
known phenomena, and it's not just IE that does that.

Ignoring Content-Type is well known to be a serious security risk,
and indeed was extensively documented as such in 1992. It is precisely
this that spawned the first generation of big 'net-borne windoze worms.
And it's windoze's continuing failure to implement this mandatory part
of several Internet specs (including HTTP) that turns virus protection
in software from the trivial task it should be to the nightmare it is
on windoze.

--
Nick Kew

Sep 17 '05 #48

On Fri, 16 Sep 2005, Toby Inkster wrote:

"Filename that happens to have a dot (which has no technical
significance) in it."
And what has it goe to do with the WWW?

Stewart Gordon wrote: At least two things:

They may effect the way some people use their web servers, but
they're of no real consequence to the way the WWW works.

Correct. But it's worse than that.

Any influence which the filename extensions coming from the server
side may appear to have at the client side are *BUGS*, in terms of the
WWW interworking specifications, and - in as much as they just might
cause a web resource to be processed in a *wrong* context - such bugs
could well prove to be a security exposure, over and above the known
risks inherent in the web interworking specifications themselves.
Some people may choose to end their XHTML2 file names with ".xhtml",
others with ".xhtml2" others with ".page", others with ".doc" and
others with nothing at all.
Indeed. I'm increasingly attracted by the idea of using Apache
Multiviews, even when there's only one document variant available, and
avoiding exposing the "filename extension" to the web.

Those users who need a filename extension when doing a "save As" of
some web resource, ought to be providing their /own/ extension, one
that makes sense in /their/ own context, irrespective of what's done
at the server. If their software does it for them, then "fine" - if
their software just blindly copies what's coming from the server, then
"not fine": sure, most of the time it may very well be OK, but it's a
potential exposure, which could be exploited by a malicious web site.
Still others may not keep their XHTML2 in files, but rather use some
other mechanism for looking up and serving XHTML content.

Certainly. (But I don't want to comment specifically on XHTML2 right
now...)

all the best

Sep 17 '05 #49