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/
