- 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>
On Fri, 20 Sep 2013 21:42:35 +0200, Dirk Schulze <dschulze@adobe.com> wrote: > 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. OK. 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. https://dvcs.w3.org/hg/csswg/rev/9cfe176393d2 -- Simon Pieters Opera Software
Received on Wednesday, 25 September 2013 13:06:36 UTC