Re: fear of "invisible metadata"

At 17:02 +0200 UTC, on 2007-06-25, Simon Pieters wrote:

> On Mon, 25 Jun 2007 15:39:49 +0200, Sander Tekelenburg <st@isoc.nl> wrote:

[<object> as an alternative for <img>]

>> Try to read the definition for <object> as if you're an average web
>> publisher [...]
>
> Let's see, then. Element-specific attributes for <img>:
>
>     alt, src, usemap, ismap, height, width
>
> Element-specific attributes for <object>:
>
>     data, type, usemap, height, width

So in HTML5 classid, codebase, codetype, archive, declare and standby are all
gone for good? I mean, <img> doesn't exactly seem to have rid itself of
longdesc just yet, judging by the discussions. So who knows how <object> will
end up. But yeah, if <object> is simplified in HTML5, that's certainly an
improvement.

> Hmm, <object> actually has fewer attributes than <img>. To be fair,
> <object> can also have <param>s, but you probably don't need to pass
> parameters to images.

We know that, but that doesn't mean it'll be obvious to Joe Average Web
Publisher, from reading the spec. Speaking for myself, when the spec for
<object> mentions an optional <param> element, I need to understand that
element before I can feel I understand <object>. Especially when IE  screws
up my gorgeous <object data=URL>fallback</object>, which surely means I am
doing something wrong, doesn't it? Clearly I need to understand the spec
better. Oh well, I'll just give up and use <img>. I'd have preferred to
publish better for users who can't do anything with the image, but that's too
expensive. At least <img> just works.

> The spec says about <object>:
>
>     The object element can represent an external resource, which, depending
>     on the type of the resource, will either be treated as an image, as a
>     nested browsing context, or as an external resource to be processed by a
>     third-party software package.

Sorry, but although that does seem better than what HTML 4 says, I cannot
imagine this is clear language to authors. "*treated* as an image"? A
"browsing context"?

>     The data attribute, if present, specifies the address of the resource.
>     If present, the attribute must be a URI (or IRI).
>
> There it explicitly calls out images as the first example

It calls out an "external resource which [...] may be treated as an image".
Not many people will perceive that as "explicit" ;)

<quick hack>
The object element can contain an image or a "nested browsing context"
[whatever that is] for inline processing, or it an contain a file to be
processed by a plug-in or helper application.

The data attribute specifies the address of the file. If present [{frown
}it's not required?], the attribute must be a URI (or IRI).
</>

I know, I know, it would be more productive if I would propose better text.
But I really cannot afford the time needed to do that. Not all of us are so
privileged to get paid to work on HTML5.

[...]

>> Talk with web publishers.
>
> Ok. I asked a web publisher if he knew what <object> was for. He said for
> e.g. flash and video. I asked whether images would work, and he said
> certainly, but he didn't know how exactly. After some quick testing he
> figured it out.

Sounds like he figured out by looking at browser behaviour (and apparently
didn't try IE). IMO we should try to make the spec readable enough that more
authors can use it -- that fewer authors feel a need to purely rely on
effects in their browsing enviroment.

Anyway, while I certainly appreciat that you actually did ask one (I did too,
but got no response yet -- he might not have received my message yet, or be
sweating on it as we speak :)), that's not indicative for web publishers in
general. (And neither is my claim, obviously.)

[...]

>>> So <image> can't be used.
>>
>> Well, then perhaps <picture>fallback<picture>, or <pic>fallback</pic>,
>> for less typing ;)
>
> I don't think that adding more elements for including images will improve
> interop or reduce confusion.

Well, I do ;P

I'm even open to the idea of dropping <img> in favour of <pic>fallback</pic>.
It would improve accessibility, the metadata (fallback content) can be
considered less invisible, it would fit nicely with <video> and <audio>, and
would better fit the description of (paraphrasing) "<img> is an alternative
for ALT text" as HTML5 currently says it. I mean, that description looks
weird, for <img>, but I completely agree with the idea behind it.
<pic>fallback</pic> fits that idea better.


-- 
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>

Received on Monday, 25 June 2007 17:04:40 UTC