[css-images] Behaviour of SVG degenerate aspect-ratios

[bfgeek]

This issue is mainly just so that we can discuss this SVGWG issue: https://github.com/w3c/svgwg/issues/848

There are a few tests in the css-grid testsuite asserting behaviour.

[css-meeting-bot]

The CSS Working Group just discussed [css-images] Behaviour of SVG degenerate aspect-ratios.

The full IRC log of that discussion

<dael> Topic: [css-images] Behaviour of SVG degenerate aspect-ratios
<lea> I will reiterate that using CSSColorValue as input is not something that needs to be explicitly added to a spec, as long as it serializes
<dael> github: https://github.com/w3c/csswg-drafts/issues/6286
<dael> iank_: Digging into replaced elements. Series of test cases in grid repo that is probing this and there's a subtle difference in impl
<dael> iank_: If you go to SVG issue it contins example in 1st comment. When embed SVG in image need to know svg intrinsic size and aspect-ratio
<dael> iank_: svg are unique in you can have one or the other or both. FF has intrinsic but no a-r.
<dael> iank_: Blink and Gecko has both
<dael> iank_: Specific exampl,e have width 0px, height 50px. Viewbox says a-r is 1-1
<dael> iank_: FF have intrinsic 0x50 which matches. a-r is different
<dael> iank_: FF does one interpretation where treats a-r as degenerate and null. Blink and WK go this is degenerate so fallback to viewbox
<TabAtkins> example: <img width=100px src="<svg viewBox='0 0 1 1' width='0' height='50px'>">
<dael> iank_: That's the crux of the issue
<TabAtkins> what is the <img>'s height?
<astearns> ack fantasai
<dael> fantasai: If in general case have width of 1px rather than 0 we will ignore viewbox and use a-r from width and height?
<dael> iank_: Correct
<dael> fantasai: b/c it's degenerate blink fallsback to viewbox
<dael> iank_: Correct. Written down in the css spec. Linked to SVG text but it's same text.
<fantasai> s/fallsback to viewbox/falls back to viewbox, and gecko continues to ignore viewbox/
<dael> iank_: I don't think when algo was written it considered that width and height could result in degenerate a-r
<dael> fantasai: Yeah, I don't htink we considered this
<dael> iank_: You can also spec width -50px and get same behavior
<dael> fantasai: I have no opinion of what we out to do here. Don't think it matters for authoring. Would be interested to know what Amelia thinks
<TabAtkins> I too have no real opinion on how we resolve this. Both behaviors seem reasonable.
<dael> iank_: Yeah, tagged Amelia on the SVG but haven't received a response
<dael> fantasai: Is there a reason to do one or the other?
<dael> iank_: Not particularly. Could argue blink/WK is slightly better in that we use an a-r when it's available. But really I don't expect authors to write this. Only reason I'm bringing it up is there's 6 test cases asserting a behavior, I think written by a Gecko engineer. Not clear those tests are right
<dael> fantasai: Yeah, should clarify
<dael> fantasai: As long as we can't think of a reason my inclination is let Amelia read and make a decision for us
<dael> fantasai: I can ping her
<dael> iank_: Anyone else with thoughts?
<dael> astearns: This is just what to do in this edge case and theres no real world changes we can think of that would result from this?
<dael> iank_: Correct. Not addressing b/c a bug. Going through grid test suite and noticed this edge case was unclear
<dael> astearns: Happy going with Amelia but also happy going with 2/3 of engines went this way so let's spec
<dael> astearns: Leave until Amelia comes?
<dael> fantasai: Or resolve to do whatever she says
<dael> astearns: Objects?
<dael> chrishtr: Question
<dael> chrishtr: Did we discuss if degenerate cases in non-svg handled same?
<dael> fantasai: 2 sourses of info for a-r. most image formats don't have that confusion. We have general degenerate case, but here is when hit in more primary source of information. Do we fall back to secondary?
<dael> iank_: Some precedent in a-r where if you specific degenerate it falls back to images a-r I believe
<dael> iank_: Is that right?
<dael> fantasai: Don't remember off top of head but I think we decided that to match SVG
<fantasai> "If the <ratio> is degenerate, the property instead behaves as auto."
<dael> iank_: With that small amount of precedent then Blink/WK behavior you can tie together. a-r behavior is if it's degenerate it falls back to next best thing
<dael> astearns: Did that answer question?
<dael> chrishtr: What I heard is it's much more uncommon because images are unlikely to have 0 height
<dael> fantasai: Not a real world case
<iank_> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=9292
<dael> chrishtr: b/c SVG is replaced leemnt it behaves different
<dael> iank_: Example ^ showing fallback for a-r property. I spec degenerate where it will use the images a-r
<dael> iank_: That's the fallback. If we want a-r to have this fallback being more consistent then blink/wk fallback makes more sense
<cbiesinger> I mean, for a while a-r: 1/0 was a parse error
<dael> astearns: Given that bit of consistency shall we resolve on Blink/WK and see if Amelia objects?
<cbiesinger> but I think that was changed for consistency with calc() that computes to zero
<fantasai> and then changed to 'auto' because that's what SVG does, IIRC ...
<dael> dholbert: I weakly lean against that. Feel like with a-r property if you're explicitly providing invalid it makes sense to not do anything. In SVG we've got a usable height and width and it makes sense that does establish a value to use
<dael> iank_: You can also spec -10px width and has same behavior. And you don't render at -10
<dael> dholbert: True. More that a-r is downstream. Don't feel too strongly. Feels a little weird adding a special fallback that no one will need for real content. I think it's a trivial change
<dael> fantasai: I think we should wait and hear back from Amelia. She might have SVG logic that leans one way

