Comments on View Modes Media Feature ED

Hi,

here are my comments on http://dev.w3.org/2006/waf/widgets-vm/vm-mediafeature.src.html 
.

> Abstract
> This specification defines a media feature related to the  
> presentation mode of the document. Multiple view modes are specified  
> that allow for accomodation of various content presentation use  
> cases. This document builds upon the Media Queries [MediaQueries]  
> and Widgets-Packaging [Widgets-Packaging] specifications.
>
The terms "media features" and "presentation mode" should be linked to  
their definitions.

"various content presentation use cases" is a bit vague, giving a few  
examples afterwards could help make it more concrete.

> 1. Introduction
> This document defines new media feature and its values.
>

I understand that this is a FPWD, but this is still a little bit  
short :) At least adding a couple sentences to explain what they do  
would help.

> 1.4. Definitions
> Chrome
> The chrome encompases the visible parts of the user agent that do  
> not depend on the content being rendered, such as minimize, restore/ 
> maximize, and close buttons in addition to adjacent items, such as  
> title bars, toolbars and resize handlers. Scrollbars, though, are  
> parts of the rendering area, and thus - being dependent on the  
> content - may be rendered even if the regular chrome is not.
>

I think that this may be taking the risk of getting into trouble. For  
instance, while it is true that some scrollbars belong to the content,  
others belong to the chrome. Explaining all of that without tying  
oneself to specifics is hard. How about "The chrome is everything  
rendered in visual media that is considered to belong to the user  
agent but sits outside the CSS viewport"?

> 3. 'view-mode' media feature
> The view-mode feature describes the current rendering context for a  
> widget.
>

This calls for a definition of "rendering context".

> 3.1 View mode's properties
> The following table defines each of the view-modes' values in terms  
> of its properties.
>

You say "the following table" but start with a list explaining the  
table, it confuses people with slow brains like me. I think that it  
might be clearer to put the table first, and place the legend (with a  
"Legend" header) right after.

For the table I would also:

   - use <th> instead of <td> for the first row
   - use CSS instead of border=1
   - instead of having the left column be <dfn>, make them links (not  
bold) to the view modes defined in the following section

An example of the sort of style I'm thinking of: http://dev.w3.org/2009/dap/ReSpec.js/css/respec.css 
  and grep for .simple.

> 	• chrome: its presence or absence,

"Whether the chrome is shown or not"

> 	• transparency: the user agent renders the view port with (CSS- 
> equivalent) opacity zero with respect to the background or  
> application environment,

I don't understand this, and I think that an equivalent to CSS opacity  
zero doesn't do what you want (for one, it still gets interaction  
events). Is this about whether the viewport is displayed or not?

I'm thinking that maybe you're trying to make too much information fit  
in a table, when sometimes the fields would need real sentences. For  
instance, in addition to not really understanding this column, I  
understand even less when the value is "yes/no". It might be clearer  
to use a <dl> and normative statements for each mode value.

> 	• overflow: CSS overflow property for the viewport,

Same thing, I'm not sure what this applies to. Does floating really  
have hidden overflow? How does it relate to:

"""
UAs must apply the 'overflow' property set on the root element to the  
viewport. When the root element is an HTML "HTML" element or an XHTML  
"html" element, and that element has an HTML "BODY" element or an  
XHTML "body" element as a child, user agents must instead apply the  
'overflow' property from the first such child element to the viewport,  
if the value on the root element is 'visible'. The 'visible' value  
when used for the viewport must be interpreted as 'auto'. The element  
from which the value is propagated must have a used value for  
'overflow' of 'visible'.
"""
http://www.w3.org/TR/CSS21/visufx.html#propdef-overflow

Can it be overridden in the document widget's document's CSS? With ! 
important? By the user CSS?

> 	• control: the viewport of the widget is controlled by application  
> by default (e.g., movable or non-selectable), but with certain  
> elements being interactive (e.g., input elements),

I don't really understand what this is.

> 	• default: whether the value is default when none is specified,

This is a good example of something that is probably better as a  
sentence than as a table column.

> 	• relevance to the width and height attributes of the <widget>  
> element: how the width and height attributes are handled.

Is the intent that for floating the UA cannot override the requested  
width/height? That should at least require some security considerations.

> 3.2 View modes
> This section is non-normative.
>

I think that it would probably be better to merge this and the  
previous section, and make all of it normative. Currently nothing is  
normative anyway because none of the RFC 2119 keywords are used.

I guess this can wait for another revision though.

> Acknowledgements
> The editors would like to thank the following people for their  
> contributions to this specification:
>

That's not a lot of people!

> Normative References
> [Media Queries]Media Queries, H. Wium Lie, T. Ηelik, D. Glazman, A.  
> van Kesteren. W3C Candidate Recommendation 23 April 2009.

Do we have an idea of when it might exit CR?

-- 
Robin Berjon - http://berjon.com/

Received on Thursday, 24 September 2009 12:38:01 UTC