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. Onewith 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.
smime.p7s
Description: S/MIME cryptographic signature
