Re: img issue: should we restrict the URI

At 12:10 AM 1/28/2008, Jeff Schiller wrote:

>On Jan 25, 2008 12:43 PM, Anne van Kesteren <annevk@opera.com> wrote:
> > On Fri, 25 Jan 2008 19:22:13 +0100, Jeff Schiller <codedread@gmail.com>
> > wrote:
>
>In my opinion, I really think that these things should be considered
>within the context of the HTML WG since we are trying to define the
>expected behavior of the UA when encountering the html:img element
>(not the UA behavior when it encounters the svg:image element, which
>does not impose all these restrictions).  Isn't it within HTML's
>jurisdication as "host language" in this scenario to impose certain
>restrictions?

I would agree. Since the types of things that are supported by <img> 
are not specified, then allowing authors to know some boundaries on 
what to expect makes sense. While I am not sure what problems we 
would have by having scripts running inside <img> that we would not 
already have with scripts running inside <object> or <iframe>, I'm 
willing to believe that there probably are reasons (see speculation 
in last paragraph below). It seems like non-scripted animation such 
as found in animated GIF and SVG/SMIL oughta be fair game. What is 
likely to be a proliferation in years to come of images created in 
SVG format makes it seem important to handle some of the interesting 
cases that Jeff mentions.

SVG by virtue of allowing nesting of external content through <svg> 
and <foreignObject> children makes it rather like a compound document 
format, and we can imagine a multitude of such formats that might be 
candidates for inclusion in an <img>. Apparently Opera handles the 
scripts inside <foreignObject>s or <svg>s within an SVG by disabling 
them as well,  so that seems like a reasonable approach to standardize.

One reason that comes to mind for disabling scripts inside <img> 
would be that certain user agents might not support scripting and 
that having a limit on what an <img> is likely to ask of the agent 
may help with graceful degradation. That is, if fancy cross-DOM 
scripting is always to be found in <object> <iframe> <frame> <embed> 
etc., then non-script aware agents will know that those things can be 
handled with alternative constructs. There are already lots of 
gadgets that display SVG but don't run script. Specifically reserving 
<img> as a place for simple declarative SVG might ultimately help 
user agents to appear graceful when they find the less simple stuff 
in <object>.

David

Received on Tuesday, 29 January 2008 15:34:13 UTC