05:25:33 RRSAgent has joined #svg 05:25:37 logging to https://www.w3.org/2025/10/02-svg-irc 05:39:51 Vinay has joined #svg 05:43:43 karlcow has joined #svg 05:44:48 present+ 05:45:23 scribe: Dirk Schulze 05:45:44 scribenick: krit 05:46:03 dmangal has joined #svg 05:46:20 present+ 05:49:23 present+ 05:49:37 topic: [css-sizing-3][css-values-4] Define width and height CSS values for SVG Elements in a mapping 05:49:42 https://github.com/w3c/csswg-drafts/issues/12376 05:50:11 q+ 05:50:17 dmangal 05:50:38 dmangal: Defioning view port related length, with sizing. 05:51:00 Ragvesh has joined #svg 05:51:05 present+ 05:51:31 dmangal: follow-up on last weeks discussions. CSS length attributes can take sizing like v-min, v-max with resolution depending on viewport. SVG elements do create their own viewbox thow. Which viewbox to use? 05:52:03 dmangal: outer SVG elements should use ICB but inner elements use viewbox of SVG eleemtns. So ICB is not clear. 05:52:25 dmangal: Viewbox related elements should be aligned to ICB or browser viewbox. 05:52:44 dmangal: most browsers do that but got pushback: what happens on an iframe? 05:53:07 dmangal: will the viewbox be the viewbox of browser window or iframe? 05:53:24 dmangal: other proposals got rejected as well. 05:54:15 https://www.w3.org/TR/CSS2/visudet.html#containing-block-details 05:54:17 dmangal: For SVG editors it will be the SVG documents width and height 05:54:32 rrsagent, make logs public 05:54:38 krit: What was the proposal on teh Iframe? 05:54:59 dmangal: If we resolve the viewbox on browser window, iframe dimensions can be shorter. 05:55:34 dmangal: bounds will still be browser window bounds and not iframe 05:55:52 Ragvesh: not sure if that would be correct? 05:56:12 dmangal: most browsers only resolve ICB with browser windows bounds. 05:56:45 krit: lets define what browsers do already? 05:57:35 dmangal: people disagreed. We want to add something in the spec that is more "correct". No conclusion what would be correct. 05:57:56 karlcow: Not easy to change interop behavior of browsers. 05:58:04 karlcow: a change might break existing content 05:58:14 karlcow: there is no versioning 05:58:39 karlcow: not in favor for a new definition not already implemented in browsers. 05:58:55 dmangal: made this experience as well 05:59:52 krit: more in favor of defining interop 06:00:38 dmangal: CSS is not talking about browser window but ICB we don't have that for inner SVG. 06:01:23 https://svgwg.org/svg2-draft/coords.html#ViewportSpace 06:01:42 > The initial viewport's width, must be the value of the width presentation attribute on the outermost svg element, unless the following conditions are met: 06:01:59 dmangal: initial proposal was resolving to nearest SVG viewport. Percentage does this already though. 06:02:41 dmangal: especially Firefox was opposed because it is doable with percentage already. 06:02:54 Ragvesh: nearest viewport makes sense to me 06:03:08 dmangal: roots SVG element was one suggestion 06:03:29 dmangal: but no consensus there either 06:04:10 dmangal: browsers usually use root SVG for ICB today. 06:04:26 dmangal: this is common in all 3 browser engines. 06:04:57 krit: here again: IMO makes more sense to define the current implemented behavior. 06:05:21 dmangal: we still need to define it in a logical way in SVG. 06:06:30 https://github.com/w3c/csswg-drafts/issues/12376 06:08:01 karlcow: we should open an issue on SVG spec and resolve the correct term in SVG itself and define the terms here. 06:08:51 resolution: We resolve units against ICB when available or SVG viewport of outer SVG root element. dmangal will clarify which terms to use with CSS WG. 06:09:07 topic: ::selection and other highlights in SVG 06:09:12 https://github.com/w3c/svgwg/issues/894 06:09:50 q- 06:10:00 karlcow: Selection of text element with ::selection here you get different behaviors on different browsers 06:10:25 karlcow: If you use colour, it doesn't work in SVG 06:10:38 karlcow: because we use the fill propoert for filling test. 06:10:42 s/test/text/ 06:11:21 karlcow: color: green does nothing in safari or chrome but with fill: green it shows green in Safari and Chrome and black in Firefox. 06:11:38 karlcow: FF seems bizar 06:12:41 krit: With currentColor you get the color in fill. If fill is not defined, it should use the initial value. What is it for fill? 06:12:46 karlcow: it is black 06:13:39 ::selection {color: green} 06:13:47 krit: so then the text should be black. If not specified it should use black (the inital value) 06:14:13 karlcow: the exmaple ::selection {color: green} is working on FF 06:14:14 ::selection {fill: green} 06:14:22 Tav has joined #svg 06:14:28 karlcow: Chrome and Safari only work with ::selection {fill: green} 06:15:04 ::selection {background-color: gold} 06:15:40 karlcow: the intention is to fill the selected text with the specified color. background-color does work even on SVG elements. 06:15:49 text {color: green} 06:16:03 text {fill: green} 06:16:41 karlcow: So background-color does work even on SVG elkements but color doesn't (in the way as for HTML elements, only via currentColor) 06:17:07 Ragvesh: In Chromium, for text, the pseudo element doesn't work (like ::first-letter) 06:17:22 Ragvesh: so maybe the behavior in FF is more reasonable? 06:18:09 karlcow: but selector is workin in general, it is only the difference for using the fill and color on SVG element. I wonder which one is right? 06:19:02 krit: so fill: green would not work in FF? 06:19:16 karlcow: no, it is black. 06:19:29 krit: what about stroke and stroke-width? Is that working in FF 06:19:33 karlcow: didn't try 06:19:46 https://wpt.fyi/results/css/css-pseudo/svg-text-selection-002.html 06:20:02 http://wpt.live/css/css-pseudo/svg-text-selection-002.html 06:20:13 taher has joined #svg 06:22:16 krit: We should create a test on stroke. My feeling is we should use fill and stroke for SVG text as specified for non-selection behavior. But lets see if FF even supports stroke. If not, it is rather an implementation issue in FF. 06:22:38 karlcow: I'll test more and get back 06:23:44 dmangal: stroke seems to work on FF and Chrome 06:23:57 dmangal: having a test case. 06:24:37 resolution: karlcow getting back with more tests and open an issue on Firefox for further discussions. Then get back to SVG WG. 06:25:19 topic: references to CSS specs in SVG2 06:25:41 Tav: Which specs do we update links to. Do we go to CSS Colors 4 as well? 06:26:31 krit: All CSS specs should be update to the latest versions in SVG, not just sizing but colors and others too. 06:27:14 Tav: what about CSS gradients as fill/stroke on SVG elements? Would that be supported too? Especially interpolation and color spaces is missing in SVG gradients. 06:29:06 resolution: Tav to create a github issue on CSS gradients in fill/stroke. All vendors shall get back to their teams and discuss this. 06:29:44 Vinay: Adoption might not be very welcome by browser implementers. Stroke does not work with text decorations in any browser. 06:31:26 Vinay: will comment on Tavs github issue with examples 06:31:38 RRSAgent, make minutes 06:31:40 I have made the request to generate https://www.w3.org/2025/10/02-svg-minutes.html krit 06:32:10 RRSAgent, make log public 12:23:47 Zakim has left #svg 14:18:37 Teukka has joined #SVG