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

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 15:48:58 UTC