Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How should ResizeObserver work for SVG layout elements? #713

Open
AmeliaBR opened this issue Jul 10, 2019 · 2 comments
Open

How should ResizeObserver work for SVG layout elements? #713

AmeliaBR opened this issue Jul 10, 2019 · 2 comments

Comments

@AmeliaBR
Copy link
Contributor

Background: w3c/csswg-drafts#4032
Current spec: https://drafts.csswg.org/resize-observer/#calculate-box-size

In w3c/csswg-drafts#4032, the CSS WG resolved that SVG elements with CSS layout boxes should be observable as regular CSS boxes. However, the group defers to SVG for what boxes should be observable for other SVG elements.

The current spec & implementations return the SVG layout object bounding box, regardless of which CSS box is asked for. Fantasai recommended that, if the spec maps CSS layout box keywords to SVG bounding boxes, it should follow the definitions in Fill & Stroke, as resolved in w3c/csswg-drafts#857

Another possibility is that no mappings from CSS boxes to SVG boxes happens at all: if you try to observe resizing of a CSS box on an element that doesn't have CSS layout, you won't get any observations. Level 2 of Resize Observer may add other boxes that you can observe, which could include observing the SVG layout boxes directly.

@css-meeting-bot
Copy link
Member

css-meeting-bot commented Jul 29, 2019

The SVG Working Group just discussed How should ResizeObserver work for SVG layout elements?.

The full IRC log of that discussion <krit> topic: How should ResizeObserver work for SVG layout elements?
<krit> GitHub: https://github.com//issues/713
<krit> AmeliaBR: ppl should look about it and comment what would makes sense
<krit> krit: is it ready for discussion?
<krit> AmeliaBR: in CSS we said SVG elements with CSS layout box should behave like all other CSS layout box elements
<krit> AmeliaBR: So I created an issue for SVG elements that are not using the CSS layout box. Should we map the CSS layout box terms to SVG or should we do it differently? What are the use cases for SVG?
<krit> krit: looking at use case first might make sense. Who should primiatly look at those? Implementers? Authors?
<krit> AmeliaBR: both. But we should come up with boxes that are rapidly caculatable.
<krit> krit: everything that creates a new SVG viewport might be easy. Everything else needs to compete the Object bounding box which might not easy to compute for text and paths.
<krit> myles: Not sure if SVG viewport only would be useful. Nested SVG might be useful still but would be shame not to support it everywhere.
<krit> krit: having more feedback from actual authors and users of resize observers would be great
<krit> krit: do we want to provide any options
<krit> AmeliaBR: Options are 1) there is nothing to observe on SVG layout (only CSS layout box elements). We could have the option to support bounding box observation in the future.
<krit> myles: authors might not know the terminology
<krit> AmeliaBR: talking in spec terms
<krit> AmeliaBR: 2) What is currently in the spec: any request for observing an element just returns the SVG object bounding box.
<krit> AmeliaBR: 3) Try to map CSS layout box to equiviland SVG boxes. padding box to object bounding box...
<krit> AmeliaBR: there is no implementation that exposes stroking bounding box
<krit> krit: we do the mapping for some CSS properties
<krit> AmeliaBR: but not in a consistent way yet
<krit> krit: might not easy to make it consistent but it still is a possibility.
<krit> krit: my personal preference would be the mapping. As said, competing the bounding box is not always fast. On the other hand, it isn't always in CSS either.

@progers
Copy link

progers commented Jan 30, 2020

When implementing resize-observer in chromium, we found an issue related to this where the resize-observer and box-model definitions to not agree. Should "content-box" use the fill-box for SVG and "border-box" use the stroke-box for SVG?

The resize-observer spec states that:

If target is an SVGGraphicsElement
Set computedSize.inlineSize to target’s bounding box inline length.
Set computedSize.blockSize to target’s bounding box block length.

If target is not an SVGGraphicsElement
If observedBox is "border-box"
Set computedSize.inlineSize to target’s border area inline length.
Set computedSize.blockSize to target’s border area block length.
If observedBox is "content-box"
Set computedSize.inlineSize to target’s content area inline length.
Set computedSize.blockSize to target’s content area block length.

The css-box spec states:

content-box
Refers to the content box or content edge. (In an SVG context, treated as fill-box.)
...
border-box
Refers to the border box or border edge. (In an SVG context, treated as stroke-box.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants