This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Mozilla removed support for skew() from Firefox 14. We've received a number of complaints of broken sites: https://bugzilla.mozilla.org/show_bug.cgi?id=734953#c20 https://bugzilla.mozilla.org/show_bug.cgi?id=747637 https://bugzilla.mozilla.org/show_bug.cgi?id=771180 https://bugzilla.mozilla.org/show_bug.cgi?id=775046 https://bugzilla.mozilla.org/show_bug.cgi?id=775710 https://bugzilla.mozilla.org/show_bug.cgi?id=775763 There are probably many more that weren't reported. All reasonable uses of this function are completely redundant to skewX() and skewY(), but people are using it. IIUC, some version of Adobe Edge even outputs it. Mozilla is most likely re-adding support for skew() to Firefox 15, or 16 at the very latest. We would like the spec updated to require skew() support again, matching all browsers, probably with a note that the feature is retained for compatibility and authors should use skewX/skewY instead. Any objections?
Did IE 10 keep skew(x, y) while also unprefixing?
Created attachment 1165 [details] Test for skew support on not prefixed transforms Test for skew support on not prefixed transforms. It is supported if the rect is skewed.
(In reply to comment #1) > Did IE 10 keep skew(x, y) while also unprefixing? Tested it on last IE 10 public preview and it is supported there.
(In reply to comment #3) > (In reply to comment #1) > > Did IE 10 keep skew(x, y) while also unprefixing? > > Tested it on last IE 10 public preview and it is supported there. Indeed; it was supported in IE9 and remains supported in unprefixed IE10. We have no plans to remove support at this time.
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #1) > > > Did IE 10 keep skew(x, y) while also unprefixing? > > > > Tested it on last IE 10 public preview and it is supported there. > > Indeed; it was supported in IE9 and remains supported in unprefixed IE10. We > have no plans to remove support at this time. If we add skew() again, we won't be able to remove it again. I don't have strong feeling on adding it again, but still don't think that this function makes sense. I don't think that edge still supports skew() in the latest version, but will check tomorrow.
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > (In reply to comment #1) > > > > Did IE 10 keep skew(x, y) while also unprefixing? > > > > > > Tested it on last IE 10 public preview and it is supported there. > > > > Indeed; it was supported in IE9 and remains supported in unprefixed IE10. We > > have no plans to remove support at this time. > > If we add skew() again, we won't be able to remove it again. I don't have > strong feeling on adding it again, but still don't think that this function > makes sense. I don't think that edge still supports skew() in the latest > version, but will check tomorrow. If existing content depends on it to a point where implementations suffer from not supporting it then we're not able to remove it *today*. If by 'it doesn't make sense' you mean 'it's redundant' then sure; I don't understand what real harm there is in that though. It's unfortunate but there are worse problems.
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > (In reply to comment #3) > > > > (In reply to comment #1) > > > > > Did IE 10 keep skew(x, y) while also unprefixing? > > > > > > > > Tested it on last IE 10 public preview and it is supported there. > > > > > > Indeed; it was supported in IE9 and remains supported in unprefixed IE10. We > > > have no plans to remove support at this time. > > > > If we add skew() again, we won't be able to remove it again. I don't have > > strong feeling on adding it again, but still don't think that this function > > makes sense. I don't think that edge still supports skew() in the latest > > version, but will check tomorrow. > > If existing content depends on it to a point where implementations suffer from > not supporting it then we're not able to remove it *today*. If by 'it doesn't > make sense' you mean 'it's redundant' then sure; I don't understand what real > harm there is in that though. It's unfortunate but there are worse problems. It is not in the spec. It was removed several months ago, even before IE went to feature freeze I guess. And redundant is not quite correct. It is maybe used in a redundant way, but can do things that are hard to describe from a graphical point of view: skew(alpha, beta).
> It is not in the spec. It was removed several months ago, even before IE went > to feature freeze I guess. Acknowledged but it's not that relevant; the relevant fact is that content depends on it. Which means the call we made months ago is no longer valid. > And redundant is not quite correct. It is maybe used > in a redundant way, but can do things that are hard to describe from a > graphical point of view: skew(alpha, beta). Check. But depending on how it's used we may be able to narrow its definition down to what overlaps with skewX/skewY and leave the rest undefined. Just a thought.
The function doesn't make sense, but it's required for compat. So require support but note in the spec that it doesn't make sense and authors shouldn't use it. This is no different from tons of web features that are stupid/useless/redundant/bad ideas/etc. but that we spec and keep forever for compat. Like, say, quirks mode. This is probably only a handful of lines of code to keep, so it's not worth trying to get rid of if there are nontrivial compat issues, which there are.
I spoke with the Edge team and there is indeed content created with Edge that uses skew(). The skew() support will be removed completely in the next preview for compatibility reasons to FireFox 14 and most skew() usage is already removed in the current version. (In reply to comment #9) > The function doesn't make sense, but it's required for compat. So require > support but note in the spec that it doesn't make sense and authors shouldn't > use it. This is no different from tons of web features that are > stupid/useless/redundant/bad ideas/etc. but that we spec and keep forever for > compat. Like, say, quirks mode. This is probably only a handful of lines of > code to keep, so it's not worth trying to get rid of if there are nontrivial > compat issues, which there are. Even if not happy, I am fine with adding it again.
> (In reply to comment #9) > > The function doesn't make sense, but it's required for compat. So require > > support but note in the spec that it doesn't make sense and authors shouldn't > > use it. This is no different from tons of web features that are > > stupid/useless/redundant/bad ideas/etc. but that we spec and keep forever for > > compat. Like, say, quirks mode. This is probably only a handful of lines of > > code to keep, so it's not worth trying to get rid of if there are nontrivial > > compat issues, which there are. > > Even if not happy, I am fine with adding it again. Aryeh's suggestion is interesting i.e. we could mark the feature as deprecated; UAs need to implement those for compat but it'd be explicitly called out as 'do not use' for authors. It may seeem weird or awkward to come out with a deprecated feature in a new spec but I'd rather be pragmatic.
I'd prefer to avoid the term "deprecated", since that suggests the feature is going to be removed at some point, which isn't the case. HTML5 uses "obsolete". I'd go for a note like """ skew() with one parameter zero is equivalent to skewX() or skewY(), but if both parameters are nonzero, it does not behave as a skew (despite its name). Authors might mistakenly think that skew() with two nonzero parameters behaves the same as skewX() followed by skewY() or similar, which it does not, so they are advised not to use skew() at all. Nevertheless, implementations must support skew() for compatibility with legacy content. """ Does anyone object to me making this change?
(In reply to comment #12) > I'd prefer to avoid the term "deprecated", since that suggests the feature is > going to be removed at some point, which isn't the case. HTML5 uses > "obsolete". I'd go for a note like > > """ > skew() with one parameter zero is equivalent to skewX() or skewY(), but if both > parameters are nonzero, it does not behave as a skew (despite its name). > Authors might mistakenly think that skew() with two nonzero parameters behaves > the same as skewX() followed by skewY() or similar, which it does not, so they > are advised not to use skew() at all. Nevertheless, implementations must > support skew() for compatibility with legacy content. > """ > > Does anyone object to me making this change? Can't you just recover the text and images from the mercurial history (it is not just the text in the 2d transform function section)? Just add the sentence: "The skew() transform function is obsolete." Don't think that we need a reason.
Yeah, of course I'd bring back the original text. I can add whatever note people like, doesn't matter to me. I prefer more reasoning rather than less in specs, or at least links to reasoning, so that readers understand better.
There have been enough spec changes in the interim that this isn't trivial to undo. I'm afraid I don't have the time anymore, so anyone who does should feel free to pick it up.
I re-added skew() with the last commit today.