- From: João Eiras <joaoe@opera.com>
- Date: Mon, 28 Nov 2011 20:19:33 +0100
On Tue, 15 Nov 2011 00:10:09 +0100, Robert O'Callahan <robert at ocallahan.org> wrote: > On Tue, Nov 15, 2011 at 10:54 AM, Tab Atkins Jr. > <jackalmage at 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). > > 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 <dialog>s 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 ?
Received on Monday, 28 November 2011 11:19:33 UTC