- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 21 Aug 2025 15:02:34 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-sizing-3][css-values-4] Define `width` and `height` CSS values for SVG Elements in a mapping``, and agreed to the following: * `RESOLVED: content dependent units used in width and height for inner SVG elements resolve to SVG's definition of auto` <details><summary>The full IRC log of that discussion</summary> <dmangal> q+<br> <astearns> ack dmangal<br> <ydaniv> dmangal: in SVG we allow width and height to be allowed<br> <ydaniv> ... these properties can take certain values, like pixels or relative values, or special keywords<br> <ydaniv> ... these values are already defined in SVG or CSS spec<br> <ydaniv> ... however there are values in form of viewport units and certain CSS keywords that depend on box model<br> <ydaniv> ... the spec is ambiguous about how to treat them<br> <ydaniv> ... so how to resolve is not clear<br> <ydaniv> ... the CSS spec requires resolving to ICB<br> <ydaniv> ... but SVG don't form that<br> <ydaniv> ... for same reason the min/max content keywords are also ambiguous<br> <ydaniv> ... we started conversations, that these should be resolved on ICB if available<br> <ydaniv> ... and for content based values would resolve on box model, we recommend to resolve to auto<br> <ydaniv> ... with defined behavior in SVG spec<br> <ydaniv> ... we want opinion on that proposal, if possible to have mapping of these values to properties in SVG spec<br> <kbabbitt> s/resolved on ICB if available/resolved on ICB if available, or browser viewport if ICB is not available/<br> <ydaniv> astearns: let's take viewport units first<br> <ydaniv> ... it seems there's general agreement in the issue<br> <ydaniv> SebastianZ: browsers seem to agree<br> <ydaniv> astearns: except for FF<br> <ydaniv> kbabbitt: they agree when these units are applied on the outmost SVG element, and we ask to specify these on the inner SVG elements<br> <ydaniv> dmangal: if the ICB is available the viewport units are resolved to that<br> <flackr> q+<br> <ydaniv> SebastianZ: sounds doable<br> <astearns> ack flackr<br> <ydaniv> flackr: what does it mean for ICB not to be available?<br> <ydaniv> dmangal: ICBs available can generate box model, and SVG elements don't have them<br> <ydaniv> flackr: inner SVG elements do have an element that initiates that block<br> <ydaniv> ... conceptually they still have an ICB, just don't live in a world where this box exists<br> <ydaniv> dmangal: initial proposal is that to use the ICB from inner elements got negative feedback from browsers<br> <ydaniv> ... instead they want to always use the viewport for resolution<br> <ydaniv> astearns: for anything other than the outermost SVG element<br> <ydaniv> dmangal: yes<br> <ydaniv> flackr: the ones that use the innermost of the SVG?<br> <ydaniv> dmangal: in the current proposal no<br> <ydaniv> flackr: as an analogy, if you make an iframe the vh unit inside it refer to the viewport<br> <ydaniv> astearns: everything in the iframe respects the box model<br> <ydaniv> flackr: I like the context<br> <dholbert> s/like/lack/<br> <ydaniv> astearns: wondering whether we should try again<br> <ydaniv> ... there is supposed to be a recharted WG to deal with bugs in SVG<br> <ydaniv> ... and this seems like a bug to me that they could spend time on fixing<br> <dholbert> (I've got similar confusion/concerns to flackr FWIW, but am also lacking context about why we can't just use the ICB for the iframe & how the ICB might not be defined)<br> <ydaniv> astearns: not pleased that we spec this just because current behavior is bad<br> <ydaniv> astearns: dmangal do you have more feedback?<br> <ydaniv> dmangal: one feedback to resolve against the ancestor's ICB<br> <ydaniv> ... in SVG case that would be the root SVG element<br> <ydaniv> ... the other proposal we got to resolve against the nearest element which is creating the viewport<br> <ydaniv> ... the first proposal was disliked because viewport units would be no different than percentages<br> <ydaniv> ... and second one was diliked because browsers don't currently do that<br> <ydaniv> astearns: don't accept either of those feedbacks<br> <flackr> q+<br> <ydaniv> ... if browers are currently managing at doing something with outermost SVG it wouldn't be that hard for doing it on inner SVG elements<br> <astearns> ack flackr<br> <ydaniv> flackr: I agree with astearns but also SVG have viewport definition that could establish a viewport that different than percentage resolution<br> <ydaniv> ... if we did resolved against the viewport of the SVG element , where would it won't match its size it would have a meaning<br> <ydaniv> ... agree it's better to have something, even it's the same value, to be more sensible<br> <astearns> s/feedbacks/feedbacks. viewport units being the same as percentages is better than viewport units having different behavoir based on the SVG hierarchy/<br> <ydaniv> astearns: let's not resolve on anything regarding viewport units, and move on<br> <ydaniv> ... proposal for content units is to resovle to auto<br> <ydaniv> dmangal: the auto behavior is specifyed in spec<br> <ydaniv> ... for SVG is to default to 100%<br> <ydaniv> ... for image tag is to default to intrinsic image size<br> <flackr> q+<br> <ydaniv> ... for all other elements it should default to 0<br> <astearns> ack flackr<br> <ydaniv> flackr: does the SVG document have intrinsic size as well?<br> <ydaniv> dmangal: the outermost SVG can have a size<br> <ydaniv> ... other define their size using the width/height properties<br> <ydaniv> flackr: when you specify auto, would it make sense to follow the image's conventions?<br> <ydaniv> dmangal: for elements like rect or other SVG elements we won't be referencing anything<br> <ydaniv> ... for image tag we take intrinsic sizes when auto is used<br> <ydaniv> ... but for other SVG elements we take the intrinsic is their portion of the size<br> <ydaniv> flackr: for SVG we would use the known size, and if not known then , what would it be? maybe 0?<br> <astearns> SVG definition of auto: https://www.w3.org/TR/SVG2/geometry.html#Sizing<br> <ydaniv> dmangal: in SVG case we use the width and height attributes<br> <ydaniv> ... would that cause a kind of confusion when we define their size?<br> <ydaniv> flackr: that would make sense for using intrisic size<br> <ydaniv> s/intrisic/intrinsic/<br> <ydaniv> flackr: I was thinking of viewbox for also providing the intrisic size<br> <ydaniv> dmangal: yes,<br> <ydaniv> flackr: we could have multiple fallbacks<br> <ydaniv> dmangal: Ok<br> <ydaniv> dholbert: for viewbox and intrinsic size it wouldn't good for many cases where they have ridicules values<br> <ydaniv> flackr: I think these are sensible<br> <ydaniv> dholbert: not necessarily<br> <ydaniv> ... in default we render 300x100<br> <ydaniv> ... there are edge cases, but not in specs<br> <astearns> dholbert: the viewbox is only reliable as a source of aspect ratio<br> <ydaniv> flackr: what happens when it's referenced by img elemnt?<br> <ydaniv> dholbert: we render the default 300x100<br> <ydaniv> ... I think there cases that we might resolved image to be size of the viewport when we don't have another fallback<br> <ydaniv> ... but in common fallback we use the 300x100 pixels<br> <ydaniv> ... we do use the viewbox to distinguish the aspect-ratio, but not for intrinsic size<br> <ydaniv> ... long story short, recommend against using viewbox for intrinsic size<br> <ydaniv> flackr: I know that many SVG editing tools have meaningful viewbox<br> <ydaniv> dholbert: usually that would be the coordinates space<br> <ydaniv> ... but when you export it's not good as defaults<br> <astearns> ydaniv: dholbert is correct. when designers export, they may just unknowingly export their huge design canvas<br> <kbabbitt> q+<br> <ydaniv> flackr: I'm convinced<br> <ydaniv> ... doesn't make value to use that<br> <astearns> ack kbabbitt<br> <ydaniv> kbabbitt: the proposal here is to treat CSS units that are content dependent as if they were auto<br> <ydaniv> ... does that make sense?<br> <ydaniv> astearns: makes some sense to me<br> <flackr> +1 makes sense to me to<br> <ydaniv> ... in particular that if SVG does get a better sense that they get that defintion if it's available to them<br> <ydaniv> ... sounds more flexible than 100%<br> <ydaniv> kbabbitt: that what the SVG spe currently says<br> <ydaniv> ... if there is no concept of content dependent units then treat it as auto<br> <ydaniv> ... and then we defer to what auto means in that concept<br> <flackr> q+<br> <ydaniv> astearns: proposed resolution: content dependent units resolve to SVG's definition of auto<br> <astearns> ack flackr<br> <ydaniv> flackr: one calrification, only for inner SVG elements?<br> <ydaniv> astearns: only for inner elements that don't participate in box model<br> <ydaniv> dholbert: just making sure there isn't anything other in the SVG spec<br> <astearns> https://www.w3.org/TR/SVG2/geometry.html#Sizing<br> <ydaniv> dmangal: you mentioned that in the SVG spec that auto has different meaning for different elements<br> <ydaniv> astearns: right, and dholbert was asking if this resolution applies only to some properties and not others?<br> <ydaniv> ... should we apply it only to widht and height?<br> <ydaniv> dmangal: yes, this is just for width and height<br> <ydaniv> astearns: fine let's scope it for that<br> <dmangal> q-<br> <astearns> proposed resolution: content dependent units used in width and height for inner SVG elements resolve to SVG's definition of auto<br> <astearns> RESOLVED: content dependent units used in width and height for inner SVG elements resolve to SVG's definition of auto<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12376#issuecomment-3210998345 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 21 August 2025 15:02:34 UTC