- From: Marcos Caceres <w3c@marcosc.com>
- Date: Wed, 20 Mar 2013 12:28:19 -0400
- To: Boris Zbarsky <bzbarsky@mit.edu>, Yehuda Katz <wycats@gmail.com>
- Cc: Anne van Kesteren <annevk@annevk.nl>, public-script-coord@w3.org
Cc'ing Yehuda, as he was the one that brought this up during the TAG meeting this week. He can articulate his concerns and the confusion better… On Wednesday, 20 March 2013 at 12:13, Boris Zbarsky wrote: > On 3/20/13 9:50 AM, Marcos Caceres wrote: > > However, the octet behavior could be redefined in prose if need be. > > > Please let's not do that. The point of having a single IDL spec for > stuff like this is to avoid every single spec that wants the behavior > having to (probably buggily) define it in prose. I agree - and this is the value of WebIDL. What I meant was that, if we do away with the actual types, we could still leave the algorithms in the spec (or somewhere) for editors to use. What I am trying to understand is what types are being used by authors today and why? For instance, why does the XHR spec really need to use an "unsigned short" for a set of constants that go from 0-4 (instead of an octet)? And so on. > > I think the are potentially helpful, but you could have them as generic prose algorithms and not part of WebIDL itself. > > I would be fine with generic prose algorithms in a centralized location, > so they're only done once. But what's the benefit of that over having > them just available in IDL? I also don't mind where these things end up, just about their utility and availability. The argument (complaint?) being made, as I understand it, is that the current numeric types in WebIDL don't have equivalents in ES itself (and apparently, this leads to confusion in certain cases - I personally don't get confused, but I can see why other people might).
Received on Wednesday, 20 March 2013 16:28:49 UTC