06:38:34 RRSAgent has joined #svg 06:38:39 logging to https://www.w3.org/2026/02/19-svg-irc 06:38:39 Meeting: SVG WG 06:38:39 Chair: Dirk Schulze 06:39:54 krit has joined #svg 06:40:58 Zakim has joined #svg 06:42:53 RRSAgent, log? 06:42:53 I'm logging. Sorry, nothing found for 'log' 06:43:51 RRSAgent, pointer 06:43:51 See https://www.w3.org/2026/02/19-svg-irc#T06-43-51 06:44:59 ydaniv has joined #svg 06:46:12 Vinay has joined #svg 06:46:24 nzimmermann has joined #svg 06:46:30 present+ 06:46:58 present+ 06:47:02 present+ 06:47:05 present+ 06:47:10 present+ 06:47:42 github-bot, https://github.com/w3c/svgwg/issues/1055 06:47:42 karlcow, Sorry, I don't understand that command. Try 'help'. 06:47:45 prsent+ 06:47:58 scribe: krit 06:48:03 topic: SVGTransform.matrix returns SVGMatrix in all browsers 06:48:24 https://github.com/w3c/svgwg/issues/1055 06:49:03 karlcow: Something was not correctly reverted in the SVG2 spec. 06:49:12 karlcow: SVGMatrix matches in all browsers 06:49:38 karlcow: issue was closed w/o reverting the change. In the spec it is still 2Dinit 06:49:49 viralipurbey has joined #svg 06:49:54 present+ 06:50:16 karlcow: Chromium takes SVGMatrix for setMatrux 06:50:38 karlcow: FF and Safari Matrix2Dinit? 06:51:46 karlcow: The resolution was to revert for SVGMatrix from DOMMatrix 06:52:58 karlcow: I added the links to the github issue that references all discussions 06:53:28 karlcow: There is a todo in Chromium it should be DOMMatrix but was never done. But it was never done 06:54:02 krit: Chromium does not have DOMMatrix but Safari and FF kind of do 06:54:20 karlcow: but it is not what browsers o 06:54:28 s/ o/do/ 06:54:50 Vinay: I wanted to pick up but sentiment was not to break what is working 06:55:15 Resolutions ( Oct 22, 2019): 06:55:15 RESOLVED: Revert decision to make SVG* geometry interfaces aliases of the DOM* geometry interfaces (pending CSS WG approval) 06:55:15 RESOLVED: Change the SVG spec to use the SVG* geometry interfaces instead of DOM* interfaces 06:55:15 RESOLVED: Keep the usage of DOM*Init types in the SVG spec 06:55:17 RESOLVED: Ask CSS WG to approve separating out most of the geometry interfaces into mixins we can reference in SVG interface definitions. 06:56:38 SVG2 06:56:38 https://svgwg.org/svg2-draft/single-page.html#coords-InterfaceSVGTransform 06:56:38 W3C Editor’s Draft 14 September 2025 06:56:38 readonly attribute unsigned short type; 06:56:39 [SameObject] readonly attribute DOMMatrix matrix; 06:56:39 readonly attribute float angle; 06:56:43 undefined setMatrix(optional DOMMatrix2DInit matrix = {}); 06:56:58 nzimmermann: appart from interop issue, is there any reason to get back to SVGMatrix? DOMMatrix seems to be the way to go eventhough not implemented yet. 06:57:30 ydaniv: 06:58:09 ydaniv: I agree with Niko we should merge SVGMartrix and DOMMatrix. I am editor for maintenance reasons. If there are interop isuses, I am willing to help to overcome these. 06:58:31 karlcow: Do we have documented issues (breakage) of any kind? 06:58:45 ydaniv: I don't think we had to rely on the API so far. 06:58:55 ydaniv: IMO it is an edge case 06:59:26 getScreenCTM 06:59:31 nzimmermann: The only relevant exposure are getScreenCTM getCTM. 06:59:52 nzimmermann: The already have the right aliases a, b, c, d, e, f 07:00:46 nzimmermann: I am not seeing the use of the methods on SVGMatrix. DOMMatrixInit is just a dict. 07:01:33 krit: yes, as long as the object have the propterties of DOMMatrixInit any object is fine. Including SVGMatrix and DOMMatrix. But can also be a regular object. 07:01:41 https://drafts.csswg.org/geometry/#DOMMatrix 07:03:24 nzimmermann: both methods return a DOMMatrix and DOMMatrix inherits the missing methods from SVGMatrix. So no backward compatibility breakage w/ the exception of the return type. But who checks the getCTM/getScreenCTM type? 07:03:43 ydaniv: unless there is a interop issue 07:04:00 https://w3c.github.io/svgwg/svg2-draft/single-page.html#types-InterfaceSVGGraphicsElement 07:04:08 krit: Nico went through the potential issues but it seems fully backwards compat. 07:04:28 ydaniv: so only instance check might fail? 07:04:30 nzimmermann: yes 07:05:03 karlcow: So it is only on the implementers? 07:05:15 nzimmermann: right, we just need to write tests for WPT 07:05:41 viralipurbey: I wonder what lead to the resolution. 07:08:32 RESOLUTION: We keep DOMMatrix and DOMMatrixInit as reference 07:09:21 topic: Editorial: Replacing draft URI from svgwg.org/svg2-draft to w3c.github.io/svgwg/svg2-draft/ 07:09:27 https://github.com/w3c/svgwg/issues/1060 07:10:56 karlcow: Just suggesting to modify the draft link from svgwg.org to github.io 07:13:37 RESOLUTION: Use github.io instead of svgwg.org until issues with domain have been resolved 07:13:57 topic: Compatibility of focusability with HTML & platform conventions 07:14:06 https://github.com/w3c/svgwg/issues/736 07:16:22 karlcow: focusable is only implemented in old Edge but in no other browser 07:16:57 Vinay: Correct. We should remove the tests from WPT and remove the focusable 07:17:14 karlcow: It needs to get removed from the spec. It is mentioned in 1-2 places. 07:17:33 karlcow: ... e.g there is a mention of SVG Tiny focusable. 07:18:00 krit: since it is legacy, do we need to deprecate it officially? 07:18:14 karlcow: maybe. Not sure if it is actually defined somewhere. 07:18:56 krit: lets make the note formal that focusable is deprecated and shall not be used. 07:19:46 RESOLUTION: Make the note formal that focusable (from older SVG specs) is deprecated and shall not be used 07:20:04 ACTION: karlcow will make the formal change to deprecate focusable from the SVG2 spec 07:20:28 topic: Does the entire path need to be valid in order to use a path attribute on a textPath 07:20:42 https://github.com/w3c/svgwg/issues/393 07:21:52 karlcow: the initial issue 2019 was to drop 1 sentence from the spec: if the path attibute contains a... then the path attribute must be used.. this was already covered so there was no point to reverting it 07:22:24 viralipurbey: spec asks to take the path attribute up to the first error and drop the rest of the path 07:22:52 viralipurbey: If we don't find a path we should fallback to href 07:22:58 S/so there was no point to reverting it/in the path error handling section, so the sentence is not necessary./ 07:23:06 viralipurbey: but ideally we should not fallback. 07:23:20 nzimmermann: makes sense to me. You set path after all. 07:23:42 nzimmermann: so either inline or reference. Would be weird to fallback to nothing if you made a typo 07:25:21 nzimmermann: maybe we should have no conditions at all if a path attribute is present 07:25:53 nzimmermann: authors should not use both at all. If path is present, it needs to take precedence in any case. 07:26:21 viralipurbey: What about an empty string (or if the error handling would result in no path) 07:26:50 nzimmermann: it doesn't make sense to have an error in a path and then have a reference in case the path has an error 07:27:01 karlcow: IMO it is a source of confusion for the authors. 07:27:10 karlcow: The author may not understand why it is breaking. 07:28:23 viralipurbey: IMO it should mean something to allow both 07:30:05 RESOLUTION: Drop the sentence where the reference should be used on invalid path. Instead use the path attribute and path data up to the first error. Even if the error results in no path at all. path takes precedence over reference. 07:32:26 topic: RRSAgent make minutes 07:32:39 Zakim, make minutes 07:32:39 I don't understand 'make minutes', krit 07:32:59 RRSAgent: make minutes 07:33:00 I have made the request to generate https://www.w3.org/2026/02/19-svg-minutes.html krit 07:33:45 RRSAgent, make logs public 13:21:23 zrhoffman has joined #svg 13:21:42 zrhoffman has joined #svg 13:28:58 Zakim has left #svg