I'm sorry if this is not the correct place to discuss implementation priority. I am under the impression that [META] invites general discussion.

I have a strong use case for the Painting API part of the Houdini spec. I develop a cross-browser highlighting add-on Mark My Search (https://github.com/searchmarkers/mark-my-search) which is an advanced tool to highlight searched keywords in different colours. The classic way to do this has always been to tamper with the DOM of every website, inserting highlight box elements into text flows - however, this is unsuitable for the modern web, and I can only see it getting less viable.

Problems:

• The web is increasingly dynamic. We need to respond to DOM mutations to keep highlighting up-to-date, but this problem is exacerbated by the fact that highlighting creates vast numbers of mutations. We can avoid responding to these ones by recognising them, but feedback loops can occur in which a page's response to the change is to make more changes.
• Page JavaScript very frequently relies on parts of a webpage being a particular way. When disrupted, this can have often invisible effects on the page's scripting, and commonly causes visible disruption to its layout as a script modifies text which has now been changed by highlighting.
  • Some of the worst examples of this come from websites that have built-in scripting solutions and markdown renderers, in which the effects are abhorrent and unreadable.
• CSS is unavoidably disrupted, resulting in confusing effects such as single text flows laying out in multiple lines, and having CSS-applied capital letters in the middle of a word.
• DOM modifications are heavy, and by intrinsically changing the text to add elements we sometimes slow the page to a crawl, regardless of vigilant optimisation.

Many add-ons function this way, and all suffer to an extent because there is no workable alternative. I have tried other solutions but none are satisfactory: drawing percent-encoded SVGs on element backgrounds is slow and blocked by many content security policies; and using the element() CSS function is non-standard and extremely slow since we must still create elements that are hidden in a different part of the document tree. That's where CSS Painting comes in.

I have entirely reproduced highlighting functionality using CSS Painting in Chromium. It is fast, does not slow down pages even in very intensive cases such as highlighting every letter of the alphabet - whereas equal DOM-based highlighting can make it freeze for 30 seconds at a time - and makes it possible to highlight lazily in multiple stages. Crucially, it never affects the functioning of a dynamic webpage, rendering it fully suited to the modern web. Developers are enabled to create add-ons that truly extend a webpage with minimal destructive changes, as opposed to making something with increasingly adverse effects - even possibly causing data loss - with the direction of the modern web.

There are certainly more use cases in a similar vein that could benefit from such an approach, especially ones which mark out areas for user attention.