[Bug 13333] audio, video (and source) elements require param children or equivalent

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13333

--- Comment #52 from Henri Sivonen <hsivonen@iki.fi> 2011-08-04 08:48:42 UTC ---
(In reply to comment #43)
> > It is true and the truth is easily experimentally verifiable. (I experimentally
> > verified it today.)
> 
> For the record, could you indicate which browsers and which versions you
> tested? 

I tested IE9's IE9 standards mode, Firefox trunk (but I know the behavior to be
the same since Firefox 3.5), some version of Chrome in the 13 or 14 series
(what I now have is 14.something but it might have been 13.something a few days
ago; anyway, I know the behavior to have been the same since Chrome 8 and most
likely since Chrome 3), Safari 5.1 (and I know the behavior has been the same
earlier) and Opera 11.50 (and I know the behavior has been the same earlier).

> Did you also test whether param on video/audio is processed or
> supported in any way by these browsers?

I didn't.

> > > (3) the resolution assumes the bug is intended to be used "to mint
> > > vendor-proprietary attributes", which is not the case;
> > 
> > It's intended to mint vendor-proprietary name-value pair parameters, AFAICT.
> 
> I have stated times that I am working with a number of standards/specifications
> organizations other than the W3C which define, promote, and deploy profiles of
> W3C specifications, including HTML. These organizations are not proprietary
> vendors. 

Let's say "special-purpose" instead of "proprietary" then. (Where
"special-purpose" means that the stuff isn't expected to be implemented in
general-purpose implementations of HTML. If what these organizations are
speccing were general-purpose features, the features should by specced in the
W3C HTML spec itself.)

> In order to remain consistent with existing implementations and plugins which
> *do* make use of param on object, and to facilitate the transition from object
> to video/audio, support of param element on video/audio is desirable.

<param> exists because the group that defined HTML 4 couldn't figure out how to
write a DTD for <embed>. The design that involves passing the attributes of an
element to a 3rd-party software component actually came first (in Netscape
2.0)! HTML5 doesn't use DTDs anymore, so that problem is no longer there.
<param> shouldn't be regarded as a positive role model or a design that merits
perpetuating or emulating for any purpose other than keeping the syntax of
<object> itself backwards compatible.

> The alternative proposed by Sylvia and yourself to make use of private x-*
> attributes is not acceptable because it is not a standardized syntax. In
> contrast, param is a standardized syntax supported by existing abstraction
> layers in media components and plugins.

If you have an attribute x-dlna-foo or dlna-foo or a param <param
name=dlna-foo>, the syntax can be exactly as standardized or non-standardized.
Whether a token is in an attribute name or in an attribute value has no bearing
on how standardized the token is.

(In reply to comment #44)
> As can be seen, the set of "standardized" param names/values increases/changes
> over time in such a manner as to preclude an a priori definition of new
> attributes.

Why can't you mint more attributes over time? Why would you need to have a
priori definitions for future attributes?

Would it work for you if HTML set attributes whose names begin with dlna- aside
for use in DLNA specs?

(In reply to comment #49)
> > Therefore, the general
> > problem of attaching proprietary name-value pairs to the <source> element is
> > WORKSFORME
> 
> Actually, this now appears incorrect - data-* will not work here.

I didn't mean data-*. I meant x-dlna-* (or just dlna-*).

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 4 August 2011 08:48:44 UTC