FWIW, I avoid private fields in all my code because ofthis. Not sure if it's really relevant to this element or whether consumers would install Proxies on it.

I'm not sure I share those opinions; if you're extending a class it's fairly common to have to override parts of the class to deal with things like private state or copying (see the whole@@species debacle). The alternatives to private fields are: make everything public (but then lose the ability to observe changes or have two public fields), or use a WeakMap, and then the loud errors about private field access turn into silent ones where properties using a WeakMap can return undefined instead.

make everything public

I prefer all-public fields because they enable advanced use cases that the original author has not considered. For example, there are numerous cases in Node.js API where one needs to access underscore props. With private fields, you restrict the consumer too much imho.

Many of the private fields in this codebase (and our other custom element codebases) are public, but they need to be observed,for example#onRelativeTimeUpdated has a get/set but it has (warranted) side-effects which can only happen if we store the state under a different name. We could publicise the field name but that means coming up with some alternative name, and runs the risk of exposing undesirable information which can cause memory leaks - for example settingonRelativeTimeUpdated removes the old event listener, but if one were to assign to the#onRelativeTimeUpdated and not remove the old event listener, it would continue to fire and could cause further errors. We could make this field aWeakMap instead, but as I say, we then face the same issue with regard to subclassing, so I feel like this is a well justified use case where the alternatives have greater trade-offs.

Okay. I'm not suggesting changing these private fields now, but for new code, I would definitely consider using them and if there's no strong reason, I wouldn't, so that I don't breakProxy usage.

On topic: Another browser often forgotten is Pale Moon. Itlooks to support private class fields since their 2023-05-16 release, so I think it'll likely be fine with this change.