Given an object literal, or jQuery(html, attributes) object, does any specification state that reserved words, or future reserved words MUST be quoted?

Or, can, for example, class be set as a property name of an object without using quotes to surround the property name, without the practice being contrary to a specification concerning identifiers, property names, or use of reserved words?

Seeking a conclusive answer as to this question to avoid confusion.

let objLit = {
  class: 123,
  var: "abc",
  let: 456,
  const: "def",
  import: 789
}

console.dir(objLit);

jQuery("<div>012</div>", {
  class: "ghi"
})
.appendTo("body");

<script src=".1.1/jquery.min.js">
</script>

Given an object literal, or jQuery(html, attributes) object, does any specification state that reserved words, or future reserved words MUST be quoted?

Or, can, for example, class be set as a property name of an object without using quotes to surround the property name, without the practice being contrary to a specification concerning identifiers, property names, or use of reserved words?

Seeking a conclusive answer as to this question to avoid confusion.

let objLit = {
  class: 123,
  var: "abc",
  let: 456,
  const: "def",
  import: 789
}

console.dir(objLit);

jQuery("<div>012</div>", {
  class: "ghi"
})
.appendTo("body");

<script src="https://ajax.googleapis./ajax/libs/jquery/2.1.1/jquery.min.js">
</script>

Related:

• What is the difference between object keys with quotes and without quotes?

• Comments on this answer

Specification

• 7.6 Identifier Names and Identifiers:

Identifier Names are tokens that are interpreted according to the grammar given in the “Identifiers” section of chapter 5 of the Unicode standard, with some small modifications.
An Identifier is an IdentifierName that is not a ReservedWord

• javascript
• language-lawyer
• ecmascript-5

• @AndrewLi - that answer says "NOT be used as identifier names" and the spec says PropertyNames are "IdentifierNames", so it's quite confusing. Identifiers are not very well described in the ES5 spec, but it does say things like "property names bee visible identifiers bindings" and "all the properties of Object.prototype are visible as identifiers within that scope" so it's hard to tell what's what ? – adeneo Commented Oct 24, 2016 at 1:18
• @RobG - If a property name is an "identifier", it clearly can't be a reserved keyword, yet this answer says otherwise, and claims a PropertyName is not an identifier – adeneo Commented Oct 24, 2016 at 1:20
• 1 @user2357112 MDN is not a specification, ECMAScript® Language Specification includes the name "Specification" in the title. Seeking clarification concerning the Question from credible sources which pose documentation as to how the language is intended to be used. Or, from an author, or even user of the language who is familiar with the language at the core level. – guest271314 Commented Oct 24, 2016 at 1:58
• 2 @guest271314 - assuming he's correct, it does. The real question for me isn't if it works or not, it seems all interpreters today are smart enough to understand that a reserved keyword used in curlybraces doesn't conflict, but outside curlybraces it's always a risk. The spec says propertyName of an object can be a string, number or identifierName, but passing in an array, object, or anything else as a key, is just fine as well, even if it's not in the spec. Also, ES6 classes seem to have names that are "propertyName", and should accept anything as well, but you really can't do class class. – adeneo Commented Oct 24, 2016 at 11:27
• 2 @adeneo Note, it is in (6.0) the spec: PropertyName may be a ComputedPropertyName, and a ComputedPropertyName can be an AssignmentExpression thus allowing many things as keys. Also, on the spec, it mentions the syntax is class BindingIdentifier, where BindingIdentifier is an Identifier thus not a ReservedWord. – Andrew Li Commented Oct 24, 2016 at 13:17

3 Answers 3

ECMAScript 5+

No, quotes were not needed since ECMAScript 5. Here's why:

As mentioned in your post, from the ECMAScript® 5.1 Language Specification:

7.6 Identifier Names and Identifiers

Identifier Names are tokens that are interpreted according to the grammar given in the “Identifiers” section of chapter 5 of the Unicode standard, with some small modifications. An Identifier is an IdentifierName that is not a ReservedWord (see 7.6.1).

[...]

Syntax

Identifier ::
  IdentifierName but not ReservedWord

By specification, a ReservedWord is:

7.6.1 Reserved Words

A reserved word is an IdentifierName that cannot be used as an Identifier.

Syntax

ReservedWord :: 
  Keyword
  FutureReservedWord
  NullLiteral
  BooleanLiteral

This includes keywords, future keywords, null, and boolean literals. The full list is as follows:

7.6.1.1 Keywords

break    do       instanceof typeof
case     else     new        var
catch    finally  return     void
continue for      switch     while
debugger function this       with
default  if       throw 
delete   in       try   

7.6.1.2 Future Reserved Words

class enum   extends super
const export import

7.8.1 Null Literals

null

7.8.2 Boolean Literals

true
false

The above (Section 7.6) implies that IdentifierNames can be ReservedWords, and from the specification for object initializers:

11.1.5 Object Initialiser

[...]

Syntax

ObjectLiteral :
  { }
  { PropertyNameAndValueList }
  { PropertyNameAndValueList , }

Where PropertyName is, by specification:

PropertyName :
  IdentifierName
  StringLiteral
  NumericLiteral

As you can see, a PropertyName may be an IdentifierName, thus allowing ReservedWords to be PropertyNames. That conclusively tells us that, by specification, it is allowed to have ReservedWords such as class and var as PropertyNames unquoted just like string literals or numeric literals.

ECMAScript <5

To go more in depth as to why this wasn't allowed in previous versions before ES5, you have to look at how PropertyName was defined. Per the ECMAScript® 3 Language Specification:

PropertyName :
  Identifier
  StringLiteral
  NumericLiteral

As you can see, PropertyName was an Identifer - not an IdentifierName, thus leading to the inability for ReservedWords as PropertyNames.

Given an object literal, or jQuery (html, attributes) object, does any specification state that reserved words, or future reserved words MUST be quoted?

No (starting with ES5).

The definition of property in the spec is that it is any identifier name. class is a perfectly good identifier name.

As others have pointed out in the ments, according to the spec, the property name in an object literal may be an (unquoted) IdentifierName (in addition to being a string etc.). IdentifierName is, for all practical purposes, any sequence of Unicode "letters", as given in section 7.6.

Note that the syntax error generated by

const {class} = obj;

is not an exception. That's not an object literal, which is what the question is about; it's an assignment (or the destructuring kind), which attempts to assign a variable class. Of course you can't, never have been able to, and never will be able to have variables which are named with reserved words.

See also this blog post, which although not authoritative is a reliable, high-quality source of information about all things ES5/6/7.

Note that in ES3, the definition of PropertyName was Identifier, not IdentifierName as in ES5. That prevented using properties such as class, since class is not an identifier. It was this change that permitted the use of unquoted reserved words as properties in object literals (as well as in dot notation).

With regard to "jQuery objects", a "jQuery object" is just a regular old JS object. Do you mean the DOM elements held by jQuery objects? They are a kind of hybrid of native objects and JS objects. As JS objects, they can have properties. However, they cannot be written in object literal form, so the question does not really apply to them. (As native (DOM) objects, they can have attributes, the latter case not being covered by the JS spec.)

This answer cannot pete with those already given but I'd love to chime in nonetheless.

In my code I prefer to ALWAYS quote keys, for example:

var o;

o = {
  "label": "Hello",
  "index": 3
};

This way, the problem of strange names or reserved keywords doesn't even arise. Furthermore, all object literals are written in a style that is very near to valid JSON, as an added bonus copy+paste into a separate JSON file (and vice-versa) can be done very quickly.

Today, I consider this a must-have style for clean code.