XHTML 1.1 and browser compatibility

[Brian]

Re: XHTML 1.1 and browser compatibility

Mark Tranchant wrote:
[color=blue]
> All URLs are provided without extension: any attempt to link to one
> with extension will redirect to the plain version.[/color]

May I ask how you did this? I tried what seemed obvious to me:

RedirectMatch (.*)\.html$ $1

When combined with multiviews, it resulted in a 404 error on all urls,
and a 302 found error while trying to use ErrorDocument.

--
Brian (remove "invalid" from my address to email me)

http://www.tsmchughs.com/

[Mark Tranchant]

Re: XHTML 1.1 and browser compatibility

Brian wrote:
[color=blue][color=green]
>> All URLs are provided without extension: any attempt to link to one
>> with extension will redirect to the plain version.[/color][/color]
[color=blue]
> May I ask how you did this? I tried what seemed obvious to me:
>
> RedirectMatch (.*)\.html$ $1
>
> When combined with multiviews, it resulted in a 404 error on all urls,
> and a 302 found error while trying to use ErrorDocument.[/color]

Close, but no cigar. The target argument must be a fully-qualified URL,
whereas the requested URL is relative to the root of the current site.

It would also be better to define this as a permanent redirect, to avoid
anyone caching or indexing the extension-ed URL.

I use this:

RedirectMatch permanent /(.*)\.html$ http://tranchant.plus. com/$1

--
Mark.

http://tranchant.plus.com/

[Mark Tranchant]

Re: XHTML 1.1 and browser compatibility

Brian wrote:
[color=blue]
> Mark Tranchant wrote:
>[color=green]
>> I will probably end up going the whole hog and serving either HTML
>> 4.01 or XHTML 1.1.[/color]
>
> May I ask why you decided to offer two variants? It's a neat idea, don't
> get me wrong. But what advantages do you get with the xhtml 1.1 version
> of your documents?[/color]

Primarily bragging rights at this juncture. There are some advantages to
XHTML-1.1 though:

1) Automatic validation in Mozilla and Firefox browsers, which will throw
an error message if the document is not well-formed XML.

2) Easier programmatic conversion from valid XHTML to other XML variants
than with arbitrary valid HTML, although *my* HTML always uses lower-case
tags and attributes, quotes attributes and closes all tags except empty one.

3) err... can't think of any more.

--
Mark.

http://tranchant.plus.com/

[David Dorward]

Re: XHTML 1.1 and browser compatibility

Mark Tranchant wrote:
[color=blue]
> Primarily bragging rights at this juncture. There are some advantages to
> XHTML-1.1 though:
>
> 1) Automatic validation in Mozilla and Firefox browsers, which will throw
> an error message if the document is not well-formed XML.[/color]

It will only check the XML for well formedness, it won't check the XHTML
itself.

http://dorward.me.uk/tmp/html-element.xhtml, for example, will not throw an
error despite the presence of a <fake></fake> in the middle of it.


--
David Dorward <http://blog.dorward.me .uk/> <http://dorward.me.uk/>

[Spartanicus]

Re: XHTML 1.1 and browser compatibility

Mark Tranchant <mark@tranchant .plus.com> wrote:
[color=blue]
>There are some advantages to XHTML-1.1 though:
>
>1) Automatic validation in Mozilla and Firefox browsers, which will throw
>an error message if the document is not well-formed XML.[/color]

Well formed != Valid.
[color=blue]
>3) err... can't think of any more.[/color]

Here's a drawback: Gecko can't incrementally render XML, to satisfy the
"a UA must throw a parsing error when encountering malformed code"
demand it only renders after the entire document has finished
downloading and has been parsed.

--
Spartanicus

[Mark Tranchant]

Re: XHTML 1.1 and browser compatibility

David Dorward wrote:
[color=blue]
> Mark Tranchant wrote:
>
>[color=green]
>>Primarily bragging rights at this juncture. There are some advantages to
>>XHTML-1.1 though:
>>
>>1) Automatic validation in Mozilla and Firefox browsers, which will throw
>>an error message if the document is not well-formed XML.[/color]
>
>
> It will only check the XML for well formedness, it won't check the XHTML
> itself.[/color]

I knew this would happen the instant I pressed Send on the original. You're
quite right, I should have written "Automatic validation of XML
well-formedness".

--
Mark.

http://tranchant.plus.com/

[Mark Tranchant]

Re: XHTML 1.1 and browser compatibility

Spartanicus wrote:
[color=blue]
> Here's a drawback: Gecko can't incrementally render XML, to satisfy the
> "a UA must throw a parsing error when encountering malformed code"
> demand it only renders after the entire document has finished
> downloading and has been parsed.[/color]

