- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Fri, 15 Jul 2016 09:39:36 -0400
- To: public-script-coord@w3.org
Dominique, this tool is awesome. :)
On 7/15/16 4:00 AM, Dominique Hazael-Massieux wrote:
> A question that emerged when we built the analyzer for the first point
> was which WebIDL names are "exported" by a spec
All the names of "named definitions". See first paragraph of
<http://heycam.github.io/webidl/#idl-names>.
> which leads to the result that the very generic "JSON"
> name is defined (differently!) as a typedef in two different specs.
Then one of those specs needs to change. Luckily, as soon as a UA tries
to implement both its IDL parser will flag the problem (see below). And
since typedef names are not web-exposed changing things doesn't involve
any compat problems.
> I think it would probably make sense for the WebIDL spec itself to be
> more explicit about the notion of exported names, if only to make it
> clearer to spec editors for which name they need to avoid name clashes.
The spec is pretty clear on this.
http://heycam.github.io/webidl/#idl-names says, after defining what the
names of things are:
Within the set of IDL fragments that a given implementation
supports, the identifier of every interface, dictionary,
enumeration, callback function and typedef MUST NOT be the
same as the identifier of any other interface, dictionary,
enumeration, callback function or typedef.
Having the tool you describe, which can surface such problems before UAs
run into them while implementing, sounds pretty nice. :)
> For an example of the reports the tool can produce, see one instance
> produced recently:
> https://github.com/tidoust/reffy/wiki/Report-per-anomaly-(20160711)
> (there are known false positives)
It would be awesome if this report included the information about which
WebIDL content was invalid, exactly, so issues can be raised on the
relevant specs.
-Boris
Received on Friday, 15 July 2016 13:40:07 UTC