Re: [w3c/webcomponents] Reserve hyphenated or `$`-including properties for customization (#700)

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.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/700#issuecomment-342972589