minutes, 20 November 2025 SVG WG telcon

Minutes from telcon are below.
<https://www.w3.org/2025/11/20-svg-minutes.html>
SVG Working Group weekly call – 20 November 2025<https://www.w3.org/2025/11/20-svg-minutes.html>
w3.org<https://www.w3.org/2025/11/20-svg-minutes.html>
[favicon.ico]<https://www.w3.org/2025/11/20-svg-minutes.html>
IRC log of svg on 2025-11-20

Timestamps are in UTC.

06:40:12 [RRSAgent]
RRSAgent has joined #svg
06:40:18 [RRSAgent]
logging to https://www.w3.org/2025/11/20-svg-irc

06:46:08 [Vinay]
Vinay has joined #svg
06:46:30 [dmangal]
dmangal has joined #svg
06:46:34 [dmangal]
present+
06:46:36 [Vinay]
present+
06:47:11 [karlcow]
present+
06:47:20 [krit]
present+
06:47:45 [caribou]
present+
06:48:49 [ydaniv]
ydaniv has joined #svg
06:48:57 [ydaniv]
present+
06:51:19 [karlcow]
Scribenick: karlcow
06:51:31 [krit]
topic: Clarify whether var() (custom properties) are allowed in SVG presentation attributes, and how they are parsed/resolve
06:51:39 [krit]
https://github.com/w3c/svgwg/issues/1031

06:52:40 [karlcow]
dmangal: The spec defines the way we should parse attributes.
06:53:26 [karlcow]
... The spec seems to disallow substitution through var. There is a discrepancy in between browsers.
06:54:05 [karlcow]
... if we decide to allow this kind of values, we need to define how to parse it.
06:54:47 [karlcow]
Krit: in SVG2, we decided to use CSS parsing rules, but if it's not clear in the spec, we need to refine that.
06:55:32 [karlcow]
... I don't see any reasons why we should not be able to have the same rules as CSS.
06:55:46 [karlcow]
... presentation attributes have very specific rules.
06:56:19 [karlcow]
Presentation attributes are coming before user style sheets, but after user agent stylesheets.
06:57:05 [karlcow]
dmangal: We might need to specify the behavior of the hierarchy of parsing the attributes.
06:57:55 [karlcow]
Vinay: I agree that we should not restrict any values.
06:58:18 [karlcow]
... We should follow the spec on cascading/
06:59:13 [karlcow]
Dmangal: the spec doesn't specify if it should be done at parse time or compute time.
07:00:28 [karlcow]
... chromium does it partially. Firefox and Safari are doing it.
07:01:13 [karlcow]
ydaniv: do we have tests for testing this area?
07:01:26 [karlcow]
Krit: Let's create tests for the next meeting.
07:03:08 [krit]
krit has joined #svg
07:03:08 [Rossen]
Rossen has joined #svg
07:03:08 [zrhoffman]
zrhoffman has joined #svg
07:03:08 [slightlyoff]
slightlyoff has joined #svg
07:03:08 [leaverou]
leaverou has joined #svg
07:03:08 [iank_]
iank_ has joined #svg
07:03:08 [emilio]
emilio has joined #svg
07:03:08 [karlcow]
karlcow has joined #svg
07:03:09 [Ragvesh]
Ragvesh has joined #svg
07:03:14 [Ragvesh]
present+
07:03:19 [krit]
present+
07:03:32 [karlcow]
RRSAgent, log
07:03:37 [karlcow]
dmangal, we want to test the cascading, the var function, and other styles of combination.
07:04:16 [krit]
topic: Specifying processing model and algorithm for ping and referrerPolicy in SVG a element
07:04:46 [karlcow]
topic: Clarify whether var() (custom properties) are allowed in SVG presentation attributes, and how they are parsed/resolve
07:06:07 [dmangal]
We want to allow substitution function values like var or env for presentation attribute, the exact parsing algorithm will be discussed later
07:06:19 [karlcow]
RESOLVED: We want to allow substitution function values like var or env for presentation attribute, the exact parsing algorithm will be discussed later
07:06:23 [krit]
https://github.com/w3c/svgwg/issues/1029

