This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Remove 'skew' from transform functions. See discussions on mailing lists: http://lists.w3.org/Archives/Public/www-style/2009Mar/0287.html http://lists.w3.org/Archives/Public/public-fx/2012JanMar/0156.html
Is WebKit willing to drop support here? I filed a Gecko bug to see if Gecko is willing: https://bugzilla.mozilla.org/show_bug.cgi?id=734953
Yep, once unprefixed.
(In reply to comment #2) > Yep, once unprefixed. We can not differ between prefixed or unprefixed in the CSSParser for transform, can we? Why not remove it once the change is in a new WD? (sorry, maybe a bit to off topic)
(In reply to comment #3) > (In reply to comment #2) > > Yep, once unprefixed. > > We can not differ between prefixed or unprefixed in the CSSParser for > transform, can we? Why not remove it once the change is in a new WD? (sorry, > maybe a bit to off topic) Sure we can.
Created attachment 1092 [details] Remove skew This patch removes skew and adapts the mathematical description. Note that I also created new images for the forumlar that are not part of the diff.
(In reply to comment #5) > Created attachment 1092 [details] > Remove skew > > This patch removes skew and adapts the mathematical description. Note that I > also created new images for the forumlar that are not part of the diff. Added a bug report for WebKit: https://bugs.webkit.org/show_bug.cgi?id=81039 It looks like I misunderstood Simon at the beginning. To clarify: WebKit will not support 'skew()' for the unprefixed property, once the function was removed from the spec. WebKit will _still_ support 'skew()' for the prefixed version, even after unprefixing.
(In reply to comment #5) > Created attachment 1092 [details] > Remove skew > > This patch removes skew and adapts the mathematical description. Note that I > also created new images for the forumlar that are not part of the diff. I think we should require that browsers not support skew(), like by saying """ Previous versions of this specification defined a transformation called skew() that took one or two angles as arguments. User agents must not support such a transformation without vendor-specific prefixes <http://www.w3.org/TR/CSS21/syndata.html#vendor-keywords>. """ Otherwise, we might have a situation where implementations don't bother dropping support. Authors might then use skew(), find that it only works in some browsers, and blame the remaining browsers for not supporting it. We should be clear that all browsers have to drop support for the unprefixed property, so that we maintain interop.
We've never done this in a spec before, as far as I know. It's OK to have a testcase for it, but I don't think the spec needs to say it.
(In reply to comment #8) > We've never done this in a spec before, as far as I know. It's OK to have a > testcase for it, but I don't think the spec needs to say it. I agree with Simon.
I don't think we can fairly test it if it's not in the spec. If you prefer, we could require that UAs not support any unprefixed transforms other than those specified in the Transforms spec, and test only for skew(). But if we don't require they don't support it, how can we fail UAs that do support it?
This is like saying that browsers that support "display: frilly" don't comply. You can't make exclusive tests.
Normally I'd agree, but the spec has required this for a long time and all browsers implemented it. Either all browsers should keep support, or they should all drop support. If we're not going to require dropping support, I'd prefer we require browsers keep support rather than saying nothing either way.
(In reply to comment #12) > Normally I'd agree, but the spec has required this for a long time and all > browsers implemented it. Either all browsers should keep support, or they > should all drop support. If we're not going to require dropping support, I'd > prefer we require browsers keep support rather than saying nothing either way. No spec required the support for skew so far. No Transform spec ever reached CR and even there it could still be possible to drop things. Also we might add it later again with a different mathematical concept. Like Simon said, we should not exclude stuff.
So if the spec doesn't require lack of support, should the tests test for lack of support (comment #8) or not?
No, I don't think so.
Well, I guess I'm outnumbered.
I think the spec shouldn't say anything, but the test suite should test for non-support of skew().
(In reply to comment #17) > I think the spec shouldn't say anything, but the test suite should test for > non-support of skew(). Yes, I don't think that this is a big deal. If for some reason the spec changes, the test can get updated. There might still be concerns on how to run the test. If the tests won't include prefixes, we are fine. If they do, then WebKit for instance would fail. But as far as I heard, tests shouldn't include prefixes. If at all, they will be added by the testing harness. So it is a question how the testing harness handles prefixes.
If no one opposes, I'll land the patch in an hour.
I'll take care of the test.
For reference, the commits were: http://dvcs.w3.org/hg/csswg/rev/fe20a7d427c1 http://dvcs.w3.org/hg/csswg/rev/28ba69e9cf34 Tests updated: http://hg.csswg.org/test/rev/596325f22c8c