W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2006

[whatwg] <img> element comments

From: Ian Hickson <ian@hixie.ch>
Date: Sat, 4 Nov 2006 06:42:34 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0611040637430.289@dhalsim.dreamhost.com>
On Fri, 3 Nov 2006, Alexey Feldgendler wrote:
> 
> > * 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.
> 
> This has been discussed here once.
> 
> The problem with requiring the alt attribute is that people will omit it 
> anyway, or, worse, write alt="" to make the documents formally valid, 
> actually mangling the meaning.

We can't do much about that, as far as I can see, regardless of whether we 
require it or not.


> The problem with allowing omission of alt depends on the meaning of 
> <img> without alt. If <img> without alt is defined to mean the same as 
> <img> with alt="", then the problem is that all cases when people omit 
> the alt attribute because they don't care will end up with mangled 
> meaning.

Right.


> If <img> without alt is defined to mean that the image is semantically 
> valuable but without an alternative text, then the problem is that we 
> need to distinguish between empty and omitted alt in DOM somehow.

That's easy enough; the real problem is that we end up saying that 
literally billions of <img> tags are semantically valuable when in all 
likelihood they're just decorative images.

The number of <img> tags with a alt="" attribute is about half the number 
of <img> tags with a src="" attribute.


On Fri, 3 Nov 2006, Michel Fortin wrote:
> > 
> > * 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="">.
> 
> Except that, contrary to bgcolor, the height and width attributes can 
> help solve a real problem: page jiggling while the images loads. It's 
> somewhat like the type="image/jpg" attribute you can set for links: it 
> gives advance information on what the external content is supposed to 
> be.

Right.


> In this case, height and width are inherent properties of the document 
> if we consider the linked image as part of the document, much alike the 
> type="" attribute on a link. Sure, we could use style="width: 32; 
> height: 32" instead of width="32" height="32", but most of the time the 
> size of an image isn't a matter of style, it's a matter of what the 
> image is.

Right. However, height/width take %s as well, and can be set to values 
that don't match the image height/width. What do we do in those cases? How 
do we justify them?


On Fri, 3 Nov 2006, Matthew Raymond wrote:
> 
> The |width| and |height| attributes don't specify the dimensions of the 
> source image. They specify the size of the image in the document. That's 
> presentational, in my book. Arguing that those attributes are properties 
> of the image within the document amounts to a free pass for all 
> presentational markup. The <font>, <center>, <s> and <u> elements 
> communicate a property of the text, not the presentation. I don't buy 
> it. Without the attributes actually describing a property of the source 
> image (which is redundant), the |height| and |width| have no semantic 
> meaning. Convenient as they are, they're styling as markup.

Sure, but what about the jiggling? Do you really want people to set IDs on 
all their images and then have the stylesheet list all their images and 
give the height and width properties that way?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 3 November 2006 22:42:34 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:49 UTC