reflection of enumerated attributes doesn't seem to process empty/missing/invalid value defaults clearly

[dbaron]

What is the issue with the HTML Standard?

While trying to spec the checkable attribute on <fieldset> I was reading the prose for how reflection of enumerated attributes works, and it doesn't seem to me to be fully defined what should happen.

The definitions in https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#reflecting-content-attributes-in-idl-attributes%3Aidl-domstring-3 define how a getter should reflect a DOM attribute when it is reflected as DOMString or (in the following definition) as DOMString?. A few things here seem problematic to me:

• for the first part (DOMString), it uses the somewhat vague wording of "correspond to" when I think it would probably make sense to determine the corresponding state using the formal (but not linkable!) definition of "to determine the state of an attribute" in https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#enumerated-attribute . As far as I can tell it doesn't do anything that actually invokes that definition. But I'm not sure what "correspond to" is supposed to mean other than referring to that definition.
• for the second part (DOMString?) I think the problem is more serious: getter step 4.2 simply says "Assert: contentAttributeValue corresponds to a state of attributeDefinition." and I don't see anything that ensures this is the case. As far as I can tell, contentAttributeValue is at that point the raw value of the attribute. I think it would make sense to again defer to the "to determine the state of an attribute" definition, and then return null when "no state" is returned from that algorithm.

That said, I'm not entirely sure if that is either (a) what is intended or (b) what is implemented.

Also, since it took me a minute to find, an existing example of the DOMString? reflection is HTMLLinkElement.crossOrigin. (And, back to my original motivation, I think it makes sense for <fieldset checkable> to reflect in a similar way.)

(This is related to the much larger work in #3238 and #11455 but I don't think either really interferes with the other. cc @lukewarlow nonetheless.)

(I'd be happy to make a PR if folks think the above makes sense.)

[lukewarlow]

So I think ideally we can linkify the words "attribute definition" to some concept that gets implemented by each of the attribute definitions (though many might be fully IDL now). Then also yes maybe the "correspond to" could be turned into a meaningful algorithm to make it explicit what is actually expected to happen.

For the second part "I don't see anything that ensures this is the case" as far as I know this is just spec editors ensuring that definitions work. Provided the attributes are defined properly then this will be true.

I agree this can probably be clarified a bit and I agree the IDL stuff doesn't block this improvement.

[dbaron]

For the second part "I don't see anything that ensures this is the case" as far as I know this is just spec editors ensuring that definitions work. Provided the attributes are defined properly then this will be true.

My concern wasn't about something that spec authors could ensure: what I'm saying is that if an author writes <link crossorigin=unknownvalue> in their markup and then calls the HTMLLinkElement.crossOrigin getter, I don't see anything that would make the value of contentAttributeValue at the time of "Assert: contentAttributeValue corresponds to a state of attributeDefinition." be anything other than unknownvalue.

Though I suppose, again, that I don't know exactly what "corresponds to" means.

[lukewarlow]

So I can explain what happens, that crossorigin content attribute on link is defined to be a CORS settings attribute here. The CORS setting attribute definition is here (ideally would be linkified as a concept within the reflection algorithms). That definition has the attributes invalid value default as the Anonymous state. So the crossorigin=unknownvalue 'corresponds to' the Anonymous state of attributeDefinition.

The Anonymous state has an associated keyword value so it doesn't return null, it instead returns the canonical keyword "anonymous".

I agree that "corresponds to" is perhaps a bit too handwavy and should make it a bit more clear what a definition is and how a value corresponds to it including the special states.

Having said all that there actually is an algorithm for this (or close), it's just not linkable for some reason. See the "To determinate the state of an attribute" here.

[dbaron]

I think we're in violent agreement, so I made a PR in #12692 and we'll see what other folks think.