Open Bug 1302328 (houdini-painting) Opened 8 years ago Updated 1 year ago

[META] Implement Houdini CSS Painting API Level 1 spec

Categories

(Core :: CSS Parsing and Computation, enhancement, P3)

enhancement

Tracking

()

Tracking Status
firefox51 --- affected

People

(Reporter: sebo, Unassigned)

References

(Depends on 4 open bugs, Blocks 1 open bug, )

Details

(Keywords: dev-doc-needed, meta, parity-chrome)

      No description provided.
Summary: Implement Houdini CSS Painting API 1 spec → Implement Houdini CSS Painting API Level 1 spec
Version: Trunk → unspecified
Component: DOM → CSS Parsing and Computation
Depends on: 1318573
Ehsan pointed out that we didn't send out the "intent to implement" for Houdini paint.
Flags: needinfo?(bugs)
(In reply to Milan Sreckovic [:milan] from comment #1)
> Ehsan pointed out that we didn't send out the "intent to implement" for
> Houdini paint.

I'll get that sorted. Thanks!
Depends on: 1324740
Priority: -- → P3
Keywords: meta
Summary: Implement Houdini CSS Painting API Level 1 spec → [META] Implement Houdini CSS Painting API Level 1 spec
This API got released with Chrome 65:
https://developers.google.com/web/updates/2018/03/nic65#css-paint

Sebastian
Whiteboard: [parity-chrome]
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-chrome
Whiteboard: [parity-chrome]
Type: defect → enhancement
Depends on: 1624296
Depends on: 1649209
Depends on: 1685228
Severity: normal → S3

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.

You need to log in before you can comment on or make changes to this bug.