Re: Browser implementations, prior to rec, used for justification

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