Re: Let every element have a src attribute

Jeff Schiller wrote:
> The HTML:object already exists for this exact fallback mechanism, we
> should be clarifying any unspecified behavior of the HTML:object
> element, not introducing new attributes/elements that do the same
> thing but "break" older user agents. 
I agree.
> 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).

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.
>
> Regards,
> Jeff Schiller
>
> On 4/2/07, Matthew Raymond <mattraymond@earthlink.net> wrote:
>>
>> Dao Gottwald wrote:
>> > Matthew Raymond wrote:
>> >> Dao Gottwald wrote:
>> >>> Elliott Sprehn wrote:
>> >>>> This would seem to complicate semantics to me. What's the 
>> difference
>> >>>> between <p src=""> and <div src=""> in terms of the meaning of the
>> >>>> replaced content?
>> >>>
>> >>> The first replaces a paragraph by an external source, the latter
>> >>> replaces, well ... anything (since div doesn't carry significant 
>> semantics.)
>> >>
>> >>    That's interesting, because I thought it was the other way around.
>> >> The content is supposed to replace the image if the image doesn't 
>> load.
>> >
>> >  From the XHTML2 WD:
>> >
>> > (1) "This collection causes the contents of a remote resource to be
>> > embedded in the document in place of the element's content."
>> > (2) "If accessing the remote resource fails, [...] the content of the
>> > element must be processed instead."
>> >
>> > Both aspects are perfectly consistent.
>>
>>    That's not consistent with HTML, though. The above makes this...
>>
>> | <p src="image.png">[...]</p>
>>
>>    ...the equivalent to this...
>>
>> | <p><img src="image.png" alt="[...]"></p>
>>
>>    However, consider an image in the middle of a sentence:
>>
>> | <p>This sentence has <img src="image.png" alt="[...]"> in it.</p>
>>
>>    Using a global |src| attribute, you're actually forced to insert
>> markup simply to use the attribute:
>>
>> | <p>This sentence has <span src="image.png">[...]</span> in it.</p>
>>
>>     So while <img> would yield the equivalent of this...
>>
>> | <p>This sentence has [image data here] in it.</p>
>>
>>     ...the global |src| attribute would give you this:
>>
>> | <p>This sentence has <span>[image data here]</span> in it.</p>
>>
>>    What's more is that in XHTML, there's no reason people couldn't do
>> the following:
>>
>> | <p>This sentence has <img src="image.png">[...]</img> in it.</p>
>>
>>    That's actually shorter than using <span> for the same thing, while
>> not forcing you to leave a container element when the image fails to 
>> load.
>>
>> > Apparently we're talking about different types of images. I'm not
>> > proposing to remove <img>, [because] there are clearly images that 
>> aren't
>> > just text replacements / can't be replaced by text.
>>
>>    In my opinion, that represents the only truly semantic use case.
>>
>> > Yet there are images
>> > that do communicate well-definable chunks of information.
>> >
>> > An example: 
>> http://design-noir.de/log/2006/12/immer-noch-nicht-gezahlt/
>>
>>    The image is irreplaceable when you're using it as evidence, so while
>> text fallback for the letter is enough to read the letter, it is simply
>> a distant second best to the image itself.
>>
>> > Or just think of the million logos out there, like
>> > <http://www.linguatec.net/images/logos/linguatec.de.gif>.
>>
>>    The whole point of a logo is to leave a visual imprint in the
>> viewer's mind, so once again, the image is more important than the text
>> that might replace it if it fails to load.
>>
>> >>    Then why not just use <object>?
>> >
>> > Its fallback mechanism isn't well supported,
>>
>>    This makes no sense. A global |src| attribute isn't supported at all
>> in HTML, and I doubt that it would be any easier for browser vendors to
>> implement given their track record with <object>.
>>
>> > and I'd like to avoid the more complex markup.
>>
>>    What complex markup? Right now, the following is perfectly valid:
>>
>> | <object data="image.png"> [...Fallback...] </object>
>>
>>    How is that any more complicated than the following?
>>
>> | <p src="image.png> [...Fallback...] </p>
>>
>>    Sure, it's a few more characters to type, but one thing it's good for
>> is allowing better fallback:
>>
>> | <object data="...">
>> |   <object data="...">
>> |     <object data="...">
>> |       [...Fallback...]
>> |     </object>
>> |   </object>
>> | </object>
>>
>>   ...Versus...
>>
>> | <p src="">
>> |   <p src="">
>> |     <p src="">
>> |       [...Fallback...]
>> |     </p>
>> |   </p>
>> | </p>
>>
>>    Not the in the above for <object>, just the fallback line is used if
>> the objects fail to load. However, if the objects pointed to by |src|
>> fail to load, you get this:
>>
>> | <p><p><p>[...Fallback...]</p></p></p>
>>
>>    Now, granted, on some browsers you have to specify |type| on
>> <object>, but that requirement is not part of the HTML 4.01 spec, and it
>> will eventually vanish as vendor implementations improve.
>>
>> >>>> Also, what benefit beyond slightly reducing the markup by 
>> removing the
>> >>>> <object> tag does this provide?
>> >>>
>> >>> It's more intuitive and links the external source with the 
>> semantics it
>> >>> carries directly.
>> >>
>> >>    I don't see it as more intuitive at all. What the heck is "src"
>> >> supposed to mean to anyone?
>> >
>> > Are you kidding me?
>>
>>    Not at all. Consider the following:
>>
>> | <!-- The |src| attribute provides the URL for the image. -->
>> | <img src="Stargate">
>> |
>> | <!-- The |src| attribute provides the URL for the video. -->
>> | <video src="X-303">
>> |
>> | <!-- The |src| attribute provides the URL for an audio file. -->
>> | <audio src="Zat">
>> |
>> | <!-- The |src| attribute provides the URL for...a paragraph??? -->
>> | <p src="DHD">
>>
>>    Furthermore, |src| is already defined with different semantics on
>> several elements, and for those who are just learning HTML, it doesn't
>> necessarily indicate image or object semantics. In fact, the names
>> "image" or "object" would have been better choices.
>>
>> >>    The image IS the semantics! If it wasn't, you could just use 
>> CSS. The
>> >> surrounding markup doesn't define the image any more than the
>> >> surrounding text defines a particular word.
>> >
>> > Just as with text, an image isn't self-descriptive, even it it 
>> contains
>> > the semantics.
>>
>>    The content we're talking about isn't supposed to describe an image,
>> it's supposed to replace it. There's a difference. Remember when Prince
>> was using that unpronounceable symbol as his name? A description would
>> tell you what that symbol looks like (and you'd probably want to put
>> that description in the |title| attribute). The replacement content
>> would be "the artist formerly known as Prince".
>>
>> > That's what we have tags for.
>>
>>    I would argue that elements don't necessarily exist to describe other
>> elements.
>>
>>
>

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