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

My understanding is that there ought to be some automatic detection for gzip encoding in svg--- I know that data-URL encoded svgz takes on the same content type as svg.

I've not checked in IE-- I've had mixed results in Chrome-- for support of svgz on the local file system.



On May 23, 2011, at 1:33 PM, Tony Schreiner <tonyschr@microsoft.com> wrote:

> 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:53:16 UTC