Re: http content type authoritative for object data?

Joe D Williams, Sun, 13 Dec 2009 15:40:55 -0800:
>> Julian Reschke, Sun, 13 Dec 2009 11:40:54 +0100:

>> [ Youtube <object> example: ]
>>>> <object style="height: 344px; width: 425px" >
>>>> <param name="movie" value="http://www.youtube.com/v/vwI3tL2yc6k">
>>>> <param name="allowFullScreen" value="true">
>>>> <param name="allowScriptAccess" value="always">
>>>> <fallback html>
>>>> </object>

>> What's the point in making Youtube invalid, as HTML 5 currently does?

> There is no point in making YouTube code invalid. [...] This is just 
> a copy/paste example for how to get it going.

I of course meant Youtube's copy/paste code.

> [...] So, the only reason the stuff works is because 
> <embed> is complete enought togive needed info, including a value for 
> 'type' and 'movie' info.

It probably shouldn't work, but for Webkit and Opera, you can delete 
the <embed>, and it still works. Speaking about <object>, without 
<embed>: As long as @data and (or) @type is present, then Firefox, 
Opera and Webkit in fact doesn't need <param name=movie ... > at all.

Webkit and Opera also lets you do things like this:

<object>
<param name="type" value="image/png" >
<param name="src" value="image" >
</object>

>> I agree that it would have made sense if _Youtube_ and _Adobe_ had 
>> formulated requirements which were in tune with what HTML 5 now 
>> requires.
> 
> I'm still looking at what HTML 5 requires,

Perhaps you're aware of this then:

http://www.w3.org/QA/2008/09/howto-insert-youtube-video.html

> but problem. When <embed> 
> was born Adobe and Netscape worked closely to get a flash player 
> running and that has continued up to now. <object> was ignored by all 
> but IE as part of GBW. Now that all browsers use <object> there 
> should be at least a meaningful construction held out as an example 
> for current browsers.

Indeed.

>> For example, this would have made the above code work in Firefox 3.5.
> 
> Sorry, what would have? It think adding @type should make it work 
> because then the UA would have a clue about which player to use.

Inserting the URL of the Youtube video into the @data attribute would 
have made Youtube's copy/paste code work in Firefox, without the 
<embed> element. To instead use @type should probably also worked. But 
IE is alone in respecting @type, it seems. Supplying both @type and 
@data 
makes it work cross browser. It seems better to use @data this way than 
to use <embed> ... 

I guess Google is too focused on scripting to be able to show off good 
code.
 
>> May be user agents would have supported <object> earlier
>> and better if @data and/or @type had been a requirement - _for Adobe_
>> and everyone else that specify a way to use <object> for embedding a
>> resource.
> 
> There is no requirement to use @data. That is just a convenience [...]
> When we use <object> then (unless the UA can use the file extension 
> suffix - no no please), then the UA has no idea of which which 
> processing to use without @type until the file content is determined.

There is no file extensions in the URI of a Youtube movie. I suppose 
Youtube sends the MIME info along with the URI to the youtube movie, 
and that this is why using @data works in  Firefox.

>> But I still don't understand why every <object> should be required 
>> to have either a @type or a @data.
> 
> Again, without @type, how does the UA determine what processing to 
> use?

I agree that it makes sense when an external resources is embedded.

[...] 
>> Because, not every <object> out there is used for embedding 
>> resource. (Except in the same sense as <figure>
>> is an element for embedding.) And thus it should not, in those 
>> cases, need whether a MIME header, @type or @data.
> 
> Me not know. Sure <object> can hold anything.

But not in HTML 5. With HTML 5, currently, you must turn to 
hacks just in order to be valid, such as <object data="#dummy-idref">.

>> <object> in HTML 4 can - like the currently proposed <figure> - be used
>> for "inline embedding". And e.g.  Microformats.org discussed if OBJECT
>> shoudl be used for "embedding" data/time information. [2] This way of
>> using <object> does not make use of @data/@type and would thus become
>> invalid.
> 
> I think <object> is a display:block; element. Comparing <object> with 
> <figure> doesn't work for me because <figure> is not an active 
> element like I think of <object>.

