- From: Shelley Powers <shelley.just@gmail.com>
- Date: Wed, 6 Jan 2010 07:52:46 -0600
- To: "Scheppe, Kai-Dietrich" <k.scheppe@telekom.de>
- Cc: Ian Hickson <ian@hixie.ch>, Paul Cotton <Paul.Cotton@microsoft.com>, HTMLWG WG <public-html@w3.org>
On Wed, Jan 6, 2010 at 2:16 AM, Scheppe, Kai-Dietrich <k.scheppe@telekom.de> wrote: > Hi, > > Yes, I was not exclusively referring to Firefox when asking my question. > And, as Paul pointed out, any browser manufacturer who is implementing > anything at this stage is running the risk of having to change that > implementation. > > However as I already read in this thread, not surprizingly, it might be > difficult to make changes to an already implemented feature if it means > breaking web sites. > This is precicely what I am concerned about...pressure being built up by > facts being created ahead of time. > > There is no question that we need implementations to show that the spec > works, but there is a time and place for this within W3C process. > Proto-implementations increase the danger of the group being pressured > into decisions that are not in the best interest of a new HTML > specification. > > Therefore I would like to see a bit more restraint or forethought by > browser manufacturers in implementing features. > Equally I would like to see a bit more awareness by the group as to what > is happening and find ways to help make potential proto-implementations > as stable as possible. > > -- Kai > > > One of the unfortunate consequences of including so much in the umbrella term "HTML 5" is that it's difficult to ensure that the appropriate audiences have seen new additions and modifications, before they're implemented. Much of the earlier effort for HTML5 was focused primarily at a subset of the HTML community, which means that the broader community, as a whole, is only now beginning to discover problems. Right now is the time for people to check out the specification, and file bugs when they see problems. As it is, I asked the author of the original article on autobuffer to file a bug, and he didn't. It's not up to this group to scour the web, looking for complaints, and then manage them within the procedures established by this group. Once the issue was brought forward, however, sound arguments were given advocating change, and the issue will, eventually, be filed as a bug. Firefox's implementation of autobuffer wasn't ignored, as the idea of redefining autobuffer seems to have been universally rejected in favor of a new attribute, which would then allow Firefox to support autobuffer, while safely deprecating its use. I would hope that any change to the specification going forward is given the same careful consideration. Such careful consideration, now, will go a long way to avoiding such problems like autobuffer's implementation in the future, when changes become that much more difficult to manage. As for Ian's message about postmessage and localStorage, well, some of this is outside of the scope of this group's effort, because localStorage is not part of the HTML 5 specification. I have also filed a bug asking for the communication section to also be split into a separate specification, which would also move postmessage out of the HTML5 spec. Regardless, if there were valid concerns about Microsoft's implementation of postmessage, these should have been addressed at an earlier time, when the concerns arose. Doing so now gives a strong impression of "tit for tat", because Paul, in his position as co-chair, reminded this group of the risks of early implementation, and Paul works for Microsoft. I'm not a co-chair for this group, but I believe as a member I can express the hope that we would refrain from such actions in the future. Otherwise, respect for this group, its members, and most importantly, its actions will decrease over time--all of which will slow the adoption of HTML5 when it has reached enough maturity to encourage use. As it is, I believe that postmessage has been implemented, as is, by all of the major browsers now (correct me if I'm wrong). Making the change would be that much more difficult, but if there is a valid concern, then the people who are concerned should bring up the issue -- but separate from this issue, which is completely unrelated. Wouldn't you all agree? Shelley > > > >> -----Original Message----- >> From: Ian Hickson [mailto:ian@hixie.ch] >> Sent: Tuesday, January 05, 2010 11:36 PM >> To: Paul Cotton >> Cc: HTMLWG WG >> Subject: RE: Browser implementations, prior to rec, used for >> justification >> >> On Tue, 5 Jan 2010, Paul Cotton wrote: >> > >> > We should all remember that the following text is in the Status >> > section of each HTML5 WD: >> > >> > ==== >> > >> > Implementors should be aware that this specification is not stable. >> > Implementors who are not taking part in the discussions are >> likely to >> > find the specification changing out from under them in incompatible >> > ways. Vendors interested in implementing this specification >> before it >> > eventually reaches the Candidate Recommendation stage >> should join the >> > aforementioned mailing lists and take part in the discussions. >> > >> > The publication of this document by the W3C as a W3C Working Draft >> > does not imply that all of the participants in the W3C HTML working >> > group endorse the contents of the specification. Indeed, for any >> > section of the specification, one can usually find many >> members of the >> > working group or of the W3C as a whole who object strongly to the >> > current text, the existence of the section at all, or the idea that >> > the working group should even spend time discussing the >> concept of that section. >> > >> > ==== >> >> So Microsoft would not object to us changing the behaviour of >> onhashchange="" or the semantics of postMessage() to be >> incompatible with what was implemented in IE8? >> >> -- >> Ian Hickson U+1047E >> )\._.,--....,'``. fL >> http://ln.hixie.ch/ U+263A /, _.. \ >> _\ ;`._ ,. >> Things that are impossible just take longer. >> `._.-(,_..'--(,_..'`-.;.' >> >> > >
Received on Wednesday, 6 January 2010 13:53:14 UTC