[css3-2d-transforms] Various spec comments

[Øyvind Stenhaug]

Following are some possible issues with the 2D Transforms spec (WD dated  
2009-03-20), and some inconsistencies with the implementation as observed  
in Safari.

1) Section 1: "The object acts as though position: relative has been  
specified[...]" should perhaps be specified more clearly. As written it  
would have an effect on the interpretation of the  
'top'/'bottom'/'left'/'right' properties, but that doesn't happen in  
Safari 4 or Minefield. (As mentioned elsewhere, several parts of this  
section look like they should be normative.)

2) Section 3: The definition of the 'transform-origin' property doesn't  
specify what should happen when only one keyword/length/percentage is  
provided. Compare with the CSS2 definition of 'background-position'.

3) Section 3: The set of valid values doesn't allow for e.g.  
"transform-origin: 0% left;", but Safari 4 does (actually it seems to  
allow a lot of things). I guess this might be an issue with Safari rather  
than the spec.

4) Section 4: The list of allowed transform functions includes the keyword  
'none', but both Safari 4 and Minefield drop the declaration if it's  
included along with other functions (e.g. "none rotate(180deg)"). The  
value 'none' is already mentioned separately (in addition to  
<transform-function>) in section 2.

5) Section 6: The (non-2D) transform function 'translateZ' is mentioned in  
the first list item. On the other hand, 'skew' is not mentioned.

6) Section 7.1: There is a description of the Point interface (which other  
methods expect to be passed), but no way to retrieve/construct such an  
object.

7) Section 7.2: The functions (should perhaps say "methods" to be  
consistent?) specified are "added to the Window interface", but it seems  
the DOM specs use 'AbstractView' instead of 'Window'. The HTML5 draft has  
Window, though.

8) Sections 7.3 and 7.4: "SYNTAX_ERR" should probably say "DOMException  
SYNTAX_ERR". "NOT_SUPPORTED_ERROR" (occurs twice, note the two extra  
letters) should probably say "DOMException NOT_SUPPORTED_ERR".

9) Section 7.3: The description of the 'scale' method mentions a "z  
component".

10) Section 7.3: There is no 'skew' method, it seems like this could be an  
unintended omission.

11) Section 7.4: "CSSTranformValue" (in the Exceptions part) should be  
"CSSTransformValue".

--
Øyvind Stenhaug
Core Norway, Opera Software ASA

[Dean Jackson-7]

On 24/06/2009, at 11:12 PM, Øyvind Stenhaug wrote:

> Following are some possible issues with the 2D Transforms spec (WD  
> dated 2009-03-20), and some inconsistencies with the implementation  
> as observed in Safari.
>
> 1) Section 1: "The object acts as though position: relative has been  
> specified[...]" should perhaps be specified more clearly. As written  
> it would have an effect on the interpretation of the  
> 'top'/'bottom'/'left'/'right' properties, but that doesn't happen in  
> Safari 4 or Minefield.

That part was badly worded. The important part was that transform  
creates a stacking context. I've removed the part about acting as if  
position:relative was specified.

> (As mentioned elsewhere, several parts of this section look like  
> they should be normative.)

Yeah.

>
> 2) Section 3: The definition of the 'transform-origin' property  
> doesn't specify what should happen when only one keyword/length/
> percentage is provided. Compare with the CSS2 definition of  
> 'background-position'.

I've added the similar text from background-position into transform-
origin.

>
> 3) Section 3: The set of valid values doesn't allow for e.g.  
> "transform-origin: 0% left;", but Safari 4 does (actually it seems  
> to allow a lot of things). I guess this might be an issue with  
> Safari rather than the spec.

That should work the same as background-position.

> 4) Section 4: The list of allowed transform functions includes the  
> keyword 'none', but both Safari 4 and Minefield drop the declaration  
> if it's included along with other functions (e.g. "none rotate
> (180deg)"). The value 'none' is already mentioned separately (in  
> addition to <transform-function>) in section 2.

I believe Safari/Minefield are doing what we intended. My suggested  
change is to remove "none" from the list of allowed transform  
functions, but leave the text in section 2 for now. That would make  
the "none rotate(1deg)" property invalid, and match current  
implementations.

