Re: Let every element have a src attribute

Elliott Sprehn wrote:
> 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?

Well, the <p> tag itself isn't a paragraph; it wraps it. The wrapped 
content (the original paragraph) is replaced by an external source (the 
new paragraph). The content of the image should be anything equivalent 
to the replaced content, e.g. graphical text or a sketch.

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

Because it's not fully supported across browsers.

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

People already do that today. Using <p> would actually make it clearer 
that you're replacing content which should stay there as an accessible 
alternative.

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

Probably all cases where you would use <img> (i.e. not CSS) today and 
some of those where you would use <object>.

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

Sure. Why is that a problem? If CSS3 defined exactly the same thing, I 
wouldn't propose it here.

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

So why do we have the type attribute for <object>? I'm sure there are 
good reasons.

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

The image *means* something, and the tag immediately tells what that is.

> To me <img> is the most 
> intuitive since you're displaying an image, not a paragraph (etc).
[...]
> 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.

The image is only a image in the first place if it's art, a photo et al. 
Otherwise it's just a special kind of a paragraph, link, list item etc.; 
it carries semantics that aren't strictly bound to an image.

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

Unfortunately, that's not backwards-compatible.

--Dao

Received on Monday, 2 April 2007 10:16:42 UTC