[whatwg] <img> element comments
ian at hixie.ch
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.
> > > * 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
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.
> 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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg