W3C home > Mailing lists > Public > public-html@w3.org > April 2007

Re: Let every element have a src attribute

From: Matthew Raymond <mattraymond@earthlink.net>
Date: Mon, 02 Apr 2007 22:30:22 -0400
Message-ID: <4611BC3E.206@earthlink.net>
To: Dao Gottwald <dao@design-noir.de>
CC: public-html@w3.org

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 Tuesday, 3 April 2007 02:29:40 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:42 UTC