Open dirkschulze opened 6 years ago
Filter effects apply to the entire visual rendered element. This is defined by SVGs compositing model.
For scrolling this means that the visual result of the current scrolling effect gets filtered once the general rendering is done. The current result of browsers seems to be consistent generally. Firefox seems to have a re-paint problem. Maybe this is a rendering optimization, performance issue or an actual bug. Either way, after waiting some seconds the visual result of the applied filter looks correct.
But when you scroll and the background-attachment is fixed, then the element still moves out of the viewport. Only the image is fixed to the viewport, so there is the empty area above and below the viewport on that element and I think blur should be applied to that empty area, so the top blur area should move out from the viewport when you scroll down. Like on the right side of this example: https://jsfiddle.net/f1k94ce9/
I think this should be the desired behaviour: https://jsfiddle.net/3bdv532b/ (JavaScript changes the background-position on scroll, so it is a little bit laggy, but you can see the blur moving in and out at the top and at the very bottom of the image)
@rrolandd Ok, so the actual issue you mean is scrolling beyond the viewport bounds and you expect that the filter result should expand beyond those viewport bounds? This doesn't even happen for a background color on the viewport.
Yes, I think filter result on background-attachement:fixed should render beyond the viewport as it does in every other case.
I'm not sure if you have a Mac for testing porpose. Safari has a viewport like every browser does. But the window frame on top is transparent and you can see the page content. That does not belongs to the viewport, but background-attachment:fixed; images are rendered there too. On load when scrollTop is 0: https://i.imgur.com/WcM53Ps.png When I scroll down you can see that the frame is see through to the background image: https://i.imgur.com/e7aK0nJ.png
So I still think that this is how it should work when background-attachement:fixed; applied: https://jsfiddle.net/3bdv532b/
@rrolandd Ok. So your concern is less about scrolling up the page (where the blur gets clipped and just half of the blur is visible) but rather scrolling down and letting the background continue on the top and therefore have no "white" of the backdrop on the top in the vertical direction?
Yes, I think the white backdrop should go out of the viewport in the top direction when you scroll down on the page.
Firefox seems to have a re-paint problem.
FWIW, this was fixed in bug 1300864..
The Working Group just discussed end
.
Including @fantasai @AmeliaBR and @smfr for this discussion.
The spec states already that a filter applies to the element and its ascendants. The spec does specifically take reference of the different paint phases of an filtered element where background is one of them.
Spec text:
The compositing model follows the SVG compositing model [SVG11]: first any filter effect is applied, then any clipping, masking and opacity [CSS3COLOR]. These effects all apply after any other CSS effects such as border [CSS3BG].
"any CSS effect" is meant to include all paint phases as it references the border property specifically. It likely should point this out more clear.
With that I think it is clear that the element gets filtered as a whole including all CSS paint phases. However, I am unsure if it does clarify the issue mentioned here. @fantasai Is the background clipped to any boundaries, like scroll area, viewport or anything else?
After reading (and slowly recollecting) the background spec there are 2 aspects.
border-box
, padding-box
, content-box
). It does not clipped or affected by scroll areas or viewports. At least I couldn't find anything in the spec that would say otherwise.background-attached
CSS property. From what I understand of the spec, it only defines the "origin" of the background but itself has no affect on the background painting area.@fantasai Please correct me if I am wrong, but taking all this into account, the behavior of Safari seems to be correct while the behavior of Firefox, Chrome and Edge is incorrect. The painting area might be outside of the viewport when scrolling a document with an attached background, but there is nothing in the spec that implies that it should be cropped.
Therefore, the expectation of @rrolandd seems to be correct and is following current specification texts.
@dirkschulze I have updated my test code with an image which does not contain white area to prevent misunderstandings: https://jsfiddle.net/ff9d2u3v/2/
Safari 11.0.2 does the same like other browsers in an iframe. Probably they just have an exception to render outside of the viewport at the top of the window.
@dirkschulze I'm not entirely following the details of what's going on here but, yes, the background and border should be painted and then filter applied to the resulting box. If the box itself is scrolled partially out of view then the filter is applied to the whole box including the parts that are out of view. If its contents are scrolled out of view within the element (i.e. the element itself has overflow: scroll
), then such overflow is not part of the filter since it is clipped by the element and then the filter is applied to the element as a unit.
The compositing model follows the SVG compositing model [SVG11]: first any filter effect is applied, then any clipping, masking and opacity [CSS3COLOR]. These effects all apply after any other CSS effects such as border [CSS3BG].
Wrt spec edits, I think there is some confusion as to what “clipping” means in the first quoted sentence--we have multiple operations that involve some sort of clipping-like thing: for example, overflow
and background-clip
have clip-like implications. So I think you should specify more clearly: “clipping via clip
or clip-path
[[!CSS-MASKING]], masking, and opacity”. And also in the second sentence, include things besides border, e.g. “backgrounds, borders, overflow
, transforms, etc.”.
For SVG, I had always assumed that overflow: hidden
was included in the "clipping" step of the rendering model. But based on tests, neither Edge nor Firefox implement it that way. Chrome treats it that way for SVG layout, but not for CSS box layout. For nested SVG, Safari clips after filtering, same as Chrome. But for inline SVG (aka, an <svg>
with CSS box layout), it looks like Safari is clipping overflow twice, once before and once after applying the filter (but I haven't explored the results carefully).
Test case: https://codepen.io/AmeliaBR/pen/aEroyJ/
The SVG layout behavior could be spec'd separately from CSS box layout (which has the complication ofbackgrounds and overflow: scroll
), but given that current behavior is inconsistent, it might be useful to converge on a universal rule.
Either way, some clearer language is required here.
Test case: https://codepen.io/AmeliaBR/pen/aEroyJ/
Latest Firefox and Chrome still disagree how to render the third image on nested vs inline SVGs in this example.
Reported by Roland Soos (https://www.w3.org/Bugs/Public/show_bug.cgi?id=30199):
I have an example where I use
background-attachement: fixed;
andfilter: blur(15px);
on the same element. Currently all browser I tested does the same. Applies blur only to the visible area of the fixed image, which I think is bad as filter should apply to the whole element. You can see the result on this example: https://smartslider3.com/bugs/firefox/blurfixed/test.htmlWhen you scroll down, you should see that a
box-shadow
like effect follows the visible rectangle of the image. I think that effect should stay on the whole div and when you scroll down, it should be visible at the top and at the bottom of the real image only.