Re: http content type authoritative for object data?

> Julian Reschke, Sun, 13 Dec 2009 11:40:54 +0100:
>> Joe D Williams wrote:
> [ 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>
>>>
>>> tells the UA absolutely nothing about what it might be working 
>>> with.
>>> Here, @type is missing and no @data so the UA has nothing to
>>> determine what processing to use. [...]
>>
>> You are right.
>>
>> I saw the URI and somehow ignored the fact that it appears in a
>> param, not as object/@data.
>
> What's the point in making Youtube invalid, as HTML 5 currently 
> does?
> Youtube is, in this regard, valid HTML 4. And, for Flash, Adobe 
> itself
> makes no requirement to use whether @data or @type either. [1]

There is no point in making YouTube code invalid. Check the code they 
actually build the page with. This is just a copy/paste example for 
how to get it going.
As I said, the only reason the <object> part of the element is a 
useless container because it holds no information that the UA can use 
to determine what processing to use for the context. Note that the 
"movie" value doesn't tell the UA anything because that is a value for 
the plugin. So, the only reason the stuff works is because <embed> is 
complete enought togive needed info, including a value for 'type' and 
'movie' info.
>
> 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, 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.


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

> 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 for 
plugins that have not defined a <param>. Flash now uses a special 
interface called "movie" which is used in the example as a special 
<embed> string and in <object> as a <param>. As I have seen, <object> 
@data was sort of the same as <embed> @src except that in <object> 
@data used some special sniffing.
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.

>
> 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? To me, this points to <object> really only being used for mimes 
not covered in 'standard' HTML. Recall an evolution: firt there was 
<p>, then there was <img>, then whenwe needed an active object outside 
the standard syntax, we got <embed> which evolved to <object>. To me, 
stating the <embed> is useful for "interactive" content is a farce 
because of the form and constraints of the string used to control the 
contenxt produced by <embed>.
For embedding .html, then use iframe. Object is convenient for that 
but in the example:

<object data=some.html>
<fallback html>
</object>
the UA would need to sniff the file extension suffix to figure out 
what to do.

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

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

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

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

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

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.

> -- 
> leif halvard silli
>

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.

Thanks and Best Regards,
Joe

Received on Sunday, 13 December 2009 23:41:37 UTC