Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Contain:strict breaks css counters #4027

Open
5e-Cleric opened this issue Feb 4, 2025 · 1 comment
Open

Contain:strict breaks css counters #4027

5e-Cleric opened this issue Feb 4, 2025 · 1 comment
Labels
bug We say this works but it doesn't P1 - high priority Obvious bug or popular features

Comments

@5e-Cleric
Copy link
Member

The Contain property was set to size previous to this version, but it was set to strict in #3965 . This property is isolating pages, which in time makes CSS counters impossible to use, as per the documentation:

  • style
    This value turns on style containment for the element. This ensures that, for properties which can have effects on more than just an element and its descendants, those effects don’t escape the element.

  • strict
    This value computes to size layout paint style, and thus turns on all forms of containment for the element.

We may look for lighter forms of performance optimization, as not to break existing features. This property should be removed whenever possible, and perhaps set as an extra setting that must be turned on by the end user with acknowledgement of the consequences.

@dbolack-ab dbolack-ab added the bug We say this works but it doesn't label Feb 4, 2025
@calculuschild
Copy link
Member

calculuschild commented Mar 10, 2025

Appears to be at least one report on Reddit:

https://www.reddit.com/r/homebrewery/comments/1j7acgt/bug_or_just_me/

If someone wants to test some different configurations on this test brew to see if we can get a case with good performance but not breaking CSS counters: Test Brew

Easiest way I think to see the speed difference is using the zoom tool in the toolbar.

@calculuschild calculuschild added the P1 - high priority Obvious bug or popular features label Mar 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug We say this works but it doesn't P1 - high priority Obvious bug or popular features
Projects
None yet
Development

No branches or pull requests

3 participants