Re: [csswg-drafts] [css-transforms-1] Browsers do not implement transform attribute syntax as described by w3c

@AmeliaBR I am not talking about a hybrid syntax but using the quirks of CSS that we can make use of. This was the plan at the time when I started working on the spec. Also, at the time at least, `translate (` would not get recognised as a function by the CSS parser/tokenizer and therefor couldn't be treated as function on processing. We could never find actual examples for things like `translate   (` which suggests that the risk is minimal if we remove support for that.

_Small correction: It is not only `translate (` but `translate <wsp>* (`. @tabatkins could you confirm that this is or is not possible with the CSS tokeniser and parser?_

If we would require the SVG syntax for the attribute, we would not speak of real presentation attributes anymore I suppose. All current presentation attributes today make use of the CSS syntax and quirks (like not requiring units on length values for the attributes and partly not even when defining the property in CSS). Furthermore, both, presentation attribute and CSS property definition would support the same property values.

Implementation wise, `transform` is special and not like any other presentation attribute. WebKit does not use, unlike for all other presentation attributes, the CSS parser here. As a result, the attribute does not support the new CSS transform functions. However, for the used value of the local transform, the computed matrix of the attribute is taken into account the same way as if it would be a presentation attribute. The computed style should take the value of the presentation attribute into account but doesn't today.

```xml
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
    <rect width="200" height="200" transform="translate(20, 20)"/>
</svg>
```

In WebKit and Firefox, the computed style is `none`. I couldn't test Edge but in the line of the three other browsers, only Chrome takes the attribute into account for the computed style.

I would like to hear from WebKit, Firefox, Edge and Chrome folks if they are willing to sacrifice parts of the SVG syntax as much as needed to make it compatible to CSS. If they won't, we might actually want to keep the transform attribute a special attribute, continue to parse it with the SVG syntax and define how it fits into the styling hierarchy. It may mean that we will not support the additional CSS transform functions on the `transform` attribute. Or, if we do, define the new functions in the SVG syntax.

-- 
GitHub Notification of comment by dirkschulze
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2623#issuecomment-386016927 using your GitHub account

Received on Wednesday, 2 May 2018 15:24:05 UTC