[whatwg] several messages
ian at hixie.ch
Tue Jul 29 19:49:44 PDT 2008
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
> 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
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
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
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg