[whatwg] IMAGE element (was XSLT: HTML 5 --> HTML)

[Nicholas Shanks]

On 9 Feb 2007, at 15:51, Benjamin Hawkes-Lewis wrote:

> Nicholas Shanks wrote:
>
>> Yes, like OBJECT, but with a different name. A nicer name than  
>> IMG. One
>> with three vowels. One that only accepts image/* content types. One
>> with a more specific usage that can be controlled independently of
>> OBJECT through CSS 1/2.
>
> Strictly, you don't really need a second element for independent
> selection.
>
> CSS 2:
>
> object[type="image/jpeg"], object[type="image/gif"]

... ad infinitum.

I don't consider that wise, because:

a) you'd have to list every possible image/* combination that exists  
or could be invented in the future
b) you'd have to add a type attribute to the element, which implies
	i) you have control over the HTML (in user.css it wouldn't work)
	ii) you ‘know’ what content type the server is going to return

> Draft CSS 3:
>
> object[type^="image/"]

better (which is why I didn't mention CSS3 originally), but point (b)  
above still applies.


The basic point of replacing <IMG> with <IMAGE> rather than replacing  
it with <OBJECT> was (would be) specificity. The image element could  
now be defined as a subtype of the object element for that most  
common usage case of including pictures on a page.

The other thing is that <IMAGE> could be *block level* by default,  
and wouldn't cause the extra line height whitespace problem that  
inline images can cause when misused. <IMG> would still be available  
for simple inline images like <img src="/emoticons/smilie" alt=":-)">
Further benefits: longdescs could be included as a hyperlink at the  
end of the normal fallback text.

Importantly, explicit inclusion in the HTML5 spec would make more  
people aware of the kind of behaviour and benefits that have always  
been available through object but that few people use (myself  
included, I must admit).
I was originally just making an off-the-cuff hostile remark about  
IMG, but the more i think about it the more I dislike them pesky and  
restrictive alt attributes!

- Nicholas.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2157 bytes
Desc: not available
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20070209/3aba81d1/attachment-0001.bin>