W3C home > Mailing lists > Public > www-style@w3.org > July 2014

Re: [css-transforms] Making 'transform' match author expectations better with specialized 'rotate'/etc shorthands

From: Dirk Schulze <dschulze@adobe.com>
Date: Mon, 14 Jul 2014 07:59:35 +0000
To: fantasai <fantasai.lists@inkedblade.net>
CC: Tab Atkins Jr. <jackalmage@gmail.com>, www-style list <www-style@w3.org>
Message-ID: <E92C72F3-411D-4B00-AAB9-25672020796A@adobe.com>

On Jul 14, 2014, at 9:23 AM, fantasai <fantasai.lists@inkedblade.net> wrote:

> On 07/11/2014 11:42 AM, Tab Atkins Jr. wrote:
>> Earlier today I saw a Twitter thread started by Lea
>> <https://twitter.com/LeaVerou/status/487350702386479105> about how she
>> commonly accidentally types the name of the transform she wants as the
>> property (like "rotate: 45deg;") and then has to go back and correct
>> it afterwards.  Several other devs chimed in that they do this as
>> well, and I know that I've done it a few times (especially when using
>> SVG - I use "transform='translate(...)'" so often that I commonly try
>> to name the attribute "translate" first).
>> Since this is something that devs trip over so much, it might be worth
>> accommodating it in the syntax.  I think we can do this compatibly
>> with the current syntax.  Here's a proposal:
> Having read the thread so far, I think this is a problem worth solving.
> However, I agree with most of Dirk's and all of Sylvain's comments, so
> I'm in support of a proposal that incorporates their feedback.
> On that note, if there needs to be separate origins for the longhands,
> they should not be handled as origin() functions as you propose [1],
> since you generally want to cascade the origin and the value independently.
> An origin() function might be useful for translate-list, however, to
> avoid the awkward translate-untranslate pattern Dirk mentions [2].
> [1] http://lists.w3.org/Archives/Public/www-style/2014Jul/0207.html
> [2] http://lists.w3.org/Archives/Public/www-style/2014Jul/0202.html
> Regardless, this should almost certainly go into a Transforms Level 2
> draft, since the set of features in Level 1 has already shipped. To
> that end, it would be nice to have Transforms in CR sometime soon. :)

Yes. During the Paris F2F (that Tab mentions), we agreed that new functionalities would go into a next level. I donít think that Tab actually proposes to edit the first level of the spec.


PS Regarding CR for Level 1: Simon and I proposed a new model for 3D transform handling during Seattle F2F at the beginning of this year. The proposal addresses most issues of the spec. Simon spend a lot of efforts creating a specification text and resolve more of the remaining issues. We were/are kindly asking everyone to review the text so that we can proceed with CSS Transforms 1. The current discussion is here[2].

[1] https://docs.google.com/document/d/1mNF7Z67WnnV05RqXa37PmfvRbgAZwj7-h-7Y_uQ_UPE/edit?pli=1#
[2] http://lists.w3.org/Archives/Public/www-style/2014Feb/0709.html

> ~fantasai
Received on Monday, 14 July 2014 08:00:22 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:23 UTC