See also: IRC log
<trackbot> Date: 03 May 2012
<kford> zakim isn't letting me enter a phone code.
<kford> and now it did.
<JAllan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2012AprJun/0053.html
Jan: the idea is to split view and viewport which had been together since 1.0.
<JAllan> IEW: A user interface function that lets users interact with web content. UAAG 2.0 recognizes a variety of approaches to presenting the content in a view:
<JAllan> - rendered views: The content is presented in rendered form, typically according to the web content technology specification. This is the default view of most user agents.
<JAllan> - source views: The content is presented in unrendered form. The source view may be plain text (i.e., "View Source") or it may include some other organization (e.g., presenting the markup in a tree).
<JAllan> - outline views: The view presents only a subset of the rendered content, composed of labels for important structural. The important structural elements will depend on the web content technology, but may include headings, table captions, and content sections.
<JAllan> - property views: Only selected properties of the content are presented, separate from their source or rendered forms (e.g., image properties, JavaScript errors).
<JAllan> VIEWPORT
<JAllan> The part of a view that the user agent is currently presenting to the user, such that the user can attend to any part of it without further action (scrolling, etc.) by the user agent. : A user agent may include more than on viewport and they can be onscreen (e.g., windows, frames, panes, dialog boxes), printed (e.g. ink on paper, [ed. branded on cattle]), audio (e.g., sound from a speaker)...
<JAllan> ...or tactile (e.g. state of a Braille display). [ed. I'm assuming olfactory UIs are still not prime-time]
<JAllan> - NESTED Viewport: A viewport that is contained within another viewport (e.g. a frame within a document).
<JAllan> - TOP-LEVEL (USER AGENT) VVIEWPORT: The highest-level viewport in a user agent application.
<JAllan> - AUTOMATICALLY-ADVANCING Viewport: Some viewports automatically advance in one or more dimension (spatially or temporally). Audio viewports typically advance automatically (temporally), otherwise they would not produce coherent output, and so do some onscreen viewports (e.g. rendering video or animations or auto-scrolling) and tactile viewports.
<JAllan> Note 1: When the viewport is smaller in extent than the content it is presenting, user agents typically provide mechanisms for the user to bring the occluded content into the viewport (e.g., onscreen scrollbars, printed page turning, audio advance and rewind).
<JAllan> Note 2: Because user agent applications can be nested, the top-level viewport in a nested user agent will not be the top-level viewport in the full user agent stack.
<JAllan> Note 3: The user agent's own user interface controls (menus, alerts, etc.) are not considered viewports, though if the user agent is nested the user interface controls may in fact be implemented using viewports of the higher-level user agent.
<JAllan> Ed. So we would replace "top-level content viewports (e.g. windows or tabs)" in the document with "top-level user agent viewports"
<JAllan> Ed. We should also replace "Graphical" in most instances with "onscreen"
<JAllan> CURRENT WORDING:
<JAllan> http://www.w3.org/WAI/UA/2012/ED-UAAG20-20120419/#def-viewport
Jan: user agents talk about views
and more flexible in what that means. There are lots of
different views of Web content.
... I was really trying to wrap my head around audio because
when you listen to audio because of that first statement --
without the user agent doing anything, but the user agent is
always doing something in audio so how does that work. Some
viewports automatically advance
<JAllan> greg's comments: http://lists.w3.org/Archives/Public/w3c-wai-ua/2012AprJun/0058.html
Jan: I like some of the points you made especially the simplification only looking at visual, but definition of viewport complicated and confusing
Greg: we have 16 SCs that use viewport and they're all about on-screen.
Jan: was trying to be backwards compatible with UAAG 1 which mentions those things
<JAllan> UAAG 10 def View, viewport
<Jan> http://www.w3.org/TR/WAI-USERAGENT/glossary.html#def-viewport
<JAllan> The user agent renders content through one or more viewports. Viewports include windows, frames, pieces of paper, loudspeakers, and virtual magnifying glasses. A viewport may contain another viewport (e.g., nested frames). User agent user interface controls such as prompts, menus, and alerts are not viewports.
<JAllan> Graphical and tactile viewports have two spatial dimensions. A viewport may also have temporal dimensions, for instance when audio, speech, animations, and movies are rendered. When the dimensions (spatial or temporal) of rendered content exceed the dimensions of the viewport, the user agent provides mechanisms such as scroll bars and advance and rewind controls so that the user can...
<JAllan> ...access the rendered content "outside" the viewport. Examples include: when the user can only view a portion of a large document through a small graphical viewport, or when audio content has already been played.
<JAllan> When several viewports coexist, only one has the current focus at a given moment. This viewport is highlighted to make it stand out.
Greg: all that you really need is the first sentence of it
<JAllan> User agents may render the same content in a variety of ways; each rendering is called a view. For instance, a user agent may allow users to view an entire document or just a list of the document's headers. These are two different views of the document.
<Greg> WCAG defines viewport as "object in which the user agent presents content"..
<Jan> http://www.w3.org/TR/WCAG/#viewportdef
<Jan> http://www.w3.org/TR/WAI-USERAGENT/glossary.html#def-viewport
Greg: not perfect, but simple
Jan: how does the view then react because it's really the view that's rendering the content
Greg: we don't use view -- do in a couple places but it would be easy to rephrase to not use view. We could not have to worry about the word view and therefore avoid the complexity.
Jan: a lot of them have to do
with such the viewport or stretch the thing behind the viewport
such that it wraps -- the viewport is just the portal like the
window in a house that I'm seeing the view through
... , all it does is constrains the view that I'm looking
at
Greg: agree that those were complicated and confusing
Jim: so outline view is the outline that appears within the viewport. Maybe just using the word view is getting conflated with viewport
Greg: because everything is presented in a viewport, or actually not because if you -- it can theoretically be presented as part of the problem, but let's say you have a navigation menu which has submenus and the whole struck for both the menus represent the view of the document and let you navigate quickly -- so it's not a viewport because it's all part of the chrome
Jan: I'd call that a viewport -- yes it's part of the menu but it has a viewport around it
Greg: so some menus are viewports and others are not?
Jan: a user interface function
that lets you interact with Web content. It could be rendered,
source, outline or just a property view which is any other
filtering, images or even JavaScript errors. We are used to
seeing that in a nice big window with a menu bar on top, but
you could imagine clicking on a menu and the first item on the
menu is the entire rendered page, that could happen.
So...
... wherever the user agent decides to let the user interact
with Web content
... that's why I like this definition, it's flexible
<Jan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2012AprJun/0053.html
Jan: for me this is the front-line definition, the definition we should be pointing to. Then we get very specific, deal with resize, scroll etc. in one section
Greg: you don't want to include
the submit button is if you, because it is something that lets
you interact with Web content. So you might need to tweak the
definition
... my general druthers is usually to omit definitions we don't
need, but if you want to include it and tweak it, it would be
okay
Jan: could be simplified by keeping it to graphical viewport, which is really what we mean -- it could be simplified if we want to go that way
Greg: first, on screen, second,
complicated stuff about who has to take action, who doesn't --
when I read it it didn't make sense at first.
... just as a menu can be of you are not a view depending on
what it's representing, so t in HTML can be a viewport or not
depending on attributes and size of content -- if you have a
normal paragraph not a viewport but if it has content that is
larger then it's a viewport.
... to make it work to match with our SC's that use
viewport
Jan: that can fit in with the definition. We could put a note somewhere that it needs to be the case that potentially the user agent would have to do some action to bring the rest of it into. Otherwise you are just looking at a view port only
Greg: everyone okay with limiting definition to on-screen?
Jeanne: where would we put audio
Greg: can we remove the step about no extra action
Jan: I'm going to try to simplify it. The user has to attend to one corner or another -- user actions, but no user agent actions
Greg: Question of what our user agent actions. If I scroll enough times in this viewport the Web client has to query the server for another chunk of data -- stuff like that. That's getting to be a user agent action.
Jan: if I touch only one right arrow that's potentially going to cause the user agent to do something. I'm just talking about pure perception. And keep that automatically advancing for audio because in that case the user agent is constantly doing things.
<Jan> Jan to update the definitions to...rem non-onscreen viewports...
Greg: you use the word rendered differently than I do -- you use it being processed in some way. I wouldn't use the word render to mean only the cooking that doesn't happen in source view
<Greg> in your definitions of "rendered view" and "source view" you're using "render" in a different way than I would. I would say that any time the user agent presents something to the user it was rendering it, regardless of whether it was processed according to some rules or scripts (e.g. HTML and CSS), or presented essentially unmodified (e.g. plain text, images, or markup language source code).
<JAllan> current UAAG20 definition: rendered content, rendered text
<JAllan> Rendered content is the part of content that the user agent makes available to the user's senses of sight and hearing (and only those senses for the purposes of UAAG 2.0). Any content that causes an effect that may be perceived through these senses constitutes rendered content. This includes text characters, images, style sheets, scripts, and any other content that, once processed, may...
<JAllan> ...be perceived through sight and hearing.
<JAllan> The term "rendered text" refers to text content that is rendered in a way that communicates information about the characters themselves, whether visually or as synthesized speech.
<JAllan> In the context of UAAG 2.0, invisible content is content that is not rendered but that may influence the graphical rendering (i.e. layout) of other content. Similarly, silent content is content that is not rendered but that may influence the audio rendering of other content. Neither invisible nor silent content is considered rendered content.
Jan: what would you use to distinguish [etc. from picture
Greg: familiar with scratch.com or Lego mind storm? in that case the source view is not just plain
text.
<Greg> (Invented by MIT's Media Lab, by the way.)
<Jan> http://www.w3.org/TR/ATAG20/#def-Content-Renderings
Jan: I was thinking about the
Lego mind storm when it was written. There's different kinds of
content rendering in a tag. There's conventional rendering,
unconventional rendering and partial rendering.
... I was trying to keep it simpler, but maybe it needs to grab
the atag complexity
Greg: would it be an unconventional rendering that would be the source code for HTML, or partial?
Jan: partial, unconventional rendering would be something completely different that you don't experience when you are hearing the music, for instance
Greg: the source code for scratch
is not something experience either
... I agree, outline would be partial. If you have more
examples that would be useful
Jan: part of the definition lies on top of view.
<Jan> http://www.w3.org/TR/ATAG20/#def-View
Jan: begin with view -- editing views, previews.
Greg: like all the things you do with partial rendering etc. but when you say rendering doesn't apply to rendering it on the screen... you're saying a source view of HTML is not rendered at all
<Greg> I think of the verb "render" as meaning "present to the user".
Jan: In atag that's right, I can see uaag saying the source is a type of rendering though
<Jan> Jan: ...bring in the content rendering defn from ATAG (conventional, unconvential, etc.) but roll in source views
Jan: there's so much diversity in the ways user agents present things
Greg: outline view would normally put into place over for something that lacks its own label -- minor point
<Greg> Minor, but in the definition of outline view you might say "labels *or placeholders* for...", since it may want to present something for important structural elements that lack labels in the specifically defined sense.
<Greg> Some of the terms, such as "property view" and "automatically advancing viewport", aren't used in the document, so do we really want to define them, or do they just introduce unneeded complexity?
Greg: some of definitions are not used in document
Jan: property view might be able to go, automatically advancing viewport important explanation, covers things like automatically scrolling windows that someone might set up
Greg: no objection as long as
it's serving a useful purpose
... instead of defining a term I'm leaning toward just rephrase
the glossary reference that is using it instead of so much
cross-referencing
<Jan> http://www.w3.org/TR/ATAG20/#def-Web-Content
Jan: in atag we define the first order terms. Example...
<Greg> Where it says "UAAG 2.0 recognizes a variety of approaches to presenting the content in a view:", you might reword slightly to clarify whether it's a comprehensive list or a list of examples, e.g. "UAAG 2.0 recognizes a variety of approaches to presenting the content in a view, such as:" vs. "UAAG 2.0 recognizes the following approaches to presenting the content in a view:".
Greg: 3.2.4, 3.2.2 use term view, also bug in 2.1.7
<Greg> Re "2.1.7 Follow Text Keyboard Conventions: Views that render text support the standard text area conventions for the operating environment. (Level A) ## DONE TPAC", should we do something to clarify that things which render text are not all text areas? For example outline views presented as tree controls, while they render text taken from the content, would be expected to support standard...
<Greg> ...*tree control* conventions of the operating environment, not "standard *text area* conventions for the operating environment".
<Greg> ACTION: Greg to revise 2.1.7 Follow Text Keyboard Conventions to acknowledge not all view showing text should follow text area conventions. [recorded in http://www.w3.org/2012/05/03-ua-minutes.html#action01]
<trackbot> Created ACTION-728 - Revise 2.1.7 Follow Text Keyboard Conventions to acknowledge not all view showing text should follow text area conventions. [on Greg Lowney - due 2012-05-10].
<JAllan> rrsagent assign action-726 to kford
<JAllan> 1.5.1 Global Volume:
<JAllan> The user can independently adjust the volume of all audio tracks, relative to the global volume level set through operating environment mechanisms. If the global setting is mute, the user agent may override a global mute on explicit user request that cautions the user about the implication. (Level A)
<JAllan> http://www.w3.org/WAI/UA/2012/ED-IMPLEMENTING-UAAG20-20120419/#gl-volume-config
Jim: Single success criteria for 1.5 -- can we mark this done?
Jan: the second sentence is really another criteria
Greg: the reason they are together is otherwise they contradict each other
Jan: should the second one be a note?
Greg: maybe they can be separated. Overall I think that the two sections are probably correct and clear but it's unfortunate that they are so lengthy. I think they are right. Do they contradict each other or not if they are separated?
Jim: rather than creating a new SC I would rather make it a note
Jan: are we going to require for conformance that there be a caution about the implication?
Greg: let's say operating system I turn volume Low, and Web browser flash player I explicitly set the volume up high that could be considered an explicit action requesting it to override. It makes the global override essentially useless.
Jan: these are not OS guidelines, these are browser guidelines
Greg: if the user agent overrides the mute is that a problem?
Kelly: why is the second sentence here?
Jeanne: think of cell phone, you could put it on mute, but don't want to not hear reminder
Greg: checkbox don't want to override mute?
Jeanne: don't want a notice every time
Greg: don't want just changing
the volume slider to count as the explicit user action
... doesn't have to be a separate confirmation step like a
prompt
Jan: is this an honor system thing where the platform says the user sets global mute, do what you want?
Greg: I don't think we can make
assumptions
... in IER can we make that clear that it doesn't have to be a
prompt because we don't normally want a prompt
... I think it's unfortunate it's too long, but when it's
trying to say is right
... it's essentially saying that even though we let the user
adjust the volume independently of the global volume settings
but that doesn't really mean override the mute
Kelly: why for accessibility
purposes does the user need this
... this is not you can only do these things, this is the
minimum, if you want to do more, go for it
Greg: deaf coworkers -- computer making noise and not knowing it
Kelly: just as it's written doesn't cover that scenario
Greg: trying to -- second sentence -- user agent should obey global mute unless the user specifically says otherwise
Kelly: this is all true for all software -- we should delete the second sentence -- what do people think?
Jim: I'm fine with it, this is a special case that only appeared when cell phones came up.
Jan: I'd like to see the second sentence removed. Too complicated to put the two together
agreed that we should delete it
<JAllan> scribe: Kim
Resolution: remove the second sentence from 1.5.1
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/IEW/VIEW/ Succeeded: s/read my head/wrap my head/ Succeeded: s/meet/omit/ No ScribeNick specified. Guessing ScribeNick: KimPatch Found Scribe: Kim Default Present: Jeanne, Jim_Allan, kford, Greg_Lowney, Jan, Kim_Patch Present: Jeanne Jim_Allan kford Greg_Lowney Jan Kim_Patch Regrets: Simon Found Date: 03 May 2012 Guessing minutes URL: http://www.w3.org/2012/05/03-ua-minutes.html People with action items: greg[End of scribe.perl diagnostic output]