Re: How to serve SVG to those UA that accept it, and HTML to those that do not?

Hello Jonathan,

if I understand the given information correct, any format is acceptable for 
all viewers because the q-factor is larger than 0 for */* - therefore it 
should be no problem to send any format, that an author prefers, to any
viewer ;o) Therefore there is no need to check especially for image/svg+xml.
However, because Amaya mentions this explictly, it seems to like it very
much (but we know of course, that in some areas of SVG it has more problems
than Opera 10, Mozilla/Gecko or WebKit or the adobe Plugin or KSVG etc ;o)

If you do not trust in */* with q larger than 0 (as me), you have to do more
than content negotiation as I do for example for XHTML already.
I use PHP-scripts, that try to explore/sniff the viewer, if it does not note
the format I want to send explictly to be known. 
However, such scripts may have funny results, for example I tried the
mobile checker you mentioned currently. Obviously it does not indicate
that it knows application/xhtml+xml, application/xml or text/xml but maybe
text/html, therefore it gets the XHTML-stuff as text/html, because it is
detected as outdated browser with a tag-soup parser.
Of course, than it has to bear the consequences - it reports funny issues,
because it does not indicate a capability to interprete the proper format ;o)
Practically, I think due to the information, that user-agents provide or do
not provide, content negotation never really worked in a reliable way :-(

Another option is of course, if you use (X)HTML anyway, to use the
fallback functionality of the object element, than the (X)HTML viewer
has to decide on his own about its capabilities. In SVG on the other
hand you can use the even more advanced switch functionalities
to provide XHTML or an SVG alternative.

But of course, I would be interested in more clever options than an advanced
server-sided sniffer script (with typically no access to active plugins),
because I have a large gallery for photography with the capability to switch
between SVG, XHTML (indicated as XHTML or as HTML), depending on the 
sniffing. And I know already, that the results are not always correct/useful 
for some audience. 
A few weeks ago, I switched search robots on default to
(X)HTML, because I got the impression, that they have more problems with SVG 
or XML in general than with HTML tag soup. 
Human users can switch manually from the default SVG output to some
(X)HTML+CSS alternatives,  but my assumptions is, that search
robots have almost no artificial intelligence to choose a better alternative
on their own, therefore one has to care about them in a different
way than for the average human audience.

But at least for the human audience it is always a good option to provide
several alternatives manually, if there is at least one accessible format as
the primary offer (the initial page of a project).

Received on Monday, 4 October 2010 10:18:08 UTC