- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 18 Sep 2012 15:18:14 +0200
- To: Glenn Adams <glenn@skynav.com>
- Cc: John Daggett <jdaggett@mozilla.com>, www-style list <www-style@w3.org>
On Tue, Sep 18, 2012 at 3:05 PM, Glenn Adams <glenn@skynav.com> wrote: > On Tue, Sep 18, 2012 at 8:12 PM, John Daggett <jdaggett@mozilla.com> wrote: >> This seems okay to some degree, I just wonder if it's not a little bit of >> overkill. Why the need for getter/setter *and* >> getDescriptor/setDescriptor? >> That almost seems java-esque. > > It depends on whether we want to only support the camel cased domain of > descriptor names, call it D(CC), or we want to support both D(CC) and the > original hyphenated domain (as found in stylesheet) of descriptor names, > call it D(HY). If we want both, then we need to have different flavors of > getters/setters which make clear which domain they operate with. If we want > only D(CC), then we won't need both. > > E.g., which of the following do you wish to work? > > (1) descriptors['unicode-range'] > (2) descriptors.unicodeRange > (3) both (1) and (2) (2) is a necessity - it's what people are used to when working with the 'style' DOM property, and it's quite natural to want to keep using that. I have no strong opinion on whether we want (3) or not. It seems convenient to authors to support both of them. I agree with Boris that this is orthogonal to whether we have a named getter/setter (the get() and set() functions in your example) or the getDescriptor/setDescriptor functions. These all seem unnecessary. WebIDL already has the point that languages which don't support getters/setters must expose the functionality in some standard way. We should consider the getProperty/setProperty pair from CSSStyleDeclaration as a legacy mistake. ~TJ
Received on Tuesday, 18 September 2012 13:19:03 UTC