- From: Elliott Sprehn <esprehn@gmail.com>
- Date: Mon, 2 Apr 2007 04:37:07 -0400
- To: Dao Gottwald <dao@design-noir.de>
- Cc: Anne van Kesteren <annevk@opera.com>, public-html@w3.org
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 UTC