[astearns]

@AmeliaBR you were tagged in the SVG issue. We are waiting for your input on how to handle this case.

[bfgeek]

Ping @AmeliaBR @fantasai

[AmeliaBR]

I'm really sorry all, this kind of testing & synthesis / cross comparison is beyond my current cognitive capabilities. I've got it at the top of my to-do list for a good brain day, but it's been a month, so please continue without my input.

My only suggestions are to cross reference what browsers currently do, looking at both SVG as image and

If you have any specific questions that can be asked & answered in tweet-size pieces, let me know.

[bfgeek]

looking at both SVG as image and

For this specific case its slightly important that we use an "SVG as an image", as a "width: 0" has meaning within CSS, which makes us "ignore" the aspect-ratio (consistently between implementations).

However we can look at the behaviour of "width: -1px" which does have significant implementation differences, consider:

<!DOCTYPE html>
<style>
img, svg {
  border: solid;
  background: lime;
}
</style>

<img style="width: 100px" src="
    data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' width='-1px' height='50px' viewBox='0 0 1 1'></svg>">

<svg style="" xmlns="http://www.w3.org/2000/svg" width="-1px" height="50px" viewBox="0 0 1 1"></svg>

<svg style="width: -1px; height: 50px;" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1 1"></svg>

OR

<!DOCTYPE html>
<style>
img, svg {
  border: solid;
  background: lime;
}
</style>

<img style="height: 100px" src="
    data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' width='-1px' height='50px' viewBox='0 0 1 1'></svg>">

<svg style="" xmlns="http://www.w3.org/2000/svg" width="-1px" height="50px" viewBox="0 0 1 1"></svg>

<svg style="width: -1px; height: 50px;" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1 1"></svg>

Here Blink's behaviour (post M93 - we've fixed lots of bugs in this area) and Safari is "treat -1px as invalid, and fallback to the viewBox aspect-ratio". Gecko's behaviour is "treat -1px as 0px when defined as an SVG attribute however in CSS ignore -1px and fallback to the aspect-ratio".

I somewhat prefer Blink/Safari behaviour of consistently treating "-1px as invalid here".

