W3C home > Mailing lists > Public > public-geolocation@w3.org > April 2010

Re: Orientation event draft

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Thu, 22 Apr 2010 13:22:38 +0300
Message-ID: <4BD0236E.4020507@helsinki.fi>
To: Andrei Popescu <andreip@google.com>
CC: Steve Block <steveblock@google.com>, public-geolocation <public-geolocation@w3.org>, dougt@dougt.org
On 4/22/10 1:16 PM, Olli Pettay wrote:
> On 4/22/10 12:53 PM, Andrei Popescu wrote:
>> On Thu, Apr 22, 2010 at 10:41 AM, Olli Pettay<Olli.Pettay@helsinki.fi>
>> wrote:
>>> On 4/21/10 7:32 PM, Steve Block wrote:
>>>>> "Implementations that are unable to provide all three angles must
>>>>> set the values of the unknown angles to null" That is strange. The
>>>>> type of the property is double. That kind of properties don't
>>>>> usually give suddenly non-numeric values.
>>>> There is precedent for this in the Geolocation spec.
>>> Sounds like a bug in Geolocation draft, IMO
>>> If the value isn't available, implementation could throw something
>> But then wouldn't you have to access all these properties from try /
>> catch blocks? I don't think that's ideal and it's just more convenient
>> to let them be null if they aren't available.
> And then all the callers need to check whether the returned value is
> null. And if (thevalue) isn't enough, because the value can be 0.
> I don't see how it is really more convenient to make it null in some
> cases. And making a double attribute null isn't something used in DOM
> Core for example.
> (Not all the things WebIDL specifies should be used, like PutForwards)
> -Olli

But I could still add that I don't care too much about this issue.
It is just very ugly, and API wise rather inconsistent if some
double attributes can suddenly become null.

Received on Thursday, 22 April 2010 10:23:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:50:59 UTC