[whatwg] <img> element comments

Wed Aug 15 03:48:42 PDT 2007

On Sat, 4 Nov 2006, Lachlan Hunt wrote:
> Ian Hickson wrote:
> > On Fri, 3 Nov 2006, Anne van Kesteren wrote:
> > > * It should probably mention 'img.src = foo' (that loading directly
> > > starts). I thought that 'img.setAttribute("src", foo)' even did different
> > > things in browsers (when the element is not yet inserted into the
> > > document) so reflect might not be accurate.
> > 
> > I couldn't find a difference. Any idea what it was?
> 
> I don't know of any difference and I don't think there should be any, 
> even if some implementations currently do.  It would only be confusing 
> for authors if they behaved differently.

Agreed.

> > > * I would also suggest to put "If the src attribute is omitted, 
> > > there is no alternative image representation." after the last 
> > > statement on the alt attribute.
> > 
> > Done. (I think. I edited a bunch of stuff before reading your comment 
> > so it may be not quite what you meant.)
> 
> And, as I mentioned in IRC, I think it should be defined that the value 
> should resolve to a valid URI for an image, so that <img src="" alt=""> 
> isn't conforming, except in this rare case:
> 
> <p xml:base="foo.png"><img src="" alt=""/></p>

Ok but... what's an image? Do we exclude PDFs and SVG? (Safari and Opera 
respectively support those.)

If we allow SVG, it's trivial to send XHTML as image/svg+xml and the 
processing is as defined then for HTML as for SVG, so why exlude HTML?

If we disallow SVG, what's the definition? image/* that corresponds to a 
non-interactive bitmapped resource? What about WMFs? Why would those be 
disallowed?

As Simon asked on IRC, who are we helping by limiting what's allowed?

> > > * I think it would also make sense to show some more examples for 
> > > the alt attribute. http://www.cs.tut.fi/~jkorpela/html/alt.html 
> > > might be too large to be included in the specification, but 
> > > guidelines to that effect would be more than welcome.
> > 
> > Noted.
> 
> The explanations you've written in this are good also.
> 
> http://hixie.ch/advocacy/alttext
> 
> The house example under argument #3 would be good to include.

I've gone through both those documents and made the spec cover the points 
made therein. Let me know if I missed anything useful.

> > > * The height and width attributes as defined are completely 
> > > presentational. I don't really see any value in keeping them. Now I 
> > > suppose they have to be supported anyway, but so does <body 
> > > bgcolor="">.
> 
> I disagree.  Specifying the size is very good for incremental rendering, 
> but the alternatives are awful.

The spec now allows sizes to be given (though not %s).

> > > * Perhaps we can allow content for XML documents?
> > 
> > That's tempting. We'd have to allow it for HTML too (via DOM 
> > manipulation).
> 
> It's already possible via DOM manipulation (except in IE which throws an 
> exception).  The spec should at least define what it means and how to 
> process it, even if it's defined that UAs should just ignore it.

I've not gone there yet, this may be a little too radical for its own 
good. The serialisation problems alone would be confusing to many.

Authors have <object> for the advanced fallback if they need it.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'