Hmmm. I'd not realised that, but you must be right. Doesn't seem to be an
issue for my site, as I keep the size of my pages small and use mod_gzip on
the output.

--
Mark.

http://tranchant.plus.com/

[Brian]

Re: XHTML 1.1 and browser compatibility

Mark Tranchant wrote:[color=blue]
> Brian wrote:
>[color=green]
>> RedirectMatch (.*)\.html$ $1[/color]
>
> The target argument must be a fully-qualified URL, whereas the
> requested URL is relative to the root of the current site.[/color]

Yep, I knew that, but apparently my brain was on break when I first
tried it.
[color=blue]
> It would also be better to define this as a permanent redirect, to
> avoid anyone caching or indexing the extension-ed URL.[/color]

Good point; I've changed that.
[color=blue]
> I use this:
>
> RedirectMatch permanent /(.*)\.html$ http://tranchant.plus. com/$1[/color]

Still no cigar.

RedirectMatch permanent /(.*)\.html$ http://tsmchughs.local host/$1

This produces a 404 error on all pages, with an additional 301 error
trying to use ErrorDocument. :(

Entering http://tsmchughs.localhost/site/help.html in the location bar
does redirect to http://tsmchughs.localhost/site/help, but then I get a
404 error. When go to the home page, http://tsmchughs.localhost/, I get
redirected to http://tsmchughs.localhost/index, again with 404. It seems
that, somehow, it isn't playing nice with multiviews.

--
Brian (remove "invalid" from my address to email me)

http://www.tsmchughs.com/

[Mark Tranchant]

Re: XHTML 1.1 and browser compatibility

Brian wrote:
[color=blue]
> RedirectMatch permanent /(.*)\.html$ http://tsmchughs.local host/$1
>
> This produces a 404 error on all pages, with an additional 301 error
> trying to use ErrorDocument. :(
>
> Entering http://tsmchughs.localhost/site/help.html in the location bar
> does redirect to http://tsmchughs.localhost/site/help, but then I get a
> 404 error. When go to the home page, http://tsmchughs.localhost/, I get
> redirected to http://tsmchughs.localhost/index, again with 404. It seems
> that, somehow, it isn't playing nice with multiviews.[/color]

Are you sure you have MultiViews switched on for that section of your
filespace? Mail me your httpd.conf if you'd like me to take a look.

You must load the mod_negotiation module, and explicitly turn on MultiViews
with "Options +MultiViews".

--
Mark.

http://tranchant.plus.com/

[George Lund]

Re: XHTML 1.1 and browser compatibility

In message <qK3hc.32197$h4 4.4720976@stone s.force9.net>, Mark Tranchant
<mark@tranchant .plus.com> writes[color=blue]
>Primarily bragging rights at this juncture. There are some advantages
>to XHTML-1.1 though:[/color]

Fair play but you're not going to be let off the other reasons you give
all the same ;-) ...
[color=blue]
>1) Automatic validation in Mozilla and Firefox browsers, which will
>throw an error message if the document is not well-formed XML.[/color]

There are validators with more useful error messages and better batch
capability; the browser is a _user_ agent and such messages certainly
wouldn't be useful to _them_.
[color=blue]
>2) Easier programmatic conversion from valid XHTML to other XML
>variants than with arbitrary valid HTML, although *my* HTML always uses
>lower-case tags and attributes, quotes attributes and closes all tags
>except empty one.[/color]

I've had success with SX <http://www.jclark.com/sp/sx.htm> on the
occasion I've had need to do it (HTML->XML). (I don't recall seeing
that tool mentioned here ever and when I needed it I was grateful for
it, so maybe this will help someone.)

--
George Lund

[Jukka K. Korpela]

Re: XHTML 1.1 and browser compatibility

Mark Tranchant <mark@tranchant .plus.com> wrote:
[color=blue]
> My site now uses Apache MultiViews and some PHP code to determine
> whether your browser can handle the application/xhtml+xml media type.[/color]

As we have discussed a few times, this will fail for the most common
browser, which happily claims to be able to handle literally everything
(and with no expressed preference for text/html over anything).

But what really puzzles me is _why_ people want to do this. What does
XHTML 1.1 win, in practical terms? If the only gain is the author's pride
in following The Latest Recommendation, the price is pretty high.
Wouldn't it be better to gamble only when there's a _possibility_ of
winning something?

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

[Mark Tranchant]

Re: XHTML 1.1 and browser compatibility

Jukka K. Korpela wrote:
[color=blue][color=green]
>>My site now uses Apache MultiViews and some PHP code to determine
>>whether your browser can handle the application/xhtml+xml media type.[/color]
>
> As we have discussed a few times, this will fail for the most common
> browser, which happily claims to be able to handle literally everything
> (and with no expressed preference for text/html over anything).[/color]

