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:

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.

dev-platform mailing list

Reply via email to