Re: "Chrome"

In your responses to my statements, I think you used your own definition 
of the terms "window chrome" and "browser-controlled presentation 
elements" rather than those that I provided.  I agree that without 
reading the definitions, the phrases "window chrome" and 
"browser-controlled presentation elements" are going to mean different 
things to different people.  The whole point of defining them was to 
clarify what are obviously loaded terms so we can use them consistently, 
or as a starting point for new/different definitions. 

Here are my definitions.
> window chrome -- visual elements used by Desktop browsers or the OS 
> window manager to surround the web page
> browser-controlled presentation elements -- any user interface 
> presentation controlled explicitly by the browser and not under direct 
> web page control
You did provide some new definitions, which are very helpful. 
> chrome  : the widgets and UI elements provided by the application
> content : content, widgets and UI elements provided by the web page
I'm happy to work with either set of definitions.  Here are my comments 
on the definitions you provided.

   1. I would recommend that "widgets" is not a precise enough word and
      is likely redundant
   2. I think the concepts apply well to visual, voice, mobile web
      browsing environments, and browsing functionality embedded in
      other systems, but the term "application" breaks that.  That and
      the phrase "web application" has many meanings.  I would recommend
      we strike the word "application".
   3. I also think the word "chrome" implies visual rendering and it
      would be ideal to use a different word for it if we do not intend
      for it to use it explicitly for visual elements.
   4. I think the word "provided" needs to be a stronger verb.
   5. I think the word content is already too overloaded and some
      precision is helpful... particularly given you defined "content"
      using the word "content".  :-)

So I would recommend reworking your definitions as follows:

Change "chrome  : the widgets and UI elements provided by the 
application" to
"browser UI elements:  the user interface elements specified by the 
browser implementor"

Change "content : content, widgets and UI elements provided by the web 
page" to
"markup UI elements:  the user interface elements specified by the web page"

--Brad

