05:43:08 RRSAgent has joined #svg 05:43:13 logging to https://www.w3.org/2026/06/11-svg-irc 05:44:01 Chair: Dirk Schulze 05:44:06 Agenda: https://github.com/w3c/svgwg/issues?q=is%3Aissue%20state%3Aopen%20label%3AAgenda%2B 05:44:09 present+ 05:44:15 nzimmermann has joined #svg 05:44:21 present+ 05:45:17 Vinayag has joined #svg 05:45:28 Vinay has joined #svg 05:45:32 viralipurbey has joined #svg 05:45:46 present+ 05:46:17 present+ 05:47:09 topic: Clarify that getPathData() returns the attribute base value, not the CSS resolved/animated value 05:47:19 https://github.com/w3c/svgwg/issues/1130 05:47:20 present+ 05:47:23 scribe: krit 05:47:48 Vinay: That is about hte pathData implementation which is in FF and is about to get implemented in Chrome 05:47:53 viralipurbey: 05:48:22 viralipurbey: It is not clear which data should get returned during animation. baseVal or value of the path? 05:48:33 viralipurbey: SMIL and CSS Animations (any animations) 05:49:28 viralipurbey: Recommendation: getPathData() returns the base value of the d attribute for any animation. 05:49:35 viralipurbey: Firefox does this already 05:50:06 krit: Is there any other way to get the animation value in any other way? As part of WebAnimation for instance? 05:50:15 viralipurbey: yes, it is changing during animation. 05:50:48 krit: I mean any animation value 05:50:57 nzimmermann: animation like with WebAnimation APIs? 05:51:00 krit: yes 05:51:43 viralipurbey: There are only 3 end points and pathData just returns the base value. 05:51:54 viralipurbey: So there is no JS endpoint to get the animate value 05:52:32 nzimmermann: In WebAnimations, the getComputedStyle is reflecting the current state of the animation. So computed stlye should always reflect the current animation state. 05:52:45 https://svgwg.org/specs/paths/#InterfaceSVGPathData 05:52:54 nzimmermann: I need to verify it still though. 05:52:56 Hmm not the right url 05:53:38 viralipurbey: You are right, getComputedStyle returns the animated value. 05:53:39 https://w3c.github.io/svgwg/specs/paths/#InterfaceSVGPathData 05:53:49 krit: as long as there is some way to get the animated value I am fine 05:54:04 nzimmermann: this is also consistent with pathLength and other values. 05:54:33 RESOLUTION: getPathData() will return base value for any kind of animation 05:54:53 topic: getPathSegmentAtLength(): Define which segment is returned at exact boundary 05:54:57 https://github.com/w3c/svgwg/issues/1129 05:55:16 viralipurbey: this is another one but pathSegmentAtLength 05:55:51 viralipurbey: what happens if the length is on the boundary between 2 path segments. 05:56:07 nzimmermann: how would that be defined in the spec? 05:56:33 nzimmermann: how would we do it mathematically 05:57:36 krit: I'd say that we use SHOULD to avoid this discussion. It would be up to the implementation how to round the values and choose which segement to return 05:58:11 nzimmermann: fine with using the latter segment 05:58:44 RESOLUTION: Implementations SHOULD return the latter segment on boundaries of 2 segments. It is up to the implementation to define rounding rules/epsilon 05:59:07 ACTION: viralipurbey to update the spec 05:59:17 topic: getPathSegmentAtLength(): Define behavior for NaN distance 05:59:26 https://github.com/w3c/svgwg/issues/1128 06:00:04 viralipurbey: When we specify a distance it should be clammed between 0 and distance of path. 06:00:20 viralipurbey: What happens with 0 or Infinity in the distance? 06:00:32 s/0/NaN/ 06:01:11 viralipurbey: these are valid values, we just need to define the behavior 06:01:50 krit: FF returns NULL for NaN and Infinity the last sgement and -Infinity the first segment, what do other implementations? 06:02:02 nzimmermann: sounds mindful to me 06:02:32 nzimmermann: I'd like to avoid exceptions. 06:03:33 krit: wasn't getPathSegmentAtLength in Chrome? 06:04:01 viralipurbey: We deprecated the API and are now implementing the new API. 06:04:19 nzimmermann: you were thinking of getPathSegAtLength krit 06:04:41 nzimmermann: but it shows the point of viralipurbey : we were not throwing an exception for the old API 06:05:21 RESOLUTION: Follow behavior of Firefox: return NULL for NaN, Infinity the last sgment and -Infinity the first segment 06:05:37 topic: Clarify glyph-orientation-vertical - whether it is obsolete or something need to be kept? 06:05:46 https://github.com/w3c/svgwg/issues/1122 06:06:31 karlcow: I was working on it and was writing tests when Robert mentioned it is not in Chrome nor Firefox. Should we keep it or drop it? 06:07:33 karlcow: One section says it has been marked obsolet and the next section that it has been replaced. 06:07:50 karlcow: The spec text seems to be confusing though. 06:08:10 nzimmermann: I would support it. We only implemented because one test in the test suite. 06:08:31 nzimmermann: The text also explicitly did exclude horizontal. 06:09:01 nzimmermann: However, for vertical text layouts in a stand alone context it could be useful. 06:09:41 nzimmermann: you do not want to deal with individual glyphs. But if you want to do layout as usual but rotate the individual glyphs. It could be implemented in InkScape. 06:10:37 dmangal has joined #svg 06:10:39 https://wpt.fyi/results/css/css-variables/variable-presentation-attribute.html?label=experimental&label=master&aligned 06:10:44 Vinay: It seems not to be supported by most browser engines and Webkit agrees to remove it, so shall we remove it? 06:11:27 ACTION: Karl to contact Tav on the implementation status 06:11:43 topic: auto-rotation due to 'Orientation' attribute in EXIF Data 06:11:47 https://github.com/w3c/svgwg/issues/819 06:12:11 nzimmermann: It is about an attribute that can be embedded in the EXIF DATA 06:12:32 nzimmermann: there is no attribute in SVG to control if the data point would be used in SVG or not. 06:12:45 nzimmermann: there is a request to implement it. Check the last comment in the ticket. 06:13:04 nzimmermann: 3 options: To repeat, I see at least 3 options: 06:13:04 (a) Always apply image orientation EXIF data in 06:13:04 (b) Use the CSS image-orientation property from the element with the filter property for that instance of the filter. 06:13:04 (c) Define an attribute on to control the orientation (analogous to the CSS property). 06:13:24 nzimmermann: I would need to get more context on some options 06:13:38 nzimmermann: We have the image element which is a defined filter resource. 06:14:12 nzimmermann: If you apply the filter some where, we need a way to choose to honor the data on the source where the filter gets applied 06:14:12 dmangal has joined #svg 06:14:46 krit: lost here: what is the relation to filter? 06:15:06 nzimmermann: we need to think about more than image like the feImage element 06:15:23 viralipurbey: is it clear for image element or do we still need to figure it out 06:15:57 nzimmermann: we need to figure it out in all situations. This is a request from CSS WG: Do we want to expose it via attribute? 06:16:15 nzimmermann: I missed that this is beyond image initially so I need to think about the other use case more. 06:16:50 nzimmermann: so do we always want to auto-orientate which is a privacy concern by chrome? Or do we want to expose it explictly? 06:17:02 karlcow: there is a similar discussion on HTML image 06:17:12 karlcow: the issue is closed but I don't know the conclusion right now 06:17:12 https://github.com/whatwg/html/issues/4495 06:17:15 https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/image-orientation 06:18:06 krit: if it is a privacy concern, what does it matter if it is auto or explicitly? 06:18:15 nzimmermann: I am confused by this myself. 06:18:33 https://html.spec.whatwg.org/multipage/imagebitmap-and-animations.html#imageorientation 06:18:42 nzimmermann: we would need more clarification: What are the privacy concerns? What does it matter if auto or explict? 06:18:53 viralipurbey: it is about cross origin leakage 06:19:08 viralipurbey: EXIF metadata could be leaked 06:19:48 krit: What does HTML do? Aren't the concerns valid there too then? 06:20:12 nzimmermann: I agree: Do not invent our own thing but do what HTML does and unerstand why feImage is special. 06:20:35 nzimmermann: that part might be related to the privacy concern. 06:20:56 ACTION: On Niko to get more information from Stephen about it. 06:22:41 topic: TPAC 06:22:54 caribou: We need to create a github issue to request a room 06:23:03 karlcow: we should use the momentum and meet 06:23:50 https://lists.w3.org/Archives/Member/chairs/2026AprJun/0067.html 06:24:12 https://github.com/w3c/tpac2026-meetings/ 06:27:04 https://github.com/w3c/strategy/issues/559 06:27:29 topic: recharter 06:27:58 caribou: We created a git ticket for recharter. Currently we have maintenance as main topic. If you have more ideas, let me know 06:28:36 karlcow: I don't know if we can do much more than finishing SVG2 for the next period 06:28:56 caribou: questions will likely be more about resources and not topics. Discussion will happen on github 06:29:11 caribou: announcement from/to AC will be send soon. Probably next week. 06:33:18 RRSAgent, make minutes 06:33:19 I have made the request to generate https://www.w3.org/2026/06/11-svg-minutes.html krit 06:33:21 s/from\/// 06:33:45 Rrsagent, make logs public 06:33:51 RRSAgent: make logs public 12:01:49 croissant` has joined #svg 12:31:15 Zakim has left #svg 13:43:02 github-bot has joined #svg