There's a false positive on css3test.com for the `display: -moz-(inline-)grid;` test that's triggered by XUL Grid while the test expects CSS3 Grid (see Bug 616605 Comment 10). (In reply to Florian Bender from comment #15) > So I think the current approach is […] to implement everything unprefixed > but behind a pref […]. That means it won't interfere with XUL Grid. > > However, I think it's worth assessing the option of disabling XUL Grid for > web content to not confuse web devs. Is there actually any use of XUL Grid > in Web content? I [thought] XUL for Web content was disabled at some point, > anyway? Is this a viable option?

See bug 879275.

Bug 879275 (thanks for mentioning!) also proposes a warning for XUL / experimental CSS extensions. That's another solution though I'd rather see it disabled for Web (untrusted) content.

Bug 975501 implements the standard-grid system in the style system.

Let's keep this discussion where it belongs (I shouldn't have started it in Bug 975501, sorry!) … can we have a decision if we want to do this? Is there telemetry for (XUL) Grid usage in the web? If not, let's do that first, try to uplift to Aurora 29 (maybe even Beta?) to get better coverage, and see what we'd break. Is this, by any chance, used within B2G/Gaia? Either way, I think this should go away sooner than later. This is proprietary stuff. I've already seen CSS Grid tutorials that add vendor-prefixed versions of display:(inline-)grid; and although the CSS Grid properties are different from XUL Grid properties, using -moz-grid (because muscle memory) may at best lead to unexpected behaviour, and at worst prevent a fallback (e.g. display:flex;) from working in Firefox. Also, many prefixing libraries test for or automatically add prefixed properties and values thus misinterpreting CSS Grid support in Firefox and failing badly. Since CSS Grid is on the horizon, and XUL Grid cannot be used as a fallback (to support earlier versions), please vote for blocking XUL Grid from content. Simon, thanks for volunteering here! I set you as assignee but feel free to unassign.

> Is there telemetry for (XUL) Grid usage in the web? No. Is there infrastructure for adding such telemetry? Not really. Once bug 968923 is fixed there might be.

:dbaron's patch in Bug 879275 introduces a warning for XUL styles (including grid and box). I assume that once the warning landed for a few versions, that Bug can/will also be used for blocking all of XUL styling for content.

Posted the site compatibility doc: https://www.fxsitecompat.com/en-US/docs/2015/non-standard-css-display-types-will-be-removed/

Here are the 'display' values we currently support: https://searchfox.org/mozilla-central/rev/292d295d6b084b43b70de26a42e68513bb7b36a3/servo/components/style/properties/gecko.mako.rs#3072-3081 I think we can unexpose the following values to web content: -moz-grid -moz-inline-grid -moz-grid-group -moz-grid-line -moz-stack -moz-inline-stack -moz-deck -moz-popup -moz-groupbox I think we should keep -moz-box / -moz-inline-box though, since we now map them to some variation of flexbox layout internally and I suspect the web depends on them being roughly equivalent to -webkit-box / -webkit-inline-box. I suspect stylo doesn't support making individual values chrome-only, so I guess the solution is to add a "if is_chrome() { parse xul values here }" somewhere, but the "format" of gecko.mako.rs seems rather opaque to me so I don't understand how to implement that. (CC a few stylo experts who might want to help out with this...)

Yeah, I'm working on that in bug 1288572. I think we should try unshipping -moz-box / -moz-inline-box too, we have a hack to remap them to -webkit-box if -webkit-box has been specified before, so my intuition is that they cause more pain than benefit. I'm putting it all behind a pref, we could split those values into another pref if we find breakage on those two.

Also looks like some values aren't even used on chrome (-moz-inline-grid). We could try to remove them after that.

(In reply to Emilio Cobos Álvarez [:emilio] from comment #9) > Yeah, I'm working on that in bug 1288572. OK, great. I think we can dupe this forward then if that's where the work will be done. > I think we should try unshipping -moz-box / -moz-inline-box too, we have a > hack to remap them to -webkit-box if -webkit-box has been specified before, > so my intuition is that they cause more pain than benefit. Maybe... I'd suggest we do that later after bug 1288572 though and add telemetry before doing it.