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 Friday, 20 May 2011 21:11:48 UTC