Re: [SVG2 CR] switch, script and style, requiredFormats?

Hello,

the media-query part of the (X)HTML:picture element approach looks 
interesting.
But sometimes one does not only have to switch format or size of the 
referenced content, sometimes one needs completely different content,
if something does not work for the audience in the current viewer.
Especially for a graphics format like SVG this is important, but for (X)HTML 
relevant as well, but only available with the html:object approach.
To combine the approaches of SMIL/SVG:switch with the media-query from 
(X)HTML:picture could be a solution.

switch and requiredFeature implementations in several viewers seem to have a 
bug.
I did tests especially concering scripting, to provide alternatives in case of 
script interpretation is swiched on by the audience, but this never worked,
therefore I never published documents with scripted content in it. 
Such features are really borked due to such elementar bugs in user-agents.
But if implementors do not manage to implement SVG 1.1 properly, I cannot see
an urgent need for SVG 2 without the required SVG 2 features.
Waiting a few years and completing SVG 2 as required would mean a few years
more time for implementors as well, to get at least the SVG 1.1 interpretation 
right and complete ;o)

Olaf

Amelia Bellamy-Royds:
> I didn't know about requiredFormats in SVG 1.2.  That is unfortunate that
> it wasn't copied over.  I have elsewhere argued that adding a file-format
> support test to switch would be helpful in making it equivalent to HTML
> <picture> element.
> 
> Unfortunately, the way it is currently spec'd, <switch> is fairly useless
> for anything except language switching (which has its own problems) and
> creating static fallbacks for proprietary extensions (as Adobe does).
> Specifically, switch is not expected to block file downloads or scripts, so
> there is no performance benefit to using it for feature testing.  I've
> argued that we should now just call it "conditional display" instead of
> "conditional processing", because it only controls rendering, not
> processing at all.
> 
> Those of us working on the spec weren't happy about writing it up this way,
> but without commitments from browsers to change their implementations, we
> went with specifying current behavior.
> 
> ~ABR
>

Received on Wednesday, 21 September 2016 15:55:26 UTC