Proposal to add missing IDREF reflection IDL attributes

[lukewarlow]

What is the issue with the HTML Standard?

To match how newer IDREF content attributes have an IDL reflection counterpart, I propose we add the missing properties for the older attributes.

I'm less convinced of the utility of some of these (e.g. headers) but potentially should be included for API completeness.

for attribute

We should add a new forElement property to the relevant interfaces.

I've chosen forElement rather than htmlForElement as the existing properties name is a quirk of history and I feel it's better to keep a simpler name at the expense of not aligning with that property name.

Currently we have htmlFor which takes an ID (cannot do cross-root association unlike the modern ones), or we have control which is readonly.

Given we have the control property already I'm proposing this just being a pure reflection.

partial interface HTMLLabelElement {
    [CEReactions, Reflect="for"] attribute Element? forElement;
};

partial interface HTMLOutputElement {
    [CEReactions, Reflect="for"] attribute FrozenArray<Element>? forElements;
};

list attribute

We should add a new listElement property to the relevant interfaces.

Currently we have no writable property you have to use set attribute with an ID, or we have list which is readonly and only returns valid list associations.

Given we have list already I propose this is pure reflection.

partial interface HTMLInputElement {
    [CEReactions, Reflect="list"] attribute Element? listElement;
};

form attribute

We should add a new formElement property to the relevant interfaces.

Currently we have no writable property you have to use set attribute with an ID, or we have form which is readonly and only returns valid form associations.

Given we have form already I propose this is pure reflection.

interface mixin FormElementThingy {
    [CEReactions, Reflect="form"] attribute Element? formElement;
};

HTMLInputElement includes FormElementThingy;
HTMLButtonElement includes FormElementThingy;
HTMLSelectElement includes FormElementThingy;
HTMLOptionElement includes FormElementThingy;
HTMLTextAreaElement includes FormElementThingy;
HTMLOutputElement includes FormElementThingy;
HTMLFIeldsetElement includes FormElementThingy;
HTMLLegendElement includes FormElementThingy;
ElementInternals includes FormElementThingy; // Not sure if this is correct or not?

headers attribute

We should add a new headerElements property to the relevant interfaces.

Currently we have the headers property but that just reflects the raw string of the attribute. So in a well formed case you can give it the list of idrefs but that won't allow the cross-root usage.

partial interface HTMLTableCellElement {
    [CEReactions, Reflect="headers"] attribute FrozenArray<Element>? headerElements;
};

[bramus]

I’ve had several direct requests from authors about supporting it for for.

[lukewarlow]

Does output's for attribute actually do anything? I can see it's specced to sometimes affect AT mappings but WebKit doesn't seem to do anything for it (Even for the linux ports using ATSPI)?

Potentially it could be omitted if it's not actually useful at all, but given it exists and isn't deprecated I guess completeness makes sense?

At least in WebKit the implementation for .formElement is also non-trivial, label.forElement is however a simple change to make. Haven't investigated the .headerElements stuff yet.

[zcorpan]

For HTMLInputElement listElement, list already exists and returns an element. It's readonly, but could be made writable without adding another IDL attribute.

The other additions make sense I think.

[lukewarlow]

The list property returns a HTMLDataListElement, so it's doing some level of validation too. I was thinking these new ones would just be pure reflection of the element.

[domenic]

I think we should not add something redundant that is generally worse (i.e. does less validation). In fact, if we could add validation for the other suggestions, maybe that's better than doing generic reflection...

[lukewarlow]

Because of the cross-root aspect I don't think we can do much validation, especially once referenceTarget exists.

Another minor point is that those existing ones also don't follow the correct naming scheme that the rest of the element reflection properties follow.

[keithamus]

I think it might be worth splitting these out into individual issues as some are less trivial and more controversial than others.

[domenic]

Because of the cross-root aspect I don't think we can do much validation, especially once referenceTarget exists.

Can you expand on this? I don't understand how cross-root or referenceTarget would prevent us from, e.g., returning null if pointing to elements of the wrong type.

[lukewarlow]

Can you expand on this? I don't understand how cross-root or referenceTarget would prevent us from, e.g., returning null if pointing to elements of the wrong type.

I'll be honest I slightly mis-remembered how some of this worked. We can nullify the returned value if it's "invalid", but the type of the property would have to be HTMLElement? (or potentially even Element?)

[alice]

For my 2c on validation: having chatted with Luke a bit about this, I think I'd lean towards not validating the reflected attributes other than checking they reflect the attr-associated element (not always equivalent to the labelled element, etc).

• I think of the reflected attributes as a piece of data, approximately equivalent to the associated content attribute.
• With custom elements and reference target, we (unfortunately) can't limit the reflected attributes by type: the getter might well return a custom element rather than an HTMLListElement or whatever.
• So, I think the most useful thing is to return the relevant piece of data, which is the attr-associated element (where relevant, retargeted to the appropriate scope); this is analogous to getAttribute().