- From: Nicholas Shanks <contact@nickshanks.com>
- Date: Wed, 30 Jul 2008 09:17:21 +0200
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.bin>
Received on Wednesday, 30 July 2008 00:17:21 UTC