15505 2012-01-10 19:05:59 +0000 Initial value of 'transform-origin' on SVG elements should be '0 0' 2012-02-10 16:25:52 +0000 1 1 1 Unclassified CSS Transforms unspecified PC All RESOLVED FIXED P2 normal --- 1 dschulze dschulze ayg cmarrin dino eoconnor oldest_to_newest 62506 0 dschulze 2012-01-10 19:05:59 +0000 The suggested modification of the user agent script suggest 'top left' as origin. That would be the same like 0% 0% of the objectBoundingBox. This doesn't reflect the current behavior on SVG where it is 0 0. Example: <rect x="100" y="100" width="100" height="100" fill="green"/> The transform-origin with the current behavior of SVG would still be 0 0. With the current description in CSS Transforms it would be top left of the objectBoundingBox, which is (100, 100, 100, 100). That means the origin is 100 100 as well. 62507 1 dschulze 2012-01-10 19:07:30 +0000 Note that this bug is partly related to bug 15504 . 63014 2 ayg 2012-01-23 17:03:04 +0000 In the current CSS Transforms spec, "0 0" means the same as "top left" -- it's still an offset from the element's border box. There's no declarative syntax to achieve the SVG effect at all right now, as far as I can tell. So some syntax needs to be added to allow origins to be specified relative to the upper left of the initial containing block. Or a magical initial value (see bug 15504). But yeah, the current spec definitely does not reflect SVG behavior here. 63017 3 1071 dschulze 2012-01-23 17:47:30 +0000 Created attachment 1071 'transform-origin' with top left and 0 0 I can confirm that '0 0' means the same as 'top left' according the tested browsers: Opera, Firefox and Safari. IIRC CSS Shaders [1] tries to addresses this already with 'filter-margin'. We should take a look how CSS shaders specify this and may share the notation of borderBox. [1] https://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html#filter-margin-property 63957 4 dschulze 2012-02-10 16:25:21 +0000 (In reply to comment #3) > Created attachment 1071 [details] > 'transform-origin' with top left and 0 0 > > I can confirm that '0 0' means the same as 'top left' according the tested > browsers: Opera, Firefox and Safari. IIRC CSS Shaders [1] tries to addresses > this already with 'filter-margin'. We should take a look how CSS shaders > specify this and may share the notation of borderBox. > > [1] > https://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html#filter-margin-property I added the following wording to the spec: "For SVG elements without an associated CSS layout box the <length> values represent an offset from the point of origin of the element's local coordinate space." I think that this fixes the problem with 0 0 and top left for SVG elements (that are not inline SVGSVGelements). 1071 2012-01-23 17:47:30 +0000 2012-01-23 17:47:30 +0000 'transform-origin' with top left and 0 0 html-test-transforms-origin-1.html text/html 740 dschulze PCFET0NUWVBFIGh0bWw+CjxodG1sIGxhbmc9ImVuIj4KPGhlYWQ+CiAgPG1ldGEgY2hhcnNldD0i dXRmLTgiPgogIDx0aXRsZT48L3RpdGxlPgogIDxzY3JpcHQ+CgogIDwvc2NyaXB0PgogIDxzdHls ZT4KZGl2IHsKICB3aWR0aDogMTAwcHg7CiAgaGVpZ2h0OiAxMDBweDsKICBiYWNrZ3JvdW5kLWNv bG9yOiBncmVlbjsKICBwb3NpdGlvbjogZml4ZWQ7CiAgbGVmdDogMzAwcHg7CiAgdG9wOiAyMDBw eDsKICAtd2Via2l0LXRyYW5zZm9ybTogcm90YXRlKDQ1ZGVnKTsKICAtbW96LXRyYW5zZm9ybTog cm90YXRlKDQ1ZGVnKTsKICAtby10cmFuc2Zvcm06IHJvdGF0ZSg0NWRlZyk7CiAgLW1zLXRyYW5z Zm9ybTogcm90YXRlKDQ1ZGVnKTsKfQoKLmJveDEgewogIC13ZWJraXQtdHJhbnNmb3JtLW9yaWdp bjogdG9wIGxlZnQ7CiAgLW1vei10cmFuc2Zvcm0tb3JpZ2luOiB0b3AgbGVmdDsKICAtby10cmFu c2Zvcm0tb3JpZ2luOiB0b3AgbGVmdDsKICAtbXMtdHJhbnNmb3JtLW9yaWdpbjogdG9wIGxlZnQ7 Cn0KCi5ib3gyIHsKICAtd2Via2l0LXRyYW5zZm9ybS1vcmlnaW46IDAgMDsKICAtbW96LXRyYW5z Zm9ybS1vcmlnaW46IDAgMDsKICAtby10cmFuc2Zvcm0tb3JpZ2luOiAwIDA7CiAgLW1zLXRyYW5z Zm9ybS1vcmlnaW46IDAgMDsKfQogIDwvc3R5bGU+CjwvaGVhZD4KPGJvZHk+CjxkaXYgY2xhc3M9 ImJveDEiPjE8L2Rpdj4KPGRpdiBjbGFzcz0iYm94MiI+MjwvZGl2Pgo8L2JvZHk+CjwvaHRtbD4=