- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 10 Jul 2019 16:38:10 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `svg interaction`, and agreed to the following:
* ``RESOLVED: svg elements generating css layout boxes are included as part of resize observer and resize observer rectangles with a definition of `svg:root, *:not(svg|*) > svg, svg|foreignObject > svg { /* SVG elements with CSS layout box */}``
<details><summary>The full IRC log of that discussion</summary>
<dael> Topic: svg interaction<br>
<dael> github: https://github.com/w3c/csswg-drafts/issues/4032<br>
<dael> bkardell: Sounds like have agreement what it's doing with SVG element and maybe some cases AmeliaBR described is looking at wrong box. I think gregwhitworth agreed.<br>
<dael> Rossen_: Can you summerize?<br>
<dael> bkardell_: Resize observer observes a box. First take was content and expanded to border.<br>
<dael> bkardell_: In SVG terms means things linse svg rendering context where box is translated into svg viewport. THose dimensions are adjusted for viewport. In main doc where thinking about css boxes you want css boxes.<br>
<dael> bkardell_: Difference between element inside svg or svg itself is easiest example<br>
<dael> AmeliaBR: Current spec has special rules for svg elements. As spec and impl those special rules are used for all svg elemnents, even those with css box so you can't use resize observer to see if your svg has been resized.<br>
<dael> AmeliaBR: That's where we have agreement from gregwhitworth this is unintentional oversite. Elements with css layout boxes you should be able to observe those values.<br>
<dael> AmeliaBR: THis is a spec change that requires impl change to match.<br>
<dael> AmeliaBR: Question of what to do about svg elements that don't have css layout boxes I don't know if there's clear agreement. No matter the box you ask for you get svg bounding box<br>
<fantasai> https://github.com/w3c/csswg-drafts/issues/857 is relevant here<br>
<dael> gregwhitworth: AmeliaBR I think what you said is fine. Id on't have knowledge on inner workings of svg. WE have bounding box as universal thing, but you say it won't be useful inside svg. Majority of use cases would end up doing what bkardell_ tried. Having the fallback where it doesn't have a css box fallback to the svg bounding box. Seems reasonable to me.<br>
<dael> gregwhitworth: Maybe other svg folks can think about it as well<br>
<emilio> q+<br>
<fantasai> See e.g. https://drafts.fxtf.org/fill-stroke/#fill-origin<br>
<dael> bkardell_: I don't knwo use cases for what you would observe inside an svg. I guess I can think of some. Seem different and more complex. Missing the one fitting in where this thing has a css box and it's not reporting it.<br>
<dael> Rossen_: Defining this on css boxes sounds more sane then defining on anything that creates a bounding box. Effect of computing trees and subtrees will be intense.<br>
<dael> Rossen_: I'm leaning toward agreeing with bkardell_ and stick to defining the behavior on css box<br>
<dael> gregwhitworth: Sounds like based on your and AmeliaBR expertese there isnt value for bounding box. Could remove svg special case<br>
<Rossen_> ack emilio<br>
<dael> emilio: It sounds fine to just not have. If it's on css bounding boxes. We had discussin on resize observer v2 about different types of boxes. Wierd if you get svg bounding box when that's not what you asked for. I'm good with restricting to those with css bounding boxes.<br>
<Rossen_> ack fantasai<br>
<dael> fantasai: As we were defining how svg doesnt have border box. There are definitions in fill and stroke that we adopt that map things like border box in a standard way. If we're going to allow any kind of lookup on svg shapes we should be consistent with that resolution<br>
<dael> AmeliaBR: Not sure we got that adoped beyond one spec.<br>
<dael> fantasai: Had a resolution though. If specs were updated is separate. BUt we said we'd do it across all specs so they're consistent. Resize observer shoudln't be exception. If we're allowing it to be set on svg shape should be consistent<br>
<AmeliaBR> q+<br>
<dael> bkardell_: I think there's 2 ends to this. One is if SVG bounding boxes should be reported. If they have css content boxes they should be, most basic version os resize observer is at least that<br>
<gregwhitworth> Proposed Resolution: Remove special case for SVG which will allow SVG elements to be observed rather than using the svg bounding box<br>
<dael> bkardell_: If my svg resizes I should be able to observe that<br>
<dael> bkardell_: According to spec and impl you can't. At a minimum we'd like that resolved.<br>
<dael> Rossen_: I think that's where everyone is leaning. We spent some time in the past defining top level viewport. as far as I remmeber we defined as viewport that is generated by svg/svg element. That's the outermost element that creates a box.<br>
<dael> Rossen_: It essentially lives in css/html world and governed by css rules. You can apply anything to that box you can apply to other boxes. Inside that it's the svg world. Until you hit a foreign element that transitions from svg back into css world and creates a css box<br>
<AmeliaBR> `svg:root, *:not(svg|*) > svg, svg|foreignObject > svg { /* SVG elements with CSS layout box */}`<br>
<dael> Rossen_: It's very natural and reasonable to expect both these boxes would be included in resize observer. If that's explicitly omitted or forbidden by resize observer we need to adjust the spec.<br>
<Rossen_> ack AmeliaBR<br>
<dael> AmeliaBR: We have clear agreement svg elements with css layout boxes should be able to observer the css layout boxes from resize observer.<br>
<dael> AmeliaBR: Pasted in IRC the definition of those elements as a css selector.<br>
<dael> AmeliaBR: Those svg elements have a css layout box and you should be able to observe it<br>
<dael> Rossen_: fantasai will this contradict anything you said?<br>
<dael> fantasai: no<br>
<dael> Rossen_: What you mentioned is important. As we add spec around what we map in terms of boxes and css box concepts I want to make sure we won't add additional confusion.<br>
<fantasai> https://github.com/w3c/csswg-drafts/issues/857 is the issue where we resolved the box correspondance<br>
<dael> Rossen_: Is that going to be the case?<br>
<fantasai> See definitions at https://drafts.fxtf.org/fill-stroke/#fill-origin<br>
<dael> fantasai: I think it's fine. Since the boxes AmeliaBR mentioned don't have strokes there's nothing we need to worry about. But we should make sure specs align going forward<br>
<dael> AmeliaBR: Improtant thing is when we have the corrispondance they don't override actual boxes. If you have a padding box we don't defer to stroke bounding box.<br>
<bkardell_> can we punt the things specifically inside of svg to a level 2, is that what emelio was asking for ?<br>
<dael> AmeliaBR: Aspect without clear agreement is what happens for svg elements that don't have css layout boxes. Current spec is they always give regular bounding box. fantasai comments come down to they should give a specific svg bounding box with a direct corrisponance to css bounding box. My concern is could be difficult to compute for a fast api<br>
<fantasai> bkardell_, yes, as long as we're comfortable with how it's not working right now and that we can change and update it in the future<br>
<dael> AmeliaBR: THe bounding boxes in general, browsers have rough and dirty calc and precise calc. Rough is for dirty paint<br>
<bkardell_> fantasai, I think this is the important part - can we resolve on that?<br>
<dael> Rossen_: Let's take this with svg wg. If svg wg has rec for how resize observer shoudl be defined on non-css boxes let's discuss later. Want to close those topic<br>
<bkardell_> +1<br>
<dael> Rossen_: prop: svg elements generating css layout boxes are included as part of resize observer and resize observer rectangles<br>
<dael> Rossen_: Obj?<br>
<dael> Rossen_: With definition of layout box is `svg:root, *:not(svg|*) > svg, svg|foreignObject > svg { /* SVG elements with CSS layout box */}<br>
<bkardell_> rossen - is there a second resolution necessary for punting some of what is in the spec currently to v2<br>
<dael> RESOLVED: svg elements generating css layout boxes are included as part of resize observer and resize observer rectangles with a definition of `svg:root, *:not(svg|*) > svg, svg|foreignObject > svg { /* SVG elements with CSS layout box */}<br>
<dael> bkardell_: Do we need second resolution to punt some of spec that deals with stuff that's not that to a v2? I think even fantasai was saying as long as comfortable with not working now...i think that's want emilio asked for<br>
<dael> AmeliaBR: Right now we have a spec and browsers matching. We don't have clear agreement spec is wrong. Unless rushing to get spec to pub why don't we have discussion about what spec should be and make edits after<br>
<dael> Rossen_: I would agree. I don't think ready for second resolution<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4032#issuecomment-510137495 using your GitHub account
Received on Wednesday, 10 July 2019 16:38:12 UTC