- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Fri, 24 Sep 2010 01:19:05 +0200
- To: Sam Ruby <rubys@intertwingly.net>, Michael Smith <mike@w3.org> (tm), Maciej Stachowiak <mjs@apple.com>, Paul Cotton <Paul.Cotton@microsoft.com>
- Cc: HTML WG <public-html@w3.org>
Sam Ruby, Thu, 23 Sep 2010 14:12:51 -0400: > The poll is available here, and it will run through Wednesday, > October 7th(*): > > http://www.w3.org/2002/09/wbs/40318/issue-41-objection-poll/ Co-Chairs and Mike, Reading the socalled "zero-edit" proposal ("heavy-edit" would have been more accurate names), I discovered info that we have not had in time. Firstly: The proposal referred to as 'zero-edit', consequently speaks about Microddata as a "feature" (a feature of HTML), while whereas HTML5+RDFa is presented as "applicable specification"extension. Draw you own conclusions. Even if I would have agreed with that proposal, those comments would hinder me from adding any support. Secondly: the @vendor--feature attribute Despite that it is referred to as "zero-edit", it informs us that HTML5 has a @vendor--feature attribute. This attribute is only one month old - and, says Ian, might still change, see bug 9590. [1] The bug, reported by Maciej, as well informs that this feature earlier was known as @_vendor-feature. The comments in bug 9590 informs us that @vendor--feature is not possible to comment out, as the following would be an invalid comment: <!--<p vendor--feature>-->. @Vendor--feature also clashes with @data--feature attribute. Since I myself for long worked - and thought - on a change proposal for ISSUE-41, it is embarrassing to learn that HTML5 already _had_ a vendor prefix feature. My CP tried to cater for that. As tries Rob Ennals' CP. I myself wrote to this list in August and asked the vendors for more info. [2] But didn't get any response, not even a pointer saying that they thought the issue to be solved. I was believing I was working on a case that the vendors were interested in. But experienced zero interest. Finally I understand why ... But until now, I was thinking that the reason for the zero interest, was that the vendors of this group weren't interested in such prefixes anymore. Which seemed quite logical to think given the rhetoric from so many of them _against_ extensions. Should I have known about _vendor-* and vendor--* ? Did the co-chairs know, apart from Maciej? How could I have known? It is impossible to spot "_vendor-feature" in the Commit-Watchers mailing list - though it probably exist there somewhere (?). (While "vendor--feature" was easy to find.) However bug 9590 hints that _vendor-feature dates back to just before April 25th. At any rate, _vendor-feature first time appeared in the current published Working Draft, of 24th of June. [3] A search in public-html for _vendor does not reveal anything either. Discussion in the whatwg list seems to be not more than a moth old. Conclusions Irrational: The so called zero change proposers have, in parallel with their work on the so called zero change proposal, worked on an extension mechanism for vendors! This, in my mind, undermines the very point that the zero change proposers want to make. (They also claim it to be important that extension happens within the standard process framework - however, the way _vendor/vendor-- has gotten into the spec, doesn't actually make me trust that view.) Uncollegial: More seriously, the other Change Proposal authors (including myself) have not been informed about this, and thus have been prevented from responding - positively or negatively - to this vendor prefix feature. E.g. the _vendor-feature solution has many likeness with my own change proposal, since my entire proposal was based on prefixes beginning with the underscore letter. I would have liked to know this as I worked and thought about my own proposal. Unclear: What if Robert Ennals proposal is accepted? What will then happen to _vendor or vendor-- ? Will we then go for the vendor solution that Rob Ennals suggests in his proposal instead? Or will someone then perform a "free interpretation" of what Rob Ennals' proposal is about? Late: The change proposals have existed for months. The zero-edit proposal has existed for 4 days. [4] Had it been presented to the group in due course, then probably much of this would have been solved in time. PS: I am really happy that Maciej suggest new bugs should go to this list. That should have happened long ago. [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9590 [2] http://lists.w3.org/Archives/Public/public-html/2010Aug/0059 [3] http://www.w3.org/TR/2010/WD-html5-20100624/infrastructure#extensibility [4] http://lists.w3.org/Archives/Public/public-html/2010Sep/0213 -- leif halvard silli
Received on Friday, 24 September 2010 00:20:05 UTC