In the table below, red is in the WG decision column indicates that the Working Group didn't agree with the comment, green indicates that a it agreed with it, and yellow reflects an in-between situation.
In the "Commentor reply" column, red indicates the commenter objected to the WG resolution, green indicates approval, and yellow means the commenter didn't respond to the request for feedback.
|Commentor||Comment||Working Group decision||Commentor reply|
<firstname.lastname@example.org> on behalf of WAI UA WG (archived comment)
Commenting on http://www.w3.org/TR/2010/WD-view-mode-20100420/
View-mode: fullscreen. It is not clear whether fullscreen includes a full
set of chrome, or includes no chrome. You mention 'chrome' in the
'windowed' and 'floating' viewmodes. For consistency, chrome presence should
be noted in fullscreen.
It should be noted that the User Agent Accessibility Guidelines 2.0  has
success criteria that allow the user to override author settings for a
variety of viewport view-modes including the inclusion/exclusion of
Please consider including a statement such as
"The user agent *must* display the view-modes in a manner that meets the
accessibility guidelines of UAAG20. "
1. User Agent Accessibility Guidelines - www.w3.org/tr/uaag20
Jim Allan, Accessibility Coordinator & Webmaster
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315 fax: 512.206.9264 http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964
|On 3-June 2010, Jim replied the WG's proposed response to UAWG's comments were "ok".
<email@example.com> (archived comment)
This is a comment for the 20-Apr-2010 LCWD of the VMMF spec.
I would like the spec to clarify whether the view modes are mutual
exclusive or not. That is currently not clear. Can I have a view mode
of "windowed" and "maximized" at the same time? I guess the idea is
that they are all mutual exclusive, but it would be nice to have that
explicitly stated in the spec.
On Tue, Apr 20, 2010 at 12:16 PM, Arthur Barstow <firstname.lastname@example.org> wrote:
> WebApps WG, CSS WG, All,
> On April 20 the WebApps WG published a Last Call Working Draft (LCWD) of the
> View Mode Media Feature spec:
> Â http://www.w3.org/TR/2010/WD-view-mode-20100420/
> The deadline for this LCWD's comments is 18 May 2010.
> In additions to the WebApps WG and community, we explicitly ask the CSS WG
> to review this LCWD. Comments from others are welcome.
> Please send comments to:
> Â email@example.com
> -Art Barstow
<firstname.lastname@example.org> (archived comment)
Can we please rename the View Mode Media Feature to "The 'view-mode'
media feature"? The current name of the spec is confusing [me].
<email@example.com> on behalf of WAI P&F WG (archived comment)
This is a review of the Last Call draft of the View Mode Media Feature
This is a formal response form the Protocols and Formats Working Group.
Approval to send this response is archived at
http://www.w3.org/2010/05/19-pf-minutes.html#item06. Our thanks to
Gregory Rosmaita and Gottfried Zimmerman for preparing this comment.
The Last Call draft of the View Mode Media Feature states that it
"Applies to: visual and tactile media types"
While these view modes make sense for visual media types, they don't
seem appropriate for the two tactile media types "braille" and
"embossed", as defined in "Cascading Style Sheets Level 2 Revision 1
(CSS 2.1) Specification". in Section 7.3 "Recognized media types"
Please consider the following:
1. A user using a screen reader with a braille display. Should the user
agent switch to the CSS rules defined for media type "braille"? This
would be odd and unexpected behavior, since the primary interaction mode
is visual. (Note: There are windows on a screen that the screen reader
reads out and feeds the braille display).
2. In a pure tactile interaction environment which is not mediated through
a visual screen, does the WIMP (Windows, Icons, Menus, Pointers)
interaction model make sense at all? It could make sense in a 2D tactile
pin matrix environment where raised dots are used to present letters
(braille) and graphical strokes, and these dots can be used for
interaction with the user. But it does not make sense for the current
media type "braille" (which is meant to be a continuous stream of
characters), and not for "embossed" (which is meant to be a static
printout in braille).
3. 2D tactile interaction environments are not yet common. Should there
be an additional tactile media type for 2D tactile interaction (such as
"pinmatrix" or "2dtactile")? In research or for early adopters, is there
already a commonly accepted interaction vocabulary for 2D tactile displays
(such as the WIMP for visual displays)? Or does the Web Applications WG
propose to go with the WIMP model for simple transfer between the visual
and the tactile representation?
In light of these points of ambiguity, Unless the Web Applications WG can
define what the view modes -- "windowed", "floating", "fullscreen",
"maximized" and "minimized" -- mean for the media types "braille" and
"embossed", the PFWG advises that it would be better NOT to apply
'view-mode' to tactile media types at the current time.
The PFWG welcomes the opportunity to discuss these issues with the Web
Applications WG to ascertain what the view modes defined in the View Mode
Media Feature means for the media types "braille" and "embossed" and
would like to work in concert with the Web Apps WG and the CSS WG to
refine and define what these concepts mean for the "braille" and
"embossed" media types.
|Editorial change; fixed.
On 24-May-2010, Michael Cooper reported the P&F WG is OK with the WG's proposed resolution: