Open mfreed7 opened 1 week ago
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?
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] ofclosedby
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 ofclosedby
corresponding to newValue, then return.
I think this is sufficiently clear and also avoids the type confusion that the OP's wording has.
Yeah that sounds very reasonable. Thanks!
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.
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:
It'd be good to clarify (and potentially fix) cases where we want to check that two enumerated states match.