minutes, February 5 2026 SVG WG telcon

Minutes from today’s telcon are below.

<https://www.w3.org/2026/02/05-svg-minutes.html>
SVG WG Meeting – 05 February 2026<https://www.w3.org/2026/02/05-svg-minutes.html>
w3.org<https://www.w3.org/2026/02/05-svg-minutes.html>
[favicon.ico]<https://www.w3.org/2026/02/05-svg-minutes.html>

IRC log of svg on 2026-02-05

Timestamps are in UTC.

06:42:44 [RRSAgent]
RRSAgent has joined #svg
06:42:49 [RRSAgent]
logging to https://www.w3.org/2026/02/05-svg-irc

06:42:49 [ydaniv]
ydaniv has joined #svg
06:42:52 [Zakim]
Zakim has joined #svg
06:43:21 [krit]
present+
06:43:23 [krit]
Meeting: SVG WG Meeting
06:43:31 [krit]
scribeNick: krit
06:46:02 [Vinay]
Vinay has joined #svg
06:46:08 [dmangal]
dmangal has joined #svg
06:46:16 [karlcow__]
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 [karlcow__]
present+
06:46:32 [Vinay]
present+
06:46:35 [dmangal]
present+
06:46:41 [ydaniv]
present+
06:47:37 [krit]
topic: Should width and height apply to nested svg elements as CSS properties
06:47:39 [krit]
https://github.com/w3c/svgwg/issues/1057

06:47:50 [nzimmermann]
nzimmermann has joined #svg
06:48:40 [krit]
dmangal: Chromium starts applying CSS properties for width/heighth on svg elements
06:48:55 [krit]
dmangal: No styling gets applied and we got a lot of feedback.
06:49:15 [krit]
dmangal: Initially we started to adviocate for the feature but there were to many
06:49:42 [krit]
dmangal: We disabled the feature. Safari and FF do not support it
06:50:06 [krit]
krit: clarification question: <svg> inside of <svg> elements?
06:50:09 [krit]
dmangal: yes
06:50:18 [Neha]
Neha has joined #svg
06:50:25 [nzimmermann]
scribe+
06:50:29 [Neha]
present+
06:50:36 [nzimmermann]
oops, sorry
06:50:38 [nzimmermann]
present+
06:50:43 [krit]
scribe_
06:50:45 [krit]
scribe+
06:50:51 [caribou]
present+
06:50:54 [krit]
krit: I am not sure if we meant to be applied for nested elements
06:50:55 [karlcow__]
q+ to ask about svg/svg?
06:51:33 [krit]
krit: spec doesn't mention outer most SVG element?
06:51:54 [krit]
dmangal: No it does not
06:52:12 [krit]
krit: Can you add more info about the rendering issues
06:52:23 [krit]
karlcow__: there are examples on the ticket
06:52:35 [krit]
karlcow__: some examples were completely incorrect.
06:52:50 [viralipurbey]
viralipurbey has joined #svg
06:52:52 [dmangal]
dmangal has joined #svg
06:52:54 [dmangal]
https://issues.chromium.org/issues/449170647#comment7

06:52:54 [viralipurbey]
present+
06:53:32 [krit]
nzimmermann: IMO the spec in 7.8 (sizing properties) "are used for SOME SVG elements"...
06:54:15 [krit]
nzimmermann: IMO it was a nice idea but should never have applied to any other elements other than outer SVG elements.
06:54:40 [krit]
nzimmermann: For rect it is not eval but for SVGSVGElement it is.
06:55:25 [krit]
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 [krit]
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 [karlcow__]
s/exluce/exclude/
06:58:03 [karlcow__]
S/inteded/intended/
06:58:35 [krit]
dmangal: According to spec, the width/height for inner outer SVGSVGElement, Rect, foreignObject and use
06:59:40 [krit]
ydaniv: And view eleement?
06:59:45 [krit]
krit: is that in SVG 2?
07:00:02 [karlcow__]
https://w3c.github.io/svgwg/svg2-draft/linking.html#ViewElement

07:00:03 [krit]
karlcow__: It is there but doesn't have width/height
07:01:24 [krit]
dmangal: rect and image are probably fine
07:01:50 [karlcow__]
https://w3c.github.io/svgwg/svg2-draft/struct.html#UseElement

07:02:19 [karlcow__]
> 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 [karlcow__]
> 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 [karlcow__]
https://w3c.github.io/svgwg/svg2-draft/struct.html#SymbolElement

07:02:56 [krit]
nzimmermann: The use element already talks about the connection to CSS sizing eventhough not explicitly referring to it
07:03:04 [karlcow__]
> 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 [dmangal]
https://chromestatus.com/metrics/feature/timeline/popularity/5730

07:03:52 [krit]
nzimmermann: Can we support width/height on use at least? Same behavior for rect?
07:04:00 [karlcow__]
Also https://w3c.github.io/svgwg/svg2-draft/struct.html#UseLayout

07:04:02 [krit]
dmangal: See example why I am not in favor.
07:05:23 [krit]
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 [dmangal]
https://svgwg.org/svg2-draft/geometry.html#Sizing

