05:46:36 RRSAgent has joined #svg 05:46:40 logging to https://www.w3.org/2026/06/25-svg-irc 05:46:45 scribe: krit 05:47:36 ydaniv has joined #svg 05:47:47 present: Dirk, Karl, Tav, Yehonatav, Carine, Nikolas 05:49:20 topic: refX/refY keyword forms unimplemented and no WPT tests 05:49:24 https://github.com/w3c/svgwg/issues/1137 05:49:28 nzimmermann has joined #svg 05:49:31 present+ 05:49:42 present+ 05:49:51 karlcow: Implemented refX/refY in markler w/o keywords but percentage/number 05:50:08 karlcow: For symbol, not implemented in browsers but for InkScape it is 05:50:39 present+ 05:50:49 present+ 05:50:55 Tav: has been implemented a long time ago 05:51:02 Tav has joined #svg 05:51:11 present+ 05:51:37 karlcow: Keywords implemented on Symbols in InkScape 05:51:59 karlcow: ditto for marker 05:52:27 karlcow: at the moment there is no coverage in WPT 05:53:22 karlcow: The specification text seems vague for now with the SVGLength and how the keywords fit into SVGDOMs SVGLength. 05:53:34 nzimmermann: and from the parsing perspective... 05:54:02 nzimmermann: the grammar only accepts percentage length for SVGLength+percentage. It could be extended. 05:54:30 krit: is it actively used in InkScape? 05:54:56 Tav: likely for canned symbols to make align correct. You don't have to move the symbol to align it to a specific point. 05:55:13 karlcow: I understand the use case for symbol with refX and refY 05:55:30 karlcow: ... but should we expose the mechanism instead of special casing symbol? 05:55:39 karlcow: could it make SVG simpler to use? 05:56:12 Tav: we keep track of the center of the shape. This is most useful for shapes like starts and rotate around its center point 05:56:22 nzimmermann: for this, we now have transform-origin 05:56:35 Tav: this was invented before CSS came up with transform-origin 05:56:52 nzimmermann: refX and refY are independent of transformation. 05:57:13 nzimmermann: you would need a skew + scale to see the affect of it 05:57:32 nzimmermann: karlcow though that we could make it more generic and apply it to all shape kinds 05:58:20 yehonatan: For generic shapes it is common to define a place and shift from it 05:58:32 nzimmermann: then you would need to know the dimension of the shape. 05:58:46 ... otherwise it would resolve to the viewport and not the shape 05:59:20 yehonatan: As the deveoper of the component, you know how the shape works and you want to align it for instance with text (baseline and so on) 05:59:36 nzimmerann: So it would make more sense to make it for symbols? 06:00:03 nzimmermann: At the end you don't want to alter the clipping and that is what refX and refY is good for. 06:00:11 Tav: it is always good for animations 06:00:43 Tav: refX and refY you want to be a specific point/anchor to place the object. 06:00:55 Tav: This is mostly coming from people doing maps. 06:01:04 nzimmermann has joined #svg 06:01:08 nzimmermann: We still ned WPT coverage 06:01:25 s/nzimmerannn/nzimmermann/ 06:01:38 karlcow: If you have tests, please add those to WPT 06:01:52 Tav: I have to search. They would need to get modified for WPT. 06:01:58 Tav: But I can create them 06:02:14 ydaniv has joined #svg 06:02:51 ACTION: Tav will check if he can contribute existing refX/refY tests to WPT 06:03:41 RESOLUTION: We keep refX/refY with keywords on symbol and marker in the spec. More implementations needed still 06:04:12 krit: what about the spec text that needs approvements? 06:04:28 karlcow: The IDL with SVGLength is not clear. Especially with animations and keywords. 06:05:34 krit: We could add a new value type for enumerations but this would still not allow animation from enum val to percentage for instance. 06:06:26 ACTION: nzimmermann and karlcow to look into refining the IDL spec text for refX and refY for keywords and SVGLength 06:06:39 ydaniv has joined #svg 06:06:55 topic: Define how requiredExtensions values should be interpreted 06:06:59 https://github.com/w3c/svgwg/issues/138 06:07:12 ydaniv has joined #svg 06:07:22 karlcow: the attribute can take links 06:07:40 karlcow: there are 2 hard coded values: namespace for HTML and XML 06:07:55 karlcow: there still is mathml for one implementation (gecko?) 06:08:05 ydaniv has joined #svg 06:08:29 karlcow: I wonder if InkScape has more namespaces than the 2/3 or if it is also limited to a set of namespaces 06:08:44 karlcow: if so, we can limit the namespaces to HTML and MathML 06:09:35 Tav: we don't have additional namespaces. I don't think we support requiredExtensions 06:09:57 nzimmermann: seems resonable to limit the support to HTML and MathML. 06:10:26 nzimmermann: it would be up to an implementation how to "rendeer" and XML tree. Gecko's support is nice but I don't see authors using it 06:10:33 nzimmermann: support limitation to HTML and MathML 06:10:48 nzimmermann: on the other hand: is there any case where it would resolve to false? 06:11:02 nzimmermann: browsers do support both after all 06:11:14 nzimmermann: or is it possible to turn of MathML in browsers? 06:11:20 nzimmermann: maybe Gecko does? 06:12:19 ydaniv: There might be security factors involved. 06:12:57 ydaniv: It does seem to be listed as an issue by sanitizer API 06:13:04 https://github.com/cure53/dompurify 06:13:20 ydaniv: that is why most people avoid it 06:13:47 caribou: It would be interesting to know if HTML is problematic but MathML isn't? 06:14:05 ydaniv: yeah then it could become useful 06:14:50 nzimmermann: I did not check dompurify but there are many features listed. Even preserveAspectRatio is listed. 06:15:12 ydaniv: some I added myself. requireExtensions I never had to use. So need to look it up 06:15:50 ydaniv: if the attribute is problematic, I wonder if it is worth the trouble. 06:16:07 ydaniv: I can look it up and get back on the issue 06:16:38 RESOLUTION: Limit namespaces for requiredExtensions to HTML and MathML 06:17:03 ydaniv has joined #svg 06:17:57 topic: charter 06:18:06 https://github.com/w3c/strategy/issues/559 06:18:14 caribou: there is a new draft for an upcoming charter 06:18:59 caribou: trying to get the approval within the next 3 months and then bring it up to AC 06:19:22 karlcow: this is only for 3 months? 06:19:41 caribou: Idea is to get a follow-up charter that is good for 2 years. 06:20:30 caribou: I'd like to prepare a republication. I hope I get to it next week. 06:20:41 caribou: July 13 is the end of the charter 06:20:59 s/charter/publication moratorium 06:21:20 charter expires on june 30th 06:27:27 RRSAgent, make logs public 06:27:39 RRSAgent, make minutes 06:27:40 I have made the request to generate https://www.w3.org/2026/06/25-svg-minutes.html karlcow 06:28:15 Meeting: SVG WG 06:28:19 RRSAgent, make minutes 06:28:20 I have made the request to generate https://www.w3.org/2026/06/25-svg-minutes.html karlcow 12:28:09 Zakim has left #svg