RE: Interactive Declarative Animation in <img>

On Thu 3/26/2015 1:28 PM
Daniel Holbert wrote:
>> This is a
>> natural extension (requirement?) of the "no external resources" rule 
>> for SVG-as-an-image.  We could conceivably allow navigation *to an 
>> anchor within the image-document*,

and Chris Lilley replied:
> yes, any link  to a fragment within the same resource. ie any link 
> that could be expressed as #foo
> 
>> but this would still let the image change its own URL, which seems to 
>> introduce undesirable complexity.
> 
> Its not changing its own *base* url, though.

And Daniel H continued: 
DH: bz might have more concrete thoughts on this. bz: in a hypothetical
world where browsers send events into <img> (for things like hover effects
and event-triggered SMIL animation), can you think of any problem with
*also* allowing clickable links in the image-document that point to anchors
elsewhere within the image-document? (assuming we block navigation to &
loads of external content)
-----------

Very interesting considerations. In fussing around with things at Wikipedia
and Ello, I stumbled into the "no external resources" rule, since I wanted
bitmaps inside an SVG, and found I had to use base64 encoding of said
bitmaps to make it happen.  I realized, at the time, why external resources
would be a security/privacy risk to the audience, but wondered if a
same-domain exception might be applied. If a resource (like an image file)
came from the same domain, is there still a problem with that? I could see
that if both a) external resources from same domain were loadable and b)
interactivity were enabled then that domain could sniff behavior of the user
within their interaction with the image, but all that sniffing data would
stay under the ever careful and respectful auspices of the social network
wouldn't it? 

Doug's question about mousewheel or position activity being possibly linked
to scrolling or zooming is a pretty interesting notion. I'm not aware of
what current SVG's thinking about standardized scroll and zoom is, since it
seems like the last time I checked it was the WG's belief that browsers
should all be free to implement that (or not) as they wished. On the other
hand, it would be very interesting for people to be able to zoom in on
individual SVG's within a page without having to set the zoom for the entire
page. That's sort of how the ASV browser handled things and it was very
nice! (observe how inconsistently the browsers handle [1] for example -- the
inconsistency has gotten worse rather than better over the past seven years
since that example was made, btw).

Cheers
David

[1] http://srufaculty.sru.edu/david.dailey/svg/recent/sliderzoom2.svg

Received on Friday, 27 March 2015 02:33:21 UTC