Re: Let every element have a src attribute

Jeff Schiller wrote:
>
> On 4/4/07, Bruce Boughton <bruce@bruceboughton.me.uk> wrote:
>> Jeff Schiller wrote:
>> > Finally, I'm actually in favour of reducing some of many "document
>> > containers" that HTML has (img, frame, iframe, object, applet, and um,
>> > embed) - so to me, using <object> to represent an image with fallback
>> > textual content helps streamline the language (I will admit that the
>> > semantics of "an image" do get lost somewhat in HTML:object, which
>> > could be a variety of things).  Why not discourage use of img and use
>> > object for images going forward?  (Ok, maybe this is last is too
>> > radical an idea)
>> One (minor?) problem with using object as a generic tag for any type of
>> non-textual content to be embedded is that it makes styling object types
>> more difficult.  If imgs become objects, it makes it harder to specify
>> that all images should have a border, unless of course our presentation
>> markup language (CSS) can disambiguate object types based on some
>> attribute of object *reliably* (e.g. @type).
>
> Bruce, you raise a good point:
>
>  object[type="image/png"], object[type="image/jpeg"] { border-style: 
> solid; }
>
> is nowhere as easy to type as:
>
>  img { border-style: solid; }
Nor as future proof.  What happens when browsers support JPEG200 or some 
other new format?  The CSS won't match the mime type.  CSS 3 Selectors 
supports substring attribute selectors and even includes the following 
example:

object[type^="image/"]

It just feels a bit kludgey on the CSS side which may affect adoption.
> And, of course, the type attribute is optional (the HTTP Content-Type
> is what is really important).  This means authors would have to use a
> class:
Ouch!
> That's not too painful really...
It may not seem to painful, but I'd like to see you explain to a 
designer *why* you've just made their job a little bit harder, for 
seemingly no gain.
> I think a bigger concern is the default width/height - if you don't
> specify the width/height on the object, the behavior is
> browser-dependent, I think.
Indeed, but I don't see that this can be spec'ed.  Object is generic and 
will support many different media types.  Any definition of default 
width/height will of necessity be media-independent.
> Jeff
>
>>
>> Otherwise I don't see any problems with migrating all embedded content
>> to the object tag.  The speed with which the types of media author wish
>> to embed changes suggests that it doesn't make sense to call some out
>> (image, video) as special cases with their own elements; we will never
>> be up-to-date with what authors want to embed.
>

Received on Wednesday, 4 April 2007 17:05:17 UTC