Rationale for when invalid value default differs from missing value default

[flackr]

What is the issue with the HTML Standard?

It seems for most properties, an invalid value default is the same as the missing value default, e.g. we do this for the following:

• referrer policy
• lazy loading
• fetch priority
• translate
• dir
• decoding
• kind
• shape
• scope
• autocomplete
• type
• wrap
• method
• enctype
• shadowrootmode
• hidden
• contenteditable
• spellcheck
• draggable
• popovertargetaction
• behavior
• direction

From a scan of the spec there are five exceptions:

• CORS
• preload has both being implementation defined
• writingmode
• autocapitalize
• popover

I'd be interested to understand the rationale for these cases where an invalid value is not treated the same as a missing value. In particular, writingsuggestions was added recently, I didn't see any discussion around the invalid value default choice, but this was pointed to as an example for why handwriting should have an invalid value default of true, but I don't understand the rationale for when we should have a different invalid value default from the missing value default.

This seems like we should be consistent unless there is a reason to deviate. In particular, writingsuggestions and handwriting seem very similar to spellcheck which does have the same invalid value and missing value defaults.

@sanketj @mfreed7

[mfreed7]

I can speak to popover, and it might offer some ideas for the general question?

The initial idea was that for forward compat, <div popover=invalid> should act as if there was no popover attribute at all, so that if we later add a supported popover=invalid value, it hopefully won't break stuff. But we wanted <div popover> (empty value) to "just work" with the most common behavior of popover=auto. Then @emilio raised some good points in openui/open-ui#533 (comment) (you can read above that also, for more motivation for different defaults) that triggered a change of the invalid value default to manual. But before/after this change, there were different empty-value and missing-value defaults.

[flackr]

Thanks @mfreed7! If I were to try to generalize, it seems like the main reason to have different behavior for invalid value is in cases where the attribute's existence (and empty string value) triggers behavior that we would expect to also be implied by future values. I think the same argument could be made for the cors attribute, that future values would be expected to have behavior similar to anonymous with some specialization, and thus falling back to no cors for future values would be more breaking than falling back to anonymous.

preload may or may not be the same, depending on whether the implementation-defined behavior varies or not.

autocapitalize has an invalid value state that roughly matches what you might expect from an empty value.

So I guess the question then is what is the expectation for writingsuggestions, and should we be changing it to match other properties, or should we be changing the other properties that are similar to follow this pattern, e.g. the following properties have a specified meaning for an empty value that differ from the invalid value state:

• translate
• hidden
• contenteditable
• spellcheck

[sanketj]

For writingsuggestions, we were modeling after the spellcheck attribute, but we didn't want authors to inadvertently turn off UA-provided writing suggestions. That's why we spec'ed it so that only a "false" attribute value - either on a target element or a parent - could put the attribute into the false state and made the invalid value default "true".

The missing value default continues to allow for inheritance and UA defaults, similar to spellcheck.

[flackr]

For writingsuggestions, we were modeling after the spellcheck attribute, but we didn't want authors to inadvertently turn off UA-provided writing suggestions. That's why we spec'ed it so that only a "false" attribute value - either on a target element or a parent - could put the attribute into the false state and made the invalid value default "true".

If the invalid value default was the same default state as the missing value default, it would still be the case that only an explicit false value would actually put it into a false state, as only an ancestor with an explicit false value would disable it. It would just honor the ancestor value for writingsuggestions as we do for spellcheck.

IMO the real question is does an author who sets writingsuggestions=foo expect to override writingsuggestions=false on an ancestor and enable writingsuggestions?

[sanketj]

IMO the real question is does an author who sets writingsuggestions=foo expect to override writingsuggestions=false on an ancestor and enable writingsuggestions?

Right. I don't know if there's a good use case either way, but my mental model is that any value other than false should set the state to something that is "not false". (That can only be "true" right now, but there could be other valid values in the future.) This seems to be how the autocapitalize attribute is spec'ed as well, where the invalid value default is also not the default state.

[flackr]

If we apply this rationale consistently, it seems like we should consider also changing translate, hidden, contenteditable, and spellcheck since they are similar.

[annevk]

I'm a bit confused by Mason's comment. The empty string value is just another keyword and for that case neither "invalid value default" (incorrect value) or "missing value default" (no attribute specified) are directly applicable. Though if there is no empty string keyword specified, then "invalid value default" (not "missing value default") would end up applying.

Say you have an attribute with three states:

• None
• Action 1
• Action 2

It seems quite reasonable that you want to default to the None state when the attribute is not specified, but to Action 1 (or 2) when it is specified but has an unknown value. That might well make sense for forward compatibility for that particular attribute. (Come to think of it, this is essentially what crossorigin wants.)

[mfreed7]

I did mis-speak a bit, in particular about the missing value default. It's unfortunate that it's not called the "missing attribute default", since mentally I think of popover (without =something) as having a missing value. However, the logic still stands:

• <div popover> - empty ("") value, has the same behavior as auto.
• <div popover=invalid> - invalid value default is manual for the reasons mentioned
• <div> - missing value default is the no popover state for the reasons mentioned.

So there are invalid & missing value defaults that are different from each other, which was the original question, I believe.

[flackr]

So there are invalid & missing value defaults that are different from each other, which was the original question, I believe.

Yes exactly. I'm trying to figure out what the consistent principle to apply is for when an invalid property value attr=invalid-value should be treated the same as some other value, often the same as the empty "" value though this doesn't necessarily have to be the case. It sounds like we might want to do this for most properties with an empty "" value behavior to have a reasonable fall back behavior when adding new values.