Clarify/fix how to describe state comparison

[mfreed7]

What is the issue with the HTML Standard?

See this review comment:

https://github.com/whatwg/html/pull/10737/files#r1834515874

related to this spec text:

<li><p>If <var>oldValue</var> and <var>value</var> are in the same <span
data-x="attr-dialog-closedby">state</span>, then return.</p></li>

It'd be good to clarify (and potentially fix) cases where we want to check that two enumerated states match.

[annevk]

Well the problem here is that value contains a string, right? Not a state. So we need a convenient way to translate a string into its state. The reference to the attribute helps with that, but it's rather vague.

@domenic any quick thoughts?

[domenic]

The fully-rigorous way to do this is to turn https://html.spec.whatwg.org/#keywords-and-enumerated-attributes:~:text=To%20determine%20the%20state%20of%20an%20attribute%2C%20use%20the%20following%20steps: into an algorithm which takes as input an attribute name and attribute value, and outputs a state. For example,

The state of an attribute name attribute corresponding to the string value is given by the following steps:

Then we would do

If the [state] of closedby corresponding to oldValue equals the [state] of closedby corresponding to newValue, then return.

---

I don't think this is worth making fully rigorous, mainly because we wouldn't use this "state" definition elsewhere. Most of the existing spec instead gets the state of an Attr; the case of not having an Attr, but instead having an attribute name/declaration and an attribute value string, is rare.

So my suggestion is instead use the same wording as above, but leave "the state of X corresponding to Y" un-rigorous and not linked to any definition. I.e.

If the state of closedby corresponding to oldValue equals the state of closedby corresponding to newValue, then return.

I think this is sufficiently clear and also avoids the type confusion that the OP's wording has.

[annevk]

Yeah that sounds very reasonable. Thanks!

[mfreed7]

Just for reference, I updated the spec PR from the OP and I believe I've removed the need to do this type of comparison. This general issue still remains, I think, so I won't close it.