W3C home > Mailing lists > Public > public-css-archive@w3.org > April 2017

Re: [csswg-drafts] [css-transforms-1] transform-origin: 0% not equivalent to 0px is confusing

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Thu, 20 Apr 2017 01:00:24 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-295521662-1492650023-sysbot+gh@w3.org>
The CSS Working Group just discussed transform-origin: 0% != 0px, and agreed to the following resolutions:

```
RESOLUTION: no need to change anything for this issue. implementations just need to support transform-box
```

<details><summary>The full IRC log of that discussion</summary>

```
<dino> Topic: transform-origin: 0% != 0px
<dino> Github Topic: https://github.com/w3c/csswg-drafts/issues/895
<dino> dbaron: it's only different for SVG?
<dino> smfr: yes
<dino> ChrisL: it's not that crazy to have the UA stylesheet do different things for SVG and CSS
<dino> Github Issue: https://github.com/w3c/csswg-drafts/issues/895
<dino> dbaron: it's only different for SVG?
<dino> smfr: yes
<dino> ChrisL: it's not that crazy to have the UA stylesheet do different things for SVG and CSS
<dino> smfr: auto is one proposal. or a keyword 'viewport'
<dino> Rossen: i'd prefer 'auto' as a magic keyword. And this might be our only option.
<dino> Rossen: other comments?
<dino> TabAtkins: I like 'auto'
<dino> TabAtkins: proposal is that the current 0% becomes 'auto', and then we change 0% to be the same as 0px
<dino> smfr: so 'auto' would be different for CSS and SVG?
<dino> TabAtkins: I don't care about that as much as having 0% and 0px using the same base.
<dino> transform-origin will now accept an 'auto' value which will be the initial value. For CSS, that is equivalent to 50% 50%. For SVG, it's equivalent to 0px 0px. And, from now on, in SVG, % are in the same base as px, so relative to the element.
<dino> <discussion of what % means for CSS properties in SVG>
<dino> ChrisL: I want to make sure that we're not clipped to 0-100% for CSS in SVG stuff.
<dino> dino: definitely not for transform-origin
<dino> smfr: there is also a proposal for transform-box, which would affect what % are resolved against
<dino> smfr: this is in level 1, but i'm not sure there are implementations
<dino> birtles: we implemented it
<Rossen> dino: if we all implement the box values there is no need have the percentages change
<birtles> Gecko intent to ship has some background: https://groups.google.com/forum/#!topic/mozilla.dev.platform/ssV6H4_3WGU
<dino> s/box/transform-box/
<dino> birtles: Blink has it implemented behind a flag
<birtles> Blink bug: https://bugs.chromium.org/p/chromium/issues/detail?id=595829
<dino> proposed resolution: no need to change anything for this issue. implementations just need to add transform-box, or behave as if you do implement it
<dino> RESOLUTION: no need to change anything for this issue. implementations just need to support transform-box
<BogdanBrinza> Edge doesn't have plans for (at least) next release or two since we don't support CSS transforms on SVG boxes yet, so the problem doesn't exist for us
<dino> smfr: so we think that heycam's comments are all addressed by transform-box
<dino> dbaron: yes
<TabAtkins> ScribeNick: TabAtkins
```
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/895#issuecomment-295521662 using your GitHub account
Received on Thursday, 20 April 2017 01:00:31 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:11 UTC