I've not seen this - my logs show several people using various versions of
IE traversing the site in such a way that is only possible by them being
served text/html.

Indeed, a manual HTTP dialogue with my server reveals that an Accept header
of */* returns the HTML version.

If anyone has any evidence of *my* implementation failing for any browser,
I'd love to hear it.
[color=blue]
> But what really puzzles me is _why_ people want to do this. What does
> XHTML 1.1 win, in practical terms? If the only gain is the author's pride
> in following The Latest Recommendation, the price is pretty high.[/color]

But... it's what the W3C recommends! ;-)
[color=blue]
> Wouldn't it be better to gamble only when there's a _possibility_ of
> winning something?[/color]

Yeah, I know the arguments. I like the elegance of having my documents
being well-formed XML, and the level of future-proofing that gives me. I
have no evidence for this, but I'd imagine the XHTML gives browsers an
easier time rendering the document.

--
Mark.

http://tranchant.plus.com/

[Nick Kew]

Re: XHTML 1.1 and browser compatibility

In article <ZJD4OBKoLuhAFw xi@lund.co.uk>,
George Lund <george@lund.co .uk> writes:
[color=blue]
> I've had success with SX <http://www.jclark.com/sp/sx.htm> on the
> occasion I've had need to do it (HTML->XML). (I don't recall seeing
> that tool mentioned here ever and when I needed it I was grateful for
> it, so maybe this will help someone.)[/color]

A good recommendation, but now rather dated. The SP project (of which
SX is one tool) has become OpenSP and lives at openjade.source forge.net.

--
Nick Kew

Nick's manifesto: http://www.htmlhelp.com/~nick/

[Bertilo Wennergren]

Re: XHTML 1.1 and browser compatibility

Mark Tranchant:
[color=blue]
> Jukka K. Korpela wrote:[/color]
[color=blue][color=green]
>> But what really puzzles me is _why_ people want to do this. What does
>> XHTML 1.1 win, in practical terms? If the only gain is the author's pride
>> in following The Latest Recommendation, the price is pretty high.[/color]
>
> But... it's what the W3C recommends! ;-)
>[color=green]
>> Wouldn't it be better to gamble only when there's a _possibility_ of
>> winning something?[/color][/color]
[color=blue]
> Yeah, I know the arguments. I like the elegance of having my documents
> being well-formed XML, and the level of future-proofing that gives me. I
> have no evidence for this, but I'd imagine the XHTML gives browsers an
> easier time rendering the document.[/color]

Hardly (now). In most every practical case, the only real reason for
using XHTML (1.0 or 1.1) today, is if the page author/maintainer is more
comfortable with coding in that version. That goes for me for example,
and it seems to go for you too ("I like the elegance..."). For the users
it won't do any good (nor any harm, as far as I know).

In a couple of years, things might be different.

--
Bertilo Wennergren <bertilow@gmx.n et> <http://www.bertilow.co m>

[Jukka K. Korpela]

Re: XHTML 1.1 and browser compatibility

Mark Tranchant <mark@tranchant .plus.com> wrote:
[color=blue]
> Jukka K. Korpela wrote:
>[color=green][color=darkred]
>>>My site now uses Apache MultiViews and some PHP code to determine
>>>whether your browser can handle the application/xhtml+xml media
>>>type.[/color]
>>
>> As we have discussed a few times, this will fail for the most common
>> browser, which happily claims to be able to handle literally
>> everything (and with no expressed preference for text/html over
>> anything).[/color]
>
> I've not seen this - my logs show several people using various
> versions of IE traversing the site in such a way that is only
> possible by them being served text/html.[/color]

Then your server does not work as you described. IE clearly says that it
can handle any data type.
[color=blue]
> Indeed, a manual HTTP dialogue with my server reveals that an Accept
> header of */* returns the HTML version.[/color]

Then it doesn't do what you described. Simple as that. Surely */* covers
application/xhtml+xml just as well as text/html.
[color=blue]
> I like the elegance of having my
> documents being well-formed XML,[/color]

Well-formedness is so extremely trivial that I think you are very happy
if you find happiness in such things. :-)
[color=blue]
> and the level of future-proofing that gives me.[/color]

There is no evidence suggesting that any future recommendation on HTML
would be compatible with XHTML 1.0 or XHTML 1.1. On the contrary, the
XHTML 2.0 draft is intentionally incompatible.
[color=blue]
> I have no evidence for this, but I'd imagine the XHTML
> gives browsers an easier time rendering the document.[/color]

It surely doesn't. They have rendered old HTML for years, and XHTML
imposes further requirements.

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