- From: Dao Gottwald <dao@design-noir.de>
- Date: Mon, 02 Apr 2007 10:07:57 +0200
- 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 UTC