- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 11 Jun 2015 14:02:44 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: public-webapps <public-webapps@w3.org>
On Thu, Jun 11, 2015 at 1:41 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > On 6/11/15 4:32 PM, Dimitri Glazkov wrote: >> I noticed that the CSS Color Module Level 4 actually does this, and it >> seems pretty nice: >> http://dev.w3.org/csswg/css-color/#dom-rgbcolor-rgbcolorcolor > > I should note that the ES code there produces semantics that don't match the > IDL in this spec (or is complete nonsense, depending on how literally you > choose to read it). Yes, the code currently there is... loose. There's a lot of problems trying to map IDL directly into ES without a lot of boilerplate. > So there are basically at least two problems here: > > 1) You have to clearly delineate when you're working with JS values and > when you're working with IDL values, to the extent that these are not the > same thing. > > 2) You have to clearly delineate which bits of JS run in the page global > and which bits run in some other clean global and which bits run in the page > global but have access to some clean intrinsics somehow. > > I would actually prefer some sort of pseudocode that is _not_ JS-looking, > just so people don't accidentally screw this up. I actually rather like using JS code for these; it's familiar and easy to read. But yeah, Domenic outlines some of the things we'd have to change before this was actually useful. I wrote Color the way I did because writing math in prose is *incredibly* awkward, but writing it in ES-ese is *even more incredibly awkward*. So for now, I opted for the insufficient third alternative of "JS, if we handwave and pretend all the obvious problems don't occur". ~TJ
Received on Thursday, 11 June 2015 21:03:33 UTC