See also: IRC log
<ScottM> Is there updated call info?
<AWK> +AWK
<scribe> Scribe: Laura
<davidmacdonald> I'm not able to join, says meeting hasn't started
<Joshue108> thats not the right channel
thanks, jim.
<AWK> Current version: https://rawgit.com/w3c/wcag21/resize-content_ISSUE-77/guidelines/sc/21/resize-content.html
joc: this issue 77
... wwe had vetted and approved this issue. Now we are having
further discussion.
... thumbs up so far. It is improving.
... what is the current staus?
AC: has gone thruough the
comments.
... rephrased for exception. instread of fix spaiial
layout.
... Now at level AA
... 1.4.4 is still needed.
... now “zoom content” instead of resize content
... some remaining issues:
... What if the text is already huge?
... would need examples
... What if the text is already huge? open to
suggestions.
... Is it ok to have the 1280px starting point in the
testability section but not the SC?
... If not, should we move to saying, "content should work at
320 CSS pixels wide".
<Zakim> AWK, you wanted to suggest changing "which require two-dimensional layout" to "which require a specific two-dimensional layout"
joc: good work. Thanks.
awk: editorial comments.
... should say specific dimensional layout.
... little concerned 2.0 resize text now 2.1 zoom content.
<Zakim> steverep_, you wanted to say I think single line inputs are already covered in the exception
steve: single line input is already covered. add it to an example.
<allanj> +1 steve 2d layout for single line input form control
AC: happy with that.
<Crystal_Jones> how do i put myself in queue?
AC: It is about native text
inputs which are only one line, as filling it in will require
scrolling.
... happy to have it as an excception.
awk: shouldn't be an issue.
<Zakim> Joshue, you wanted to say what does this mean in relating to hard resize vs zoom?
joc: what does this mean in relating to hard resize vs zoom?
ac: curernt SC is still needed as
a fallback.
... currrent one still needed. and promoted.
<Zakim> Crystal, you wanted to say
cj: what is the test scenario?
<alastairc> First line of the testability: Display content in a user agent capable of zooming 400% and start with a window width of 1280px at a 100% zoom level.
cj: will it be spelled out?
ac: it is in the testability section.
awk: wouldn't be applicable to all scenarios.
AC: See FAQ: Mobile devices start
smaller, how does that work?
... not a content issue.
... The main principle here is that the web content must be
capable of resizing, it is not a device-specific issue.
... have a note to that effect.
<alastairc> NB: Mobile devices are by necessity more limited in how they can resize content. This success criteria is to ensure the content is capable of resizing to a reasonable degree. In practice people will need to use a device or user-agent capable of reflowing content such as a desktop or laptop computer.
awk: needs to be in the SC text.
cj: doesn't have to be on mobile
to fail.
... will get different results.
<alastairc> The original exception: If the user-agent fits the layout to the viewport and does not provide a means of reflowing content, bidirectional scrolling is exempt.
cj: if you decrease the size of the window still not on a 1280 display.
<allanj> change screen resolution to 1280 x 720
cj: another issue does the device support it?
<alastairc> Or, we start the SC text with: Content displays at 320 CSS pixels wide without loss of content or functionality
joc: sounds like a contrived issue.
<allanj> I just tested on my machine. changed resolution of monitor to 1280 x 720. responsive site is still responsive to 500% in chrome
cj: SC does not spell out the environment for testing.
joc: we need to be technology agnostic.
wayne: could create a
table.
... come up with a formula for it.
... can do the calculation for it. It is fairly accurate.
david: can get different results
based on screen size.
... starting to see the concern.
... we need to be super clear. maybe in the language of the
SC.
joc: maybe have exemptions?
david: make a condition.
... when tested on a 1280.
... when viewed on a 1280 content can be magnified by 400
percent.
ac: appreciate the concern.
... device independent test.
<Joshue108> +1
<AWK> Can we see that in IRC to digest?
<alastairc> Content displays at 320 CSS pixels wide without loss of content or functionality, and without requiring scrolling in the direction of text except for parts of the content which require two-dimensional layout for usage or meaning.
david: maybe have an or clause.
AC: propose SC text “Content displays at 320 CSS pixels wide without loss of content or functionality, and without requiring scrolling in the direction of text except for parts of the content which require two-dimensional layout for usage or meaning.”
<davidmacdonald> Content can be zoomed to 400% OR displays at 320 CSS pixels wide without loss of content or functionality, and without requiring scrolling in the direction of text except for parts of the content which require two-dimensional layout for usage or meaning.
chris: scaling down. Mac can do down pretty low. Don’t want to focus on this issue. If the OS is capable we should consider it.
<chriscm> McMeeking
wayne: we can refer to a table in the SC.
<alastairc> Note - resolution is a different things from what size web content works at.
wayne: we need to think about if
we should tie the SC to a number.
... need to think about forward comaptiablity.
awk: 320px width on a small phone. This SC wouldn’t impact it.
AC: yes. need to define pixel width. Question on id it is the SC text or technique.
<AWK> Content can be zoomed to 400% OR displays at 320 CSS pixels wide without loss of content or functionality, and without requiring scrolling in the direction of text except for parts of the content which require two-dimensional layout for usage or meaning.
<AWK> vs
<AWK> Content displays at 320 CSS pixels wide without loss of content or functionality, and without requiring scrolling in the direction of text except for parts of the content which require two-dimensional layout for usage or meaning.
joc: likes david’s suggestion.
<alastairc> Should it still start with Zoom content: Content display at...
<alastairc> ?
<wayne> +1 to zoom
<Joshue108> Content can be zoomed to 400% OR displays at 320 CSS pixels wide without loss of visibility or functionality [...]
david: Having it in SC will be less problematic.
<wayne> +1 to zoom 4 or 320
<AWK> Rethinking and liking the specific testability of just the 320px, without the 400% zoom
<Rachael> possible editor note: Should it be displayed (vs displays)
JOC: preference for which goes first?
<AWK> Content displays at 320 CSS pixels wide without loss of content or functionality, and without requiring scrolling in the direction of text except for parts of the content which require a specific two-dimensional layout for usage or meaning.
AC: no.
joc: helps having both clauses in the SC text.
<Zakim> steverep_, you wanted to say that specifying a CSS pixel width is one option, but another might be to better define zoom
steve: agree with AC. an’t test the or statement.
<AWK> +1 to Steve
<alastairc> q_+
steve: maybe better to define what zooming really means.
wayne: maybe do need to define
zooming.
... 400 percent should be in there. so the intent is
apparent.
<davidmacdonald> Content can be viewed at 320 CSS pixels wide without loss of content or functionality, and without requiring scrolling in the direction of text except for parts of the content which require two-dimensional layout for usage or meaning. Note: 320px is a 400% zoom at 1280px
wayne: for legislators.
... okay with the OR statement.
... need normative definition of zooming.
awk: comming around to definition
of zooming.
... need “at least” in SC text.
... qualifier can help make the percentage clear.
AC: resolution vs CSS pixels. Conern of including both.
<alastairc> Content can be zoomed to at an equivalent of 320 CSS pixels wide without
AC: maybe have “Content can be
zoomed to at an equivalent of 320 CSS pixels wide
without”
... zoom increasing the size of pixels.
... we need a starting and ending point.
<alastairc> starting OR ending point is needed
david: like AC’s proposal.
<AWK> "Content can be displayed at a minimum width of 320 CSS pixels without loss of content or functionality…"
al: also CSS pixel forward compatibility is an issue.
AC: CSS pixel has been stable.
David: think we should go forward with this language.
AC: will incorpoate.
RESOLUTION: Leave open, alastair to work on edits
RESOLUTION: Leave open.
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Present: jasonjgw steverep Laura MichaelC Joshue108 alastairc ScottM chriscm Found Scribe: Laura Inferring ScribeNick: laura Found Date: 25 May 2017 Guessing minutes URL: http://www.w3.org/2017/05/25-ag-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]