Bug 273208 – Filters on multi-column layout result in bad rendering

• Status: NEW
• Component: Layout and Rendering

CSS-filters break the box-model!
In my case I’ve built a page with a footer-Area. It ist there for some additional text. And as it might have a wide inline-size, I gave him columns.
Then I made a hoovering-area in some corner of the page. Its elements represent sth. like versioning: if you hoover over element „x“, the page shall give you a big hint where the version-„x“ infos are to find.
I decided to do that with a filter:

```
footer {
	padding- …
	margin- …
	columns: 5 40ch;
	column-gap: 24pt;
	column-fill: balance-all;
	overflow: auto hidden;
}

…

body:has(version-section ol > li:nth-child(1):hover) [version="0"],
body:has(version-section ol > li:nth-child(2):hover) [version="1"],
body:has(version-section ol > li:nth-child(3):hover) [version="2"],
body:has(version-section ol > li:nth-child(4):hover) [version="3"] {
	&[version] {
		outline-style: solid;
		filter: grayscale(0);
		transition: filter 1s ease-in-out;
		animation: blinker 1s ease-in-out infinite alternate;
	}
}
@keyframes blinker {
	from { filter: invert(0%); }
	to { filter: invert(100%); }
}
```

Doesn’t look look bad. But: when hovering over „version y“, the paragraphs don't flow in the columns, they break their styling and insist to be a pure block-element running down (and so will not be shown in their full size: the footer area is set to scroll horizontally).

Tested the page with an actual firefox. No rules to make differences, both get the same html and same css rules. Firefox does filter the columns as expected. And it doesn't tend to an empty column at the end.


BTW: Columns don’t look really good as they tend to have at least an empty column at the end! And: who made the routines for drawing column rules? Resize the area with columns and get some vertical strike throughs! …

Hey, what’s that? while I’m writing here, my page with all this hovering things behind this window: sometimes(!) when moving my mouse INSIDE the active window, the hoover-event is beamed through this window and toggles the elements in the back window! Click-trhough is sth. to be discussed. But hoovering-through? Is this another idea of Sirius cybernetic? Because people are to blind to see: every web-page MUST be blurry as EVERY single pixel must be anti-aliased. Or: who has an 96dpi-Monitor? And what’s the distance, the user is looking at it? (https://www.w3.org/TR/CSS22/syndata.html#length-units at the end, just before https://www.w3.org/TR/CSS22/syndata.html#percentage-units). Long lives the kings body, beware of the effects of https://en.wikipedia.org/wiki/Gravitational_wave, when this body fades away and the new measures are slated to the size of asses …

Oooops! Broke my CSS. Should be

```
footer {
	padding- …
	margin- …
	columns: auto 40ch;
	column-gap: 24pt;
	column-fill: balance-all;
	overflow: auto hidden;
}
```

[Simon Fraser (smfr)]

Could you give us access to your page, or attached a reduced copy? Thanks!

The page is not online. It’s a mixture of private infos and my “try to master HTML+CSS (without JS)”.
So I’ll try to build a small example. But for me now it’s very late. So you will have to be a bit patient. Maybe tomorrow this time, maybe at the weekend …

Created attachment 471153 [details]
Stylesheet for the example

Created attachment 471154 [details]
Some HTML to run the show

Ok, “here you are”. You? Well, they are.

[Karl Dubost]

Created attachment 471157 [details]
testacse reduction 01

This will need to be reduced a bit more. 
In my progress in reducing. Not yet there.

[Karl Dubost]

Created attachment 471158 [details]
rendering in safari, firefox, chrome

fwiw, the rendering is the same in Safari and Chrome
different in Firefox.

[Simon Fraser (smfr)]

Karl, this bug was filed about filtering. Are you distracted by unrelated differences in grid/multicol?

Yes, I found this after using filter. But: the effect of this filtering is the difference in the rendering! If filter comes up to work, the container doesn’t show columns for the filters elements!
Firefox keeps the column layout. And as I do not see a rule, saying “change the boxing model”, I think, firefox does this correct. Not Safari and others.

[Karl Dubost]

@Simon, I tried initially to reduce to Filter and multi-column but without success. 
Too many moving pieces.

[Karl Dubost]

Created attachment 471209 [details]
initial testcase

Let's recreate the initial test as submitted by stevestasteislost

[Karl Dubost]

Steps to reproduce:

1. Go to https://bugs.webkit.org/attachment.cgi?id=471209
2. Hover on Version A, Version B, Version C at the bottom right of the page
3. Observe the columns beside

Results:
When hovering Version B, the top text on the second column disappears on both Safari and Firefox.
It stays in place on Chrome.

Safari and Firefox are the same for this part.

[Karl Dubost]

Created attachment 471210 [details]
screen recording on activation hover in web inspector

We can see what is happening with this screen recording on hover.

[Karl Dubost]

With hover:
 
=============================================
version-section {
     & ol {
        & > li {
            padding-block: 0.125lh;
            padding-inline: 3ch;
            color: rgb(250 50 50 / 0.3);
        }
    }
}
 version-section {
     & ol {
         & > li {
            &:hover {
                color: rgb(255 100 100 / 1);
                opacity: 1;
            }
        }
    }
}
=============================================



Without hover:
=============================================
 version-section {
     & ol {
        & > li {
            padding-block: 0.125lh;
            padding-inline: 3ch;
            color: rgb(250 50 50 / 0.3);
        }
    }
}
=============================================



Disabling in

body:has(version-section ol > li:nth-child(1):hover) [version="0"], body:has(version-section ol > li:nth-child(2):hover) [version="1"], body:has(version-section ol > li:nth-child(3):hover) [version="2"], body:has(version-section ol > li:nth-child(4):hover) [version="3"] {
    filter: grayscale(0);
    transition: filter 1s ease-in-out;
    animation: blinker 1s ease-in-out infinite alternate;
}


this rule:
    animation: blinker 1s ease-in-out infinite alternate;

fixes the issue. 

But Safari is losing obviously the visual animation. 
So the background blinking shadowy color is what seems to modify the content here. 


aka 

@keyframes blinker {
	from { filter: invert(0%) drop-shadow(3px 3px 2px red); }
	to { filter: invert(25%) drop-shadow(3px 3px 2px blue); }
}

ok let's get rid of the animation. 

And just try two states:

ok if I set a value different from grayscale(0) on 

body:has(version-section ol > li:nth-child(1):hover) [version="0"], body:has(version-section ol > li:nth-child(2):hover) [version="1"], body:has(version-section ol > li:nth-child(3):hover) [version="2"], body:has(version-section ol > li:nth-child(4):hover) [version="3"] {

/* THIS HERE */
    filter: grayscale(0);

    /* transition: filter 1s ease-in-out; */
    /* animation: blinker 1s ease-in-out infinite alternate; */
}

the top of the 2nd column disappears. When I put it back to 0. It takes *too much time* to reappear.

[Karl Dubost]

Created attachment 471213 [details]
reduced test case exhibiting the issue

@Simon Here a reduced test case

OK this is an interaction between filters, overflow and columns.
With also strange behaviour if the window is in focus or out of focus.

[Karl Dubost]

Created attachment 471214 [details]
screen recording

There's even a funny behavior where clicking on the area reveals the hidden text.

[Radar WebKit Bug Importer]

<rdar://problem/127276606>

> OK this is an interaction between filters, overflow and columns.
> With also strange behaviour if the window is in focus or out of focus.

More fun? I couldn’t make it reproducible. But maybe it has something in common? See the last paragraph of my opening in https://bugs.webkit.org/show_bug.cgi?id=273208

Created attachment 471309 [details]
Two pieces of inspectors view at my “new” code with filter and :hover

I just found something else, maybe related. If you look at the attachments, you see a close-up into inspector. The one without “unsupported” mark is the normal state of the element. But if I hoover over it, I geht this “!“. With hovering Safari doesn’t like multiple transition-things (not only the shown), if the element should filter.