-
Notifications
You must be signed in to change notification settings - Fork 636
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
[css-contain] content-visibility: auto and SVG-as-image #10347
Comments
Doesn't the SVG width and height define a viewport for This is essentially what Chromium does: anytime we paint an SVG, we set a "viewport" on it into which we paint and update all of its rendering as if that was the viewport (including intersection observer determination for c-v). /cc @progers |
Hmm... does chromium run the whole lifecycle update for SVG images? That seems generally wasteful? Also, what if the image is out of view in the parent document? That'd behave inconsistently with |
I believe Chromium does that yeah (@progers would know for sure). I suspect it's exactly to support cases like this. We're drawing this SVG into a canvas, and then using the pixels for some other reason. It's very disconnected from when we actually use the pixels and presumably we want to treat those pixels as if they were visible when painted.
Can you elaborate on the iframe inconsistency, I'm not sure I follow |
Chrome does run most of the steps for a full animation frame (see: SVGImage::PaintRecordForCurrentFrame), but steps like resize observer are no-ops. Chrome isn't calculating real user viewport intersection for images though, and is just treating the image contents as relevant to the user, regardless of whether the image is on screen. Offscreen content brought on-screen via a filter is considered relevant to the user (spec). I think |
I mean, at least Gecko shares SVG-as-images. A Consider:
IIUC, the content would be "relevant" in both images regardless. While if they were iframes, the content will be relevant in the top iframe, but not in the bottom. So I think that, effectively for this purpose at least, you just ignore |
Chrome does this as well. We need to pass in some context-specific data when drawing the image, such as when two There are are some spec'd differences between svgs in iframes vs svg images, such as how svg image do not allow interaction or script (secure animated mode). Because of the restrictions of svg images, there is almost no observable difference if we just consider them as always relevant to the user vs actually calculating top-level-viewport intersection. |
After the initial, synchronous, viewport-proximity check in update-the-rendering (checkForInitialDetermination), subsequent viewport-proximity is updated in the next rendering opportunity, and so is one frame late. Animations in svg could be used with this one-frame-late aspect to show a user-visible difference between svg-iframe and svg-image content-visibility behavior. Because of this, and |
That seems reasonable. Honestly I am a bit surprised about this use case as a whole, but that is trivial to implement and easy to test too. |
I am also surprised about this case -- it took a big of digging to figure out what Blink was doing. I also support making svg-as-image cases always relevant |
Over in Mozilla bug 1894546, we got a report about something like an (invisible) SVG image rendering
content-visibility: auto
elements in Chromium but not Firefox / Safari.Off-hand, I think per spec it is invalid. At least, I don't see how the viewport checks would run, since they run from the "update the rendering" steps in HTML.
I think that bug is invalid, but seems worth double-checking... @vmpstr do you know what's going on in Chromium? Should I file a Blink bug? Have I missed something that should make that work per spec?
The text was updated successfully, but these errors were encountered: