06:42:44 RRSAgent has joined #svg 06:42:49 logging to https://www.w3.org/2026/02/05-svg-irc 06:42:49 ydaniv has joined #svg 06:42:52 Zakim has joined #svg 06:43:21 present+ 06:43:23 Meeting: SVG WG Meeting 06:43:31 scribeNick: krit 06:46:02 Vinay has joined #svg 06:46:08 dmangal has joined #svg 06:46:16 FYI: the real state of the spec is at https://w3c.github.io/svgwg/svg2-draft/ until we get the possibility to publish on svgwg.org domain 06:46:28 present+ 06:46:32 present+ 06:46:35 present+ 06:46:41 present+ 06:47:37 topic: Should width and height apply to nested svg elements as CSS properties 06:47:39 https://github.com/w3c/svgwg/issues/1057 06:47:50 nzimmermann has joined #svg 06:48:40 dmangal: Chromium starts applying CSS properties for width/heighth on svg elements 06:48:55 dmangal: No styling gets applied and we got a lot of feedback. 06:49:15 dmangal: Initially we started to adviocate for the feature but there were to many 06:49:42 dmangal: We disabled the feature. Safari and FF do not support it 06:50:06 krit: clarification question: inside of elements? 06:50:09 dmangal: yes 06:50:18 Neha has joined #svg 06:50:25 scribe+ 06:50:29 present+ 06:50:36 oops, sorry 06:50:38 present+ 06:50:43 scribe_ 06:50:45 scribe+ 06:50:51 present+ 06:50:54 krit: I am not sure if we meant to be applied for nested elements 06:50:55 q+ to ask about svg/svg? 06:51:33 krit: spec doesn't mention outer most SVG element? 06:51:54 dmangal: No it does not 06:52:12 krit: Can you add more info about the rendering issues 06:52:23 karlcow__: there are examples on the ticket 06:52:35 karlcow__: some examples were completely incorrect. 06:52:50 viralipurbey has joined #svg 06:52:52 dmangal has joined #svg 06:52:54 https://issues.chromium.org/issues/449170647#comment7 06:52:54 present+ 06:53:32 nzimmermann: IMO the spec in 7.8 (sizing properties) "are used for SOME SVG elements"... 06:54:15 nzimmermann: IMO it was a nice idea but should never have applied to any other elements other than outer SVG elements. 06:54:40 nzimmermann: For rect it is not eval but for SVGSVGElement it is. 06:55:25 nzimmermann: I think we should explicitly exluce non-outer SVG elements. Including foreignObject. rect is relatively fine but for none of the other elements. 06:57:27 nzimmermann: it is mostly about web compatibility with existing content that applies svg { width: 100%, height: 100% }. This was inteded to only apply to outer SVG elements for those devs. So we are breaking a lot of existing content. So the issue is not supporting it from a technical perspective -- it would be possible. My concern is only about web compat 06:57:30 s/exluce/exclude/ 06:58:03 S/inteded/intended/ 06:58:35 dmangal: According to spec, the width/height for inner outer SVGSVGElement, Rect, foreignObject and use 06:59:40 ydaniv: And view eleement? 06:59:45 krit: is that in SVG 2? 07:00:02 https://w3c.github.io/svgwg/svg2-draft/linking.html#ViewElement 07:00:03 karlcow__: It is there but doesn't have width/height 07:01:24 dmangal: rect and image are probably fine 07:01:50 https://w3c.github.io/svgwg/svg2-draft/struct.html#UseElement 07:02:19 > The x, y, width and height geometric properties specify the positioning of the referenced element. The width and height attributes only have an effect if the referenced element defines a viewport (i.e., if it is a ‘svg’ or ‘symbol’); if so, a value other than auto for the ‘use’ element overrides the value of the corresponding geometric property on that element. 07:02:19 > A negative value for width or height is invalid and must be ignored. If width or height is zero, and the properties have an effect on the referenced element, then rendering of that element will be disabled. 07:02:48 https://w3c.github.io/svgwg/svg2-draft/struct.html#SymbolElement 07:02:56 nzimmermann: The use element already talks about the connection to CSS sizing eventhough not explicitly referring to it 07:03:04 > The x, y, width, and height geometry properties have the same effect as on an ‘svg’ element, when the ‘symbol’ is instantiated by a ‘use’ element. In particular, if width and height compute to auto (and are not over-ridden by values on the instantiating ‘use’ element), then they will be treated as a value of 100%. 07:03:28 https://chromestatus.com/metrics/feature/timeline/popularity/5730 07:03:52 nzimmermann: Can we support width/height on use at least? Same behavior for rect? 07:04:00 Also https://w3c.github.io/svgwg/svg2-draft/struct.html#UseLayout 07:04:02 dmangal: See example why I am not in favor. 07:05:23 dmangal: For inner SVGs and use, symbol we won't honor CSS width/height. For Rect, Image, foreignObject and outer SVG elements, the CSS properties will be honored. 07:06:07 https://svgwg.org/svg2-draft/geometry.html#Sizing 07:06:18 krit: how can we easily categories these elements to make it easier to understand which elements do honor CSS properties of width/height? 07:06:34 dmangal: can we add a reference to sizing? 07:06:46 karlcow__: The idea is, can we simplify? 07:07:41 nzimmermann: we could copy the section on each of the effected elements but it would be easy to miss. We should add it in the general section, references directly by the individual elements? 07:08:19 viralipurbey6 has joined #svg 07:08:34 nzimmermann has joined #svg 07:08:35 krit: I am fine with this compromise too 07:08:42 viralipurbey8 has joined #svg 07:09:51 proposed Resolution: The CSS width/height properties are honored as presentation attributes for rect, image, foreignObject and outer-SVG elements and ignored by all other elements with the width/height attributes. 07:10:24 RESOLUTION: The CSS width/height properties are honored as presentation attributes for rect, image, foreignObject and outer-SVG elements and ignored by all other elements with the width/height attributes. 07:10:49 ACTION: dmangal to update specification text 07:11:04 topic: SVG path animation: unclear behavior for from + by when commands mismatch 07:11:08 https://github.com/w3c/svgwg/issues/1056 07:11:41 viralipurbey: Using from/by animations on the d attribute. 07:12:06 viralipurbey: When animation values are incompatible, the animation should fall back to discrete animation. 07:12:22 viralipurbey: this is not clear for from/by animations on d path. 07:12:45 viralipurbey: should the render the from value/by value? 07:13:03 viralipurbey: Firefox is not rendering anything. 07:13:35 viralipurbey: It reads it as animation. This feels reasonable. Other engines may take a different decision as we do not talk about additive animations in the spec. 07:13:55 viralipurbey: so either renderers should render nothing or fall back to from/by values. 07:14:10 nzimmermann: Did you spec the original SMIL specification? 07:14:18 viralipurbey: I went thought the spec. 07:15:31 viralipurbey: We can not use the original SMIL animation as it does not apply to d. But I would interprete it as discrete animation. But it too does not mention additive animations with mismatching values for from/by. 07:16:12 nzimmermann: I agree with you. If there is no valid use case, having an error is better than defining a behavior. This is much easier to spot for developers. IMO it is a good point. 07:17:02 Is it part of https://svgwg.org/specs/animations/ ? 07:17:10 krit: should we really not render the element at all in case of error? 07:17:22 nzimmermann: no, it is about not applying the animation 07:17:54 viralipurbey: I actually mean not to render as it is easier to spend. During animation it should not render anything. 07:18:28 https://svgwg.org/specs/animations/#FromAttribute 07:18:31 nzimmermann: well in that case there is no value to start from. So they can't render anything. This is specific. 07:18:54 nzimmermann: not rendering at all would be against the spirit of the SVG spec 07:19:28 karlcow__: I haven't tried it yet. But there is a different spec: Web Animations. 07:19:43 dmangal has joined #svg 07:20:34 viralipurbey0 has joined #svg 07:20:47 karlcow__: may the answers be in that spec. 07:22:45 SVG Animations is not listed as a deliverable in our charter either 07:24:04 viralipurbey: For from/by animations or additive animations, if we have incompatible values, the animation should be canceled and rendering falls back to the base value for the time of the animation. Even after the animation, the base value should be used. 07:24:20 krit: simplified: animation has no effect? 07:24:22 viralipurbey0: yes 07:25:33 https://w3c.github.io/svgwg/svg2-draft/animate.html 07:25:49 q+ 07:25:54 Q- 07:26:05 nzimmermann: There is SMIL, SMIL3, SVG Animations, Web Animations, CSS Animations/Transitions... what should be referenced by SVG2? WebAnimation has nothing from SMIL. So where would we reference the animations? No on uses SMIL as a reference anymore. Do we even investigate into SMIL? Should we discourage the use of SMIL? 07:26:41 karlcow__: I don't think we are in a state where we are looking into animations. Our task is to work on SVG2. 07:27:08 karlcow__: I don't think we can take other things. 07:29:02 Web Animations Level 1 https://drafts.csswg.org/web-animations-1/ 07:29:06 krit: We still need to specify what we stand to to SVG Animations: 1. don't support it anymore? 2. frozen to SVG 1.1? 3. Replaced by CSS Animations? 07:29:24 nzimmermann: Animating colors has a complete replacement in CSS. 07:29:32 nzimmermann: transform has a full replacement 07:29:52 nzimmermann: there is animation attributes possible 07:30:04 nzimmermann: there is CSS Motion for d attribute 07:30:35 nzimmermann: we won't have matching support for everything but to what extend is CSS attribute animation possible? 07:30:48 nzimmermann: IMO CSS covers 90% of real use cases for animations 07:31:06 ydaniv: SMIL animations are deprecated. This has been stated for a while. 07:31:18 ydaniv: SMIL should be considered deprecated. 07:31:33 ydaniv: there is a lot you simply can't do with SMIL 07:31:51 ydaniv: clearly the path forward is facing to CSS 07:31:59 ydaniv: SMIL is already behind in many ways 07:32:23 ydaniv: best way forward is more presentational attributes where it works and animate with CSS. 07:33:06 ydaniv: sequencing is still missing for web animations. Which is one gap on CSS yet. But we should continue the work in Web Animations. 07:34:56 ydaniv: There are still many ppl using SMIL. 07:35:35 Need to jump to another meeting. 07:35:36 Wondering if we need to guide of equivalence in between SMIL/SVG -> CSS animations. 07:35:47 nzimmermann: Would suggest: 1. depricate SMIL 2. Reference SVG Animations in SVG 1.1 for web compat 3. Add a list of WG resolutions for additional clarifications but no further update on the actual spec. 07:36:19 Vinay has joined #svg 07:37:11 https://www.w3.org/TR/SVG2/paths.html#TheDProperty 07:37:23 For animation, two d property values can only be interpolated smoothly when the path data strings contain have the same structure, (i.e. exactly the same number and types of path data commands which are in the same order). If an animation is specified and the lists of path data commands do not have the same structure, then the values must be 07:37:23 interpolated using the discrete animation type. 07:38:02 https://w3c.github.io/svgwg/svg2-draft/paths.html#DProperty 07:39:23 RESOLUTION: For from/by animations or additive animations, if we have incompatible values, the animation should be canceled and rendering falls back to the base value for the time of the animation. Even after the animation, the base value should be used. 07:40:21 viralipurbey: Should we add it to the existing text for this particular issue as we already have it mentioned in the spec? 07:40:25 nzimmermann: fine with me 07:40:45 ydaniv: shouldn't we make it wider to match CSS animations as well? 07:40:53 nzimmermann: additive animations are byond CSS. 07:41:13 RESOLUTION: Add calrification into SVG spec directly for this partiuclar issue. 07:41:55 ACTION: Virali to do spec edits 07:42:51 RRSAgent: make minutes 07:42:52 I have made the request to generate https://www.w3.org/2026/02/05-svg-minutes.html krit 07:42:57 RRSAgent, make logs public 07:48:09 Thanks krit for scribing. That was a long one. 08:13:52 viralipurbey has joined #svg 09:36:15 Zakim has left #svg