Loosen DOMString? getter to accommodate ARIA-style string reflection

[rahimabdi]

Addresses #10037.

The ARIA WG is currently working on improving IDL which includes converting ARIA attributes (where applicable/possible) to be truly enumerated.

As a subtask of this general work, this PR loosens HTML spec to allow DOMString? reflection that is not limited to only known values. This is desirable for non-enumerated ARIA content attributes (e.g., aria-label, role) where the most appropriate IDL attribute type is DOMString? and the absence of the attribute's value is meaningful. This change will also ensure HTML-conformant reflection for future ARIA attributes that require string reflection.

CC @annevk

• At least two implementers are interested (and none opposed):
  • N/A, already implemented
• Tests are written and can be reviewed and commented upon at:
  • N/A, already tested
• Implementation bugs are filed:
  • N/A, already implemented
• Corresponding HTML AAM & ARIA in HTML issues & PRs: N/A
• MDN issue is filed: N/A
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

/acknowledgements.html ( diff )
/common-dom-interfaces.html ( diff )

[domenic]

Can you clarify which of the paths outlined in #10037 this follows?

[rahimabdi]

@domenic Apologies, please see this latest comment in the issue: #10037 (comment).

[annevk]

Thanks! Couple more nits.

[annevk]

@rahimabdi thanks again for tackling this!

This looks good to me now. With this PR in place ARIA can use DOMString? and use the reflect language for IDL attributes whose content attributes are not defined as enumerated attributes. The meaning of which will be that if the content attribute is absent, the IDL attribute getter will return null. (And the IDL attribute setter will remove the content attribute when given the null value. Though this does not require further changes on the HTML side.)

While this was not the most desirable solution, it is the most reasonable one now that everyone has shipped. And in parallel ARIA folks will continue to investigate migrating their content attributes to become proper enumerated attributes as that would yield additional benefits, such as feature testing.

@domenic any further thoughts from you?

[domenic]

This looks good, although since we have decided on 1A instead of 2A, I wonder if we should have some sort of normative guidance in https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#using-reflect-in-specifications to avoid using DOMString? for non-enumerated attributes.

[annevk]

It would probably be good to have some more detailed advice on attribute design in general, but I would not really want to block this PR on that as this seems like a strict improvement over not having anything.

It's also quite nuanced as I don't think we generally prefer DOMString? even if the attribute is enumerated, as generally it seems preferable to have an explicit state over null.