07:07:15 [karlcow]
dmangal: on the a element, we support a couple of elements from HTML.
07:07:33 [karlcow]
... There are concerns about the processing model for some elements.
07:08:06 [karlcow]
... What processing models they should follow? We should probably defined as they are defined in the HTML spec.
07:10:55 [karlcow]
Karlcow: I had discussion with Simon Pieters at TPAC. There is probably a need for clarification for the way the attributes are defined on HTML.
07:11:31 [karlcow]
... I think we should double check the status of the attributes on HTML but definitely it should follow what HTML spec is doing.
07:12:02 [karlcow]
Krit: What is the best way to define the attributes in SVG spec still following what the HTML spec is doing.
07:12:29 [karlcow]
Dmangal: it is probably to work what needs to be defined in the HTML spec.
07:12:49 [karlcow]
Karlcow: Is there an issue opened on the HTML spec?
07:12:59 [karlcow]
Dmangal: Probably not at this time.
07:13:54 [karlcow]
Krit: I'm not opposed to follow the html spec, the question is becoming more how to phrase it?
07:14:48 [karlcow]
Dmangal: (Given an overview of the support through the tests on WPT. See the issue for references.)
07:18:58 [karlcow]
RESOLVED: let's create a note in the SVG spec mentioning that we are waiting on the HTML spec to clarify the processing model for these attributes.
07:19:10 [karlcow]
ACTION: dmangal to open an issue on the HTML spec… about this issue.
07:19:18 [krit]
topic: Clarify <iframe> behavior in <svg:use>
07:19:22 [krit]
https://github.com/w3c/svgwg/issues/876

07:19:41 [ydaniv]
scribe+
07:20:01 [ydaniv]
karlcow: we had a discussion in TPAC about shadow trees
07:20:35 [ydaniv]
... clarify that the script elements inside iframes inside an svg:use
07:21:06 [ydaniv]
... we create a shadow tree, and what the use creates inside it, with the iframe, how does it execute scripts loaded inside that iframe
07:21:51 [ydaniv]
krit: question is, what does inert scripts mean?
07:22:17 [ydaniv]
dmangal: by inert we mean not able to modify shadow DOM elements
07:22:33 [ydaniv]
karlcow: when it's inert you can't modify anything visible to the script
07:22:51 [ydaniv]
dmangal: it also means it won't execute at all
07:22:54 [ydaniv]
karlcow: yeah
07:23:58 [ydaniv]
ydaniv: I guess inert should cascade down to iframes
07:24:13 [ydaniv]
krit: you're saying people are relying on this behavior?
07:24:51 [ydaniv]
ydaniv: yes, if this is what scripts do then seem silly to be able to bypass
07:25:00 [ydaniv]
krit: is it implemented in SF?
07:25:04 [ydaniv]
karlcow: have to check
07:26:07 [ydaniv]
krit: in WK and Blink foreignObject isn't properly implemented according to shadow DOM spec
07:26:34 [ydaniv]
... don't see a reason why it should behave differently but should be specified
07:26:57 [ydaniv]
karlcow: need more tests
07:27:00 [ydaniv]
krit: yes
07:27:10 [ydaniv]
... spec text should be based on current implementations
07:27:24 [ydaniv]
... do we have anything to resolve on now?
07:27:39 [karlcow]
ACTION: karlcow to create tests for understanding the way it is currently implemented.
07:27:39 [ydaniv]
karlcow: I'll try to create tests and understand the way it's currently working
07:28:06 [ydaniv]
Github: https://github.com/w3c/svgwg/issues/875

07:28:07 [krit]
topic: <svg:use> shadow tree shouldn't be open
07:28:11 [krit]
https://github.com/w3c/svgwg/issues/875

07:28:58 [ydaniv]
karlcow: similar to last issue, FF implemented this and saw it allows XSS, and needs to be done properly
07:29:19 [ydaniv]
... you have a use element, and it creaates a shadow tree, you should not be able to modify and inspect things outside
07:29:31 [ydaniv]
... it needs more tests
07:30:05 [ydaniv]
krit: so what is the request?
07:30:32 [ydaniv]
krit: spec says inpectable by script but read only
07:31:43 [ydaniv]
... please comment there and ask emilio for more feedback
07:35:50 [karlcow]
RRSAgent, make minutes
07:35:52 [RRSAgent]
I have made the request to generate https://www.w3.org/2025/11/20-svg-minutes.html karlcow
07:36:03 [karlcow]
RRSAgent, make logs public
07:40:04 [caribou]
Meeting: SVG Working Group weekly call
07:40:12 [caribou]
RRSAgent, make minutes
07:40:13 [RRSAgent]
I have made the request to generate https://www.w3.org/2025/11/20-svg-minutes.html caribou
13:25:43 [Zakim]
Zakim has left #svg