W3C home > Mailing lists > Public > www-svg@w3.org > May 2011

RE: HTML5 how to indicate missing content: inline SVG & .svgz?

From: Tony Schreiner <tonyschr@microsoft.com>
Date: Mon, 23 May 2011 20:33:06 +0000
To: Jonathan Chetwynd <j.chetwynd@btinternet.com>, Dr.Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
CC: "www-svg@w3.org" <www-svg@w3.org>
Message-ID: <B20868C1F6435540A97DBB6B05F18F253122FA9F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com>
Hi Jonathan, 

IE9 does support compressed SVG as long as the server sends the standard "Content-encoding: gzip" in the response header. The server running http://www.peepo.com is sending the legacy x-gzip encoding instead, which is incorrect (at least as of HTTP/1.1) since the Accept-Encoding list being sent is "gzip, deflate, peerdist". If this is fixed then the site should work.

To partially answer your other question about indication of missing content, normally I would expect to immediately see the <object> fallback content in a scenario like this where the document type is unsupported (e.g. image/svg+xml on IE8 without any plugins) or there is an error. This does eventually happen but it takes a while as this seems to get treated like a network timeout.

For inline SVG in HTML5 the best solution is to use feature detection (e.g. http://blogs.msdn.com/b/ie/archive/2010/09/03/same-markup-using-canvas-audio-and-video.aspx) rather than browser detection. This embedding type is relatively new, so only the latest versions of browsers include support.

- Tony

-----Original Message-----
From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf Of Jonathan Chetwynd
Sent: Friday, May 20, 2011 2:11 PM
To: Dr.Olaf Hoffmann
Cc: www-svg@w3.org
Subject: Re: HTML5 how to indicate missing content: inline SVG & .svgz?

Olaf,

really the answer  is that it would be nice if the spec considered these possibilities from the start.
then it might be simple to implement.

instead of which it is a mess, as you describe quite well.

the content is available in each case, however the browser whilst rendering SVG is not able to render either inline or compressed svg.
see http://www.peepo.com as testcase.

in fact earlier versions of Internet Explorer such as IE7 do render the object alternate text message, but 'naturally'
the SVG capable IE9 can render SVG just not compressed svg, so one gets an empty box, no text message...

in Safari the inline svg is just missing, and this seems a serious error in spec design as clearly one needs a defined method to ensure users expect the outcome ((

~:"


On 20 May 2011, at 16:48, Dr. Olaf Hoffmann wrote:

> Jonathan Chetwynd:
>> HTML5 how to indicate missing content: inline SVG & svgz?
>
> Do you mean, it is not available for the browser or that the browser
> does not present it?
> However it seems to be more a question to the HTML5-WG how to
> indicate this to the audience.
>
> But in theory you can at least use object to provide alternatives,
> if a referenced format is not interpretable for a viewer.
>
> For SVG one can use externalResourcesRequired to avoid presentation
> of incomplete content, but there is not conditional processing  
> available
> to display something else instead - and how long the viewer has to
> wait for missing content before displaying alternatives.
> Taking into account this, for SVG it is an interesting question too,
> how to provide an alternative display, if referenced content is  
> missing -
> well obviously one can display a container with alternative content in
> general, covered by another container with  
> externalResourcesRequired="true",
> that is only rendered, if the referenced content is available.
>
> If only the viewer cannot present some parts of the internal content,
> in theory at least SVG has conditional processing for the author
> to provide alternatives.
> Well in practice due to bugs and gaps in viewers and that it is not
> precisely defined, when a condition becomes true and the problem,
> that different versions of SVG (1.0, 1.1, 1.2) have different feature
> strings for the same features, the results can be surprising ;o)
>
> For embedded other formats one can use conditional processing
> as well in SVG. This seems to be not the case for XHTML currently
> and presumably not for HTML5. At least for XHTML with namespace
> capabilities this could be a nice feature for authors, but this needs
> to be precisely defined, what it means, that a viewer has the  
> capability
> to interprete another format - only basically, complete, a subset/ 
> profile?
> And how can an author indicate, what is required to be interpreted?
> Interesting questions for the already existing conditional processing
> in SVG as well.
> Maybe if there are no precise answers to such questions, such a
> feature wouldn't be pretty useful.
> For example if I need SVG tiny 1.2 audio or video, it does not matter
> much, that an HTML5-viewer may have already the capability to  
> interprete
> a subset of SVG tiny 1.1 and some features of 1.1 full partly.
>
>
> Concerning problems with gzippt content - does the server send
> 'Content-encoding: gzip' in the header of such files?
> If yes, if the MSIE does not uncompress it, it looks simply like a bug
> in the MSIE, maybe they do not know the compression method ;o)
> I think, it is in general not trivial to care about such basic  
> features like
> gzip or tar with microsoft windows ...
>
>
> The more practical approach (well many including me do not really
> like it for some reasons, but anyway), that really does work  
> independently
> from working group decisions, format capabilites and viewers:
> If you already know, that a specific viewer (version) has specific  
> problems,
> you can use a server sided (PHP)-script so sniff the user-agent,  
> analyse
> it carefully and send only such content, that can be presumably  
> interpreted
> more or less properly by the identified viewer.
> Another approach is to write down, which features are required to  
> interpete
> the content properly and which viewer (versions) are already known to
> interprete this properly or which ones fail. This information can  
> help the
> audience to chose a proper tool or at least not the rely on the  
> presentation
> of a dubious viewer version.
>
> Olaf
>
>
>
>
Received on Monday, 23 May 2011 20:33:34 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:48 GMT