Re: img issue: should we restrict the URI

Boris,

That is  exactly why I started this thread [1].  Unfortunately it got
somewhat derailed by the <img> "deprecation" suggestion.  The bottom
line is there is very few web pages out there that do not use the
<img> tag - it isn't going anywhere. So we need to specify what it
means in a backward-compatible way.

I would like to specify what an "image" means to HTML.

At the very least, I would suggest that an image is non-interactive in
both the user and the user-agent sense.

Whether or not script should be allowed to run inside an "image" (like
SVG) is another question that I would like to bring to the forefront.
.There might be some arguments to allow scripts to run inside images.
For instance:  an image may want to reflect the current time of day...
 But so far I haven't come up with any convincing arguments to allow
this.  If the author wants some scriptability, they can always use
<object>

So can we consider specifying that images are both non-interactive and
must not be allowed to run scripts?

Regards,
Jeff

[1] http://lists.w3.org/Archives/Public/public-html/2008Jan/0217.html
On 1/25/08, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>
> Dr. Olaf Hoffmann wrote:
> > I think, these problems show mainly, that the img element
> > of html is outdated since the object element was introduced.
>
> The two have very different behavior from a security perspective.  In
> particular, the content of an <img> is guaranteed to be static content in the
> sense that it won't run JavaScript (though I do wonder how Opera's SVG and
> Safari's PDF handling play there; I would hope they disable JavaScript when
> embedding SVG and PDF via <img>).  <object> carries no such security guarantee;
> quite the contrary.
>
> Now this guarantee is not spelled out in the HTML4 specification, of course.
> But it has been provided by all UAs for a number of years now, and it's widely
> relied on by content.
>
> In fact, it would make a lot of sense to specify this guarantee in HTML5...
>
> -Boris
>
>

Received on Friday, 25 January 2008 17:26:46 UTC