Re: [whatwg] Fullscreen CSS
Robert O'Callahan wrote: I think we should go the route that the dialog element did in Ted's change proposal and have a pseudo-element that gets created when an element is fullscreened. Simple and easy, and trivial for the author to manipulate to get most effects they could want. Interesting. I did not know about that. That proposal requires layout engine changes[…] Also, it doesn't address situations where[…] (and maybe other things I've forgotten). Yeah, I'm sure I missed lots of potential issues in the initial ::cover proposal. Please follow up on the www-style thread linked to below! :) I think we should probably define a unified mechanism that can be used for the fullscreen element and the dialog element and anything else like it Exaclty. I've made a proposal for a backdrop feature, for the Fullscreen API and dialog, here: http://lists.w3.org/Archives/Public/www-style/2011Nov/0705.html Ted
Re: [whatwg] Fullscreen CSS
On Tue, 15 Nov 2011 00:10:09 +0100, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Nov 15, 2011 at 10:54 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: I think we should go the route that the dialog element did in Ted's change proposal and have a pseudo-element that gets created when an element is fullscreened. Simple and easy, and trivial for the author to manipulate to get most effects they could want. Interesting. I did not know about that. That proposal requires layout engine changes --- specially, at least one new rule for CSS stacking contexts in the infamous appendix E. Also, it doesn't address situations where an ancestor of the dialog or fullscreen element has 'opacity', 'transform', 'filter', 'mask' or 'clip-path' (and maybe other things I've forgotten). I think we should probably define a unified mechanism that can be used for the fullscreen element and the dialog element and anything else like it we need. And figure out what happens if you make part of a page fullscreen and that uses dialog. Or if you have nested dialogs mixed with fullscreen... Hmm. This proposal seems like will make fullscreen styling non-transparent and non-trivial. Currently the elements are just resized and that very easy to implement, understand and workaround with CSS. How would that affect, for instance, a canvas element that is resized to fit the whole screen ?
Re: [whatwg] Fullscreen CSS
Hm, why would it require stacking-level changes? One obvious way to get it to act correctly is to make it wrap around the element, like the old ::outside pseudo-element proposal. Then it's trivial. The CP says The dialog and its cover, taken together, are siblings within a new stacking context which is placed above all other stacking contexts. This seems like something new in CSS. Oh, whoops, indeed. Sorry about that, I forgot the CP worked like that. Yeah, I guess we *would* need some changes to the stacking algorithm. :/ Some thought needs to go into how much of this should be expressed in author-usable CSS and how much should be magic. It seems like we shouldn't assume that these are the only two features that will ever need this sort of rendering support. I'll get a www-style thread going. Ted
Re: [whatwg] Fullscreen CSS
On Thu, Nov 17, 2011 at 8:20 AM, Edward O'Connor eocon...@apple.com wrote: It seems like we shouldn't assume that these are the only two features that will ever need this sort of rendering support. I'll get a www-style thread going. Thanks. If multiple specs (or even multiple running instances of the same spec) try to define a stacking context that is above all other stacking contexts, we'll have a problem :-). Rob -- If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us. [1 John 1:8-10]
[whatwg] Fullscreen CSS
I have removed background:black as the way the rendering is defined at the moment is that it cannot be overridden unless !important is used. That's not ideal for backgrounds. Since no color was defined that did not help either. I added margin:0; box-sizing:border-box so the height/width declarations make sense. I also added transition:none to :fullscreen-ancestor per the comment that was present in the draft. Latest draft: http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html#rendering -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Fullscreen CSS
On Tue, Nov 15, 2011 at 9:25 AM, Robert O'Callahan rob...@ocallahan.orgwrote:
Having the rest of the page visible under the fullscreen element is not
expected and I think we should default to avoiding it. background:black
seemed like the right thing for video and a reasonable default for other
kinds of element. Maybe the background:black rule could be at the UA
not-important level?
Glenn Maynard wrote:
The background: black makes a basic case strange: fullscreening
divhello/div will result in black text on a black background. Maybe
having that on video:fullscreen and maybe img:fullscreen makes sense, but it
doesn't seem right in general.
That's a reasonable point but I'm not sure how to solve it. Making other
page content visible behind divhello/div (which would happen if we just
remove the background rule) is just as unexpected, maybe more so.
Brainstorming:
-- Maybe we could create a new CSS color meaning the document background
color (including the fallback color used when the viewport background is
nominally 'transparent') and use that here?
-- Try a rule :fullscreen-ancestor
:not(:fullscreen-ancestor):not(:fullscreen) { display:none; }? Or
opacity:0?
I really want to avoid solutions that require magical new CSS behaviors.
I think video:fullscreen { background:black; } seems like a good idea in
any case.
Rob
--
If we claim to be without sin, we deceive ourselves and the truth is not
in us. If we confess our sins, he is faithful and just and will forgive us
our sins and purify us from all unrighteousness. If we claim we have not
sinned, we make him out to be a liar and his word is not in us. [1 John
1:8-10]
Re: [whatwg] Fullscreen CSS
On Mon, Nov 14, 2011 at 12:54 PM, Robert O'Callahan
rob...@ocallahan.org wrote:
On Tue, Nov 15, 2011 at 9:25 AM, Robert O'Callahan
rob...@ocallahan.orgwrote:
Having the rest of the page visible under the fullscreen element is not
expected and I think we should default to avoiding it. background:black
seemed like the right thing for video and a reasonable default for other
kinds of element. Maybe the background:black rule could be at the UA
not-important level?
Glenn Maynard wrote:
The background: black makes a basic case strange: fullscreening
divhello/div will result in black text on a black background. Maybe
having that on video:fullscreen and maybe img:fullscreen makes sense, but it
doesn't seem right in general.
That's a reasonable point but I'm not sure how to solve it. Making other
page content visible behind divhello/div (which would happen if we just
remove the background rule) is just as unexpected, maybe more so.
Brainstorming:
-- Maybe we could create a new CSS color meaning the document background
color (including the fallback color used when the viewport background is
nominally 'transparent') and use that here?
-- Try a rule :fullscreen-ancestor
:not(:fullscreen-ancestor):not(:fullscreen) { display:none; }? Or
opacity:0?
I really want to avoid solutions that require magical new CSS behaviors.
I think video:fullscreen { background:black; } seems like a good idea in
any case.
I think we should go the route that the dialog element did in Ted's
change proposal and have a pseudo-element that gets created when an
element is fullscreened. Simple and easy, and trivial for the author
to manipulate to get most effects they could want.
~TJ
Re: [whatwg] Fullscreen CSS
On Mon, 14 Nov 2011 21:25:38 +0100, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Nov 15, 2011 at 1:38 AM, Anne van Kesteren ann...@opera.com wrote: I have removed background:black as the way the rendering is defined at the moment is that it cannot be overridden unless !important is used. That's not ideal for backgrounds. Can you elaborate on this? Currently we define a specific place in the cascading order for the style rules that currently does not exist. Just before author important basically. I suppose we could put background:black accompanied by color:white in the normal cascading order for user agent style sheets so people could override it easily (and would not make us remove existing backgrounds). Having the rest of the page visible under the fullscreen element is not expected and I think we should default to avoiding it. That seems fair. background:black seemed like the right thing for video and a reasonable default for other kinds of element. Maybe the background:black rule could be at the UA not-important level? UA does not have an important level. But yes, we could do that. But we should include a rule for the color property too. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Fullscreen CSS
On 11/15/11 11:25 AM, Anne van Kesteren wrote: UA does not have an important level. In Gecko it actually does: it's a level that overrides the user important level. Such a level is sort of needed in some cases, no matter what you actually choose to call it. -Boris
Re: [whatwg] Fullscreen CSS
On Tue, Nov 15, 2011 at 10:54 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: I think we should go the route that the dialog element did in Ted's change proposal and have a pseudo-element that gets created when an element is fullscreened. Simple and easy, and trivial for the author to manipulate to get most effects they could want. Interesting. I did not know about that. That proposal requires layout engine changes --- specially, at least one new rule for CSS stacking contexts in the infamous appendix E. Also, it doesn't address situations where an ancestor of the dialog or fullscreen element has 'opacity', 'transform', 'filter', 'mask' or 'clip-path' (and maybe other things I've forgotten). I think we should probably define a unified mechanism that can be used for the fullscreen element and the dialog element and anything else like it we need. And figure out what happens if you make part of a page fullscreen and that uses dialog. Or if you have nested dialogs mixed with fullscreen... Hmm. Rob -- If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us. [1 John 1:8-10]
Re: [whatwg] Fullscreen CSS
On Mon, Nov 14, 2011 at 3:10 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Nov 15, 2011 at 10:54 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: I think we should go the route that the dialog element did in Ted's change proposal and have a pseudo-element that gets created when an element is fullscreened. Simple and easy, and trivial for the author to manipulate to get most effects they could want. Interesting. I did not know about that. That proposal requires layout engine changes --- specially, at least one new rule for CSS stacking contexts in the infamous appendix E. Also, it doesn't address situations where an ancestor of the dialog or fullscreen element has 'opacity', 'transform', 'filter', 'mask' or 'clip-path' (and maybe other things I've forgotten). Hm, why would it require stacking-level changes? One obvious way to get it to act correctly is to make it wrap around the element, like the old ::outside pseudo-element proposal. Then it's trivial. I think we should probably define a unified mechanism that can be used for the fullscreen element and the dialog element and anything else like it we need. And figure out what happens if you make part of a page fullscreen and that uses dialog. Or if you have nested dialogs mixed with fullscreen... Hmm. Yes, we should give some thought to how these combine. ~TJ
Re: [whatwg] Fullscreen CSS
On Tue, Nov 15, 2011 at 12:38 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: Hm, why would it require stacking-level changes? One obvious way to get it to act correctly is to make it wrap around the element, like the old ::outside pseudo-element proposal. Then it's trivial. The CP says The dialog and its cover, taken together, are siblings within a new stacking context which is placed above all other stacking contexts. This seems like something new in CSS. Rob -- If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us. [1 John 1:8-10]
Re: [whatwg] Fullscreen CSS
On Mon, Nov 14, 2011 at 3:46 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Nov 15, 2011 at 12:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Hm, why would it require stacking-level changes? One obvious way to get it to act correctly is to make it wrap around the element, like the old ::outside pseudo-element proposal. Then it's trivial. The CP says The dialog and its cover, taken together, are siblings within a new stacking context which is placed above all other stacking contexts. This seems like something new in CSS. Oh, whoops, indeed. Sorry about that, I forgot the CP worked like that. Yeah, I guess we *would* need some changes to the stacking algorithm. :/ Some thought needs to go into how much of this should be expressed in author-usable CSS and how much should be magic. ~TJ
