05:44:13 RRSAgent has joined #svg 05:44:17 logging to https://www.w3.org/2026/04/23-svg-irc 05:44:17 Zakim has joined #svg 05:44:40 Meeting: SVG WG 05:44:58 Agenda: https://github.com/w3c/svgwg/issues?q=is%3Aissue%20state%3Aopen%20label%3AAgenda%2B 05:45:35 Agenda: https://github.com/w3c/svgwg/issues?q=state%3Aopen%20label%3AAgenda%2B 05:45:47 present+ 05:45:58 present+ 05:46:14 I see only Tav and me on the meeting for now 05:47:12 nzimmermann has joined #svg 05:47:16 present+ 05:48:55 scribe: krit 05:48:59 topic: side and path attributes on textPath are missing on the IDL #1086 05:49:03 https://github.com/w3c/svgwg/issues/1086 05:49:20 present+ 05:50:29 karlcow: path attribute on textPath not implemented at all 05:51:49 nzimmermann: This could make sense to add. I wouldn't mind. It can be useful. 05:52:41 nzimmermann: Yohnathan suggested to expose it as CSS property (like the d attribute) to animate it via CSS Animation. 05:53:02 nzimmermann: if we keep path, we should make it a CSS presentation attribute 05:53:59 krit: maybe we can add an annotation and put it at-risk unless there is interest to implement it 05:54:42 Yehonatan: We mimic the attribute with a library 05:54:51 Yehonatan: but CSS animation would be very useful 05:55:12 s/Yohnathan/Yehonatan/ 05:56:01 nzimmermann: I am refused by Roberts comment on the issue. If we had an animation, we could only use constants. The suggestion doesn't play well with baseVal or animVal 05:56:37 nzimmermann: ... we would need to define animations for constants which is a nobel task but has risks with backwards compatible way 05:57:00 nzimmermann: we shouldn't mix constants/enum that define animations in one but not another case 05:57:44 Yehonatan: there was a discussion to support logical values in CSS animations 05:57:47 https://w3c.github.io/svgwg/svg2-draft/single-page.html#types-InterfaceSVGAngle 05:58:16 krit s/animations/SVGAnimatedEnumeration/ 05:58:58 karlcow: If you look at the IDL, there is a specified value for degree/radian/... any other value type should be treated as unknown type 05:59:08 karlcow: would that apply to the side attribute? 05:59:27 karlcow: just want to know which path we are following 05:59:45 > The use of numeric angle unit type constants is an anti-pattern and new constant values will not be introduced for any other units or angle types supported by SVGAngle. If other types of angles are supported and used, the SVGAngle uses the SVG_ANGLETYPE_UNKNOWN unit type. See below for details on how the other properties of an SVGAngle operate with these types of angles. 06:00:15 nzimmermann: we need constants. They are simply missing. for consistency we should follow the existing enumerations. 06:00:19 karlcow: ok. 06:00:49 nzimmermann: later we could have an animated enum type, strongly typed that is backwars compatible to AnimateEnum. 06:01:27 nzimmermann: ...indistinguishable for JS. But right now, not. 06:01:57 nzimmermann: the constants for for side attribute. For path we still need to discuss. 06:02:25 RESOLUTION: Add constants for side attribute to IDL 06:02:57 RESOLUTION: Keep path attribute unchanged. No reflection in the IDL for this attribute 06:03:54 topic: [SVG2] Drop inline-size attribute on text element from SVG2 #1087 06:03:57 https://w3c.github.io/svgwg/svg2-draft/paths.html#InterfaceSVGPathElement 06:04:01 https://github.com/w3c/svgwg/issues/1087 06:04:35 karlcow: There was more discussion on the git issue. Tav says InkScape implements the d attribute 06:05:02 s/d attribute/inline-size attribute/ 06:05:12 karlcow: currently not implemented in any browser 06:05:19 Tav: is it the CSS box model? 06:05:43 nzimmermann: related. Text layout is always hard. I don't think there is a technical issue to implement. 06:06:10 nzimmermann: But there is some resistance by browser vendors but can't tell. 06:06:32 nzimmermann: this is only about defining the size of the box and do text wrapping right? 06:06:35 Tav: yes 06:06:53 nzimmermann: You can not do that to text with CSS as we don't follow the box model. 06:07:34 https://w3c.github.io/svgwg/svg2-draft/text.html#InlineSize 06:07:58 > The inline-size property allows one to set the wrapping area to a rectangular shape. The computed value of the property sets the width of the rectangle for horizontal text and the height of the rectangle for vertical text. The other dimension (height for horizontal text, width for vertical text) is of infinite length. A value of zero disables the creation of a wrapping area. 06:08:00 nzimmermann: all browsers implement text as CSS inline boxes. So should be easy to implement. Only restrain is that inline boxes are not infinite but have a size constrains. 06:08:12 nzimmermann: everything is there but someone would need to do it. 06:08:39 Yehonatan: Is this the only issue with text wrapping or is there more? 06:08:50 Tav: There is also wrapping in shapes 06:09:11 Tav: Firefox also supports multi-line text in SVG 06:09:23 Tav: So there are 3 ways of multi-line text in SVG21 06:09:31 s/SVG21/SVG2/ 06:09:54 Yehonatan: Having text wrapping in SVG is a holy grail 06:10:08 Yehonatan: If we would have wrapping it would be a very big thing 06:10:30 karlcow: SVG2 is not a living spec. So it does not evolve over time 06:10:49 karlcow: So if we do not have cross interop we should fix it or remove it 06:12:44 krit: that is a good point but it is in the spec already. So we are not adding it. We have one implementation and interest of the community. So it only requires another implementation. I'd suggest add an annotation that we are interested in it but need to remove if there is no 2nd implementation. 06:13:36 nzimmermann: I was wondering if there is any mention of text path? That is the tricky case. 06:13:40 Tav: agree 06:14:00 karlcow: Is there any issue with RTL or vertical text? 06:14:03 Tav: it works 06:14:46 nzimmermann: it is not just inline-size but als shape inside/outside 06:15:21 nzimmermann: if you look at the scope: if we define text to clip at boundaries with normal text line wrapping, we would get 95% of the use cases. 06:15:46 nzimmermann: So not make it complex and it would get approval 06:16:25 Shape-* issues https://github.com/w3c/svgwg/issues/1067 06:16:52 RESOLUTION: Drop text wrapping in CSS shapes for SVG2 06:16:52 https://www.w3.org/2026/03/05-svg-minutes.html 06:17:55 RESOLUTION: Keep inline-size as it is the simplest text wrapping suggestion for SVG2 and easy to implement it for browser vendors 06:18:31 topic: Clarify systemLanguage parsing and evaluation algorithm 06:18:39 https://github.com/w3c/svgwg/issues/1089 06:19:02 karlcow: Implementing it in WebKit... Proposal is to clarify the text in the spec. 06:19:12 karlcow: it is a big paragraph 06:19:22 karlcow: I created a PR which is ready for review 06:20:14 karlcow: for empty tokens, 2 commas, the spec says it gets empty items. 06:20:46 karlcow: but what should we do with the empty tokens? Drop it? 06:21:00 karlcow: how do we evaluate the empty tokens? 06:21:27 karlcow: I am suggesting to drop empty tokens as they don't provide any additional value 06:21:51 karlcow: there is only the language of the system so there is no fallback language. Just take what the browser suggests 06:22:20 karlcow: what do we do with invalid language tags? Drop them? 06:22:44 karlcow: I suggest to drop. 06:23:59 karlcow: There is a big chunk what to do with text. I did it reverse and reduced the amount of text. Replacing it with a list of steps. 06:24:51 nzimmermann: I think there is another level of complexity with svg string list 06:25:12 nzimmermann: In other cases there is a 1:1 reflection 06:25:47 nzimmermann: So the comma spearated list needs to have valid entries. So empty token would be an empty string in the string lists? 06:26:05 nzimmermann: Main question: when do we reflect the empty tokens? When we add them to the string lists? 06:26:23 karlcow: I don't have a strong opinion either 06:26:50 karlcow: in WebKit we are parsing the tokens into the string list 06:27:09 nzimmermann: so for WebKit it would be internally and exposed to the web 06:27:35 nzimmermann: and we can clarify that we drop empty tokens and keep them as invalid 06:28:21 RESOLUTION: Drop empty tokens during parsing and not add them to string list 06:28:49 RESOLUTION: Drop invalid system languages and align with error processing 06:30:53 RRSAgent: make minutes 06:30:55 I have made the request to generate https://www.w3.org/2026/04/23-svg-minutes.html krit 06:31:12 RRSAgent, make logs public 08:01:41 Zakim has left #svg 09:55:25 PRs which need love. 09:55:25 Open: 09:55:25 - https://github.com/w3c/svgwg/pull/1097 — Remove shape-inside, shape-subtract and related properties from SVG2 #1067 09:55:25 - https://github.com/w3c/svgwg/pull/1092 — Fix #1091 - Clarify the prose of Rendering order section 09:55:27 - https://github.com/w3c/svgwg/pull/1090 — Fix #1089 Clarify systemLanguage prose 09:55:30 - https://github.com/w3c/svgwg/pull/1078 — FIX #1018 getbbox returns 0,0,0,0 when values are invalid or absent 09:55:33 - https://github.com/w3c/svgwg/pull/1077 — Update path/href fallback behavior per WG resolution 09:55:36 - https://github.com/w3c/svgwg/pull/1076 — Remove SVGElementInstance mixin interface - Fix #1070 09:55:54 All in need for reviews.