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

Re: Let every element have a src attribute

From: Dao Gottwald <dao@design-noir.de>
Date: Mon, 02 Apr 2007 10:07:57 +0200
Message-ID: <4610B9DD.9010202@design-noir.de>
To: Elliott Sprehn <esprehn@gmail.com>
CC: Anne van Kesteren <annevk@opera.com>, public-html@w3.org

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.

Note that the same is possible with CSS3, e.g.
   p { content: url(foo.png); }
But that works with images only; a in-markup solution with the "type" 
attribute can be more powerful.

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

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

--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 08:08:07 GMT

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