- From: Alice <notifications@github.com>
- Date: Tue, 18 Feb 2025 14:41:50 -0800
- To: WICG/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <WICG/webcomponents/issues/1093/2667084351@github.com>
alice left a comment (WICG/webcomponents#1093) > I don't see how 3 would work with `delete`. That doesn't end up invoking the getter or setter, iirc. Hm, yeah, I didn't really think about that. Definitely a non-starter! > I have a preference for 2 as that more closely matches the semantics of the `id` getter/setter and `getElementById()`. It's *slightly* different from the `id` setter in that if you do `el.id = ''`, `el` will sprout an empty `id` attribute, which will result in a different result when using `getAttribute()` or `hasAttribute()` or attribute selector matching. Obviously it won't do you much good for any ID-based APIs, since it's an invalid ID, but it does change the semantics of the element. Implementation-wise, it looks like both existing implementations currently assume a non-null value for `referenceTarget` is meaningful, even if it's an empty string: i.e. any non-null value (including empty string) for `referenceTarget` means that the host will **not** be the result of resolving the reference target. If we went with option 2, I think we'd have to update the implementations and write the spec such that the value defaults to empty string, and we consider empty string to be a "missing value" meaning that the host should be the result of resolving the reference target in that case. -- Reply to this email directly or view it on GitHub: https://github.com/WICG/webcomponents/issues/1093#issuecomment-2667084351 You are receiving this because you are subscribed to this thread. Message ID: <WICG/webcomponents/issues/1093/2667084351@github.com>
Received on Tuesday, 18 February 2025 22:41:53 UTC