Should renderPriority on visible elements cause asynchronous updates

[vmpstr]

(from @chrishtr, via discussion in #201 ):

It's an interesting question. What should renderPriority=background do to a DOM subtree that is visible? I suggest we add text like:

• renderPriority only applies to replaced elements and elements with a used style of contain:style layout paint.
• The user agent should (may?) treat any element whose contents are visible and on-screen as at least userVisible priority.

[chrishtr]

Just remembered an important point: if content is on-screen and is not sync rendered, then there is a question about what we should display on-screen in the meantime, and how hit testing/input should work.

Display options:

• Show old content
• Show a placeholder
• Invisible
• Leave it up to the developer via a pseudoclass like :duringrender, with a default of one of the above

Hit testing options:

If we show the old content or a placeholder, then clearly hit testing should not run against the new content, because there's no way for the user to tell what they were interacting with. Then there is the question of whether hit testing should eat the event, or it should act as if the content was not present in the DOM. The latter only makes sense if the content is invisible, but note that basically this same question is being debated about the inert attribute.

Other input:

If an element in this subtree was focused and keyboard events occur, then it seems clear that the subtree should always be user-blocking priority.

I think a good choice seems to be:

• Show old content, plus expose a pseudoclass
• Eat the events that need hit testing
• Always be user-blocking priority when focused
• Upgrade to user-blocking when there are input events that strongly indicate interest, such as click (but not hover).

[vmpstr]

This is a good point. This is the main reason why I wouldn't want to tackle this as part of the renderPriority work. We should pursue this work as a new feature that builds on renderPriority.

[chrishtr]

This is a good point. This is the main reason why I wouldn't want to tackle this as part of the renderPriority work. We should pursue this work as a new feature that builds on renderPriority.

I'm all for it, but if we add an HTML attribute we will need to define how it works in all situations, and make sure that how we define it is forward-compatible to future use cases.