Clarify IDL reflection for `closedby` attribute

[keithamus]

What is the issue with the HTML Standard?

Preamble

In #10737 we added the closedby attribute. This is an enumerated attribute limited to known values, where the missing/invalid state is the auto state. The auto state does not have a keyword.

The spec states:

The closedBy IDL attribute must reflect the closedby content attribute, limited to only known values.

Root issue

Limited to known values declares that if a state like auto has no corresponding keyword, then the empty string must be returned. However Chrome and the WPTs expect something different (all of these were tested on Chrome canary).

• A dialog which is closed returns the string "none"
• A dialog which is open (non modal) returns the string "none"
• A dialog which is open as modal returns the string "closerequest"

This matches the values represented in the algorithm computed closed-by-state but the closedby reflection rules don't mention this.

Next steps

I think the following paths forward exist for us:

1. Alter the WPTs and Chrome's behaviour to return "" (the empty string) when closedby is in the auto state.
2. Alter the spec to properly clarify that the closedby attribute does not do simple reflection, and instead reflects the computed state.

Of course I could be missing something, in which case this issue could be closed.

/cc @mfreed7 @domenic

[domenic]

Good catch!

I think (2) is slightly preferable, but I don't feel strongly.

[mfreed7]

Note the "Note", which attempted to define the behavior:

Note: The Auto state behaves as Close Request state when the dialog was shown using its showModal() method; otherwise the None state.

I think (2) basically means converting that from a Note to an actual algorithm, right? If so, and if there's a pointer somewhere for how to word that, I'm happy to give it a try!

[lukewarlow]

My preference would be (1) personally. It feels odd that round tripping the IDL property with its own value can change the behaviour of the element? e.g. I have a bare dialog, I call show(), I round trip the IDL property, I call .close() and then I call .showModal() suddenly close watchers don't work?

Whereas with popover invalid values reflect as manual, round tripping that has no effect?

[domenic]

My preference would be (1) personally. It feels odd that round tripping the IDL property with its own value can change the behaviour of the element?

This is already the case for some other reflection-ish properties, like spellcheck, writingSUggestions, autocapitalize, etc. But maybe this case is a bit more dangerous?

[mfreed7]

So there are two scenarios that conflict here:

1. You want to be able to do dialog.closedBy = dialog.closedBy (this is better with option (1))
2. You want the IDL reflection to tell you what's actually happening (this is better with option (2))

I guess I don't know what the use case is for #1. I can see the point of #2 - it allows code to "ask" what behavior they're getting.

[lukewarlow]

Agenda+ this so we can discuss and reach a conclusion to fix the spec / wpts + impls as it potentially blocks further implementations.

Having thought on this more I'm neutral on which solution we go with.

[domenic]

It sounds like everyone is either neutral or leaning toward (2), so it would also be possible to resolve this async, if we could get Gecko and WebKit to chime in. @annevk @smaug----.

[annevk]

Generally I think we should do 2 unless the computation is involved (e.g., see the discussion around dir and lang). That's not the case here, so 2 seems correct.

[zcorpan]

I prefer (2), since it also allows for checking support for values (if we want to add new values in the future).

[annevk]

That's supported by both options.