search

w3c / input-events

Input Events
https://w3c.github.io/input-events/
Other
24 stars 16 forks source link

Invalid Web IDL syntax #2

Closed domenic closed 8 years ago

domenic commented 8 years ago

StaticRange[] is not valid Web IDL syntax. Probably you want sequence<StaticRange>.

johanneswilm commented 8 years ago

@domenic: Why would you think it should be a sequence rather than an Array?

domenic commented 8 years ago

sequence<> is how you express a JavaScript array in Web IDL. The [] syntax is meaningless and does not denote an array.

johanneswilm commented 8 years ago

@domenic Ok, I must have been confused by this text: https://www.w3.org/TR/WebIDL/#idl-array

Is there some better place where to find the correct syntax for this?

domenic commented 8 years ago

Ah, you have to remember that "/TR/ stands for trash" and not look at anything there. (That is an obsolete spec that doesn't represent implementer consensus.) https://heycam.github.io/webidl/#idl-sequence and https://heycam.github.io/webidl/#es-sequence is what you're looking for.

johanneswilm commented 8 years ago

@domenic So you are saying I should follow the editor's draft rather than the candidate recommendation?

domenic commented 8 years ago

Yeah, exactly, editor's drafts are what are implemented and agreed upon.

domenic commented 8 years ago

More generally, you should follow specs from 2016 instead of specs from 2012.

johanneswilm commented 8 years ago

Ok, that seems slightly contrary to the logic I have heard so far. If they represent consensus, why are they not advanced to a more official status than editor's draft?

domenic commented 8 years ago

That's a long and involved question involving the conflicting interests of implementers, which need specs that are kept updated in response to bug reports etc., and patent policies, which need stable "dead standards" frozen years ago in order to get IPR commitments.

Suffice to say, a spec involving [] syntax is not implementable, whereas one involving sequence<> is. If your goal is to get implementations, then sequence<> is the way to go.

johanneswilm commented 8 years ago

@domenic ok, I'll take you word for it in this case, but I really think this should be cleaned up on the part of those defining the webidl standard in some way -- if nothing else by changing the w3c procedures for this. It does not seem right to have a FPWD based upon editor's draft of other specs when in general one isn't supposed to base anything on editor's drafts.

@chaals Not sure if this si something you guys can do something with, but these types of complications sure make spec writing more complex than what it should need to be.

domenic commented 8 years ago

Yeah, I agree, this is one of the biggest problems with the W3C Process :(.

In practice you get an ecosystem of editor's drafts referencing other editor's drafts (and living standards), which implementers use to implement. Then after some time W3C staff come along to advance something down a recommendation track, and in doing so change all the normative references to be to outdated /TR/ snapshots, often making the specs incoherent, but that's OK since implementers don't look at those. In my experience the best way to deal with this is for the editors to focus on the editor's drafts (i.e. the ecosystem of what's implemented) and leave the W3C staff to focus on the ecosystem of obsolete things that follow pubrules. That's what's happened with Web IDL, certainly.

johanneswilm commented 8 years ago

@domenic So you are saying that as we try to do FPWD, I should now first base this on the editor's draft, and then it's shifted back to the /TR/ version before we publish the FPWD by W3C staff? Can't we just wait with changing anything before the FPWD has been published?

domenic commented 8 years ago

I'm saying you should focus on producing an implementable spec above all. If your goal is to influence what is shipped in browsers, all this process stuff is a distraction.

johanneswilm commented 8 years ago

@domenic Ok, but right now the question is the FPWD, which it is my understanding you are voting against approving. And as long as there is no consensus on approving that, we'll be caught in this situation, right?

Simultaneously, as I understand it, we can do all the changes you are proposing to the editor's draft without holding up the FPWD version, which is going its own way. Incorrect?

domenic commented 8 years ago

Yeah, that's fair. Perhaps I should not be making a process-based objection. I was mostly concerned with the fact that someone thought this was ready for wide review, but it had some fairly fundamental bugs. I'll go withdraw my -1 since the process stuff is indeed unimportant; I trust you'll work toward addressing the issues regardless.

johanneswilm commented 8 years ago

@domenic: OK, sounds good. I'll work through the issues anyway. Getting implementations is top priority, but additionally it would be good to get to the FPWD stage.

annevk commented 8 years ago

FPWD or not does not really block progress. Implementers will implement. A broken spec however might not have trouble getting to REC, but is less likely to ever ship.