[whatwg] several messages

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 
> 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.   `._.-(,_..'--(,_..'`-.;.'