- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 30 Jul 2008 02:49:44 +0000 (UTC)
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). > > 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>. > - 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.) > - You don't have to provide a type attribute and match on: object > [type^="image/"] Seems like "img" handles this too. On Wed, 21 Mar 2007, Nicholas Shanks wrote: > On 21 Mar 2007, at 00:27, Simon Pieters wrote: > > > > The <image> start tag is parsed as if it were <img>, so you would get > > both the image and the fallback with HTML+ markup. Existing content > > rely on this behaviour, which is why it was added to the Parsing spec > > (see "A start tag whose tag name is "image"", and see comment in > > source). > > So what's the problem? > > Content with a doctype of <!DOCTYPE html> or <!DOCTYPE htmlplus> is > treated correctly, and content without a doctype is handled in quirks > mode, where the UA can look for </image> and if found in a suitable > place, treat the start tag as <image>, or if not found, treat the start > tag as <img>. Any content using <image> in strict mode with another HTML > doctype is broken anyway, so it doesn't really matter how that looks. We're not doing any DOCTYPE-based parsing differences unless we _absolutely_ have to. This kind of switch is a giant source of implementation bugs and authoring problems. On Wed, 21 Mar 2007, Benjamin Hawkes-Lewis wrote: > > Or, how about getting more specific? > > <bitmap> [e.g. image/gif of an icon] > <diagram> [e.g. image/svg of a map] > <photo> [e.g. image/jpeg of a cat] > > Would that help search engines, I wonder? I don't see why it would (who would be making sure the right one was used each time?). This really doesn't seem to solve a real problem. On Wed, 21 Mar 2007, Anne van Kesteren wrote: > > > I guess we have to agree to disagree here, but I think > > <image src="foo">Download Foo 1.4<br><small>(12 <abbr > > title="Megabytes">MB<abbr>)</small></image> > > is preferable to > > <img src="foo" alt="Download Foo 1.4 (12 MB)"> > > which it would appear you prefer. > > Yeah. An abbreviation such as MB should be known by an accessibility > client anyway and I think it's also perfectly capable of dealing with a > few parenthesis. Besides, the latter has been standard practice for over > a decade and trying to change authoring habbits with respect to that now > seems silly. Besides, you can use <object> if you really care about > "proper" fallback. In any case, what's the image in the case above? Why would you ever want that text _not_ visible when the image was visible? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 29 July 2008 19:49:44 UTC