Re: [csswg-drafts] [css-contain] content-visibility: auto and SVG-as-image (#10347)

The CSS Working Group just discussed `[css-contain] content-visibility: auto and SVG-as-image`, and agreed to the following:

* `RESOLVED: treat content-visibility:auto as visible inside of SVG Image documents`
* `RESOLVED: when printing a document, also treat content-visibility:auto as visible`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> emilio: someone was using &lt;foreignObject> inside of svg-as-image with content-visibility:auto on it<br>
&lt;TabAtkins> emilio: spec isn't super clear... c-v:auto determination happens on the html rendering loop<br>
&lt;TabAtkins> emilio: not clear when and how that happens for svg images<br>
&lt;TabAtkins> emilio: for gecko and webkit it doesn't seem to happen in the rendering loop<br>
&lt;TabAtkins> emilio: so in gecko/webkit, c-v:auto remains hidden<br>
&lt;TabAtkins> emilio: It also isn't clear what that would mean for svg images actually attached ot the document<br>
&lt;TabAtkins> emilio: like using canvas<br>
&lt;TabAtkins> emilio: I think the simplest fix is to say that c-v:auto behaves as visible on svg images<br>
&lt;TabAtkins> emilio: they're generally not dynamic anyway, you can't run script<br>
&lt;TabAtkins> emilio: so I think that's a simple answer to the question, trivially implementable. and aligns with chrome.<br>
&lt;TabAtkins> emilio: so proposal to treat c-v:auto as visible in SVG Image documents<br>
&lt;TabAtkins> TabAtkins: the html rendering loop handles inline svg, right?<br>
&lt;TabAtkins> emilio: Yes, and iframes. just not svg images.<br>
&lt;vmpstr> +1 to the proposal<br>
&lt;TabAtkins> astearns: questions or concerns?<br>
&lt;TabAtkins> astearns: objections to the proposal?<br>
&lt;ydaniv> +1<br>
&lt;emilio> q+<br>
&lt;TabAtkins> RESOLVED: treat content-visibility:auto as visible inside of SVG Image documents<br>
&lt;TabAtkins> emilio: another thing i just thought of, similar issue with lazy-loaded images<br>
&lt;TabAtkins> emilio: long-standing issue across engines<br>
&lt;TabAtkins> emilio: what to do about printing of lazy-loaded images<br>
&lt;TabAtkins> emilio: should we do the same for printing? un-hide them?<br>
&lt;TabAtkins> emilio: you could argue that for c-v:auto you should treat it as visible<br>
&lt;TabAtkins> emilio: might be worth discussing in a separate issue<br>
&lt;TabAtkins> emilio: Printing is just another palce that doesn't go thru the normal rendering loop<br>
&lt;fantasai>  /win 15<br>
&lt;bramus> TabAtkins: in a meaningful sense you print a viewport sized to the entire document spread across pages<br>
&lt;fantasai> s|/win 15//<br>
&lt;bramus> … for purpose of cv auto I agree with you<br>
&lt;fantasai> s|/win 15||<br>
&lt;TabAtkins> emilio: I'm happy to propose that, or we can take it to another issue<br>
&lt;TabAtkins> astearns: so if printing is defined as printing in a large viewport<br>
&lt;TabAtkins> astearns: isn't it already defined?<br>
&lt;bramus> TabAtkins: its not actually defined that way. The viewport while printing is page based. For prupose of cv auto its as is full document is in viewport<br>
&lt;TabAtkins> astearns: So does anyone have objections to resolving on this?<br>
&lt;emilio> ack emilio<br>
&lt;TabAtkins> RESOLVED: when printing a document, also treat content-visibility:auto as visible<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10347#issuecomment-2165576895 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 13 June 2024 12:53:52 UTC