RE: Let every element have a src attribute

I agree strongly that existing UA support of HTML:object isn't really an excuse to discount it.

We will have to (continue to) fix the IE implementation of <object> to adhere to the standard in future releases.  I expect there are compelling reasons to introduce new semantic elements; just to get <object>-like fallback without using the word "object" is a goofy reason, IMO.

-----Original Message-----
From: public-html-request@w3.org [mailto:public-html-request@w3.org] On Behalf Of Jeff Schiller
Sent: Monday, April 02, 2007 8:31 PM
To: Matthew Raymond
Cc: Dao Gottwald; public-html@w3.org
Subject: Re: Let every element have a src attribute


I agree with Matthew.  As earlier was stated, what we really want:

  <img src="image-i-really-want-to-show.png">Fallback text describing
the image here</img>

is, unfortunately, not backward compatible.

The proposal:

  <p src="image-i-really-want-to-show.png">Fallback text describing
the image here</p>

changes the semantics of the <p> element.  The <p> element is a
paragraph, not an image.

It gets worse when you want to first fallback to another image and
then fallback to some descriptive text (as Matthew mentions):

  <p src="image-i-really-want-to-show.png"><p
src="next-image-to-try.jpg">Fallback text</p></p>

Now you have two nested paragraphs that are really trying to represent
an image.  So now, does the outer image (PNG) _mean_ the inner image
(JPG)?  That's not really applying any semantic meaning to the outer
image by nesting an inner image (they're still just binary images).

And here's a worse scenario, what if we need multiple paragraphs and
other markup to describe an image in the fallback case:

  <div src="image-i-really-want-to-show.png"><p>The image shown is
from <a href="">...</a>....</p><p>It reperesents ...</p></div>

Now the image has become a div - but it's really still just an image
with some meaning - why are we switching markup tags?

But to me, the biggest argument against the src attribute everywhere
is this:  Let's say authors start heavily using it - now suddenly
older user agents, which might have been able to display the image in
the first place, will be ignoring the src attribute and only
displaying the fallback text.  Why?  Suddenly, pages that could have
still rendered in older user agents will stop displaying their images.

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.

And existing UA support of HTML:object isn't really an excuse, in my
book.  As Matthew says, UAs are not likely to fully support any new
features we introduce immediately anyway, so it's the same scenario
(and worse for legacy UAs).

To me, this is just cleaner represented as:

  <object src="image-i-really-want-to-show.png">fallback here, could
be another object, could be markup, etc</object>

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)

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 18:25:15 UTC