> 5) Section 6: The (non-2D) transform function 'translateZ' is  
> mentioned in the first list item. On the other hand, 'skew' is not  
> mentioned.

Fixed.

> 6) Section 7.1: There is a description of the Point interface (which  
> other methods expect to be passed), but no way to retrieve/construct  
> such an object.

Correct, there should be a constructor.

> 7) Section 7.2: The functions (should perhaps say "methods" to be  
> consistent?) specified are "added to the Window interface", but it  
> seems the DOM specs use 'AbstractView' instead of 'Window'. The  
> HTML5 draft has Window, though.

I've changed to "methods". Not sure about AbstractView v Window. Which  
do you prefer?

> 8) Sections 7.3 and 7.4: "SYNTAX_ERR" should probably say  
> "DOMException SYNTAX_ERR". "NOT_SUPPORTED_ERROR" (occurs twice, note  
> the two extra letters) should probably say "DOMException  
> NOT_SUPPORTED_ERR".

Fixed.

> 9) Section 7.3: The description of the 'scale' method mentions a "z  
> component".

Fixed.


> 10) Section 7.3: There is no 'skew' method, it seems like this could  
> be an unintended omission.

Added.

> 11) Section 7.4: "CSSTranformValue" (in the Exceptions part) should  
> be "CSSTransformValue".

Fixed.

Dean

[Øyvind Stenhaug]

On Sat, 31 Oct 2009 01:52:46 +0100, Dean Jackson <dino@...> wrote:

> On 24/06/2009, at 11:12 PM, Øyvind Stenhaug wrote:

> I believe Safari/Minefield are doing what we intended. My suggested  
> change is to remove "none" from the list of allowed transform functions,  
> but leave the text in section 2 for now. That would make the "none  
> rotate(1deg)" property invalid, and match current implementations.

Sounds good (as does the rest).

>> 7) Section 7.2: The functions (should perhaps say "methods" to be  
>> consistent?) specified are "added to the Window interface", but it  
>> seems the DOM specs use 'AbstractView' instead of 'Window'. The HTML5  
>> draft has Window, though.
>
> I've changed to "methods". Not sure about AbstractView v Window. Which  
> do you prefer?

I thought it might be problematic to have to reference HTML5 which is only  
a draft still. If that's not an issue either one seems fine by me. Maybe  
Anne has an opinion (especially if this is to be moved to CSSOM).

--
Øyvind Stenhaug
Core Norway, Opera Software ASA

[Anne van Kesteren-2]

On Mon, 02 Nov 2009 10:09:02 -0800, Øyvind Stenhaug <oyvinds@...>  
wrote:

> On Sat, 31 Oct 2009 01:52:46 +0100, Dean Jackson <dino@...> wrote:
>> On 24/06/2009, at 11:12 PM, Øyvind Stenhaug wrote:
>> I believe Safari/Minefield are doing what we intended. My suggested  
>> change is to remove "none" from the list of allowed transform  
>> functions, but leave the text in section 2 for now. That would make the  
>> "none rotate(1deg)" property invalid, and match current implementations.
>
> Sounds good (as does the rest).
>
>>> 7) Section 7.2: The functions (should perhaps say "methods" to be  
>>> consistent?) specified are "added to the Window interface", but it  
>>> seems the DOM specs use 'AbstractView' instead of 'Window'. The HTML5  
>>> draft has Window, though.
>>
>> I've changed to "methods". Not sure about AbstractView v Window. Which  
>> do you prefer?
>
> I thought it might be problematic to have to reference HTML5 which is  
> only a draft still. If that's not an issue either one seems fine by me.  
> Maybe Anne has an opinion (especially if this is to be moved to CSSOM).

Maybe they should be on Screen (window.screen) instead? Then again,  
elementFromPoint and caretRangeFromPoint (soon to be renamed to  
caretPositionFromPoint) are on Document (window.document).

If we can avoid it I rather avoid polluting the global object further.


--
Anne van Kesteren
http://annevankesteren.nl/