Re: Multilanguage alt/title

HI Maciej,


On Aug 30, 2007, at 12:56 AM, Maciej Stachowiak wrote:

>
>
> On Aug 29, 2007, at 7:37 PM, Robert Burns wrote:
>
>> Hi Maciej,
>>
>>> <embed> is there primarily for content handled by plugins. The  
>>> best plugin markup for degrading gracefully in a wide variety of  
>>> browsers nests <embed> in <object>, and it would be unfortunate  
>>> to make such markup non-conforming, even if you can use <object>  
>>> alone to target newer browsers only.
>>
>> I understand how <embed> is used, but I don't see any reason to  
>> make it a part of document conformance. Everyone who uses it now  
>> uses it even though its not a part of document conformance. Adding  
>> it to document conformance simply makes the language more  
>> complicated without any benefit whatsoever.
>
> The benefit is that people can use <embed> for the same very good  
> reasons they use it today, and still get the benefits of  
> conformance checking for your document. If you make it impossible  
> to do something useful without violating conformance requirements,  
> people begin to disrespect the conformance requirements.
>
> Another risk is that people may add some markup via scripting  
> solely to pass conformance checking. This happens today and is  
> harmful to users who have script disabled and to non-interactive  
> UAs like search engines.
>
>> If it was a part of the language in HTML 4.01 it would make sense  
>> to remove it now. Why would we add it? The object element is also  
>> for plug-ins. I see no reason to have two separate elements that  
>> serve the same purpose: one with fallback capabilities and the  
>> other without fallback capabilities.
>
> Combining <object> and <embed> allows you to both work in a wider  
> range of browsers than through <object> alone, and at the same time  
> use the rich fallback capabilities of <object>. At least if we say  
> the <object>'s fallback should apply if both the <embed> and the  
> <object> can't be presented.

Yes, I understand why embed is used. That's not the issue. The issue  
in document conformance is how do we want authors to create content  
in the future. embed does not allow authors to use the rich fallback  
content of object, it terminates the rich fallback content of object.  
In other words object is designed to have nested objects arbitrarily  
deep. However, as soon as one reaches an embed, the nesting ends;  
there's no room for a text alternate equivalent as the final fallback.

If we're to focus our attention on users and authors, then its hard  
to imagine what benefit adding another element to document  
conformance does for either group. If I make a new browser tomorrow  
using a new element for embedding content like robburnsembed, then  
should we support that too in document conformance: perhaps as one of  
the nested fallback elements inside object? No, I don;'t think we  
should. The object and embed elements are both elements aimed at  
exactly the same purpose: but one (object) has clear benefits over  
the other (embed)  so there's no reason to add embed in the document  
conformance norms.  They're both designed as generic containers for  
embedded content. At least with applet, video, audio, picture and  
canvas there's some meaningful distinction that provides some  
justification for having separate elements around.

As you know keeping embed out of our document conformance does  
nothing to stop it from working since it will be part of the UA  
conformance norms. This is just another document conformance norm we  
can have that helps raise authoring standards. Will authors need to  
use embed elements to target legacy browsers? I would expect they  
might. However, that doesn't mean we should encourage the future use  
of embed by including in the document conformance criteria. We have  
starter wiki pages ready if someone wants to develop the use cases  
and solutions surrounding embed versus object.[1]

Take care,
Rob

[1]: <http://esw.w3.org/topic/HTML/AddedElementEmbed>

Received on Thursday, 30 August 2007 06:14:43 UTC