- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Thu, 27 May 2010 16:23:28 +0200
- To: "Tran, Dzung D" <dzung.d.tran@intel.com>
- Cc: Max Froumentin <maxfro@opera.com>, public-device-apis <public-device-apis@w3.org>
Le jeudi 27 mai 2010 à 06:58 -0700, Tran, Dzung D a écrit : > > * although the syntax of arrays is not formally defined in WebIDL yet, I > > believe they are supposed to be written > > attribute DOMString[] foo; > > rather than > > attribute DOMString foo[]; > > (which is what the spec currently uses) > > Will fix. Is that what the WebIDL specify today?> As I alluded to, the WebIDL spec doesn't specify it formally yet; but from what I've read of the discussions around it, and from the little the spec has currently, I think it's safe to assume that this is the intended syntax. > > * Error.PERMISSION_DENIED has a numeric value of 0 — isn't it a bit > > dangerous to use 0 as a value since it is equivalent to false? The > > PositionError interface in Geolocation only uses strictly positive > > Values > > If this is the case then there are several place where numeric values starting at > 0 will have to start at 1. Is this what this WG agree to do? I looked at the other cases in the spec, but from what I could see the semantics of the other constants with value 0 were compatible with the semantics of false; for instance: > const unsigned short TYPE_UNKNOWN = 0; TYPE_UNKNOWN seems aligned with false. PERMISSION_DENIED doesn't seem to fit that pattern since it's one of the error codes among other error codes. > > * StorageUnitAttributes.isReadWrite is a boolean - it means it doesn't > > allow to distinguish read-only from write-only storages? (actually, the > > description seems to imply that the attribute really means > > "isNotReadyOnly", but even that is not entirely clear) > > Ok, maybe I will change this to "isWritable"? What do you think? That works for me, although maybe what we need is a more detailed field that allows to express readable/writable. > > * KeyboardAttributes.type and KeyboardAttributes.isHardware don't seem > > to be orthogonal; a virtual keyword can typically present a full > > keyboard or just a keypad > > Yes, a virtual keyboard (software keyboard) can be a full keyboard or keypad > and the values return would be KeyboardAttributes.type = TYPE_KEYBOARD and > KeyboardAttributes.isHardware = false. Is there some thing wrong with this? OK; I find it a bit awkward, but I can certainly live with it. Dom
Received on Thursday, 27 May 2010 14:23:41 UTC