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

[bfgeek]

This issue is mainly just so that we can discuss this SVGWG issue:
w3c/svgwg#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//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 <svg> element in a shrink to fit layout (e.g., float, flex box). Last I checked, there wasn't cross browser consistency, so if you can make that happen, it will be an improvement either way. For weird edge cases, it usually comes down to picking something & getting everyone to implement it. 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 element

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//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)