- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Sun, 30 Oct 2011 12:01:58 +0200
- To: HTML WG <public-html@w3.org>
I think x- vs. no x- is a distraction as far as the ISSUE is concerned. The crux of the matter is that HTML already has a mechanism for adding key-value pairs elements: attributes. Adding key-value pairs to elements using nested param elements where both the key and the value reside in attribute values (instead of the key residing in an attribute name) is a misguided artifact of letting the DTD validation mechanism affect language design in the HTML 4 cycle. With today's validation technology, non-standard key-value pairs can be made equally invalid when expressed as param as when expressed as attributes. On the other hand, it's equally feasible to make a validator call valid content that uses key-value pairs unknown to the validator in advance. In other words, even if this WG added <param> to where av_param suggests, I could program a validator to flag params invalid unless the param names have been approved somehow. Or I could program a validator not to complain about attributes with names starting with "dlna-" (or whatever). As for browser implementation, <embed> implementations already pass arbitrary key-value pairs expressed as attributes through a plug-in interface (and <embed> even predates <param>), so it's clearly possible to use attributes for passing parameters to software components that aren't part of the browser engine proper. The notion that <param> is somehow more extensible than attributes is an illusion. Because attributes are more compact and because all major browsers have shipped implementations that parse <source> as a void element, I think this WG should reject av_param no matter what this WG thinks of DLNA or other such consortia minting key-value pairs that aren't stardardized in *this* WG for inclusion in HTML proper. (However, I have a hard time believing that there'd be key-value pairs that wouldn't be useful for Web content but would be good ideas for multivendor walled gardens like cable TV. That is, I'm predisposed to assume that either HTML is missing features that should be defined in HTML proper or the additional features are bad ideas and shouldn't be specced by DLNA, either.) I object to the av_param change proposal due to reasons given above. P.S. Even if one agreed with the general idea of av_param, the av_param proposal is obviously flawed: It fails to define parsing algorithm changes that would make it possible to express the kind of tree that'd use the proposed content models. It claims there are no conformance classes changes, which logically has to be a bogus claim, since it's proposing something that isn't an editorial change. It's also disingenuous to claim that there are neither known negative effects nor known risks, when I had stated at least one in the bug report from which the ISSUE was escalated. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Sunday, 30 October 2011 10:02:38 UTC