[whatwg] <img> element comments

Fri Oct 12 15:55:46 PDT 2007

On Sat, 4 Nov 2006, Anne van Kesteren wrote:
> On Sat, 04 Nov 2006 07:37:32 +0100, Ian Hickson <ian at hixie.ch> 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?
> 
> From what I recall setting the DOM attribute on a newly created element 
> (not appending it to the DOM) would cause download immediately in all 
> browsers, but some browsers acted differently when the "src" content 
> attribute was set on the newly created element. As in, the download 
> started the moment it was appended to the DOM, not before (no load event 
> would fire).

Is this required for compat or can we leave it as is? How widely is it 
implemented?

> > > * 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'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?
> 
> If you require this only for images with known intrinsic dimensions than 
> that would be fine with me (as in, for some cases of SVG the 
> requirements are likely different).

Is the way it is phrased now acceptable?

On Sat, 4 Nov 2006, Henri Sivonen wrote:
> 
> What about non-square pixels in the image file? Both GIF and PNG allow 
> pixel aspect ratios other than 1:1. I don't have test cases and I don't 
> know what browsers do.

The spec sidesteps this by defining the dimensions as CSS pixels.

> Also, such a requirement would make document conformance dependent on 
> resources other than the (X)HTML5 file itself. Is that a good idea? Is 
> the document conforming, not conforming or undecided if there are no 
> other errors but the image cannot be retrieved?

I think we're going to have to work this out -- maybe there should be two 
things, document conformance and related resource conformance.

> What image formats should a conformance checker know about? GIF, PNG and 
> JFIF?

Same as browsers, I guess.

On Tue, 7 Nov 2006, Shadow2531 wrote:
> 
> Yeh, in example method, this is the suggestion:
> (at least from what I got out of the proposal)
> 
> [conforming]
> <img src="276x110.png" alt="fallback text" title="description">
> <img src="276x110.png" width="276" height="110" alt="fallback text"
> title="description">
> 
> [non-conforming]
> <img src="276x110.png" width="400" height="200" alt="fallback text"
> title="description">
> <img src="276x110.png" width="50%" height="50%" alt="fallback text"
> title="description">

Agreed.

> <img src="276x110.png" width="276" alt="fallback text" title="description">

This is fine in the spec as it is today.

On Tue, 7 Nov 2006, Andreyka Lechev wrote:
> 
> Don't forget that percentage values are relative values. And in current 
> browser implementations, setting those values via CSS-rules or using 
> width- and height-attributes are leading to different results! It's due 
> to different parents to calculate actual (pixel) values from!

This doesn't seem to be true.

> CSS values are relative to the the parent element in HTML tree:
> 
> <div style="width: 100px; height: 100px;">
> 	<img src="276x110.png" style="width: 50%; height: 50%;">
> </div>
> => displays image 50x50px.
> 
> 
> Attributes values are relative to the actual size of the image:
> 
> <img src="276x110.png" width="50%" height="50%">
> => displays image 138x55px.
> 
> 
> That may be very useful in many cases, so as a HTML-coder, I don't think 
> anybody should change that behavior without proposing something to 
> replace it.

I couldn't reproduce the behaviour you give above. Do you have test cases 
showing this?

On Tue, 7 Nov 2006, Greg Kilwein wrote:
>
> Also, if only one of either the "width" or "height" attributes is set, 
> some browsers will scale the other dimension automatically.  Consider 
> this example:
> 
> <img src="100x50.png" width="50">
> 
> Some browsers will scale height to be 25 in this instance, given an 
> image with a width of 100 pixels and a height of 50 pixels.  This is 
> quite useful when the height or width of an image needs to be fixed 
> without distorting the aspect ratio.

This will be defined in the rendering section in due course.

On Sat, 4 Nov 2006, Matthew Raymond wrote:
> Lachlan Hunt wrote:
> > 
> > The style attribute is far more presentational than the height and 
> > width attributes.
> 
> I don't see how either is more or less presentational. The |height| and 
> |width| attributes are entirely presentational, since their sole purpose 
> is to define the sizing of the image in the document layout.

I agree that style="height: 100px" is different from height="100" only in 
a syntactical fashion, from a semantic standpoint.

On Sun, 5 Nov 2006, Lachlan Hunt wrote:
> 
> Using attributes to describe actual metadata about an image that has 
> real practical benefits, for both the author and user, is not 
> presentational in my view.

