renderpriority: Should it be an HTML attribute or a CSS property

[vmpstr]

... and should it have values that indicate priority

Presumably this would be an attribute on Element, meaning that any element would support this attribute. This would also be no-op for cases where rendering must be done anyway -- such as cases without content-visibility: hidden.

I don't want to call it anything like asynchronous because that gives an erroneous impression that if this element is visible, the updates to it are asynchronous. That may be something we do in the future for a different attribute, but this isn't it.

I was thinking something like keepUpdated. Do folks have better suggestions?

/cc @chrishtr

[vmpstr]

/cc @noahlemen

[noahlemen]

I wonder if the fact that this is no-op without content-visibility:hidden suggests that it would fit better as a value for content-visibility? Something like content-visibility:hidden-updatable perhaps? Downside there, I suppose, is that we wouldn't be able to articulate priority via a value. Given that, I think something like keepUpdated makes sense too.

I would suspect that values indicating priority might be useful - for example, it's easy to imagine a page having many hidden menus that could be updated where you may want to prioritize one that is known to be used more frequently.

Another question that comes to mind around priority, though: how would priority of the attribute version interact with calls to the imperative version? I would assume that the imperative version would always take highest priority.

[vmpstr]

I wonder if the fact that this is no-op without content-visibility:hidden suggests that it would fit better as a value for content-visibility? Something like content-visibility:hidden-updatable perhaps? Downside there, I suppose, is that we wouldn't be able to articulate priority via a value. Given that, I think something like keepUpdated makes sense too.

Having a CSS property for this also has a problem that you can't really apply this to a CSS class. Or rather, you can't have a per-element control without inline style or a very specific selector. I'm kind of leaning towards attribute for these reasons

I would suspect that values indicating priority might be useful - for example, it's easy to imagine a page having many hidden menus that could be updated where you may want to prioritize one that is known to be used more frequently.

That's an excellent point!

Another question that comes to mind around priority, though: how would priority of the attribute version interact with calls to the imperative version? I would assume that the imperative version would always take highest priority.

I think about this as having a many different sources asking for updates. So if one source is saying "idle priority -- whenever you get a chance", and another source is saying "must be updated soon", then the obvious choice is to update the element soon, and resolve both promises (if there are promises). Translated into a description, I would say that it picks the highest priority of any request -- whether it's multiple updateRendering() calls or updateRendering() mixed with keepUpdated

[chrishtr]

How about renderPriority=<value>, where is one of the options in the postTask API, plus "auto" as default? e.g. renderPriority=background would mean do it when you can, renderPriority=userVisible would mean do it pretty quickly, and renderPriority=userBlocking means do all of it in the next update-the-rendering task.

"auto" means the UA choses based on the semantics of the style etc.

[vmpstr]

That sounds good. Would auto be equivalent to userBlocking in this case? IOW, I assume userBlocking means the same thing as do it as if you're always updating the rendering

[chrishtr]

That sounds good. Would auto be equivalent to userBlocking in this case? IOW, I assume userBlocking means the same thing as do it as if you're always updating the rendering

Auto would do it based on style / UA heuristics. It would basically be a no-op vs our current behavior for content-visibility: hidden, and would mean we could try to optimize rendering work for offscreen content-visibility: auto content if we want.

userBlocking means "blocking the user’s ability to interact with the page, such as rendering the core experience or responding to user input." (quoting the postTask spec).

[noahlemen]

I'm not certain this is something we'd actually use, but I'm trying to think through the implications of nested renderPriority. Would renderPriority for the child here no-op without content-visibility despite being within a subtree that has content-visibility:hidden?

<div style="content-visibility:hidden" renderPriority="userVisible">
  /* some other content */
  <div renderPriority="background"></div>
</div>

[vmpstr]

That's an interesting question. Here's how I think about it:

<div style="content-visibility:hidden">
  /* some other content */
  <div id=target renderPriority="background"></div>
</div>

in the above, renderPriority has no effect and contents of #target will not be updated, since it has an ancestor that prevents any updates. So, it wouldn't cause parents with content-visibility to update themselves.

<div style="content-visibility:hidden" renderPriority="userVisible">
  /* some other content */
  <div id=target></div>
</div>

in the above, #target is updated at userVisible priority since it's just a regular child of a content-visibility, userVisible element.

<div renderPriority="userVisible">
  /* some other content */
  <div id=target></div>
</div>

in the above, everything is updated always (although we're having some discussion about it in #201 ). This is because nothing is preventing the updates in the first place, so it doesn't matter what the renderPriority is (although @chrishtr suggests that maybe this is the first time we can try to have asynchronous visible updates)

So what happens in the following?

<div style="content-visibility:hidden" renderPriority="userVisible">
  /* some other content */
  <div id=target renderPriority="background"></div>
</div>

Since this looks more like the second example, I would lean towards saying that this has no effect in that the contents of the content-visibility element are updated at userVisible priority, and #target being an element in such contents is also updated at userVisible priority. In other words, if content-visibility wasn't present, then this would be very similar to the third example where we just keep everything updated anyway. However, since it is present, we only update it at userVisible priority.

The alternative here is since we're already in some non-immediate level of updates, we can downgrade userVisible to background once we enter #target. However, this would essentially delay having the top level element's updates which sort of violates the userVisible promise. The flip version of this, where the top level is background and #target is userVisible can also make this problematic in that we would upgrade the priority once we reach some child of a background div. That seems that it would violate the background promise and cause more work than needed.

[noahlemen]

The flip version of this, where the top level is background and #target is userVisible can also make this problematic in that we would upgrade the priority once we reach some child of a background div. That seems that it would violate the background promise and cause more work than needed.

This was going to be my follow-up question 🙂

I'd agree that taking the route of these scenarios having no effect seems simpler and less pitfall-prone, especially when considering the inverted-priority case.

[vmpstr]

I think renderpriority is sticking as a name (#205 suggested different case, per guidelines). So I'm going to close this

[andruud]

Agree with @noahlemen that this seems more appropriate for CSS if it's tied (and maybe even if it's only loosely tied) to content-visibility.

Downside there, I suppose, is that we wouldn't be able to articulate priority via a value.

But we have several options to solve that?

• E.g. a new keyword to the property content-visibility: hidden background.
• A new property altogether: content-priority: background. (I like this).
• Possibly with a shorthand which can expand to both: content-whatever: hidden / background.

Having a CSS property for this also has a problem that you can't really apply this to a CSS class. Or rather, you can't have a per-element control without inline style or a very specific selector. I'm kind of leaning towards attribute for these reasons

@vmpstr, I don't understand this argument. You can be as broad or narrow as you like with CSS selectors. It feels pretty foreign that you have to go "elsewhere" to essentially "tweak" content-visibility, especially if that tweak should apply to the same element that content-visibility applies to.