Re: Figuring out easier readonly interfaces

On Oct 17, 2013, at 12:23 AM, Simon Pieters <simonp@opera.com> wrote:

> On Wed, 16 Oct 2013 22:13:28 +0200, Dirk Schulze <dschulze@adobe.com>  
> wrote:
> 
>> 
>> On Oct 14, 2013, at 10:01 PM, Robert O'Callahan <robert@ocallahan.org>  
>> wrote:
>> 
>>> How about "DOMRectRead"? Is that acceptable to everyone?
>> 
>> If others accept this compromise it is fine with me.
> 
> My knee-jerk reaction is: it looks silly, and the argument about the  
> semantics of "only" is also silly.

I would not say silly. But I agree that Readonly (ReadOnly) is more descriptive and that I do not think it is misleading. Given that the interface itself is more important than its name, I would like to reach a consensus on the least important thing :).

> 
> Readonly doesn't mean immutable or constant.
> 
> For example, <input readonly> means that the user can only read the value,  
> but the value can still be mutated by script or by the UA.
> 
> Node#firstChild is a readonly attribute (WebIDL term), which means that a  
> script can't change it by setting Node#firstChild, but the value can  
> change by e.g. invoking Node#insertBefore() or by the UA changing the DOM  
> (e.g. parsing).
> 
> SVGRect has a "read only" flag, which means that setting its attributes  
> throws, but the values can still be changed. SVGAnimatedRect#animVal  
> changes over time while the animation is running, but the SVGRect is "read  
> only".

SVGRect is going to be replaces by DOMRect (and its readonly version). The current definition is not very WebIDL friendly and implementations differ widely, especially when it comes to lists (SVGPointList, SVGTransformList and so on). That is one of the reason I suggested to have the geometry interfaces in one spec so that it is more clear that these APIs are going to be used by more than just CSS.

Greetings,
Dirk

> 
> -- 
> Simon Pieters
> Opera Software
> 

Received on Thursday, 17 October 2013 07:11:06 UTC