- From: Sander Tekelenburg <st@isoc.nl>
- Date: Mon, 25 Jun 2007 19:01:09 +0200
- To: public-html@w3.org
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