On Thu, Jun 11, 2015 at 1:41 PM, Boris Zbarsky <bzbar...@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".


Reply via email to