W3C home > Mailing lists > Public > www-style@w3.org > September 2013

Re: [cssom-view][matrix] Unrestricted doubles for DOMMatrix, DOMPoint, DOMQuad (was Re: [cssom-view] More getBoxQuads/convert*FromNode issues)

From: Simon Pieters <simonp@opera.com>
Date: Wed, 25 Sep 2013 15:05:54 +0200
To: "Dirk Schulze" <dschulze@adobe.com>
Cc: "robert@ocallahan.org" <robert@ocallahan.org>, www-style <www-style@w3.org>
Message-ID: <op.w3yxb4jlidj3kv@simons-macbook-pro.local>
On Fri, 20 Sep 2013 21:42:35 +0200, Dirk Schulze <dschulze@adobe.com>  

> This is merging a discussion about the same topic on a different thread.
> On Sep 20, 2013, at 11:58 AM, Simon Pieters <simonp@opera.com> wrote:
>> On Fri, 20 Sep 2013 08:54:33 +0200, Dirk Schulze <dschulze@adobe.com>
>> wrote:
>>>> Smaller issues: Should DOMPoint/DOMRect/DOMQuad  
>>>> constructors/attributes
>>>> allow unrestricted doubles? I think probably not.
>>> To support unrestricted double was an explicit request for DOMMatrix
>>> from some implementers.
>> Can you elaborate on this? Why was it requested?
> The argumentation on public-fx for Matrix at the time was that you can  
> get NaN values for the matrix items anyway by certain operations. The  
> solution was to avoid operations that could result in NaN, but this is  
> neither what browsers do, nor was their positive feedback. You would  
> need to fail silently or throw an exception. Both was not acceptable for  
> people on the discussion.
> To DOMPoint. You can have transformations on DOMPoint. If DOMMatrix has  
> a NaN item, then the DOMPoint as a result of a transformation is not  
> valid either. So even if you do not permit unrestricted values, you may  
> not be able to guarantee that generated DOMPoints are valid. Unless you  
> do one of the silent fails or throw exceptions.


I've made DOMRect use unrestricted double also since DOMQuad#bounds is a  
DOMRect, so it needs to be able to represent the same things as DOMPoint.


Simon Pieters
Opera Software
Received on Wednesday, 25 September 2013 13:06:36 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:32 UTC