Meeting minutes
<karlcow> github-bot, w3c/
<github-bot> karlcow, Sorry, I don't understand that command. Try 'help'.
prsent+
SVGTransform.matrix returns SVGMatrix in all browsers
karlcow: Something was not correctly reverted in the SVG2 spec.
karlcow: SVGMatrix matches in all browsers
karlcow: issue was closed w/o reverting the change. In the spec it is still 2Dinit
karlcow: Chromium takes SVGMatrix for setMatrux
karlcow: FF and Safari Matrix2Dinit?
karlcow: The resolution was to revert for SVGMatrix from DOMMatrix
karlcow: I added the links to the github issue that references all discussions
karlcow: There is a todo in Chromium it should be DOMMatrix but was never done. But it was never done
krit: Chromium does not have DOMMatrix but Safari and FF kind of do
karlcow: but it is not what browsersdo
Vinay: I wanted to pick up but sentiment was not to break what is working
<karlcow> Resolutions ( Oct 22, 2019):
RESOLUTION: Revert decision to make SVG* geometry interfaces aliases of the DOM* geometry interfaces (pending CSS WG approval)
RESOLUTION: Change the SVG spec to use the SVG* geometry interfaces instead of DOM* interfaces
RESOLUTION: Keep the usage of DOM*Init types in the SVG spec
RESOLUTION: Ask CSS WG to approve separating out most of the geometry interfaces into mixins we can reference in SVG interface definitions.
<karlcow> SVG2
<karlcow> https://
<karlcow> W3C Editor’s Draft 14 September 2025
<karlcow> readonly attribute unsigned short type;
<karlcow> [SameObject] readonly attribute DOMMatrix matrix;
<karlcow> readonly attribute float angle;
<karlcow> undefined setMatrix(optional DOMMatrix2DInit matrix = {});
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.
ydaniv:
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.
karlcow: Do we have documented issues (breakage) of any kind?
ydaniv: I don't think we had to rely on the API so far.
ydaniv: IMO it is an edge case
<karlcow> getScreenCTM
nzimmermann: The only relevant exposure are getScreenCTM getCTM.
nzimmermann: The already have the right aliases a, b, c, d, e, f
nzimmermann: I am not seeing the use of the methods on SVGMatrix. DOMMatrixInit is just a dict.
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.
<karlcow> https://
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?
ydaniv: unless there is a interop issue
<karlcow> https://
krit: Nico went through the potential issues but it seems fully backwards compat.
ydaniv: so only instance check might fail?
nzimmermann: yes
karlcow: So it is only on the implementers?
nzimmermann: right, we just need to write tests for WPT
viralipurbey: I wonder what lead to the resolution.
RESOLUTION: We keep DOMMatrix and DOMMatrixInit as reference
Editorial: Replacing draft URI from svgwg.org/svg2-draft to w3c.github.io/svgwg/svg2-draft/
karlcow: Just suggesting to modify the draft link from svgwg.org to github.io
RESOLUTION: Use github.io instead of svgwg.org until issues with domain have been resolved
Compatibility of focusability with HTML & platform conventions
karlcow: focusable is only implemented in old Edge but in no other browser
Vinay: Correct. We should remove the tests from WPT and remove the focusable
karlcow: It needs to get removed from the spec. It is mentioned in 1-2 places.
karlcow: ... e.g there is a mention of SVG Tiny focusable.
krit: since it is legacy, do we need to deprecate it officially?
karlcow: maybe. Not sure if it is actually defined somewhere.
krit: lets make the note formal that focusable is deprecated and shall not be used.
RESOLUTION: Make the note formal that focusable (from older SVG specs) is deprecated and shall not be used
ACTION: karlcow will make the formal change to deprecate focusable from the SVG2 spec
Does the entire path need to be valid in order to use a path attribute on a textPath
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
viralipurbey: spec asks to take the path attribute up to the first error and drop the rest of the path
viralipurbey: If we don't find a path we should fallback to href
<karlcow> S/so there was no point to reverting it/in the path error handling section, so the sentence is not necessary./
viralipurbey: but ideally we should not fallback.
nzimmermann: makes sense to me. You set path after all.
nzimmermann: so either inline or reference. Would be weird to fallback to nothing if you made a typo
nzimmermann: maybe we should have no conditions at all if a path attribute is present
nzimmermann: authors should not use both at all. If path is present, it needs to take precedence in any case.
viralipurbey: What about an empty string (or if the error handling would result in no path)
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
karlcow: IMO it is a source of confusion for the authors.
karlcow: The author may not understand why it is breaking.
viralipurbey: IMO it should mean something to allow both
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.
RRSAgent make minutes
RRSAgent: make minutes