On 10/14/16 8:30 PM, Tantek Çelik wrote:
I searched those 23 open issues for "mixin" and found no open issue
with "mixin" in the title.
WebIDL has two bug tracking systems at the moment. People started using
Github for some of the new stuff, but a lot of the old issues are still
in the W3C Bugzilla. This one is at
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26452
(This also means you didn't see all the open issues, for what it's worth).
I found 3 open issues with "interface" in the name, and from my naive
quick read, none of them appear to be *this* issue, so this should be
filed as well, again, for specific referencing in our FO.
This is the same issue. Right now mixins and interfaces are conflated
in the syntax so a thing can be one or the other (or both at once!)
depending on non-local information. We want to stop doing that.
There are other probably-unstable features (e.g. serializers, which no one
implements in the specced form and no one is likely to) in the PR draft.
None of the 23 issues mention "serializer" in their names.
There are four serializer issues filed in the W3C Bugzilla, which you
can see at
https://www.w3.org/Bugs/Public/buglist.cgi?component=WebIDL&list_id=65481&query_format=advanced&resolution=---&short_desc=serializer&short_desc_type=allwordssubstr
and one of those mentions this concern on my part
(<https://www.w3.org/Bugs/Public/show_bug.cgi?id=20361#c4>) as part of
the general discussion about the grammar in the spec being wrong.
I guess we could split out the explicit "this is overengineered and
should be simplified" concern into a separate issue. I've filed
https://github.com/heycam/webidl/issues/188
If you can find an email permalink for that, we can (and should) cite
that as well (for 3.)
All the Bugzilla stuff is mirrored to the list.
https://lists.w3.org/Archives/Public/public-script-coord/2015JanMar/0213.html
is the mail corresponding to the above Bugzilla comment.
> W3C notional (external?) publication scheduling pressure is not your
burden to bear per se.
While true, the fact that it's been years without much meaningful
progress on this draft is rather poor, and is my burden to bear. :(
Note that Tobie has recently started editing and so I have high hopes of
there being more progress in the next few months.
Continuing with that aforementioned implementation report:
https://www.w3.org/WebPlatform/WG/implementations/webidl-1/report/all.html
For extra fun, these aren't part of web platform tests, apparently? :(
5. There are NUMEROUS (more than I'm going to bother copy/pasting
here) tests in the implementation report that have fewer than 2
implementations (zero or one "PASS")
Some of these tests are testing what the spec says, not what everyone
has agreed the spec _should_ say and what UAs have implemented. An
example is the "Event constructor returns an object that is instanceof
Event" test in
https://www.w3.org/WebPlatform/WG/implementations/webidl-1/tests/Constructor-001.html
is based on what the spec says right now, but
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22808 covers changing the
behavior, and see also https://github.com/heycam/webidl/issues/62 (which
also mentions the fact that Web IDL needs to actually be updated to play
nice with ES 2015, which is part of the issue here).
Some of the tests are just buggy. For example,
https://www.w3.org/WebPlatform/WG/implementations/webidl-1/tests/ByteString-001.html
does:
assert_throws(new TypeError(),
client.setRequestHeader("X-ByteString", input));
which is failed by all browsers... but that's because it should be:
assert_throws(new TypeError(),
function() {
client.setRequestHeader("X-ByteString", input)
});
to actually be testing the thing it wants to be testing.
None of which invalidates your point, of course. ;) But someone really
needs to review these tests. :(
That should be enough material for a pretty solid FO.
The real question is whether we want to object or not. Realistically, I
think there are three possible general opinions we can have on the
matter as an organization:
1) We way want a REC, soonish (eg. for the patent protections), and we
might want it to actually be somewhat meaningful and not sucky. In that
case we should FO the move to PR and actually put resources into fixing
the suck, either in the main spec (and letting the L1 editors deal with
merges) or in parallel in the main spec and L1 (less good, imo).
2) We may want a REC, soonish, but not care about its quality. In that
case, we should just stay quiet.
3) We may want a REC, care about its quality, but not about the
urgency. In that case, we should FO but not do a firedrill around
addressing the issues.
Left to my own devices, I would probably go with #2 or #3... but that's
because I don't have the time to do #1. #1 would be better as a general
outcome.
-Boris
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