It is presentational. But it's ok.

On Sun, 5 Nov 2006, Elliotte Harold wrote:
> > 
> > Using attributes to describe actual metadata about an image that has 
> > real practical benefits, for both the author and user, is not 
> > presentational in my view.
> 
> Yes, but that is not what the height and width attributes are. They say 
> nothing about the image and everything about the size at which the image 
> is drawn.

Yes and no. They do, in practice, control the size at which the images are 
drawn. But as defined in HTML5, they actually give the "real" image size, 
even if the size in the image file itself is "inaccurate".

On Sun, 5 Nov 2006, Michel Fortin wrote:
> 
> Taking this back to the subject of height and width of images, I'd 
> simply ask myself if the attributes are necessary to have an acceptable 
> presentation. I see two cases in which the attributes have a benefit:
> 
> 1.  while the document is loading;
> 2.  if the image needs to be resized.
> 
> I won't rehash case one, I think it's clear that many people consider 
> that useful, useful enough at least to add these attributes to a lot of 
> images even if they aren't resizing anything.
> 
> Two is tricky too. Let's say I have a high resolution image of a 
> mathematic formula inline in the text (presumably to have good results 
> when printing). It's clear that you don't want the image of the formula 
> to be too big: in this case the resizing, while clearly presentational, 
> is absolutely necessary to have a readable document. I take note however 
> that it'd be more useful to set the size in em or in ex than in pixels, 
> the downside is that you need CSS for that. I also admit that this is a 
> made up hypothetical case; maybe no one does that, I've no idea.

I think the spec handles these cases now (except for the 'em' thing, which 
still requires CSS).

On Tue, 7 Nov 2006, Henri Sivonen wrote:
> > 
> > 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?
> 
> Suppose there are desktop systems in the near future that double the 
> pixel density of the display compared to what is common today. 
> Considering the handheld displays Nokia ships, I guess it is only a 
> matter of time for similarly small pixels to appear in desktop-sized 
> panels at affordable prices. Apple already seems to be preparing for 
> this.

The spec handles this by requiring the attributes to be given in CSS 
pixels.

> So I think width and height should not have conformance requirements 
> tied to pixel dimensions of the references image file. They are 
> presentational, but they are such a useful presentational optimization 
> that I think it doesn't make sense to try the get rid of that 
> presentationalism just to comply with a principle.

Is the compromise in the spec today acceptable?

On Wed, 15 Aug 2007, Dave Singer wrote:
> > 
> > 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?
> 
> Making life a little easier for the browser implementers in what they 
> might reasonably expect to find there?

Fair enough.

> Clearly images have to have a visual representation.  Embedding only 
> audio, or ancillary data, here would be too weird.
> 
> Perhaps images are things that are non-temporal and with visual 
> representation, or "slightly temporal" in the sense of animated GIFs 
> etc. where temporal control etc. is not expected or desired.  They 
> probably do not have associated audio, perhaps?
> 
> That means that a 'static' SVG image is indeed an image, whereas an SVG 
> presentation that has 'significant' temporal behavior is video.
> 
> I'm not sure what to say about interactivity;  SVG allows it, so 
> probably it's allowed.  But then, why isn't an HTML page embeddable in 
> image?  It has a visual representation, and if we allow interactivity, 
> it would seem to fit.
> 
> Similarly using SMIL to layup something that was 'static' (perhaps 
> several images overlayed in regions) would seem to also be allowed.

I'm all for making <img> be non-interactive.

The spec currently has an open issue w.r.t. what limitations to put on the 
endpoint of an <img> src="".

On Wed, 15 Aug 2007, Bert Altenburg wrote:
> 
> Displaying PDF is great for company web-apps (mine uses it extensively, saving
> us lots of time).

But does it have to be in <img> instead of <iframe>?

On Thu, 16 Aug 2007, Lachlan Hunt wrote:
> 
> I think you're putting too much emphasis on the words "for an image" in 
> what I wrote.  I think my intention was to avoid cases where it's 
> pointing to itself. In practical terms, it just needs to point to file 
> in a format that browsers support for <img>, but HTML has never 
> explicitly defined which image formats browsers should or should not 
> support, and I don't think it should.

Fair enough. I'm not sure pointing to itself is a huge problem though.

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