Re: Exposing constructors of readonly interfaces to web authors

On Fri, Jun 27, 2014 at 6:39 AM, Domenic Denicola <> wrote:

> From: [] On
> Behalf Of Anne van Kesteren
> > The way Domenic explained this the last time around was that certain
> constructors would accept an ID of sorts as argument that only the UA would
> know about.
> > Given that explanation, I don't see the problem throwing for these
> constructors, just like we throw for
> >> new Navigator
> >> new Window
> To be clear, here is the code you would have to write to explain this in
> JavaScript:
> ```js
> var unguessableSecret = generateSecret();
> class DOMRectReadOnly {
>   constructor(x, y, width, height, secret) {
>     if (secret !== unguessableSecret) {
>       throw new TypeError("Only UAs can construct DOMRectReadOnlys!");
>     }
>     ....
>   }
>   get x() { ... }
>   ...
> }
> ```
> But this is just silly in the case of DOMRectReadOnly and friends. There
> is no magic data, like a browser-internal representation of a window or
> navigator, or of a crypto algorithm (see
> which cannot be used by a user. You are instead just artificially limiting
> users for no good reason, by not giving them the unguessable secret.

The ReadOnly interface names should not be exposed to the user. I think
this is a oversight in the spec and we should put [NoInterfaceObject] on
Instead, the conceptual model is that method that returns a readonly object
does the following:

function getMatrix() {

var retval = { m11: 5, m12: 6, .... };

Object,DefineAttribute(retval, "a", function() { retval.m11;}).

retval.translate = function(...){...};

return retval;


FWIW Cameron told me that an author could create these readonly objects
without having the instantiate a full mutable object.
If there's a DOM method that takes a DOMPointReadOnly, he could write:

Translate({x: 2, y: 5, z:0, w:1});

Maybe he can fill in how that works.

This has no benefits, since it does not enable implementations to do
> anything special with e.g. object layout or tying it to special object
> pointers. It has only downsides.
> From: Dirk Schulze []
> > My concern is that we expose functionality that might not be used by
> authors (creating a readonly object that even the creator can not modify).
> Why is the DOM creating a readonly object that even the DOM cannot modify?
> Or is the DOM somehow able to modify these objects?

The ReadOnly object are indeed designed to be live. For instance, you can
hold on to the matrix of an SVG element [1] and look at its changes.
SVG had big problem with return live, *modifiable* objects and we want to
avoid repeating that mistake.

> I notice that despite there being no setter for x, y, width, and height,
> the spec says things like
> "The x attribute, on setting, must set the x coordinate to the new value."
> Since you can't set a readonly attribute, this is just a bug in the spec
> as it stands.

Can you point to where in the spec that is stated? I can only find the
setter language for DOMPoint which is not read-only.

> The question is whether the intention was to allow the DOM to modify the
> object, in which case they would do so via mutable internal slots that the
> x, y, width, and height public getters return the value of, or whether the
> intention was for these objects to be immutable after creation. (Again, for
> an excellent example of this, see WebCrypto, e.g.
> where the getters are specified.)

I don't see the language in that spec to be all that different.
Do you prefer that we use "reflect" instead of "correspond"?


Received on Saturday, 28 June 2014 04:35:58 UTC