On Mon, Apr 12, 2010 at 1:07 PM, Robin Berjon <[email protected]> wrote: > Dear CSS WG, > > On Mar 11, 2010, at 09:36 , Daniel Glazman wrote: >> 2. this should not be restricted to widgets; we suggest to expand >> the scope of the document. > > We have done so. > >> 3. about values: >> - is the 'all' value really useful since a (view-mode: all) query >> is always true? > > It's been removed. > >> - a rendering can be 'application' and 'fullscreen'; isn't there >> an orthogonality issue here? Same thing for 'application' and >> 'maximized' for instance > > So we now have "windowed" instead of fullscreen. The orthogonality issue is > still perhaps present: we could have chrome (a boolean) and a separate view > mode to represent how the window is being shown. What I'm wondering is > whether it's worth going to that level of granularity of it the common cases > are enough. > >> - chrome can be added by the windows manager or by the application >> itself, does it make a difference? > > I don't believe that it makes a difference who adds it — the content wants to > know if it has any. > >> - is a 'hidden' value needed to query whether a window is visible? > > Do we have some use case clearer than what's been said so far? There's been > discussion about saving CPU/battery on mobile but that's all. I can add it as > "at risk". > >> - if the current medium (CSS-speaking) is 'projection', does it >> assume view-mode is fullscreen? What about the other way round? >> (Opera for instance assumes 'projection' when fullscreen is on) > > No, those are orthogonal. > >> - Is it possible to be floating but also have a media type >> 'projection'? > > I would think so. It's not entirely clear what projection most strongly > implies, but I would tend to think of things like removing one's speaking > notes or increasing the contrast. > >> - the background of the viewport is often applied through CSS, and >> that could lead to circular dependencies because the media query >> would depend on the result of the cascade > > It took me a while to figure out where this one came from, but I see that the > problem is on our side based on "with viewport's background being transparent > such that other system items such as other applications or the display's > background can be seen through part of the viewport that are not being > painted to." > > Our intent is that the viewport's *initial* state is transparent (i.e. you > don't get a big grey rectangle) — if CSS then goes ahead and paints stuff on > it (including filling it completely) then so be it — it doesn't affect the > fact that the query matches. This is simply there to allow for > non-rectangular UIs to be created. > > I've added "initial" to our description — is that enough of a change? Would > you have a more CSS-y suggestion? > >> - more generally, we think some of the value definitions could >> be clearer, it can be hard to understand if a given rendering >> matches a value or not. > > We've added a number of definitions and rephrased the values (several of > which have also been renamed). We'd appreciate your input on those changes, > and welcome specifics about parts that may remain hard to understand. > >> 4. all these queries could/should have an event-based counterpart so the >> changes are detectable by code. We understand this is outside of the >> scope of this spec but that's still an important comment. > > We're all for that, the CSSOM seems like a great place for such an API to > take shape :)
Right, a strawperson for this is [1]: [1] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0071.html -- Marcos Caceres http://datadriven.com.au
