Update autofocus algorithm

[tkent-google]

• Handle a case where an element with autofocus is connected and then disconnected before focused.
  HTML: remove autofocused element before its task runs web-platform-tests/wpt#11193
• First step of the algorithm is too vague
  Autofocus test port web-platform-tests/wpt#16780 (comment)
• Also, see Autofocus spec should probably allow browsers to delay running the focusing steps, maybe?

[tkent-google]

• Handle a case where an element with autofocus is connected and then disconnected before focused.

I think it's done by just adding connected check to the autofocus steps.

• First step of the algorithm is too vague

We should specify as much as possible to improve interoperability. IMO we should standardize the Firefox behavior. How about changing the first step to:

1. If focus update steps has been executed in element's node document, then return.
   if the scroll position of element's node document is different from the initial one, then return.

@bzbarsky @rniwa What do you think?

[rniwa]

What are you referring to by "the Firefox behavior"? What do other browsers do today? Are you talking about waiting until all pending stylesheets are loaded??

[tkent-google]

What are you referring to by "the Firefox behavior"?

It's web-platform-tests/wpt#16780 (comment) . That is to say, Firefox doesn't handle autofocus if any element was focused beforehand, and Firefox doesn't handle autofocus if the page was loaded with a fragment anchor.

What do other browsers do today?

Neither of WebKit nor Blink do them today. However, I (as a Blink dev) prefer the Firefox behavior.

Are you talking about waiting until all pending stylesheets are loaded??

No in this issue. It's discussed in #3551.

[tkent-google]

@bzbarsky Do you think #4645 (comment) is reasonable?

[domenic]

@smaug---- as well as I hear he has been closer to focus stuff (although @bzbarsky filed some of the initial issues).

[tkent-google]

I posted a specification PR to resolve this issue: #4763