07:06:18 [krit]
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 [krit]
dmangal: can we add a reference to sizing?
07:06:46 [krit]
karlcow__: The idea is, can we simplify?
07:07:41 [krit]
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]
viralipurbey6 has joined #svg
07:08:34 [nzimmermann]
nzimmermann has joined #svg
07:08:35 [krit]
krit: I am fine with this compromise too
07:08:42 [viralipurbey8]
viralipurbey8 has joined #svg
07:09:51 [krit]
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 [krit]
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 [krit]
ACTION: dmangal to update specification text
07:11:04 [krit]
topic: SVG path animation: unclear behavior for from + by when commands mismatch
07:11:08 [krit]
https://github.com/w3c/svgwg/issues/1056

07:11:41 [krit]
viralipurbey: Using from/by animations on the d attribute.
07:12:06 [krit]
viralipurbey: When animation values are incompatible, the animation should fall back to discrete animation.
07:12:22 [krit]
viralipurbey: this is not clear for from/by animations on d path.
07:12:45 [krit]
viralipurbey: should the render the from value/by value?
07:13:03 [krit]
viralipurbey: Firefox is not rendering anything.
07:13:35 [krit]
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 [krit]
viralipurbey: so either renderers should render nothing or fall back to from/by values.
07:14:10 [krit]
nzimmermann: Did you spec the original SMIL specification?
07:14:18 [krit]
viralipurbey: I went thought the spec.
07:15:31 [krit]
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 [krit]
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 [karlcow__]
Is it part of https://svgwg.org/specs/animations/ ?
07:17:10 [krit]
krit: should we really not render the element at all in case of error?
07:17:22 [krit]
nzimmermann: no, it is about not applying the animation
07:17:54 [krit]
viralipurbey: I actually mean not to render as it is easier to spend. During animation it should not render anything.
07:18:28 [karlcow__]
https://svgwg.org/specs/animations/#FromAttribute

07:18:31 [krit]
nzimmermann: well in that case there is no value to start from. So they can't render anything. This is specific.
07:18:54 [krit]
nzimmermann: not rendering at all would be against the spirit of the SVG spec
07:19:28 [krit]
karlcow__: I haven't tried it yet. But there is a different spec: Web Animations.
07:19:43 [dmangal]
dmangal has joined #svg
07:20:34 [viralipurbey0]
viralipurbey0 has joined #svg
07:20:47 [krit]
karlcow__: may the answers be in that spec.
07:22:45 [caribou]
SVG Animations is not listed as a deliverable in our charter either
07:24:04 [krit]
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]
krit: simplified: animation has no effect?
07:24:22 [krit]
viralipurbey0: yes
07:25:33 [karlcow__]
https://w3c.github.io/svgwg/svg2-draft/animate.html

07:25:49 [ydaniv]
q+
07:25:54 [karlcow__]
Q-
07:26:05 [krit]
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 [krit]
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 [krit]
karlcow__: I don't think we can take other things.
07:29:02 [karlcow__]
Web Animations Level 1 https://drafts.csswg.org/web-animations-1/

07:29:06 [krit]
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 [krit]
nzimmermann: Animating colors has a complete replacement in CSS.
07:29:32 [krit]
nzimmermann: transform has a full replacement
07:29:52 [krit]
nzimmermann: there is animation attributes possible
07:30:04 [krit]
nzimmermann: there is CSS Motion for d attribute
07:30:35 [krit]
nzimmermann: we won't have matching support for everything but to what extend is CSS attribute animation possible?
07:30:48 [krit]
nzimmermann: IMO CSS covers 90% of real use cases for animations
07:31:06 [krit]
ydaniv: SMIL animations are deprecated. This has been stated for a while.
07:31:18 [krit]
ydaniv: SMIL should be considered deprecated.
07:31:33 [krit]
ydaniv: there is a lot you simply can't do with SMIL
07:31:51 [krit]
ydaniv: clearly the path forward is facing to CSS
07:31:59 [krit]
ydaniv: SMIL is already behind in many ways
07:32:23 [krit]
ydaniv: best way forward is more presentational attributes where it works and animate with CSS.
07:33:06 [krit]
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 [krit]
ydaniv: There are still many ppl using SMIL.
07:35:35 [Neha]
Need to jump to another meeting.
07:35:36 [karlcow__]
Wondering if we need to guide of equivalence in between SMIL/SVG -> CSS animations.
07:35:47 [krit]
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]
Vinay has joined #svg
07:37:11 [Vinay]
https://www.w3.org/TR/SVG2/paths.html#TheDProperty

07:37:23 [Vinay]
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 [Vinay]
interpolated using the discrete animation type.
07:38:02 [karlcow__]
https://w3c.github.io/svgwg/svg2-draft/paths.html#DProperty

07:39:23 [krit]
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 [krit]
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 [krit]
nzimmermann: fine with me
07:40:45 [krit]
ydaniv: shouldn't we make it wider to match CSS animations as well?
07:40:53 [krit]
nzimmermann: additive animations are byond CSS.
07:41:13 [krit]
RESOLUTION: Add calrification into SVG spec directly for this partiuclar issue.
07:41:55 [krit]
ACTION: Virali to do spec edits
07:42:51 [krit]
RRSAgent: make minutes
07:42:52 [RRSAgent]
I have made the request to generate https://www.w3.org/2026/02/05-svg-minutes.html krit
07:42:57 [krit]
RRSAgent, make logs public