- 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