-
Notifications
You must be signed in to change notification settings - Fork 132
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
Labels
Comments
The SVG Working Group just discussed 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. |
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:
The css-box spec states:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The text was updated successfully, but these errors were encountered: