This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The conclusion from https://lists.w3.org/Archives/Public/www-style/2014Nov/thread.html#msg287 seems to be that the rendering section should override 'flex' and 'transform'. Presumably as follows: *|*:not(:root):fullscreen { flex:none !important; transform:none !important; } If anyone disagrees with this now would be a good time to speak up.
Sounds great, one less non-standard thing about Chromium's fullscreen support to worry about!
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/css/fullscreen.css
So apparently Blink/WebKit have flex:1 !important, from this change: https://trac.webkit.org/changeset/83654 flex:none means 0 0 auto says http://dev.w3.org/csswg/css-flexbox/#flex-property I can't tell from the WebKit bug <https://bugs.webkit.org/show_bug.cgi?id=58291> what the original problematic CSS was. When does flex:1 and flex:none result in different rendering? /me is clueless
I've asked Tab to clue us in about flexbox.
No reply from Tab. Here's a related Gecko bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1099052
In https://codereview.chromium.org/974783002/ I've updated our style sheet to look more like the spec and came to the conclusion that the flex override doesn't matter when the fullscreen element is forced to fill the viewport by other style. What remains, although prefixed, is: :not(:root):fullscreen { transform: none !important; } This should be uncontroversial, so make it so :)
(In reply to Philip Jägenstedt from comment #5) > No reply from Tab. Here's a related Gecko bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=1099052 Whoops, I missed that email because it came in while I was in Sydney; my email glut afterwards was horrific and still hasn't been fully processed. The flex difference is because the fullscreen element is placed in an anonymous flexbox that fills the screen. "none" means the element stays its natural size, while "1" means it'll stretch to fill the screen if possible (and importantly, *shrink* to fit in the screen if oversized).
(In reply to Tab Atkins Jr. from comment #7) > (In reply to Philip Jägenstedt from comment #5) > > No reply from Tab. Here's a related Gecko bug: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1099052 > > Whoops, I missed that email because it came in while I was in Sydney; my > email glut afterwards was horrific and still hasn't been fully processed. > > The flex difference is because the fullscreen element is placed in an > anonymous flexbox that fills the screen. "none" means the element stays its > natural size, while "1" means it'll stretch to fill the screen if possible > (and importantly, *shrink* to fit in the screen if oversized). Does this matter when the fullscreen element is also has !important UA style sheet rules for top, right, bottom, left, width, min-width, max-width, height, min-height and max-height to make it fill the screen? In 10 minutes of tinkering I couldn't find a case where flex could have any influence, but I could very well be mistaken.
Oh, sorry, I was thinking of <dialog>, not fullscreen. No, there shouldn't be any reason to mess with 'flex' on a fullscreen element. It's not a flex item (being fixpos guarantees that, even if it's a child of a flex container), so 'flex' does nothing at all, regardless of what value it takes.
Awesome, thanks Tab! Just to get things going: https://github.com/whatwg/fullscreen/pull/1
Thanks Philip! https://github.com/whatwg/fullscreen/commit/a7d0ccf09c9ec01f987856dd9bc99e46a3f33fe2