W3C home > Mailing lists > Public > public-wsc-wg@w3.org > April 2007

Re: ISSUE-51: distinguished Chrome is not the answer (public comment)

From: Mary Ellen Zurko <Mary_Ellen_Zurko@notesdev.ibm.com>
Date: Thu, 19 Apr 2007 14:20:36 -0400
To: Web Security Context WG <public-wsc-wg@w3.org>
Message-ID: <OFA7FD7A17.20DB44B7-ON852572C2.00647C62-852572C2.0064C399@LocalDomain>
I hate to open up the great Chrome debate again, but Al is right that we 
need to be able to refer to the chrome is a way that is not purely visual. 

I propose changing in section 9:

Chrome is the part of the browser window outside of the area displaying 
the current web page. 


Chrome is the representation through which the user interacts with the 
browser itself, as distinct from the web content accessed. In graphical 
layout terms, it is the part of the browser window outside of the area 
displaying the current web page. 

There are also some interesting tidbits in this one for when we're doing 
prototyping (on link representation), so I'll want to keep this (or a 
companion) open even after we agree/decide on this change. 


Mary Ellen Zurko, STSM, IBM Lotus CTO Office       (t/l 333-6389)
Lotus/WPLC Security Strategy and Patent Innovation Architect

Web Security Context Issue Tracker <dean+cgi@w3.org> 
Sent by: public-wsc-wg-request@w3.org
04/17/2007 08:14 AM
Please respond to
Web Security Context WG <public-wsc-wg@w3.org>


ISSUE-51: distinguished Chrome is not the answer (public comment)

ISSUE-51: distinguished Chrome is not the answer (public comment)


Raised by: Bill Doyle
On product: Note: use cases etc.

>From public comments
raised by: Al Gilman Alfred.S.Gilman@ieee.org


distinguished Chrome is not the answer 
where it says, in 9.1 Poorly defined area for chrome
(user should recognize what information is from browser and not page)
must change
The present definition for the chrome is layout-wise.  Change to "the 
representation through which the user interacts with the browser itself, 
distinct from the web content accessed."  Compare with the language in 
1.0, Guideline 1.
please consider
Think again.  You are asking the user to make crisp distinctions where 
don't want to, and we don't want them to need to.  The chrome represents 
functionality that, in the way the user recalls it, doesn't change from 
to page.  What you use frequently, you want to bring from recall memory 
you don't want display capability wasted on tickling your recognition 
for these things.  The innovations are strongly confined inside the page. 
it's rational for the chrome to be a wallflower.  And it's not just the 
chrome.  The GUI web presents the user with lots of information that they 
ignore.  The only problem is that what they ignore and what they notice 
from user visit to user visit.  The user doesn't distinguish page content 
doesn't get their attention from chrome that doesn't get their attention 
because, well, frankly, their attention is elsewhere.  So asking them to 
hairs among what they don't care about is a futile approach.
please consider
Review the relationship of sounds to events and ShowSounds to the critical 
of  attention-getting on event.  Different modality mixes have working BCP 

solutions to this problem and they are different, based on the modality 
audio is more atomic than is graphics; it's harder to be out of earshot 
to be out of the visual focus.  On the other hand, it's not always 
please consider
Design the event information (filtering, compression to friendly terse 
gestures) on the basis of a VoiceXML dialog.  Then abstract to SCXML for 
modal presentation.
You will note that screen readers say 'link' when a hyperlink is 
That is to say, some of the dialog-situation information that is conveyed 
(status) presentation properties (color, underline) in the GUI 
presentation is 
spelled out, articulated in language on-transition events, for the audio 
presentation.  Designing for a voice dialog, and backing all messages with 
least a "say it in a sentence" [if longer] backup will improve your 
of events the user needs to understand, and can be pruned for the default 
presentation.  Spelling out both a status and an events view of the 
will both improve the quality of your work and make repurposing the the 
presentation go better.
please consider
I want to return to the matter of High Contrast mode.  The reason you are 
going to have trouble seeking a remedy within the confines of present Web 
technology is illustrated by the similarity between two functions that are 

attempting to make the browse experience user-centric and accountable to 
user's interest: security and accessibility.  The Web technology of today 
characterized by the CSS cascade rule that local rules trump global rules. 
This is effective in making point and click operation efficient/easy, but 
stable/secure/accessible.  What we are up against is a re-factorization of 
user-web engagement into aspects, where there needs to be better support 
the stability of the security aspect (and the presentation-adaptation 
as well).  For the purposes of information integrity assurance, we can't 
the local escape from global discipline.  But that's a change from the 
techbase.  With the ascendancy of Web Applications (rapidly rising market 
share w.r.t. installed) you can't just retreat into "what the browser 
do."  There has to be a rationalized and enforced continuity between what 
happens in OS, [AT], browser,[plugin], webApp layers.
Received on Thursday, 19 April 2007 18:20:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:36:44 UTC