Reflection of IDREF attributes will leave stale ID value

[rniwa]

In the following example, document.write will log "label-id" in all three cases even though the target element had moved to be inside a shadow tree:

const element = document.createElement('div');
const label = document.createElement('div');
label.id = 'label-id';
document.body.appendChild(element);
document.body.appendChild(label);
element.ariaLabelledByElements = [label];
document.write(element.getAttribute('aria-labelledby') + '<br>');

const newLabel = document.createElement('div');
newLabel.id = 'label-id'
document.body.insertBefore(newLabel, document.body.firstChild);

document.write(element.getAttribute('aria-labelledby') + '<br>');

const host = document.createElement('div');
document.body.appendChild(host);
host.attachShadow({mode: 'closed'}).appendChild(label);

document.write(element.getAttribute('aria-labelledby') + '<br>');

This doesn't seem right. It's really confusing that setting id-ref leaves id values that are stale and no longer representative of the actually referenced element.

[rniwa]

@smaug---- @domenic @annevk

[mrego]

This seems to be on purpose from the ARIA reflection explainer: https://github.com/WICG/aom/blob/gh-pages/aria-reflection-explainer.md#relationships-are-validated-on-get

[mrego]

What happens if the element already has the attribute set, and it was not set by attribute reflection, should we remove it when it's moved?

Example:

const element = document.createElement('div');
const label = document.createElement('div');
label.id = 'label-id';
document.body.appendChild(element);
document.body.appendChild(label);
element.setAttribute('aria-labelledby', 'label-id');
document.write(element.getAttribute('aria-labelledby') + '<br>');

const host = document.createElement('div');
document.body.appendChild(host);
host.attachShadow({mode: 'closed'}).appendChild(label);

document.write(element.getAttribute('aria-labelledby') + '<br>');

[annevk]

Hmm. I hadn't appreciated this when commenting on #8307.

Do we know why we need to set a content attribute at all? Perhaps not doing that is preferable when there's no actual serialization (such as when you have a pointer to an element).

[annevk]

cc @whatwg/a11y

[alice]

I explained my original intent around "sprouting" content attributes here: WICG/aom#181 (comment)

Essentially: having at least an empty string as the content attribute means you can reliably know when to check the IDL attribute to understand element associations.

For example, if you wanted to find all the elements which have an aria-owns association, you could do a querySelectorAll("[aria-owns]") to find all elements with an aria-owns attribute, and then query the ariaOwns IDL attribute for each to get the owned elements (since the IDL attribute is the source of truth). If the content attribute isn't always set, you'd have to write a tree walk instead, checking the ariaOwns IDL attribute for every element in the page.

As for specifically sprouting the IDs, it's nice to have for serialization, as @annevk alludes to - the idea being that if authors have bothered to set IDs on the element/s in the first place, they may as well get serializability for free (assuming all relevant elements have IDs which are in the right scope, etc).

As we were originally designing this, it seemed unlikely enough that IDs would be changing or elements would be moving in and out of scope to design around that edge case and lose the benefit of the feature, rather than just warning authors in documentation about when the values may become stale ("play stupid games, win stupid prizes").

If it is indeed a show stopper, then hopefully we can fall back to at least having empty content attributes reliably, for the reasons I outlined above.

I certainly don't think we want to maintain the reverse mapping in order to update the content attributes when the DOM changes.

The WPT tests do a fairly good job of covering the edge cases around ID values becoming stale, I think.

Perhaps not doing that is preferable when there's no actual serialization (such as when you have a pointer to an element).

I'm not sure I understand this comment, could you possibly rephrase it?

[annevk]

The problem I see is that best-effort clashes a bit with how APIs normally behave, in that they work consistently and "correctly", even for contrived cases. Here there's a number of contrived cases where things get out-of-sync, which might be understandable to some and confusing for others. That's why I think that maybe we shouldn't try to go for best-effort and instead make it clear that when you use an element pointer there is no serialization. (Or empty string, as you suggest.)

E.g., if a website uses duplicate id attribute values, that mainly works fine. It's just that getElementById() will only return the first. However, with this API you can target the second element, but if you verify yourself using getElementById() you'd still get the first. I suspect it might be easier to explain that this feature doesn't have reflection through ID attributes than that sometimes ID attribute reflection ends up with poor results.

[patrickhlauke]

not thought through all the implications, but my naive take is that this reminds me of things like <input type="checkbox" checked> ... and how then later testing for hasAttribute('checked') won't reflect the actual "checkedness" for the input once it hits reality/user interactions. having said that, getElementById() is near-ubiquitous in its use, so the possibility that the id may be modified in other ways may be surprising to devs and should definitely be explicitly called out/explained, as well as the "don't mix and match approaches/APIs" (though it may not always be under the dev's direct control ... if they pull in 3rd party JS they may not even be aware that this is happening)

[annevk]

(Checkedness is reflected by the checked IDL attribute. The checked content attribute is reflected by the defaultChecked IDL attribute. The content attribute should probably have been named defaultchecked or the checked IDL attribute should have been named liveChecked or some such, but that mistake was made a long time ago.)

[rniwa]

I think setting empty string seems like a good compromising ground. That would not confuse authors with stale ID values and still indicate that the attribute is in use.

[alice]

Making the compromise on the conservative side is ok with me. I do agree that it can feel a bit precarious even just knowing that these cases exist. I can also see that, even if it seems highly unlikely that any given developer would stumble into one of these cases, just having to explain how the content attribute can get out of sync means the documentation necessarily has to be longer and more complicated than it would otherwise.

[annevk]

@mrego would you be willing to drive the PR for this?

[mrego]

@mrego would you be willing to drive the PR for this?

If there's agreement yeah, I can prepare a PR, update tests and implementations. :)

[cookiecrook]

Probably need to make sure other ARIA stakeholders are okay with this, since it would mean element reflection doesn't actually reflect anything. @jnurthen @spectranaut

[cookiecrook]

But I do like seeing spec simplification, so @mrego's linked diff is gorgeous…

[alice]

Probably need to make sure other ARIA stakeholders are okay with this, since it would mean element reflection doesn't actually reflect anything. @jnurthen @spectranaut

I don't know that I'd think of it as not reflecting anything - if the content attribute is set, the IDL attribute will indeed reflect the computed attr-associated elements based on that attribute, and if the IDL attribute is sent to null then the content attribute is removed.

But I agree, it would be nice to understand what the impact might be of never setting the content attribute based on the IDs of the attr-associated elements, compared to the impact of having the content attribute becoming stale under certain circumstances; even if it's decided (as it seems to be) that the latter is a deal breaker regardless.