W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

Re: Publishing a Last Call Working Draft of Web IDL on June 30

From: Arthur Barstow <art.barstow@nokia.com>
Date: Tue, 21 Jun 2011 07:03:39 -0400
Message-ID: <4E007A8B.5060409@nokia.com>
To: Cameron McCormack <cam@mcc.id.au>, public-webapps <public-webapps@w3.org>, public-script-coord <public-script-coord@w3.org>
Hi Cam - thanks very much for this update and the good progress!

All - please help Cam come to closure on the bugs listed below.

Cam mentioned off-list that closing these bugs by June 30 should be 
doable so let's please work toward that deadline.

If any new bugs are raised between now and the time the LC is published, 
unless a bug is a showstopper for LC, let's plan to address those new 
bugs during the LC comment period.

-Art Barstow

On Jun/21/2011 12:11 AM, ext Cameron McCormack wrote:
> Arthur Barstow:
>> >  * June 20 - start a 1-week Call for Consensus (CfC) to publish a LCWD
> That is today, and there are still some open bugs on the spec.  Here is
> a status update.
>
> Features I have deferred until a second version/revision of the
> specification I’ve marked as Severity:Enhancement in Bugzilla:
> http://www.w3.org/Bugs/Public/buglist.cgi?quicksearch=comp%3Awebidl+sev%3Aenh
>
> For the remaining open bugs:
> http://www.w3.org/Bugs/Public/buglist.cgi?quicksearch=comp%3Awebidl+-sev%3Aenh
>
> * Bug 8241 - Named properties on Window
>    This was resolved, but reopened.  Discussion is ongoing, and this
>    might well need further changes to the spec.
>
> * Bug 10623 - Simplify Web IDL exceptions
>    This was resolved, and also reopened.  It seems to need further
>    discussion on whether everyone agrees this is the desired way forward
>    for DOMExceptions across web platform specifications.
>
> * Bug 11267 - Add a [NonConfigurable] extended attribute
>    This may or may not be worth addressing in Web IDL itself.  If is, it
>    shouldn’t be much work.  Discussion is ongoing.
>
> * Bug 12320 - ECMAScript binding forbids using ECMAScript to implement
>                many interfaces
>    This hasn’t been started.  It isn’t a major change in requirements,
>    more of an editorial change.  But it still needs a bit of thought on
>    my part.
>
> * Bug 12458 - Interface objects should be Functions
>    This has open discussion on the bug, but not clear resolution yet.
>    I’ve asked for data around the compatibility constraints so we can
>    decide how to move forward.
>
> * Bug 12635 - calling Functions corresponding to IDL
>                operations/attributes on unexpected objects should throw
>    This is pretty much done.  It is dependent on bug 12320.
>
> * Bug 12798 - Default to [TreatNullAs=EmptyString]
>    This is a high profile issue, and it has had a bunch of discussion
>    since I resolved the bug.  I reverted the change due to that
>    discussion, although there have been subsequent calls for the change
>    to be reapplied.  The bug awaits some concrete data on site breakage
>    that would need the patch to be reapplied to resolve.
>
> * Bug 12845 - Disallow shaing attributes
>    There appear to be some philisophical differences between commentors
>    in the bug about whether shadowing should be allowed or not at all.
>    The smaller change is to continue allowing it, since at least HTML
>    does shadow some attributes.  I’d rather leave this bug open for a
>    little longer.  If there aren’t any further arguments, I’d say to
>    close this bug without disallowing shadowing, as the simpler way
>    forward.
>
> * Bug 12979 - Set [[Enumerable]] in §4.6.3 and §4.6.4
>    This is dependent on resolving the issue raised in this thread:
>    http://www.w3.org/mid/20110618052618.GA30408@wok.mcc.id.au
>
>    In that mail I propose a solution, but wanted to hear from people as
>    to whether that would unduly risk website compatibility before making
>    the change.
>
> I think the open bugs listed above could do with more time to allow
> discussions to come to a conclusion.
>
> There are a few of additional Editorial Notes left in the specification
> itself, which are items that can be discussed in LC.  They might inform
> a list of At Risk features, too.
>
> The spec probably needs a bit of an editorial brush run through it, too,
> but I don’t think that needs to hold up LC.
>
> -- Cameron McCormack ≝ http://mcc.id.au/
Received on Tuesday, 21 June 2011 11:04:26 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:45 GMT