This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In the IDB spec the definition of a valid key path is built around: A DOMString containing a JavaScript identifier [ECMA-262]. ... plus dotted combinations of identifiers and arrays thereof. ECMA-262 gives: Identifier :: IdentifierName but not ReservedWord IdentifierName :: IdentifierStart IdentifierName IdentifierPart (etc) And defines ReservedWord as: ReservedWord :: Keyword FutureReservedWord NullLiteral BooleanLiteral Keyword :: one of break do instanceof typeof case else new var ... (etc) This would appear to preclude key paths such as: "foo.delete.bar" "my.public.data" "response.true.details" "options.null" Neither FF nor Chrome appear to reject such key paths. I suggest the IDB spec be updated to refer specifically to the IdentifierName production in ECMA-262.
Opera also allows such keypaths. Looking at the implementation it calls the IdentifierName checker from our ecmascript module. Guess that's what everyone else did as well :P I proactively changed keypath tests to also test that: http://w3c-test.org/webapps/IndexedDB/tests/submissions/Opera/keypath.htm
https://dvcs.w3.org/hg/IndexedDB/rev/c6b12332f5ae