[whatwg] <img> element comments

Sat Nov 4 00:43:00 PST 2006

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>

>> * Regarding the alt attribute, wouldn't it make sense to just allow it 
>> to be omitted? In terms of meaning it seems the same. On the other hand, 
>> it probably shows the difference between people who thought of the 
>> alternative representation and people that haven't.
> 
> Maybe. I dunno.

Screen readers have a reason to to distinguish between these cases.
When an author fails to specify any alt text, users can make the screen
reader read the file name or, if it's a link, the URI so that the user
has a better chance of guess what it's for.  I could be wrong, but I
think when alt="" is explicitly specified, screen readers ignore it.

>> * 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.

>> * 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.

1. <img ... style="height: 100px; width: 100px;">

The style attribute is far more presentational than the height and width 
attributes.

2. <img ... id="foo">

#foo { height: 100px; width: 100px; }

This is simply not feasible in most cases, unless there are very few 
images on the site.  Think about flickr, it just wouldn't be possible to 
specify the dimensions of all their images in a stylesheet.

> I'm thinking of only allowing integer values, and requiring them to be 
> equal to the dimensions of the image, if present (and requiring both to 
> be present if either is present). Would people be ok with that?

I agree.  Any use case for specifying percentages should be done with CSS.

>> * 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'm not sure, though. <object> is pretty buggy, wouldn't 
> this just cause <img> to get those bugs?

Maybe.  We'd have to get feedback from implementers.  The limitations 
and bad design of alt have been complained about quite often, this could 
be an opportunity to fix it.

This could be useful in XHTML:

<img src="foo" alt="foo bar">foo <em>bar</em></img>

That could give a richer fallback for newer UAs and the plain text 
fallback in current XHTML UAs.  That technique could help with the 
transitional period until UAs were upgraded.  Although, <object> already 
provides a similar abilities.

-- 
Lachlan Hunt
http://lachy.id.au/