Re: CSS WG comments on View Modes Media Feature spec

On Mon, Apr 12, 2010 at 1:07 PM, Robin Berjon <robin@berjon.com> 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

Received on Monday, 12 April 2010 11:26:10 UTC