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

Re: Let every element have a src attribute

From: Elliott Sprehn <esprehn@gmail.com>
Date: Mon, 2 Apr 2007 04:37:07 -0400
Message-Id: <DE0DE081-CB66-4A29-A89C-14DA3226684C@gmail.com>
Cc: Anne van Kesteren <annevk@opera.com>, public-html@w3.org
To: Dao Gottwald <dao@design-noir.de>

On Apr 2, 2007, at 4:07 AM, 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.)
>
>> If you think about how it is now <p><img></p> is an image inside  
>> the paragraph, but if we allow <p src=""> then is that an image  
>> inside the paragraph or is the image itself a paragraph or is it  
>> just an image unless it doesn't load and then its a paragraph?
>
> The image itself is the paragraph.

This is the exact conflict I'm talking about here: you first said it  
replaces the paragraph with an external source, and then that the  
image is the paragraph.  In such cases the content of the image  
should actually be a paragraph of text?

In general I'm not entirely sure it should be promoted that entire  
element groups be swapped with images. I know its already possible  
with <object>, but this has rarely (from what I've seen) been used in  
the wild to replace whole paragraphs of text with an image containing  
that text. Allowing src on any element doesn't sit right with me in  
terms of semantics and accessibility, and if we promote replacing   
<p> with an image that contains the paragraph text we break font  
sizing (and thus limit accessibility) for many users.

So in short, do we have a good use case scenario where this would be  
useful and semantically proper?

>
> Note that the same is possible with CSS3, e.g.
>   p { content: url(foo.png); }

This is true, but CSS3 defines presentation, not meaning. If we  
introduce this feature we are adding semantic meaning to the image  
itself even when CSS is disabled.

> But that works with images only; a in-markup solution with the  
> "type" attribute can be more powerful.

I'm not sure why type is more powerful since mime negotiations should  
be done with the HTTP protocol, not the markup language.

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

Can you define what's intuitive in this context? To me <img> is the  
most intuitive since you're displaying an image, not a paragraph (etc).

>
>>  From what I see the only case for extending the existing behavior  
>> in a similar manner would be supplementing the alt attribute on  
>> the <img> element with the element contents since <img> has much  
>> clearer semantics, similar to the behavior of <video> or <audio>.
>
> <img> has much clearer semantics than what? It tells me as much as  
> a single text node does. That is, the surrounding markup carries  
> the semantics, but <img> itself doesn't.

Compared to <object>, <img> has much clearer semantics in its  
explicit that the content it represents is an image. This is one  
reason that <video> and <audio> were proposed.

What I was talking about though, was adding the capability to do <img  
src="">alt text here</img> much the way you're suggesting be done  
with all elements.

- Elliott

>
> --Dao
>
>> - Elliott
>> On Mar 29, 2007, at 11:32 AM, Dao Gottwald wrote:
>>>
>>> In order to avoid having to mess with a bunch of related  
>>> attributes as with "href", I'd allow "src" (or "data"?) and  
>>> "type" only. I'd see it as a <object> shorthand, thus it should  
>>> behave the same when it comes to events.
>>>
>>> Note that by "every element", I mean those who can have visible  
>>> child nodes. This way you automatically exclude elements that  
>>> have a src attribute today.
>>>
>>> That's all a bit tricky though, as it implies inconsistencies.  
>>> E.g. <img src="foo.png" alt="foo"> would differ from <span  
>>> src="foo.png">foo</span> in some non-obvious ways.
>>>
>>> --Dao
>>>
>>> Anne van Kesteren wrote:
>>>> On Wed, 28 Mar 2007 18:29:21 +0200, Dao Gottwald <dao@design- 
>>>> noir.de <mailto:dao@design-noir.de>> wrote:
>>>>> .... which seems very plausible to me. Contrary to letting  
>>>>> every element have a href attribute, it's backwards-compatible  
>>>>> by design.
>>>> Not really. <script src> has very different semantics from <img  
>>>> src>, <iframe src> and <embed src> for instance which have  
>>>> different semantics from <video src>, <event-source src> and  
>>>> <source src> (which also all differ from each other). The  
>>>> semantics of an element are in general decided by the element  
>>>> and after that by their attributes. This means that how the  
>>>> attribute functions depends on the element and not the other way  
>>>> around.
>>>> Exactly the same arguments as for href="" apply I would say. For  
>>>> src="" you have can think about how loading would happen for the  
>>>> element. When are the various events dispatched? Does the  
>>>> element delay the load event of the document? Does it start  
>>>> loading the monment it is inserted? Does mutating the src=""  
>>>> attribute affect any API (see <event-source>)? Et cetera.
>>>
>>>
>
Received on Monday, 2 April 2007 13:52:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:15:52 GMT