As noted in https://code.google.com/p/chromium/issues/detail?id=426644: * Blink (and maybe WebKit?) have a media query for 3d transform support, "@media (-webkit-transform-3d)". (This sort of query should really be done using @supports, but it was introduced using @media for some reason.) * There are apparently compat issues associated with not supporting this media query. (At least: Microsoft ran into this when developing their 'preserve-3d' support, and the Chrome team decided that enough web content depends on this that they WontFix'ed https://code.google.com/p/chromium/issues/detail?id=426644 ) * We are likely going to spec this I'm not yet directly aware of any breakage that this causes (the example sites in https://code.google.com/p/chromium/issues/detail?id=426644#c11 seem fine to me) but it seems like we may need to support it, so I'm filing this tentatively/proactively. See also https://github.com/whatwg/compat/issues/8 which is filed on speccing this.

about.com (https://github.com/webcompat/web-bugs/issues/2151) is broken in Nightly Fennec because it relies on Modernizr.csstransform3d being true.

I'm going to link this to Bug 1170774 since Modernizr is so widely used.

(In reply to Daniel Holbert [:dholbert] from comment #0) > * Blink (and maybe WebKit?) have a media query for 3d transform support, > "@media (-webkit-transform-3d)". Yes, WebKit has it too. > (This sort of query should really be done > using @supports, but it was introduced using @media for some reason.) I would guess that it predates @supports.

(In reply to Chris Rebert from comment #3) > I would guess that it predates @supports. (Ah, I think you're right -- first comment on the blink bugpage (linked in comment 0) says this was added to webkit in 2009, and I believe @supports was proposed around 2011 [oldest version of the spec I can find is dated 2011, at least]. That explains that, then.) I've got a local patch for this, and I can confirm that it fixes the about.com bug. I'll post it after tweaking a few things & adding testcases.

This first patch doesn't change behavior at all. This is to handle the problem that heycam foresaw in bug 1237720 comment 7.) This just refactors the way in which the -webkit-device-pixel-ratio pref (added in bug 1237720) controls our media-query parsing code. This is needed before we can support other prefixed media queries. I'm doing this by adding another dedicated "requirement flag" that makes this media query depend on this pref. This strategy is perhaps slight overkill, but it lets the code in nsCSSParser.cpp be nice & clean. And, hopefully this requirement flag won't be needed for too long, once we get to a state where we can ship -webkit-device-pixel-ratio.

Here's the fix. I'm basically just cribbing from the code for nsGkAtoms::grid / GetGrid. (which is a boolean media feature that's always-not-supported) This new feature is the same, except it always *is* supported.

Comment on attachment 8708646 [details] [diff] [review] part 1: refactor -webkit-device-pixel-ratio check so we can support other prefixed media queries Review of attachment 8708646 [details] [diff] [review]: ----------------------------------------------------------------- ::: layout/style/nsMediaFeatures.h @@ +51,5 @@ > enum RequirementFlags : uint8_t { > // Bitfield of requirements that must be satisfied in order for this > // media feature to be active. > eNoRequirements = 0, > + eHasWebkitPrefix = 1, // Feature name must start w/ "-webkit-", even Nit: Maybe make this 1 << 0 to follow the pattern in other files like nsChangeHint.h.

Comment on attachment 8708648 [details] [diff] [review] part 2: add support for @media(-webkit-transform-3d) Review of attachment 8708648 [details] [diff] [review]: ----------------------------------------------------------------- ::: layout/style/nsMediaFeatures.cpp @@ +329,5 @@ > + nsCSSValue& aResult) > +{ > + // Gecko supports 3d transforms, so this feature is always 1. > + aResult.SetIntValue(1, eCSSUnit_Integer); > + return NS_OK; Two space indent here. (I recently fixed up the indenting and modeline in this file.)

Addressed comment 7 and 8, and landed: remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/a1674bc106ab remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/5c6accc23866

(Try run, with [non-functional] nits unaddressed but otherwise the same as what landed: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound )

https://hg.mozilla.org/mozilla-central/rev/a1674bc106ab https://hg.mozilla.org/mozilla-central/rev/5c6accc23866

Spec link: https://compat.spec.whatwg.org/#css-media-queries-webkit-transform-3d

Update MDN docs: https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Using_media_queries#WebKit_media_features https://developer.mozilla.org/en-US/Firefox/Releases/46#CSS

(In reply to percyley from comment #13) > Update MDN docs: [...] > https://developer.mozilla.org/en-US/Firefox/Releases/46#CSS Hmm -- I wonder if we should actually be announcing this in the release notes, since this is part of a suite of features which are disabled by default. (until bug 1259345 is closed out) (The release notes text currently reads "Added support for @media (-webkit-transform-3d) as a media query for 3D transform support" -- and that's not really accurate, unless the user takes action & flips a pref.)

(ni=Liz for her thoughts on this; this is in the same category as bug 1213126 comment 19.)

This isn't in the main release notes for Firefox. It seems OK treat it like we do bug 1213126 in the MDN notes for developers. But it might be less confusing to just move it from 46 release to 47 beta notes.

Thanks for clarifying that. I tweaked the MDN notes to mention that this is behind a pref -- maybe that's sufficient for now. (If we do take this out of the 46 notes [which would be fine by me], then I don't think we should bother adding it to a later set of release notes, since it's just one of many webkit-prefixed CSS features that will be shipping when the pref is enabled, and we probably won't be listing each one individually in the notes when the pref-flip happens.)

Setting dev-doc-complete as of comment 13. Sebastian