[whatwg] image element

[Nicholas Shanks]

On 30 Jul 2008, at 4:49 am, Ian Hickson wrote:

> On Tue, 20 Mar 2007, Nicholas Shanks wrote:
>>
>> I asked for the resurrection of HTML+'s <image>fallback</image>  
>> element
>> last month. The reasons I cited were exactly the same as the reasons
>> being given now in favour of the <video> element, however I was told
>> (paraphrasing) "Why bother, you can just use <object>" and "That  
>> would
>> break existing implementations" (though no such implementations were
>> cited).

To continue this:
The video and audio elements are being introduced because they have  
DOM APIs that exceed that of <object>, and we don't want to overload  
the general element with features specific to certain kinds of media.  
By analogy, images could have specific APIs too (dontScale/scaleToFit/ 
stretchToFit, nextFrame/previousFrame/startAnimating/stopAnimating).  
These aren't being proposed at present, but overloading object is not  
something it seems like we should be telling people to do.

I would expect, if an analysis was done, that the number of people  
using <image/> as an empty element (thinking they were using img), and  
the number of people using <image></image> as was defined in HTML+ are  
both no higher than the background noise of misspelled tags. As such,  
I don't believe it would be to any vendor's detriment to change the  
meaning of an opening <image> tag to not be empty, since the numbers  
of pages rendered incorrectly would stay about the same (just that it  
would be a different set of pages). The action, however, would free up  
the tag for future use.

>> So again, I ask for an <image> element to replace <img>. Benefits  
>> include:
>> - As <video> would cater for video/* MIME types, <image> would  
>> cater for
>> image/*
>
> I don't see how this is a benefit over <img>.

In order of importance to me:

1. It's spelt correctly.
2. It's not an empty element.
3. It's spelt correctly.

>> - The alt and longdesc attributes can be part of the fallback  
>> content,
>> allowing markup.
>
> If you need markup in the fallback, use <object>. (Or, better,  
> consider
> exposing the content to everyone and not making it only available to  
> those
> who don't see the image.)

The point of fallback is ‘help for people who can't see the image’  
rather than ‘an explanation of the image suitable for all’. Of course,  
if you can provide the latter, that's great, and there's no problem.  
Fallback content could be as simple as "Figure 2", where the  
surrounding text discusses the image sufficiently that it isn't  
necessary to see the image, but users still want to know which image  
element on the page that text was referring to (so they can download  
it to disk, or whatever).

>> - You don't have to provide a type attribute and match on: object
>> [type^="image/"]
>
> Seems like "img" handles this too.

Aye, but <img> gets me very angry.
I believe this was the worst moment in the history of HTML:
http://1997.webhistory.org/www.lists/www-talk.1993q1/0182.html

Why did nobody stop this guy at the time?  We're still cleaning up his  
mess 15 years later :-(

— Nicholas Shanks.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2427 bytes
Desc: not available
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080730/996809fe/attachment-0001.bin>