See also: IRC log
<trackbot> Date: 17 May 2012
js: any request for items on agenda, or other issues.
ja: any dietary issues?
<Jan> http://www.w3.org/WAI/UA/2012/ED-UAAG20-20120510/#gl-style-sheets-config
<Jan> http://www.w3.org/WAI/UA/2012/ED-UAAG20-20120510/#def-stylesheet
<jeanne> http://www.w3.org/WAI/UA/2012/ED-UAAG20-20120510/#def-style-grouping
gl: use term stylesheet, define broadly to cover other technologies
<jeanne> Most agreed they did not see that Style Rule and Style Grouping designation was needed. There are no links to it.
gl: perhaps a note
<Jan> http://en.wikipedia.org/wiki/Style_sheet_%28web_development%29
<Jan> A web style sheet is a form of separation of presentation and content for web design in which the markup (i.e., HTML or XHTML) of a webpage contains the page's semantic content and structure, but does not define its visual layout (style). Instead, the style is defined in an external style sheet file using a style sheet language such as CSS or XSL.
<jeanne> GL: I would keep the definition of Stylesheet, but it needs to include non-CSS technologies.
<Greg> In particular, it is a set of style rules that can both be separated from content and applied to content.
<jeanne> JS: CSS does not appear to define Stylesheet. However, they do have a concept of Style Profile which is diffferent from what Wayne was proposing, which strengthens my opinion not to use the term Style Profile as it will be more confusing.
<Greg> Content that supports only inline styling would not count, presumably, but what about a script that applied styles, or applied inline stylings? If a script bolds every phrase ending in a colon, or underlines every other word, would they count?
<scribe> scribe: jallan
<Greg> Ensure the final definition applies to non-markup (e.g. binary) file formats, and that it is clear on whether or not scripts count, and that the stylesheets can be separate from content and applied to content.
<scribe> ACTION: jan to write definition of stylesheet. [recorded in http://www.w3.org/2012/05/17-ua-minutes.html#action01]
<trackbot> Created ACTION-729 - Write definition of stylesheet. [on Jan Richards - due 2012-05-24].
Resolution: remove other definitions related to style (profile, rule, etc.)
<Greg> Re 1.7.1 we could simply require that the same styling or formatting mechanisms available to authors should be available to users. For example, if authors can define a style sheet but users could only define scripts, they might both be equally effective but one is far more difficult.
ja: thought, last week we removed 'equally effective' from the SC, not testable
gl: what the method available to
users is usable and as easy it is for authors.
... add a note in the intent. explaining the mechanism for
users
resolution: remove words "an equally effective" replace with "a", and use UAAG standard phrasing
<jeanne> 1.7.1 If the user agent supports a mechanism for authors to supply stylesheets, the user agent also provides a mechanism for users to supply stylesheets.
gl: level of 1.7.2, currently A, could be AA, quotes from email message
<Greg> It seems that 1.7.2 could be AA because the bare minimum component, C, is already covered by 1.7.1; what 1.7.2 adds is the ability to switch between that baseline and more complex behaviors (A and B).
<Greg> I would not fail a browser from minimal accessibility because it failed to do A and B, even though I would hope every browser would do them.
<Greg> Jim, when working on 1.7.4 note that if you lose the part after the comma (as per the email discussino) then you're left with the problem of a lot of tools (e.g. Session Manager) that you can only save and restore them on a single system, but cannot transfer them between systems and cannot modify them. That would almost entirely remove their usefulness.
<scribe> ACTION: Jim to revise GL 1.7, pay attention to current behavior and aspirational subpoints, adjust IER and add where necessary [recorded in http://www.w3.org/2012/05/17-ua-minutes.html#action02]
<trackbot> Created ACTION-730 - Revise GL 1.7, pay attention to current behavior and aspirational subpoints, adjust IER and add where necessary [on Jim Allan - due 2012-05-24].
<jeanne> JS: when Wayne originally proposed these SC, Shawn Henry (WAI's low vision person) recommended that the levels be AA or AAA.
kim will write IER for new SC on user generated in page bookmarks
<Jan> http://www.w3.org/WAI/UA/2012/ED-UAAG20-20120510/#def-point-of-regard
jr: if in an interactive movie, you click on some content that takes you to a different site. you hit the back button you return to the point in the movie you return to.
<Greg> If we want the definition of viewport to address both static visual and audio/video, we could have two paragraphs in the definition, one that starts "in video and audio..." and the other that starts "in (something else)...". Better two simple definitions than one very complicated one like we used to have for "viewport".
<Greg> The current definition has a lot of parentheticals, making it difficult to read and comprehend.
jr: when zooming you zoom on a particular pixel. use that as a base
gl: but if I search, want the
found item in the view port after zoom
... definition should be more general.
items that may b relevant to the def:
Starting with the base assumption that regardless of
other content that may have focus, or be selected, the current point
of regard is that information that is visible to the user with the
bounds of the viewport (user agent content area).
There are at least three cases where the user agent may have to take
action to keep the point of regard in essentially the same location
<trackbot> Sorry, couldn't find user - to
within the visible portion of the viewport: (a) the viewport is
resized; (b) the zoom/scale on the content is changed; or (c) the
formatting of some or all of the content changes (e.g. font or text
size, causing content to change height and/or rewrap).
In these cases the user agent should maintain the same top-left
(top-right for RTL) corner UNLESS there is a focussed/selected content
INSIDE the pre-zoomed viewport, in which case the focused/selected
content remains in the post-zoom viewport.
Note: "Content" and "selected" are used because there may be cases
where the viewport is zooming into just part of an element (e.g. if I
select a few words of text that are part of a <p> and zoom in)
Starting with the base assumption that regardless of
other content that may have focus, or be selected, the current point
of regard is that information that is visible to the user with the
bounds of the viewport (user agent content area).
There are at least three cases where the user agent may have to take
action to keep the point of regard in essentially the same location
<trackbot> Sorry, couldn't find user - to
within the visible portion of the viewport: (a) the viewport is
resized; (b) the zoom/scale on the content is changed; or (c) the
formatting of some or all of the content changes (e.g. font or text
size, causing content to change height and/or rewrap).
In these cases the user agent should maintain the same top-left
(top-right for RTL) corner UNLESS there is a focussed/selected content
INSIDE the pre-zoomed viewport, in which case the focused/selected
content remains in the post-zoom viewport.
Note: "Content" and "selected" are used because there may be cases
where the viewport is zooming into just part of an element (e.g. if I
select a few words of text that are part of a <p> and zoom in)
gl: should stay in the intent. how point of regard is used should stay in the sc
<Greg> "The point of regard is the position in rendered content" could be "The point of regard is the portion of rendered content", or perhaps "point or portion", but it's rarely if ever a real point; normally it's at least a character which is larger than a point.
<Greg> Even if it's just the insertion bar, that has height, if not width.
sc 1.8.z Maintain Point of Regard: By default, when the user changes
viewport or content size the point of regard remains at the same
relative location within the visible portion of the viewport.
<Greg> Re 1.8.z, minor wording ambiguity "changes viewport or content size", which could be read as "changes viewport, or changes content size".
<Jan> 1.8.z Maintain Point of Regard: When the user resizes the viewport or rendered content then the point of regard remains at the same
<Jan> relative location within the viewport.
gl: should this be always, or a setting
<Jan> 1.8.z Maintain Point of Regard: When the viewport or rendered content is resized, the point of regard remains at the same
<Jan> relative location.
gl: limiting to resizing.
<Greg> 1. should we indeed limit this to resizing?
<Greg> If the content changes, say a paragraph is added, or some hidden content shown, does this still apply?
<Greg> I would say yes.
jim and jr +1
<Jan> 1.8.z Maintain Point of Regard: The point of regard remains at the same relative location:
<Jan> (a) the viewport is resized
<Jan> (b) the rendered content is resized
<Jan> (c) rendered content is added or removed
gl: application, if I deleted something then the tool would shift the content to the beginning of the content
<Greg> 2. Maintaining the relative location within the viewport is less important than keeping the point of regard visible. For example, let's say you do a Find and it highlights a sentence in the middle of the viewport. Now you increase the zoom considerably, it's more important for the entire highlighted sentence to be kept visible than for the beginning of the sentence to still be in the middle...
<Greg> ...of the screen.
jr: 2 sc, 1 on resize and 2 on content modification
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) Found Scribe: jallan Inferring ScribeNick: JAllan Default Present: Greg_Lowney, Jan, Jeanne, sharper, Kim_Patch, Jim_Allan Present: Greg_Lowney Jan Jeanne sharper Kim_Patch Jim_Allan Found Date: 17 May 2012 Guessing minutes URL: http://www.w3.org/2012/05/17-ua-minutes.html People with action items: jan jim[End of scribe.perl diagnostic output]