RE: Comments on View Modes Media Feature ED

Hi Robin,

Thanks for your comments.
My answers inline below.

Thanks,
Marcin

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com

-----Original Message-----
From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org] On Behalf Of Robin Berjon
Sent: Thursday, September 24, 2009 2:37 PM
To: public-webapps WG
Subject: 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.

[MH] I added a bit more prose.

> 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"?

[MH] I modified the text by combining what was there and your sentence.

> 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".

[MH] Modified to the combination of view mode and media feature. I hope it is simpler now.

> 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
Fixed.

   - use CSS instead of border=1
Fixed.

   - instead of having the left column be <dfn>, make them links (not
bold) to the view modes defined in the following section
Fixed.

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?

[MH] This may need more detail. I hope to get feedback during WD review.
In case the part of the viewport is transparent (opacity zero), no events for the WUA and widget/document shall be fired. It may depend on the underlying graphics engine and its configuration. Some study could be made. I added new column about interactivity.

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.

[MH] Changed to more prose and more prose to come.

>       * overflow: CSS overflow property for the viewport,

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

[MH] Yes. Do you have some usability issues in mind?

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

[MH] I think here comes into the game the difference between widget user agent and user agent.

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

[MH] I assume it is not to be overridden, it would affect the width and height.
I will add clarifying prose to start with. I assume also that we would need alignment with CSSOM.

>       * 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.

[MH] Replaced with interactivity. More prose to be added.

>       * 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.

[MH] Column removed, I made the prose normative.

>       * 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.

[MH] Done. E.g. the language of the view-modes' values must be changed from descriptive to normative (i.e. RFC2119 language). I am working on it.

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!

[MH] I added the people who commented the spec before the split.

> 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?

[MH] I am not aware of the related timeline yet.

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





________________________________________

Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.

Received on Thursday, 1 October 2009 12:35:29 UTC