On Wed, Nov 30, 2011 at 6:22 PM, Tab Atkins Jr. <[email protected]> wrote: > On Wed, Nov 30, 2011 at 6:11 PM, Israel Hilerio <[email protected]> wrote: >> On Wednesday, November 30, 2011 3:55 PM, Jonas Sicking wrote: >>> On Wed, Nov 30, 2011 at 3:09 PM, Joshua Bell <[email protected]> wrote: >>> > Should the parameter used in IDBObjectStore.createIndex() and the >>> > property on IDBIndex be spelled "multientry" (as it is in the spec >>> > currently), or "multiEntry" (based on "multi-entry" as the correct English >>> spelling)? >>> > >>> > Has any implementation shipped with the new name yet (vs. the old >>> > "multirow")? Any strong preferences? >>> >>> Much of HTML uses all-lowercase names for similar things, both in markup >>> and in the DOM. >>> >>> I would actually prefer to go the other way and change autoIncrement to >>> autoincrement. >>> >>> / Jonas >>> >> >> We currently have implemented the behavior per spec as "multientry" on our >> Win8 preview build and in follow on IE preview builds. However, we would >> prefer for it to be camelCase since it matches the attributes we've already >> defined in the spec. More important, this seems to match the web platform >> closer. I believe the difference here is that these names are supposed to >> represent properties in a JS object which devs would expect to be camelCase >> like other attributes in the DOM spec. I'm not sure about the markup >> argument. Also, if we end up making autoincrement all lower case, I would >> imagine we would want to be consistent and make keyPath all lower case too. >> This seems different. > > Agreed. While HTML favors all-lowercase, JS and DOM favor camelCase.
While I still prefer multientry (and autoincrement and keypath), I don't care that strongly. So does this mean we should make the name both in the options object and on IDBIndex(Sync) use multiEntry? Also, I noticed that IDBObjectStore(Sync) doesn't expose .autoIncrement. We should expose that right? / Jonas