<object> is not display:block by default. It defaults to inline or 
inline-block. Like <img>. That's the difference from <figure>: Figure 
is a block element. I was unclear when I said that both can be used for 
"inline embedding". What I meant was that <figure>, which is placed 
under the "embedding" chapter of HTML 5, is designed to include a 
mark-up construction. And so is <object>. (Another similar element is 
<button>, btw.) The fact that the so called fallback of <object> is 
meant for those who are using a Web browser which doesn't present 
graphics, doesn't matter: The mark-up fallback of the <object> _is_ a 
figure. For example, you may use <object> to display a diagram, and 
place a table as fallback.

I do not get what you mean by saying that object is "an active 
element". If you use <object> to display a image, then it is not any 
more active than a <img> - although the fallback could in fact be very 
active ...

> Your example of <object> 
> representing some time function seems OK, if the UA will allow data 
> to be written to and read from the <object>. Unfortuneately, most 
> <object> implemenations are so crippled in terms of allowing <param>s 
> to be used for anything but initialization, it may not be workable.

It is true that <object> has some problems, but it is also true that 
Youtube and authors use <embed> because they _think_ that it _still_ is 
necessary to do so. 

>> Thus I would suggest to separate the concerns: When <object> is used
>> for embedding a resource, then @data and/or @type should be required.
>> But other use of <object> should not have such requirements.
> 
> The purpose of <object> and originally <embed> was to deal with an 
> active context, meaning that the runtime was external from the DOM, 
> yet connected to it. <embed> and <object> provided some standard 
> interfaces to pass basic data and allowed other interfaces to be 
> defined by the plugin and available to the host.

<object> differs from <embed> by being more extendable and by having 
fallback. <object> also became the "generic" way for embedding stuff. 
It already generically embeds fallback. Actually specifying that it is 
permitted to show the fallback to everyone is not a big step.

>> [1] http://kb2.adobe.com/cps/127/tn_12701.html#required
> 
> I understand this OK. Just one question. Will any browser support 
> using all those attributes as live inerfaces, or just initialization?
> The flash player can have internal scripting, but how does the 
> <object> interface work for "external' scripts using DOM interfaces? 
> What is the user code to replace the current movie with another look 
> like?

I'm not following. Did you mean that it is understandable that flash 
could work without @type?

>> [2] 
http://microformats.org/wiki/abbr-datetime-pattern#.3Cobject.3E_element_to_represent_dates
> 
> <object id="date_object" data="20050125">January 25</object>
> 
> Sure, then a date, just coincidentaly one of my bdays, might be 
> accessed like:
> 
> dateString = document.date_object.data;
> 
> where dateString would be "20050125".
> 
> However, the characters that would actually be displayed by this 
> <object> would be "January 25" and would only be shown due to the 
> <object> fallback operation and only changable by rewriting the 
> complete object. How do you affect 'fallback' content? I haven't 
> tried that.

Are you in lack of understanding of how <object> operates? ;-)

It works just fine. Except in IE6 and 7. Just style the mark-up content 
of OBJECT as you would style any other element. For IE6 and 7 you need 
some kind of wrapper instead.

>  I would say why do that? I would think of creating some 
> actual time process and getting the object to i/o a date using a 
> <param> or two.

I can't answer for this Microformats proposal. There is also a proposal 
about using a <param> for holding the date, instead, and that makes 
more sense to me. For example, what if you use data="20050125", and 
there accidentally is a page with that name in the same folder?

> So this example is a clear case of not understanding how <object> 
> operates; only an example of how it is specified to operate when the 
> UA doesn't know what else to do.

It only shows a clear understanding of the fallback behaviour.

> As in other messages on this topic, I would rather get away from 
> tricks using <object> and define the way we want it to work, as a 
> live context accessible via the DOM using standard interfaces and and 
> special interfaces negotiated between the plugin and the UA.

This specific example might be worthy to be called a trick. The point I 
wanted to drive home right now, was that, unlike what the spec now 
says, it should not be necessary to perform even more tricks, such as 
adding a dummy @data or @type attribute, just in order to be valid HTML 
5. 
-- 
leif halvard silli

Received on Tuesday, 15 December 2009 01:59:36 UTC