Re: [svgwg] "Sizing properties" section should mention the "use" element (#607)

The SVG Working Group just discussed `"Sizing properties" section should mention the "use" element`.

<details><summary>The full IRC log of that discussion</summary>
&lt;myles> Topic: "Sizing properties" section should mention the "use" element<br>
&lt;krit> me https://github.com/w3c/svgwg/issues/607<br>
&lt;myles> GitHub: https://github.com/w3c/svgwg/issues/607<br>
&lt;myles> AmeliaBR: This one is my fault. I did the edits to one section on the &lt;use> element and didn't do the edits to the other section about the actual property, saying they apply to the &lt;use> element. That's how we ended up with the inconsistency. Backstory: Originally, when width and height were added as CSS properties to replace the SVG attributes, it was only a limited number of elements it applied, and &lt;use> wasn't on the list. So it wasn't in the first batch<br>
&lt;myles>  of implementation in chromium and webkit. The reason it was added in later had to do with some testing. Because of the way things were defined with symbol, width and height were getting used on &lt;symbol> even though they weren't defined to, so we decided to add in the attributes on &lt;symbol> and in the discussion we asked if there's no reason not to allow them as properties<br>
&lt;myles> AmeliaBR: But, it's a case of: I don't think anyone has followed up at this point.<br>
&lt;myles> AmeliaBR: so width and height on &lt;use> would only be attributes. Benefit: Gets away from the extra confusion about how width and height on &lt;use> and how they apply to the re-used element in the shadow dom. So we wouldn't have to deal with describing that in CSS. Opinions?<br>
&lt;myles> krit: You're right that width and height propagation to shadow dom is something that needs more description. As the reporter noted, there aren't implementatiosn that would allow the widht and height properties on &lt;use>. Should we defer the presentation attributes on the &lt;use> attribute?<br>
&lt;myles> AmeliaBR:<br>
&lt;myles> AmeliaBR: Based on the test, even for nested &lt;svg> and some other elements, we don't have two implementations.<br>
&lt;myles> AmeliaBR: either way, even if we roll back this specific behavior with &lt;use>, we still need to put pressure on implementations to add it on the other elements. Maybe it's worth having that discussion to see if it will happen.<br>
&lt;myles> ericwilligers: I think the properties are important for animation.<br>
&lt;myles> AmeliaBR: Yes. CSS animations of size, they need to be CSS properties.<br>
&lt;myles> ericwilligers: Can we defer? i will look at it.<br>
&lt;myles> AmeliaBR: sounds good.<br>
&lt;myles> AmeliaBR: Myles, please follow up and see on WebKit if there are trakcing issues<br>
&lt;myles> myles: ok<br>
&lt;myles> krit: Is specifically about &lt;image> &lt;foreignObject> &lt;use> or what?<br>
&lt;myles> krit: We have &lt;image> and &lt;foreignObject> implemented in blink.<br>
&lt;myles> AmeliaBR: Nested SVG isn't working even in Chrome.<br>
&lt;myles> krit: mhm.<br>
&lt;myles> krit: For those that dont' have any implementations, would they be at risk? It would jsut be nested &lt;svg>, right? It's a bit tricky.<br>
&lt;myles> AmeliaBR: an SVG element that is SVG layout, as opposed to the outer SVG element which uses CSS layout anyways.<br>
&lt;myles> krit: We would need to specificy it more specifically. SVG elements in some contexts would be one way ... it's a little bit weird.<br>
&lt;myles> krit: We should open issues on different implemetnations. The question comes up with &lt;use>, and ericwilligers asked to defer, I'm fine with that. For &lt;image> and &lt;foreignObject>, should we mark "at-risk" or just leave it?<br>
&lt;myles> AmeliaBR: Let's make the decision when we get to the topic again.<br>
&lt;myles> krit: Let's move on.<br>
&lt;myles> krit: if there is implementor interest and a timeline or priority....<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/svgwg/issues/607#issuecomment-445977541 using your GitHub account

Received on Monday, 10 December 2018 21:20:01 UTC