OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [docbook-apps] [QUESTION] Generating XHTML 1.1 from docbook-xsl


On 12/20/06, Kevin Ruscoe <kevin@sapphireoflondon.org> wrote:
> Hi Jirka
>
>  > The question is whether it is worth to spend time implementing support
>  > for XHTML 1.1 when major browser doesn't support it
>
> I must admit that, after waiting for years for Internet Explorer to support
> CSS Fixed Positioning and noting that IE7 finally does, I rather assumed
> that
> other areas of standards compliance had been addressed as well.  However,
> having (just) checked, I see that, although XHTML is better supported than
> in IE6, support for the MIME type application/xml+xhtml has slipped to
> the next release.
>
> (For other people who did not know this, there is an explanation at:
> http://blogs.msdn.com/ie/archive/2005/09/15/467901.aspx )
>
>  > without resorting to ugly hacks
>
> Adding a mod_rewrite rule to Apache cfg files is certainly ugly, but no
> great problem.  IMHO, reducing the priority of support for
> standards because certain vendors don't do a good job of supporting them
> risks leading us into a vicious circle.  On the other hand, supporting and
> evangelising standards can have the opposite effect.  I do not
> think that IE7's greatly improved support for CSS would have come without
> pressure being applied from the user community.

This is probably the wrong list on which to be speaking of such
things, but one does not need to use mod_rewrite to serve xhtml or
html as needed if one is willing to use Apache's mod_negotiation and
the MultiViews directive. Content negotiation is a standard part of
HTTP, but IE complicates things.

Content negotiation + MultiViews will cause /dir/blah.xhtml and
/dir/blah.html to be considered for delivery to a client if the
requested URL is http://www.example.com/dir/blah (instead of having
.html or .xhtml on the end).

The method of selecting the page is given here:
http://httpd.apache.org/docs/2.0/content-negotiation.html

The trick to making IE receive the right page involves thwarting IE's
overly permissive http-accept header. Here is what a header from IE
looks like:

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/x-shockwave-flash, application/vnd.ms-excel,
application/vnd.ms-powerpoint, application/msword, */*

Notice the complete lack of quality settings and the */*. Thus, IE
says it accepts every MIME type with equal "quality" (q). IMHO, making
IE do this is a poor decision.

Here is what a header from Firefox looks like:
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

Notice that the xml based formats are at a (default) quality of 1.0,
while text/html is at a quality of 0.9 and */* is at a quality of 0.5.

As stated (I think) in Apache's content negotiation description, the
client side quality is multiplied with the server side source quality
(qs) to come up with a ranking for which item to deliver when using
MultiViews. So, to cause IE to always receive the html file, just set
the quality for the xhtml file to be less than 1 and greater than 0.95
(so that Firefox will continue to recieve the XHTML version).

The relevant line in Apache's httpd.conf might look like:

AddType application/xhtml+xml;qs=.99 .xhtml

As an added benefit, one can specify your page URLs without the file extensions.

By the way, one may also need to set the DirectoryIndex to index
instead of index.html:

DirectoryIndex index

-- 
http://chris.chiasson.name/


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]