This however is only about a "clearly invalid" value of -1px. 0px is valid for intrinsic sizing purposes and the question if it should fallback to the viewBox aspect-ratio still remains.

<!DOCTYPE html>
<style>
img, svg {
  border: solid;
  background: lime;
}
</style>

<img style="width: 100px" src="
    data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' width='0' height='50px' viewBox='0 0 1 1'></svg>">

<svg style="" xmlns="http://www.w3.org/2000/svg" width="0" height="50px" viewBox="0 0 1 1"></svg>

<svg style="width: ; height: 50px;" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1 1"></svg>

Here the intrinsic-size is clearly 0x50. But does the aspect-ratio fallback to the viewBox to be 1/1 or not? This somewhat depends on how "-1px" is handled.

[AmeliaBR]

One quick note: style="width: -1px" should be rejected & ignored at the parser level. If you want to test auto width, best to say so explicitly. To test the default stylesheet width, you could leave off or use a revert keyword where supported. But that might depend on how the default stylesheet integrates presentational width attributes.

[css-meeting-bot]

The CSS Working Group just discussed SVG degenerate aspect ratios, and agreed to the following:

• RESOLVED: degenerate aspect ratios derived from SVG width/height attributes fall back to viewbox aspect ratio (whether due to negative values or zero values)

The full IRC log of that discussion

<fantasai> Topic: SVG degenerate aspect ratios
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/6286
<fantasai> iank_: We were going to ask Amelia, but she had to defer
<fantasai> iank_: So it's up to us
<fantasai> iank_: I posted a comment describing the various behaviors
<fantasai> iank_: I still slightly prefer the WebKit/Blink behavior
<fantasai> iank_: ...
<fantasai> iank_: Reminder that this is just about interop on an edge case for which we have testcases in WPT, not something that impacts web devs
<fantasai> Rossen: can you summarize?
<fantasai> iank_: With negative widths, Blink/WebKit will treat as invalid whereas Firefox will treat as zero
<fantasai> iank_: Blink/WebKit will use the viewbox aspect ratio as a fallback
<fantasai> iank_: whereas Firefox will have no aspect ratio
<fantasai> iank_: If there is a negative width/height specified, it gets clamped to zero and then continue
<fantasai> iank_: Firefox's behavior from there was to treat aspect-ratio as null
<fantasai> iank_: Whereas when we have a negative width/height, we treat as invalid
<fantasai> iank_: So we use fallback aspect ratio
<fantasai> iank_: Separate issue of when we have explicit width of zero and height of 50
<fantasai> iank_: Blink/WebKit will fallback to viewbox of 1:1
<fantasai> iank_: and Firefox will behave as if there is no aspect ratio
<fantasai> Note: spec currently says “If the <ratio> is degenerate, the property instead behaves as auto.”
<fantasai> Rossen: so your preference is to fall back from degenerate width/height on SVG to the viewbox aspect ratio
<fantasai> iank_: Right. This mirrors how the aspect-ratio property itself falls back from degenerate ratio value to intrinsic ratio of image
<fantasai> dholbert: Are you proposing just for negative case, or also for zero case?
<emeyer> fantasai: So the proposal is to fall back to the intrinsic aspect ratio
<emeyer> fantasi: In all degenerate cases
<fantasai> s/intrinsic/viewbox/
<fantasai> dholbert: OK, would not object to that
<emeyer> s/fantasi/fantasai/
<dholbert> iank_, got it, thanks
<fantasai> fantasai: So the proposal is that in the same way that the aspect-ratio property's explicit degenerate aspect ratios fall back to the intrinsic aspect ratio of the image, the proposal is that a degenerate aspect ratio from an SVG derived from its width/height attributes also falls back: to its viewbox ratio
<fantasai> RESOLVED: degenerate aspect ratios derived from SVG width/height attributes fall back to viewbox aspect ratio (whether due to negative values or zero values)