Reserve hyphenated or $-including properties for customization

[brettz9]

For the sake of enhancing individual element instances (or their prototypes), having the peace of mind to add a method (or other property) via JS without fear of conflict would be helpful, even if it doesn't meet all use cases of customized built-in elements. It would also avoid the ugliness of adding symbols (or worse, maps) during attachment and method invocation (though admittedly hyphens are still somewhat awkward for JS given the need for calling methods like elem['my-method']()). An alternative would be reserving $ so elem.$myMethod() would not only work without the need for brackets, but would also clearly signal a non-standard method/property.

While this might not deal with custom elements per se, since the spec is reserving the hyphen for elements, and since the suggestion relates to one of the use cases for customized built-in elements (being able to enhance them as is, including intuitively using this scoped to the element along with convenient access through that this to other such custom methods), I thought it might be appropriate to add the suggestion here.

[domenic]

There's no conflict here. Custom element properties and methods shadow those from prototypes, so we don't have any compatibility concerns. You can use whatever names you want.

For attributes, we've already reserved the data- prefix.

Closing, as the JavaScript language already had us covered here. Happy to continue discussing in the closed thread.

[brettz9]

Sure, but for libraries which enhance an element, providing a kind of public API, there is the risk/concern that the wrapped element API will block future use of a new built-in API without modifications being required of the library and modification of prior consumer code. This is a very practical concern.

And sorry, I didn't mean to add "attributes" in the title. But speaking of which, to be clear, since dataset converts values to strings, leveraging that feature of course doesn't meet the objective here for supporting non-strings like functions.

And while setting element properties (as opposed to attributes) with data-* doesn't seem to result in the same conversion treatment, encouraging the overloading of the same syntax relating to attributes may contribute to a mistaken impression that setting elem.setAttribute('data-foo', 5) is equivalent to elem['data-foo'] = 5 (of course, any other namespacing format for property overloading would have the same distinction between attributes and properties, but it would not come with the baggage of being associated with attribute use, and the spec could even explicitly discourage using attributes of the same format (or use a format which was incompatible with existing attribute name requirements), even though its current reserving of data-* may be enough.)

[domenic]

block future use of a new built-in API without modifications being required of the library and modification of prior consumer code.

How? Can you give a concrete example?

[brettz9]

Let's say I released a buffed up <select> widget with a number of methods, one of which was values, a convenience setter property (or method) which could be used to set multiple values at the same time on a <select multiple> without the user needing to dig into the option elements.

If the spec later added such a feature using the same name, but implemented in a different manner, users of the widget could not progressively take advantage of the new API while avoiding the need to upgrading all of their prior code. Even for the case where the user had never used the old API, they'd still need to delete it from the old library before using the new API.

With namespacing, however, they could lazily update their old code, leveraging the standard API (e.g., values) for say new code, while continuing to use the old API (e.g., $values) for old code until such time as they might wish to adapt it. They'd also have no need of deleting a conflicting method to take advantage of the new enhancement.

Beyond such general purpose libraries, there could also be special purpose libraries which added behaviors beyond the element, e.g., an enhanced HTMLInputElement which could create and populate an adjacent drop-down (if say datalist hadn't been added). (These would most likely be better served as full-blown customized built-in elements but they could be implemented as methods like HTMLInputElement.prototype.$setupDropdown and then allowing one to continue to use the familiar input API as far as setting and getting values, etc.)

[domenic]

OK. In that case yes, I personally guarantee you we will never add methods starting with any of the following prefixes:

• $
• _
• $_$_$_$
• jquery
• myLibrary
• ....

You can use any of those in your libraries, if you are concerned about such cases. I don't think we should encode such practice in the spec though, as not everyone is concerned about such cases.

[brettz9]

Ok, good to know. Of course myLibrary and the like would be safe, but as the point is to avoid cumbersomeness (or otherwise symbols would work), $ would be a good prefix, imo (_ less so for reasons of its historical pseudo-privacy usage).

I'd still like to ask though what makes data-* different where attributes called for namespacing and properties don't? Given the staticness (and ugliness) of regular HTML, I think many of us spend more of our time these days with dynamically built HTML and may even fail to avail ourselves of the practice of adding custom properties because of such a fear of not having a "space" for it. (Consider how many sites disapprovingly advised against creating invalid HTML with custom attributes before data-*.)

[brettz9]

And even when one is convinced they are doing something perfectly acceptable, without the spec granting "permission" so to speak, one has to spend time dealing with the disapproval of others, and perfectly legitimate libraries end up with less traction because of it...

[annevk]

The main distinction I think is that with conflicting properties the developer-added property overrides the browser implementation, but with conflicting attributes the browser implementation overrides the developer-added attribute.

So we created the data-* namespace to steer folks away from creating attributes that might cause problems in the future (they can still such problems and we'll have to do compatibility analysis because of that each time we add a new attribute, but at least we steered folks in the right direction).