- From: Dirk Schulze <dschulze@adobe.com>
- Date: Tue, 24 Sep 2013 23:15:41 -0700
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- CC: "www-style@w3.org" <www-style@w3.org>
On Sep 25, 2013, at 7:34 AM, Boris Zbarsky <bzbarsky@MIT.EDU> wrote: > On 9/25/13 1:27 AM, Dirk Schulze wrote: >> I don't think so. We have this behavior in SVG for years. > > I was describing it from the point of view of a JS author. > > Immutable things in JS work in a certain way (either an accessor with no > setter, or a value prop marked readonly). We should aim to have the > APIs we design work that same way. > > Obviously the SVG DOM API looks nothing like what JS APIs tend to look > like. But that's not a reason to be following the historical SVG > pattern here, quite the contrary. Do not disagree that we don't need to follow the pattern of SVG. Stating that it is not possible is something different though. And as long as SVG DOM exists, it must still be considered. However, I am fine with removing this sentence and leave it to SVG DOM to define it. > >> You can also describe what happens if it is not mutable and the author tries to modify the object. > > My point is that the thing that _should_ happen in this case to be > consistent with how normal JS objects work is not describable in prose, > because it needs to happen before you ever get to the prose. > >> That is what I did for DOMMatrix [1]. > > Right, that throws on sets in non-strict mode. Which is not how normal > JS objects behave on sets of immutable properties. > >> So the both WGs should work together for a unified API. > > I strongly suggest doing API design like this in public-script-coord, > with input from people familiar with JS APIs, not in working groups that > have no particular expertise designing such APIs…. No objection to that. Greetings, Dirk > > -Boris
Received on Wednesday, 25 September 2013 06:16:07 UTC