[resize-observer] svg interaction

[bkardell]

ResizeObserver mentions SVG specially several times (see, for example https://drafts.csswg.org/resize-observer/#calculate-box-size). I don't recall the intent of this, but I am wondering if perhaps it is intended for observing the resizing of things inside the SVG and not the SVG itself? It seems that if I had some construct with a svg with width="100%" the SVG itself is resizing, but if it is observing the boundingBox then those things will not be reported. This little pen illustrates what I mean - here, I believe the path should fill green, but it doesn't because it seems that what is being observed is the bounding box. The pen also updates the reporting of the size of that bounding box every 100ms and as you can see, it never updates.

This seems strange and it does seem (at least from what I can tell) implemented this way in all of the browsers. As an author, it's true that you can work around this by wrapping a div around it and monitoring that instead, but that seems like a strange workaround and like maybe this creates a need for special understanding. It seems what we want to observe here is not this?

[AmeliaBR]

For SVG elements that have associated CSS layout boxes, you should definitely be able to access the CSS content and border boxes, the same as on an <img> or container element. This applies to the root <svg> in an SVG document and any inline <svg> element that is a direct child of HTML elements (or other non-SVG elements) or a direct child of an SVG <foreignObject> element, which creates an internal CSS layout context. Other specifications have special rules for SVG elements with or without CSS boxes, including transform-origin and some CSSOM View APIs.

For SVG elements without CSS layout boxes (i.e, shape or group elements, or <svg> nested inside other <svg>), then content-box and border-box aren't defined. So perhaps it makes sense to default to the SVG object bounding box size. This will only be useful in limited cases — where the container <svg> does not have a viewBox attribute and this element or its children are defined using percentage dimensions, which will therefore change as the container is resized — but most other cases could be handled by listening for resize events on the SVG that does have CSS layout boxes, if those are handled as normal CSS boxes.

[gregwhitworth]

For SVG elements that have associated CSS layout boxes, you should definitely be able to access the CSS content and border boxes, the same as on an <img> or container element. This applies to the root <svg> in an SVG document and any inline <svg> element that is a direct child of HTML elements (or other non-SVG elements) or a direct child of an SVG <foreignObject> element, which creates an internal CSS layout context.

I agree that this is what an author would expect and may just be an oversight, I'm personally in favor to adjusting the spec text to allow for this scenario to work. FYI @atotic

[css-meeting-bot]

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 */}

The full IRC log of that discussion

<dael> Topic: svg interaction
<dael> github: https://github.com//issues/4032
<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.
<dael> Rossen_: Can you summerize?
<dael> bkardell_: Resize observer observes a box. First take was content and expanded to border.
<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.
<dael> bkardell_: Difference between element inside svg or svg itself is easiest example
<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.
<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.
<dael> AmeliaBR: THis is a spec change that requires impl change to match.
<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
<fantasai> https://github.com//issues/857 is relevant here
<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.
<dael> gregwhitworth: Maybe other svg folks can think about it as well
<emilio> q+
<fantasai> See e.g. https://drafts.fxtf.org/fill-stroke/#fill-origin
<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.
<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.
<dael> Rossen_: I'm leaning toward agreeing with bkardell_ and stick to defining the behavior on css box
<dael> gregwhitworth: Sounds like based on your and AmeliaBR expertese there isnt value for bounding box. Could remove svg special case
<Rossen_> ack emilio
<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.
<Rossen_> ack fantasai
<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
<dael> AmeliaBR: Not sure we got that adoped beyond one spec.
<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
<AmeliaBR> q+
<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
<gregwhitworth> Proposed Resolution: Remove special case for SVG which will allow SVG elements to be observed rather than using the svg bounding box
<dael> bkardell_: If my svg resizes I should be able to observe that
<dael> bkardell_: According to spec and impl you can't. At a minimum we'd like that resolved.
<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.
<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
<AmeliaBR> `svg:root, *:not(svg|*) > svg, svg|foreignObject > svg { /* SVG elements with CSS layout box */}`
<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.
<Rossen_> ack AmeliaBR
<dael> AmeliaBR: We have clear agreement svg elements with css layout boxes should be able to observer the css layout boxes from resize observer.
<dael> AmeliaBR: Pasted in IRC the definition of those elements as a css selector.
<dael> AmeliaBR: Those svg elements have a css layout box and you should be able to observe it
<dael> Rossen_: fantasai will this contradict anything you said?
<dael> fantasai: no
<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.
<fantasai> https://github.com//issues/857 is the issue where we resolved the box correspondance
<dael> Rossen_: Is that going to be the case?
<fantasai> See definitions at https://drafts.fxtf.org/fill-stroke/#fill-origin
<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
<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.
<bkardell_> can we punt the things specifically inside of svg to a level 2, is that what emelio was asking for ?
<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
<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
<dael> AmeliaBR: THe bounding boxes in general, browsers have rough and dirty calc and precise calc. Rough is for dirty paint
<bkardell_> fantasai, I think this is the important part - can we resolve on that?
<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
<bkardell_> +1
<dael> Rossen_: prop: svg elements generating css layout boxes are included as part of resize observer and resize observer rectangles
<dael> Rossen_: Obj?
<dael> Rossen_: With definition of layout box is `svg:root, *:not(svg|*) > svg, svg|foreignObject > svg { /* SVG elements with CSS layout box */}
<bkardell_> rossen - is there a second resolution necessary for punting some of what is in the spec currently to v2
<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 */}
<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
<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
<dael> Rossen_: I would agree. I don't think ready for second resolution

[AmeliaBR]

SVG bug for discussing what should happen for elements without CSS layout boxes: w3c/svgwg#713