Formalise the empty value state for enumerated attributes

[lukewarlow]

What is the issue with the HTML Standard?

There's currently at least 9 content attributes that have special handling for the empty string value, these are currently mapped in the keyword tables to a state. It seems more appropriate to define an "empty value default" to go alongside the "missing value default" and "invalid value default"? This way keywords are keywords and special default states are defined separately.

[domenic]

I don't understand the motivation for this. The empty string is a perfectly good keyword, why give it special treatment?

[annevk]

I think we either have to add special casing for the empty string or we have to design something more generic that works for certain legacy cases where multiple keywords map to the same state. More generic might be nice, but it's not totally clear it's worth it given that it seems unlikely we'll ever do something like that again, whereas we'll continue to use the empty string to initialize some state.

[domenic]

More generic seems necessary to me; there are many cases like that in the existing spec.

[lukewarlow]

The empty string is a perfectly good keyword

The thing is it's never actually the canonical keyword. As far as I'm aware it's currently always mapped to a different keyword. So in that sense it's much closer to a special state.

My gut is that Empty is both non-legacy and used enough (I count at least 9 usages) that it deserves some special treatment.

The other cases where multiple keywords map to the same state I think can probably be left to spec prose. Without some very funky WebIDL grammar we wouldn't be able that mapping behaviour in the IDL anyway.

[annevk]

I don't think there are many actually. I just went through them again and I find shape (from area) and autocapitalize (global). What else is there? And for those two it seems reasonable to just handle them as distinct states that are treated the same. But the empty string is very common and it would definitely be much nicer if it was normalized away early on.

[domenic]

Hmm, I still disagree. I'd prefer a system where all the keywords are expressed in IDL, and we were flexible enough to map them, like we do today.

This doesn't even seem that hard. For example:

enum X {
  [Canonical="auto"] "",
  "auto",
  "manual",
  "hint"
};

[lukewarlow]

Webidl doesn't allow extended attributes on enum values ATM but there's no reason we couldn't I guess.

[annevk]

That seems like a lot of grammar changes for two legacy attributes, neither of which is particularly well-designed. Anyway, I guess I won't stand in the way.

[lukewarlow]

I'm leaning towards agreeing with Anne on this one. I think there's enough odd cases where we probably won't ever be able to handle in IDL that adding new IDL syntax + extended attribute to handle those few cases doesn't seem worth it.

#11450 (comment) - goes through a few cases from the HTML spec where IDL reflection probably can't be used.

[lukewarlow]

just went through them again and I find shape (from area) and autocapitalize (global).

Shape isn't specified to be limited to only known values so can just use "[Reflect]" the keyword and state design is purely in spec handling of those states rather than related to reflection.

Autocapitalize isn't specced to use reflection it has a custom getter that handles its weirdness. (Though it could use a ReflectSetter if we added one).

So neither of these actually need any special casing in IDL because they just don't use reflection currently. I think we should prioritise codifying the existing usages of reflection rather than trying to account for edge cases like this.

Though if we can handle simple getters with a [ReflectGetter] and simple setters with a [ReflectSetter] then that would be beneficial regardless.