Mike Beltzner wrote:
> On 12-Feb-07, at 9:58 PM, Brad Porter wrote:
>
>> Mike Beltzner wrote:
>>> It's not at all the case that the chrome populated with content from 
>>> web pages isn't under the browser's control. The browser is the 
>>> application that fetched it and placed it there, and the application 
>>> can choose not to, or choose only to do so according to specific 
>>> rules, etc.
>
>> Just to clarify definitions here, you're now using the term 
>> "application" to refer to the Firefox or IE as distinct from the web 
>> page?  We sometimes use "application" to refer to a web site, so I 
>> wanted to clarify.
>
> Yes, I am. Good to clarify, since that's really the crux of what we're 
> talking about here. "Chrome" might be the wrong word entirely, really, 
> since the skin of the UI elements on a web application would be 
> considered that web application's "chrome". :)
>
>>> I think the real issue here is the potential for confusion about the 
>>> source of the content. That the content appears inline with what 
>>> users are used to thinking of as chrome -- that is to say, UI 
>>> elements from an application which they have chosen to run -- often 
>>> makes users assume that the content is being provided by the 
>>> application, not the web page.
>
>> Again, I assume application refers to an OS application?
>> You have provided yet another definition of "chrome" more in line 
>> with the concrete definition of window chrome and separate from the 
>> semantic concept of chrome.
>> Do we think the definitions I suggested earlier are insufficient or 
>> need to change in some way, or can they map clearly to what you're 
>> describing?
>
> I think the definitions are fine, but I don't know if they help us 
> accomplish the difference we're trying to draw "window chrome" (or 
> "browser chrome", I'm fine with either) refers to the controls that 
> the browser draws in its protected context. 
This is yet another definition for "window chrome" separate from the 
definition I provided.  Please propose an very crisp alternative 
definition if you don't like the ones I provided.
> Sometimes the browser might draw widgets (ie: favicons) using 
> information that is dynamic and drawn from the web page content -- 
> those widgets are still "window chrome", though.
>
>>> All elements of chrome are under browser control. It's just that the 
>>> browser populates some of those elements from a website, which may 
>>> not be as trusted (by the user) as the browser.
>
>> Effectively, for certain parts of the "window chrome" the browser has 
>> decided to cede control of those pixels to the content.  Certainly, 
>> the entity which implements the browser application may use any pixel 
>> however they like, but if the application chooses to relegate the 
>> definition of those pixels to the content, then it is no longer a 
>> "browser-controlled presentation element" but instead it is a 
>> "content-controlled presentation element".
>
> I disagree. The browser controls it. It can turn it on, turn it off, 
> replace it with something else, etc. "Content-controlled" implies that 
> the browser is not at all in control of the content, which is entirely 
> false.
>
>> Better terminology or definitions are welcome?
>
> The crux of the issue is that users will erroneously assume that web 
> page content inlined in the "window chrome" is being generated by the 
> browser instead of merely drawn from the webpage. They therefore imbue 
> that content with the same amount of trust that they have for their 
> browser, which ends up being potentially dangerous.
>
> I think the definitions we want to use are:
>
> "chrome"  : the widgets and UI elements provided by the application
> "content" : content, widgets and UI elements provided by the web page
>
> We want to then illustrate what parts of chrome are dynamically 
> populated with content, such as the content area (the main browsing 
> pane in which web pages reside), favicons, etc.
>
> cheers,
> mike
>
>>> I think what we want to do is catalog the list of places where 
>>> chrome is populated by web page content and then see if we can find 
>>> better ways of expressing that concept.
>
>> That presumes we think making the "window chrome" the place to 
>> express security context information is the right solution.  I'm 
>> personally not sure the "window chrome" is the best place for that.  
>> Perhaps the user should look elsewhere.
>>
>> --Brad
>>>
>>> cheers,
>>> mike
>>>
>>> On 12-Feb-07, at 5:58 PM, Brad Porter wrote:
>>>
>>>> Yes, I agree that there are lots of sources for "semantic chrome" 
>>>> and today there's no way to know which presentation elements are 
>>>> browser-controlled vs which aren't.
>>>>
>>>> If the browser is going to say anything about the site at all, then 
>>>> the user needs to have some way of establishing trust with the 
>>>> browser.
>>>>
>>>> Consequently, I think establishing trust between 
>>>> user->browser-controlled-presentation-elements for those 
>>>> presentation elements which make statements about a web site is a 
>>>> prerequisite to pretty much any solution we come up with and 
>>>> therefore must be in scope.
>>>>
>>>> --Brad
>>>>
>>>> michael.mccormick@wellsfargo.com wrote:
>>>>> I like the distinction between "window chrome" and "semantic 
>>>>> chrome".  But I think there's a whole spectrum of semantic chrome 
>>>>> sources.  From most to least trusted, all the following can 
>>>>> produce such chrome: OS > base browser > TTP browser plug-in > TTP 
>>>>> script/applet/control > unintentionally activated 
>>>>> script/applet/control > malware emulating the OS or browser.
>>>>>
>>>>> For example all the things I just listed can generate pop-up 
>>>>> dialogs.  Ideally there's needs to be some contextual information 
>>>>> in the pop-up chrome that tells me its source or gives me 
>>>>> contextual cues about the source's trustworthiness.  In scope or not?
>>>>>
>>>>> From: public-wsc-wg-request@w3.org 
>>>>> [mailto:public-wsc-wg-request@w3.org] On Behalf Of Brad Porter
>>>>> Sent: Monday, February 12, 2007 11:24 AM
>>>>> To: Hal Lockhart
>>>>> Cc: Mike Beltzner; Bob Pinheiro; Mary Ellen Zurko; 
>>>>> public-wsc-wg@w3.org
>>>>> Subject: Re: "Chrome"
>>>>>
>>>>> Your separation between semantic chrome and the desktop visual 
>>>>> chrome is genius.  Given that, I propose two phrases with 
>>>>> definitions:
>>>>>
>>>>> window chrome -- visual elements used by Desktop browsers or the 
>>>>> OS window manager to surround the web page
>>>>>
>>>>> browser-controlled presentation elements -- any user interface 
>>>>> presentation controlled explicitly by the browser and not under 
>>>>> direct web page control
>>>>>
>>>>> --Brad
>>>>>
>>>>> Hal Lockhart wrote:
>>>>>> The key point I tried to make at the F2F was that the definitions 
>>>>>> that most of us would like to use for Chrome represent the way we 
>>>>>> wish browsers work or hope they will work in future. For example, 
>>>>>> a strict separation between what the application can control and 
>>>>>> what the browser controls seems desirable to most of us, but does 
>>>>>> not currently exist, as reported by many sources. The point of 
>>>>>> this comment is that first of all, we need to make this clear in 
>>>>>> our glossary, so as to avoid arguments about current violations. 
>>>>>> Also in evaluating potential definitions, we need to be aware of 
>>>>>> the present/future distinction. Looking at the thread below, I 
>>>>>> believe MEZ and Bob have proposed future definitions, whereas the 
>>>>>> two that Mike found are present definitions. I see the choice as 
>>>>>> being between defining Chrome in purely graphical terms (stuff 
>>>>>> around the edge of the screen) or semantically (stuff from 
>>>>>> browser not web site).  Hal
>>>>>>> -----Original Message----- From: public-wsc-wg-request@w3.org
>>>>>> [mailto:public-wsc-wg-request@w3.org]
>>>>>>> On Behalf Of Mike Beltzner Sent: Monday, February 12, 2007 10:13 
>>>>>>> AM To: Bob Pinheiro Cc: Mary Ellen Zurko; public-wsc-wg@w3.org 
>>>>>>> Subject: Re: "Chrome" A couple of definitions I found ..: "The 
>>>>>>> interface elements of a browser, or any other program, that 
>>>>>>> create the frame around the window that displays pages." (cite: 
>>>>>>> http://www.chriscassell.net/classes/2001/winter/gdt150/ 
>>>>>>> handouts/vocabulary.html) "The visible graphical interface 
>>>>>>> features of an application are sometimes referred to as 
>>>>>>> "chrome". They include graphical elements (widgets) that may be 
>>>>>>> used to interact with the program. Common widgets are: windows, 
>>>>>>> buttons, menus, and scroll bars. Larger widgets, such as 
>>>>>>> windows, usually provide a frame or container for the main 
>>>>>>> presentation content such as a web page, email message or 
>>>>>>> drawing. Smaller ones usually act as a user-input tool." (cite:
>>>>>> http://en.wikipedia.org/wiki/User_interface_chrome#GUI_design)
>>>>>>> I think the salient detail is that chrome is what allows the 
>>>>>>> user to interact with the browser alone from interacting with 
>>>>>>> the web content. Bob's point about the display of chrome being 
>>>>>>> restricted to the browser is also good to keep in mind, and 
>>>>>>> relevant for our
>>>>>> purposes.
>>>>>>> cheers, mike On 12-Feb-07, at 9:44 AM, Bob Pinheiro wrote:
>>>>>>>> I thought the key distinction with regard to "chrome" is that 
>>>>>>>> there are certain areas of the browser window that are solely 
>>>>>>>> under the control of the browser, and not the website being 
>>>>>>>> displayed. So anything displayed in the "chrome" can be assumed 
>>>>>>>> to be coming from the browser itself, and not the website. 
>>>>>>>> However, if some browsers have areas where both the browser and 
>>>>>>>> the website can communicate information, that seems to muddy 
>>>>>>>> the issue. Maybe such areas should have a different name, 
>>>>>>>> reserving "chrome" for those areas where only the browser can 
>>>>>>>> communicate to the user. At 08:16 AM 2/12/2007, Mary Ellen 
>>>>>>>> Zurko wrote:
>>>>>>>>> During our f2f, the discussion about "chrome - what is it" 
>>>>>>>>> came up again. The discussion was part of going over "Poorly 
>>>>>>>>> defined role for chrome". It was a divergence at the time, so 
>>>>>>>>> we decided to take the discussion to the list. See: 
>>>>>>>>> http://www.w3.org/2007/01/30-wsc-minutes.html "what is chrome? 
>>>>>>>>> diaglog boxes should be included" We'll need the definition of 
>>>>>>>>> Chrome for the Glossary that Tim is pulling together as well. 
>>>>>>>>> What I mean to mean by Chrome are the parts of the window that 
>>>>>>>>> include information that the User agent/Browser is trying to 
>>>>>>>>> communicate to the user, vs the parts where the browser is 
>>>>>>>>> (expected to) faithfully represent what the web site/page is 
>>>>>>>>> trying to communicate to the user. Some areas in some browsers 
>>>>>>>>> currently contain both (for example, the title area including 
>>>>>>>>> both the HTML title and browser identity information). Anyone 
>>>>>>>>> else have a better definition? I also remember people getting 
>>>>>>>>> fixated on the word. If the word itself is getting in the way 
>>>>>>>>> of a concept we consider important, then we can start using 
>>>>>>>>> some other word which we can all agree on. So this might 
>>>>>>>>> instead be an exercise where we agree on the concept first, 
>>>>>>>>> then agree on the word we'll use. [ACTION-132 - Start 
>>>>>>>>> discussion on mailing list to draw chrome items out and get 
>>>>>>>>> analysis completed [on Mary Ellen Zurko - due 2007-02-13].] 
>>>>>>>>> Mez Mary Ellen Zurko, STSM, IBM Lotus CTO Office (t/l 
>>>>>>>>> 333-6389) Lotus/WPLC Security Strategy and Patent Innovation 
>>>>>>>>> Architect
>>>>>>>> --------------------------------------- Bob Pinheiro FSTC 
>>>>>>>> Project Management Bob.Pinheiro@FSTC.org 1 908-654-1939
>>>
>>>
>
>