Re: Let every element have a src attribute

Dao Gottwald wrote:
>>>>    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>
> 
> Could you elaborate on the problem that you see here? If you don't want 
> to replace the whole paragraph, it makes perfectly sense not to use 
> <p>'s src attribute.

   The problem here is that markup is being used here purely to serve as
a container where no container is needed.

>>    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.
> 
> As I said, it's not backwards-compatible.

   Refresh my memory as to why this would not work specifically in
XHTML, which was the context I specified.

   As for backwards compatibility in HTML, <object> can be used in the
exact same way. All you have to do is make sure |width| and |height| are
defined for images, and that's only because of a bug in Internet Explorer.

>  >> 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.
> 
> The image could be replaced very well by multiple paragraphs and 
> emphasises.

   That is not sufficient if you wish to prove the existence of a
physical letter, and if that was not the intent, they should have used
CSS. The reason that images in place of text are common is because:

a) For various legal and technical reasons, downloadable fonts have not
really taken off, resulting in a lot of images that contain rendered
fonts rather than the fonts themselves.

b) Standards-based technologies like SVG, until recently, haven't been
available in most browsers.

   Both of these issues will eventually be resolved, but in the
meantime, we can use CSS. In fact, I used CSS Level 2 and some <span>
elements to accomplish essentially the same thing.

> That you consider a big text string as "enough" is probably
> due to the fact that you're not disabled.

   So use <object>. Or CSS Level 3.

>  >> 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.
> 
> ... which was not my point. My point was and is that the image's 
> information can and should be available as markup.

   First of all, |alt| in combination with |lang| is sufficient for the
vast majority of use cases involving logos. The <object> element is
sufficient for the rest.

>  >>>    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>.
> 
> The proposed fallback-mechanism is supported out of the box.
> Technically, Opera already supports replacing an element's contents via 
> CSS3 (content: url(...)).

   CSS (Level 3, by the looks of the property you're using) is not a
requirement for HTML. Furthermore, the feature requires additional CSS
to work in Opera, and Opera does not have significant market share
compared to other browser vendors. (That isn't to say that Opera isn't
one of the best browser around, though.)

   Also note that the resource disappears as soon as the user overrides
or turns off the styling, or it may never appear at all if the style
sheet fails to load. This clearly indicates that the supposed support is
entirely presentational in nature.

>  >> 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>
> 
> Actually:
> 
> <object data="image.png"> <p> [...Fallback...] </p> </object>
> vs.
> <p src="image.png> [...Fallback...] </p>

   Actually:

| <p><object data="image.png">[...Fallback...]</object></p>

> That should be more obvious.

   I agree, which is why an element rather than an attribute is superior
in this instance. With an attribute, there's no visual cue to let you
know if the element the attribute is declared on is part of the fallback
or if it's the container.

>  >    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>
> 
> Nesting <p> is neither allowed nor supported in any browser.

   That was the point. If people misunderstand something as simple as
the fact that the container element (<p>) is not itself replaced, they
can end up with non-conformant markup.

>>>>>> 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">
> 
> Exactly.

   "Exactly" what?!? There is a clear ability to violate the user's /
author's expectation of content. If I point the |src| of an <img> to a
non-image file, I get a broken image icon. For <video> as it is
currently defined, I get the fallback content if the source isn't a
video. Are you suggesting that if the source isn't text or an HTML
fragment that's legal within a <p>, that the contents of the paragraph
will be rendered? That's not my understanding of what you've been saying
at all.

   That brings up an interesting point, though. What happens if you use
|src| on an element that's not supposed to accept the content in
question? For instance, <hr> can't be a container. What would happen if
it had an |src| attribute?

>  >    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.
> 
> In fact, neither XHTML2 nor I did limit the given proposal to images. 
> The "remote resource" may very well be any media.

   Considering the poor implementation of <object>, how are you so much
more optimistic about turning every HTML element into a potential
<object> element?

   By the way, is it your intention to deprecate |width| and |height|,
or are you making those global as well?

>>>>    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.
> 
> Exactly! And since an image's information can be complex, the alt 
> attribute isn't enough to replace it.

   No, but the <object> element is.

Received on Wednesday, 4 April 2007 01:19:11 UTC