- From: Joe D Williams <joedwil@earthlink.net>
- Date: Sun, 13 Dec 2009 15:40:55 -0800
- To: "Leif Halvard Silli" <xn--mlform-iua@xn--mlform-iua.no>, "Julian Reschke" <julian.reschke@gmx.de>
- Cc: "Jonas Sicking" <jonas@sicking.cc>, "Boris Zbarsky" <bzbarsky@mit.edu>, <public-html@w3.org>
> 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