Re: [css-transforms] 'transform-box' defaults in svg

Erik: Are you suggesting that the `auto` value would use the viewBox as the
reference if `transform-origin` was set in absolute units, and `fill-box`
as a reference if it used percentages?

That sounds very difficult to implement & unnecessarily confusing.  What if
the `transform-origin` included calc() functions?  Or was animated between
different values?  An animation between 100px and 100% is implemented as an
animation between `calc(100px + 0%)` and `calc(0px + 100%)`.

Yes, it's unfortunate that the existing SVG behavior doesn't match the
implemented behavior for HTML.  But as someone who works in SVG transforms
a lot, I am personally really eager to use percentage transforms *relative
to the viewBox* and would be annoyed if an auto value messed those up.

As with all other features of CSS where the established default does not
match what many people want, there is a single line solution:

* {transform-box: fill-box;}


Which gets us back to the issue I brought up earlier: making sure we have a
consistent and clear mapping between the SVG-specific "box" values and the
CSS layout boxes, across all specs and properties that use them.

Alternatively, could properties like `transform-box` take two values, one
for CSS layout and one for SVG layout?  So you could choose to use
content-box for CSS layout elements but stroke-box for SVG elements?  There
could still be default mappings if the author only specified one or the
other.  Then we wouldn't need a user-agent stylesheet to set the
SVG-specific defaults, it could just be `border-box view-box` as the
initial value.

Then again, if there is no interest in supporting alternative reference
boxes for transforming non-SVG content (currently, `border-box` is the only
option in the draft spec), maybe the property could be renamed to something
SVG-specific (`transform-box-svg`?), with the potential to re-introduce
`transform-box` as a shorthand later.

ABR


On 30 September 2015 at 10:36, Erik Dahlström <erik@dahlström.net> wrote:
>
> If one sets 'transform-origin' to '50% 50%' on a <rect>, I would expect
> that to behave the same way an element in html would, which is to use the
> center point of that element as the origin for transforms, and that
> 'transform-box' in that case doesn't default to something nonsensical like
> 'view-box'.
>
> Would it be possible for 'transform-box' to use an initial value of 'auto'
> to defer the choice of what the computed/used keyword is, based on
> 'transform-origin'?
> /ed
>