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