Lea: not sure I understand the use case

Kenneth: you have a lot of .. rendering today virtual scrolling - now you can do search in page - and you know that yiu're going to render soon. It's a way to request rendering...

Lea: for pre-rendering of subtrees.

Rossen: It's the oppososite of pre-rendering. not rendering as much as possible - but being ready to paint... There are many different ways you can scroll something into view or close to the view... ways to understand when something is close to the visible viewport... everything else from API point of view is not supposed to be effected. Where things come into friction is to do with accessibility. A different view on top of DOM. Not the same as the render view. In order to complete the correct view .. you need info ready. With this technique in fact some web pages that are too large to hold with a screen reader... this approach will help because you're now reducing the amount of info that goes to the screen reader. Where I pushed back on this - and opened up a design principle issue (new features shouldn't rbeak existing ones) if you want to enumerate all the headings in a doc you can do this today regardless if the heading is visible or not - but here that promise is broken. Things can be parsed but not ready for the accessibility ... So it's a game of trades... Fine line is - how much of a bennefit vs the accessibility risks... We've come a long way in the discussions in various places... The current proposal is mostly there - one remaining issue which is pertaining to one particular value - that still has open discussion. The rest of it .. worked out. It's beneficial to users of regular media as well as those using assistive tech. Grealy improves experience from CPU, memory PoV.

Lea: Why is this a HTML attribute and not a CSS property?

Rossen: we had a long discussion and took it out of CSS and that was feedback that came partially from TAG at the time... It was a CSS wg decision after a long conversation.

Ken: that would be great to know... people will ask.

Peter: sounds like the feature can defer computation of style...

Ken: right and now you can set the priority - that's good for battery performance UX.

Peter: but if you're not computing style on the unrendered content then it can't be a CSS property. At some point the parent will be the root...

Lea: defering rendering doesn't mean necessarilly defering parsing of CSS...

Peter: you don't have to compute style if you know e.g. it's off-screen. You can say "i want to compute the login controls first and the ads last".

Lea: since you have to parse stylesheets anyway...

Peter: you do have to parse but you don't have to match selectors. Seperate computation than parsing the stylesheet. HTML attribute can say "deprioritize this".

Lea: but if you don't compute the selectors...

Peter: if it was a CSS property then you'd have to do the selector matching - that's why it's an attribute.

[some discussion on this point]

Lea: another question - how are authors supposed to use it? Are you supposed to set it on elements or change it when you want it to render?

Ken: you set it beforehand.

Rossen: right.

Ken: but for web components - it would be annoying to have to set this for every element...

Peter: you don't have to set it for everything - this is something you "set and forget".

Ken: in some cases for components you need to set it in many places...

Dan: who is intended to use this? I'm hearing adding complexity to the web platform for a marginal nanosecond gains in performance?

Ken: the display login teams.. web components.. working on small features on the web that you can build web components, scroll in list, find in page, that are going to be really fast. They dont' expect everyone to do their own. If it's not something everyone is going to do and use these componants it's going to be super fast. Have an API that they set globally for every componant of that type. Instead of putting it on the devs using the custom element

Peter: I hear you but not sufficient. Just because an element is used for certain types of things doesn't tell you how it's being used. A custom input could be used for two different things in one page

Ken: change the default.. you can change it if you know what you're doing

Peter: that's reasonable

Lea: how does this attribute behave when nested? render priority user blocking..

Peter: good question - you can increase priority down the tree but increasing priority gets weird?

Dan: what is stopping someone providing third party content through an api (eg. an ad) from saying my ads are the most high priority thing? From hijacking?

Ken: very good point

Lea: also share Dan's concerns about adding complexity with nanoseconcds. Not clear to me the perf gain. Nanoseconds, miliseconds? On a sufficiently large app, what kind of gains?

Peter: I'm thinking about huge pages, understand where it could be seconds

Ken: part of the display locking effort...

Ken: they said they'd update explainer but so fare not...

Dan: leaves comment

Hi @vmpstr,

@cynthia and I discussed this again today in a breakout today. On attribute vs CSS property we definitely think this is more suitable as a CSS property. This way it is easier to use it for creating defaults, including in Web components, and also given that it interacts with other CSS properties.

We are still not sure about certain details of the proposed algorithm, including my question from above about nesting higher priority elements inside lower priority elements.

We would like to see some examples of actually using the feature to target the user needs you are targeting. Are all these values necessary to address these use cases?

closed on feedback from chris H. at Google

marked as "withdrawn"