Comments (9)
Doesn't the SVG width and height define a viewport for content-visibility
within that image?
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
from csswg-drafts.
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 <iframe>
unless I'm missing something.
from csswg-drafts.
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.
content-visibility
aside, Chromium does it also because of paint culling that we do for offscreen content. We basically want to ensure when we draw the SVG into a canvas in this way, the culling is not cutting off any paint.
Can you elaborate on the iframe inconsistency, I'm not sure I follow
from csswg-drafts.
does chromium run the whole lifecycle update for SVG images?
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 ctx.drawImage
should work similarly.
from csswg-drafts.
I mean, at least Gecko shares SVG-as-images.
A content-visibility: auto
element in an iframe will, IIRC use an IntersectionObserver
-like check to intersect with the top level viewport. But that doesn't work if your image can be painted in multiple places and the data is shared.
Consider:
<!doctype html>
<img src="foo.svg">
<div style="height: 5000px"></div>
<img src="foo.svg">
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 content-visibility: auto
(everything is relevant in an SVG image, kind of)
from csswg-drafts.
I mean, at least Gecko shares SVG-as-images.
Chrome does this as well. We need to pass in some context-specific data when drawing the image, such as when two <img>
s reference the same svg but have different sizes (code). It would be technically possible to include top-level viewport intersection in this context-specific data.
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.
from csswg-drafts.
almost
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 ctx.drawImage
, I think it would be useful to specify whether svg-as-image is always relevant to the user (I am in favor).
from csswg-drafts.
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.
from csswg-drafts.
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
from csswg-drafts.
Related Issues (20)
- [anchor-position] CSS anchor position gap HOT 6
- [cssom-view] Proposal: Document.elementsFromRect()
- @media queries on mobile + zoom and media queries don't re-evaluate on zoom
- Feature: Display:Grid: grid-temp-col*: repeat+[set](autofill, min-column-width, max-column-width , bias-change, max-repeat) = repeat(auto-fill, 30rem, 40rem, min, 5)
- CSS Attribute presence and value selectors - Numerical Comparison <,>,<=,>=,== bitflagsOps + inspect width, height HOT 1
- CSS [parent-element]:nth-[attrib/class]-child[attrb+op+val](nth [BitflagOps] [value] ) Selectors for Display:Grid
- Viewport Meta - Property => Max-Element-Width: 800px or 40rem or width=device-width+inflation
- CSS: element property : device-overflow-inflation-width + device-overflow-inflated-width HOT 1
- Feature: @Container support zoom and re-evaluation of queries on mobile
- Feature: Display:Grid -> grid-[auto/section]-[flow/align]: row-reverse, column-reverse (Right to Left) languages + Grid: Relative Plus Modifier
- [selectors] Add selector match custom element
- [css-anchor-position] could anchor()'s side argument be optional?
- [css-anchor-position] Ability to provide multiple anchor-elements to try for position-anchor property and other anchor functions
- [css-anchor-position] Should scroll-margin/padding have an effect on position-visibility: anchors-visible? HOT 1
- [css-anchor-position] An ability to have a transition for `position-visibility`'s hidden effect HOT 1
- [css-anchor-position] The containing block should be allowed as an acceptable anchor element
- [css-color-5] Should intermediate out of range values be preserved in color-mix?
- [css-color-5] Missing forms to use to serialize color-mix and relative color HOT 1
- [css-cascade-6] Enable `revert-layer` layer limiting and fallback values
- Position of the text-overflow ellipsis
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from csswg-drafts.