- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 17 Mar 2010 00:22:05 -0700
- To: "Ennals, Robert" <robert.ennals@intel.com>
- Cc: HTMLwg <public-html@w3.org>
- Message-id: <44574BAB-12EA-4ACA-B288-6FFF1414F10B@apple.com>
On Mar 15, 2010, at 8:28 PM, Ennals, Robert wrote: > > Proposal Y: tries to give a better fallback and backwards-compat > story: > http://www.w3.org/html/wg/wiki/ChangeProposals/fixedprefixsimple > I read over Proposal Y. Because it has no effect on parsing behavior, I don't think it suffers from the issue I noticed with Proposal X. Its effects seem to be limited to creating an "extended HTML document" conformance class and making a (non-normative) recommendation to those making extensions, so the details it gives seem sufficient to evaluate it on the merits. I think the rationale for the proposal could be improved by mentioning specific scenarios where a party may wish to define an extension to HTML, but none of the existing mechanisms would be appropriate. This is including data-* attributes, the "other applicable specifications" mechanism, as well as metadata mechanisms such as RDFa, Microdata or traditional features like class/rel/link/meta. I assume a key point here is that these extensions would be expected to affect behavior or presentation, but are not suitable for being made a core Web standard, at least not yet. At least one example that I think fits these criteria is experimental features in browsers. Browser vendors from time to time want to implement features that are not in any specification as a way to demonstrate their merits or explore the design space. It would be good to have a way to do this without squatting on good names or locking in designs that turn out to be suboptimal. So I recommend listing that scenario. You may have others in mind. Regards, Maciej
Received on Wednesday, 17 March 2010 07:22:39 UTC