Meeting minutes
Clarify whether var() (custom properties) are allowed in SVG presentation attributes, and how they are parsed/resolve
<krit> w3c/
dmangal: The spec defines the way we should parse attributes.
… The spec seems to disallow substitution through var. There is a discrepancy in between browsers.
… if we decide to allow this kind of values, we need to define how to parse it.
Krit: in SVG2, we decided to use CSS parsing rules, but if it's not clear in the spec, we need to refine that.
… I don't see any reasons why we should not be able to have the same rules as CSS.
… presentation attributes have very specific rules.
Presentation attributes are coming before user style sheets, but after user agent stylesheets.
dmangal: We might need to specify the behavior of the hierarchy of parsing the attributes.
Vinay: I agree that we should not restrict any values.
… We should follow the spec on cascading/
Dmangal: the spec doesn't specify if it should be done at parse time or compute time.
… chromium does it partially. Firefox and Safari are doing it.
ydaniv: do we have tests for testing this area?
Krit: Let's create tests for the next meeting.
dmangal, we want to test the cascading, the var function, and other styles of combination.
Specifying processing model and algorithm for ping and referrerPolicy in SVG a element
Clarify whether var() (custom properties) are allowed in SVG presentation attributes, and how they are parsed/resolve
<dmangal> We want to allow substitution function values like var or env for presentation attribute, the exact parsing algorithm will be discussed later
RESOLUTION: We want to allow substitution function values like var or env for presentation attribute, the exact parsing algorithm will be discussed later
<krit> w3c/
dmangal: on the a element, we support a couple of elements from HTML.
… There are concerns about the processing model for some elements.
… What processing models they should follow? We should probably defined as they are defined in the HTML spec.
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.
… I think we should double check the status of the attributes on HTML but definitely it should follow what HTML spec is doing.
Krit: What is the best way to define the attributes in SVG spec still following what the HTML spec is doing.
Dmangal: it is probably to work what needs to be defined in the HTML spec.
Karlcow: Is there an issue opened on the HTML spec?
Dmangal: Probably not at this time.
Krit: I'm not opposed to follow the html spec, the question is becoming more how to phrase it?
Dmangal: (Given an overview of the support through the tests on WPT. See the issue for references.)
RESOLUTION: 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.
ACTION: dmangal to open an issue on the HTML spec… about this issue.
Clarify <iframe> behavior in <svg:use>
<krit> w3c/
karlcow: we had a discussion in TPAC about shadow trees
… clarify that the script elements inside iframes inside an svg:use
… we create a shadow tree, and what the use creates inside it, with the iframe, how does it execute scripts loaded inside that iframe
krit: question is, what does inert scripts mean?
dmangal: by inert we mean not able to modify shadow DOM elements
karlcow: when it's inert you can't modify anything visible to the script
dmangal: it also means it won't execute at all
karlcow: yeah
ydaniv: I guess inert should cascade down to iframes
krit: you're saying people are relying on this behavior?
ydaniv: yes, if this is what scripts do then seem silly to be able to bypass
krit: is it implemented in SF?
karlcow: have to check
krit: in WK and Blink foreignObject isn't properly implemented according to shadow DOM spec
… don't see a reason why it should behave differently but should be specified
karlcow: need more tests
krit: yes
… spec text should be based on current implementations
… do we have anything to resolve on now?
ACTION: karlcow to create tests for understanding the way it is currently implemented.
karlcow: I'll try to create tests and understand the way it's currently working
Github: w3c/
<svg:use> shadow tree shouldn't be open
<krit> w3c/
karlcow: similar to last issue, FF implemented this and saw it allows XSS, and needs to be done properly
… you have a use element, and it creaates a shadow tree, you should not be able to modify and inspect things outside
… it needs more tests
krit: so what is the request?
krit: spec says inpectable by script but read only
… please comment there and ask emilio for more feedback