Related: since the *-box value are currently scattered around at least four specs, and have conflicting definitions in at least one case, @fantasai has begun collecting them into Box instead: https://drafts.csswg.org/css-box-3/#keywords

Consider this content:

<svg width="100" height="100" viewBox="1000 1000 1000 1000">
  <rect x="1000" y="1000" width="500" height="500" transform="rotate(1)"/>
</svg>

We have transform-box: view-box; transform-origin: 0 0; from the initial value and the UA sheet. The origin for the rotation needs to be (0, 0) in the rect's coordinate space (i.e., far off-screen to the top-left), not the top-left corner of the viewport.

As for the size of the box,

<svg width="100" height="100" viewBox="1000 1000 1000 1000">
  <rect x="1000" y="1000" width="500" height="500" style="transform: translate(25%, 0);"/>
</svg>

This translates the rectangle horizontally into the middle of the viewport in Firefox and Chrome. Whether you consider the percentage to resolve against the width of a (0, 0, 1000, 1000) reference box, or visually against the width of the viewport, I guess doesn't matter. (Though maybe it would matter with preserveAspectRatio involved?)

Having the ability to make a % relative to the visible viewport is useful, yes, but the zero point is still arbitrary and unrelated. Or the opposite - the zero point might be reasonable, but then the visible viewport area is arbitrary and unrelated. There's no connection between the box used to size translates and the point used to center rotates/scales, unlike in the other values.

If the visible viewport's width/height and start/start corner were used, I'd be fine.

Is there a reason this particular choice of values was made?

I don't disagree that a box that has its origin be at (0, 0) and its size the size from the viewBox is strange. Given the way we retrofitted CSS' transform-related properties into SVG, the origin must be at (0, 0) for compatibility with existing SVG content. That leaves us with considering something different for the size of the box, but I really don't know if there is anything more useful we could choose.

In what context does SVG use this concept?

The definition may sometimes create unintuitive results, but this is how transforms and percentages have always been defined in SVG. Transforms are relative to the 0,0 origin, regardless of where that is in the graphic (or even if it is way outside the graphic). And percentage width/height are always relative to the full viewBox width/height, regardless of how that is offset from the origin.

And the basic behavior is definitely useful, if you're used to working with SVG viewBox intentionally (e.g., to create a centered coordinate system) and sizing SVG elements in percentages relative to that origin. (I don't have any examples doing this, but mostly because the support hasn't existed to really make it worth playing around with transform-origin for SVG.)

In your case of fudging the viewBox width/height to create padding, the results are less useful, but I'm not sure what would be more useful? In your example of viewBox="-20 -20 140 140", you probably want 100% = 100 units, but I'm not sure how the browser is supposed to guess that. Best to avoid setting your transform origin in percentages at all in that case.

The CSS Working Group just discussed [css-transforms-1] 'view-box' definition doesn't make sense, and agreed to the following:

• RESOLVED: No change to the behavior, add a note to the spec
• RESOLVED: move the box keyword definitions on css-box and publish a new working draft
• RESOLVED: rebase the rest of the spec referring to these definitions to point to css-box
• RESOLVED: Move margin-trim to css-box-4 before republishing

Ah yeah, centered coordinates (like viewBox="-.5 -.5 1 1") happen to be fairly meaningful here. It's still weird that, say, transform-origin: 100% 100%; puts the origin off the bottom-right corner, but eh.

Ultimately, tho, it wasn't clear to me that this was just capturing the legacy behavior of SVG; it looked like a de novo addition. If it's just capturing a legacy behavior, I'm fine with it; I'd just like a note indicating that.

OK, added this definition in. As part of that, I defined a new term, “SVG viewport origin box”. @AmeliaBR Let me know if it looks correct to you, and also if you want me to either export the term or to link to an equivalent term in the SVG spec. :)

@fantasai, I'm OK with defining a new term, since SVG doesn't have an equivalent, but we need to be careful about the difference between SVG viewport and SVG viewbox (= the difference between the viewport coordinate system and the initial user coordinate system).

Suggested wording:

view-box
Refers to the nearest SVG viewport element’s origin box, which is a rectangle with the width and height of the initial SVG user coordinate system established by the viewBox attribute for that element, positioned such that its top left corner is anchored at the coordinate system origin. (In a CSS box context, treated as border-box.)

Note: When the SVG viewBox includes min-x or min-y offsets, this origin box does not actually correspond to the visible region defined by the viewBox!