- From: Jan Richards <jan.richards@utoronto.ca>
- Date: Tue, 20 May 2008 09:57:25 -0400
- To: Jeanne Spellman <jeanne@w3.org>
- Cc: WAI-UA list <w3c-wai-ua@w3.org>
Thanks Jeanne, I've done a thorough re-write incorporating your points: *Flow* The process that fits a stream of text or content blocks into lines in a two-dimensional visual display. The flow is dictated by the primary reading direction, the fixed dimension of the display, and the position of the next line. For example, most Latin-based documents use a horizontal left-to-right text layout flow in which the display width is fixed and the next line appears below the previous one. A *reflow* occurs when changes to the content or the display dimensions necessitate recalculating this layout. If the display dimensions are tied to the viewport dimensions, when the user changes the viewport size a reflow will occur. 1. In *passive (re)flow*, the user agent inserts soft returns as needed to keep the content blocks within the fixed display dimension, but does not attempt to rescale or split oversize blocks. This may result in content blocks overflowing the fixed display dimension. 2. In *active (re)flow", the user agent inserts soft returns as needed to keep the content blocks within the fixed isplay dimension and also attempts to rescale or split content blocks to prevent overflow. Cheers, Jan Quoting Jeanne Spellman <jeanne@w3.org>: > > Jan, > > The definition of "Flow" didn't specify visual medium which IMHO needs > to be included. I also thought it needed to be more generic, so I re- > purposed some text from Internationalization. I also added a word to > passive reflow, since it only gives priority to one dimension and > usually extends the non-fixed (vertical) dimension. See if this fits > your thoughts. jeanne > > Jeanne proposes: > *Flow* > <INS>Display of text or blocks of content in a logical order for that > language or as specified by the author. For example, most Latin-based > documents use a horizontal left-to-right text layout flow in which the > next line always appears below the previous one. </INS> A *reflow* > occurs when changes to the content blocks or the viewport dimensions > necessitate recalculating this layout. > > 1. In *passive (re)flow*, the user agent gives priority to the <INS> > fixed </INS>dimensions of the content blocks, resulting in overflow of > the fixed viewport dimension and the need for the viewport to scroll in > its fixed dimension. > > > Jan Richards wrote: >> >> For my action item - draft a definition of "passive reflow": >> >> >> *Flow*: >> Laying out blocks of content into rows (when the horizontal >> viewport dimension is fixed) or columns (when the vertical viewport >> dimension is fixed). A *reflow* occurs when changes to the content >> blocks or the viewport dimensions necessitate recalculating this >> layout. >> >> 1. In *passive (re)flow*, the user agent gives priority to the >> dimensions of the content blocks, resulting in overflow of the >> fixed viewport dimension and the need for the viewport to scroll in >> its fixed dimension. >> >> 2. In *active (re)flow", the user agent fives priority to the fixed >> viewport dimension and rescales content blocks to fit. >> >> >> Cheers, >> Jan >> >> >> >> >> >> >> >> Jim Allan wrote: >>> http://www.w3.org/2008/05/15-ua-minutes.html >>> >>> Action Items: >>> GR send the scribing tips to Jeanne who will combine it with some other >>> instructions. [recorded in >>> http://www.w3.org/2008/05/15-ua-minutes.html#action02] >>> >>> GR will post information on the Test Suite. [recorded in >>> http://www.w3.org/2008/05/15-ua-minutes.html#action05] >>> >>> GR will re-examine CSS 2.1 on flow. [recorded in >>> http://www.w3.org/2008/05/15-ua-minutes.html#action04] >>> >>> GR will take back to the HTML group. [recorded in >>> http://www.w3.org/2008/05/15-ua-minutes.html#action01] >>> >>> JR will draft a definition of "passive reflow" [recorded in >>> http://www.w3.org/2008/05/15-ua-minutes.html#action03] >>> >>> Draft Minutes >>> 15 May 2008 >>> >>> See also: IRC log >>> Attendees >>> >>> Present >>> Regrets >>> Chair >>> Jim Allan >>> Scribe >>> jeanne >>> >>> Contents >>> >>> * Topics >>> 1. next week meeting >>> 2. F2F >>> 3. scribing >>> 4. future directions: >>> 5. printing >>> * Summary of Action Items >>> >>> <AllanJ> Title: UAWG telecon >>> >>> <AllanJ> Agenda: >>> http://lists.w3.org/Archives/Public/w3c-wai-ua/2008AprJun/0099.html and >>> http://lists.w3.org/Archives/Public/w3c-wai-ua/2008AprJun/0106.html >>> >>> <oedipus> www.freedomchat.org >>> >>> <AllanJ> http://www.student.oulu.fi/~vtatila/iamc.html >>> >>> JA: HTML group wants to see "MUST" in the access module. >>> >>> GR: HTML group says over-riding key bindings are a MUST. >>> >>> <KFord> What's the syntax to put myself on the queue? >>> >>> JB: SHOULD, SHALL and MUST are policy/procedure words. Judy wants >>> to look at >>> this more carefully. >>> >>> JA: The items in question are P2 which would be "should" by WCAG1. >>> ... we haven't used that before. Makes it difficult for the developer to >>> know what to code to. >>> >>> JR: Only use MUST when there is no reasonible exception to the rule. >>> >>> GR: Correct, they think there is no exception. >>> >>> <oedipus> http://www.rfc-editor.org/rfc/rfc2119.txt >>> >>> KF: I'm not ok with MUST. I can't make this an absolute. >>> >>> GR: XHTML2 WG is not negotiating on this. >>> >>> ??: Does this draft now go to public comment? Can we provide feedback to >>> that? >>> >>> JB: THey are enforcing a higher level of accessibility than UAAG? >>> >>> <AllanJ> propose Access module wording - >>> http://lists.w3.org/Archives/Public/w3c-wai-ua/2008AprJun/0100.html >>> >>> It is their spec. >>> >>> JA: We reviewed their spec and make our comments and cross-referenced the >>> dependencies to our UAAG 1.0 checkpoints. >>> ... We re-wrote it based on our understanding of the language. They came >>> back to a higher priority. >>> >>> JB: It would be a good cross-group courtesy to work this out before it goes >>> to LC. >>> ... it could be useful to invite cross-group discussion so that our >>> priorities can be synchonized. It could be difficult to coordinate >>> time-wise. >>> >>> GR: the main editor is not available for meeting today. They like the idea >>> of "persistent over session" >>> ... we need to define what we mean by session. It is in the WAI glossary, >>> which is out-dated. >>> >>> JA: Can we just put a period after "persist"? >>> >>> <AllanJ> old: If no key attribute is specified, the user agent >>> SHOULD assign >>> a key and >>> >>> <AllanJ> alert the user to the key mapping and the resultant user agent >>> assigned >>> >>> <AllanJ> key SHOULD persist across sessions. >>> >>> GR: That wording leaves it open for sites that want to give user session >>> options. >>> >>> <AllanJ> new: If no key attribute is specified, the user agent >>> SHOULD assign >>> a key and >>> >>> <AllanJ> alert the user to the key mapping and the resultant user agent >>> assigned >>> >>> <AllanJ> key SHOULD persist. >>> >>> KF: In a public environment, you may not want the key to persist. >>> >>> JA: Sometime when we go to write techniques, we can give examples >>> of writing >>> it to a cookie, or other techniques. >>> >>> KF: If you have done something for accessibility, it should be implemented. >>> It is open to enough interpretation that the user agent development >>> community should have the flexibility they need. >>> >>> vote: KF: yes. GR: yes. JR: yes. JB: yes. JA:yes. JS:yes >>> >>> <scribe> ACTION: GR will take back to the HTML group. [recorded in >>> http://www.w3.org/2008/05/15-ua-minutes.html#action01] >>> >>> JB: Wants link to mailing archive for this discussion from the HTML group. >>> next week meeting >>> >>> Jim is away next week. Judy recommends skipping one week and planning a >>> meeting for the following week. >>> F2F >>> >>> JA: Want to discuss now because there deadlines coming up. >>> >>> JB: Tech Plenary and TPAC in France around October 29. Good opportunity for >>> meeting. >>> >>> JA: Another option is ATAG is meeting in Redmond, WA in July 25, >>> 26. Tuesday >>> it was asked: Could we have a UAAG meeting at same time? >>> >>> KF: if we have the meeting scheduled in France, do we need another? >>> >>> JB: It can be an advantage. With it scheduled for July, it could be good >>> timing. We don't want to overwhelm hosting. >>> ... Another possibility would be another host in the same town. Or meet >>> somewhere else before October. >>> >>> KF: Could get an official answer by ... >>> >>> JA: When KF finds out, he will send an email. >>> scribing >>> >>> JB: Who else is able to scribe? >>> >>> Jan, Jim, Gregory (once a month), Jeanne >>> >>> Kelly is willing, but doesn't know how to do it. >>> >>> JB: There are scribing tips we can distribute. We can set up a scribe >>> rotation. >>> >>> GR: Has a scribe >>> >>> <scribe> ACTION: GR send the scribing tips to Jeanne who will combine it >>> with some other instructions. [recorded in >>> http://www.w3.org/2008/05/15-ua-minutes.html#action02] >>> future directions: >>> >>> <AllanJ> >>> http://lists.w3.org/Archives/Public/w3c-wai-ua/2008AprJun/0072.html >>> >>> JA: We need to work on these topics (printing, keyboard access, UA and >>> Video) and work them out on the email list. >>> printing >>> >>> <AllanJ> SC: 3.11.X Print Scale: If a print from viewport feature is >>> provided, >>> >>> <AllanJ> the user has the option of printing using the viewport's scale >>> settings >>> >>> <AllanJ> such that the user agent should attempt to *passively reflow* the >>> >>> <AllanJ> content into the horizontal dimensions of paper. If passive reflow >>> is >>> >>> <AllanJ> not possible, more than one sheet of paper will be required >>> horizontally. >>> >>> JA: JR proposed removing "pieces of paper". >>> ... we need a new definition of "passively reflowing" >>> >>> KF: "print" is too restrictive, it doesn't include embossing. >>> >>> JB: propose "printing and embossing" to keep it from getting too obscure. >>> >>> JR: Does embossing horizontally cross two pages? >>> >>> GR: "Paged media" is too cryptic. Most user agents don't print directly to >>> an embosser, they use another AT software to do the embossing. >>> >>> JB: Does it make sense to say "printing" and define it elsewhere? Or the >>> first time it is used also include embossing? >>> >>> KF: When you send to an embosser, the embosser software does the >>> reflow. The >>> user agent doesn't have anything to do with it. >>> ... Leave it as is and include a note that some printing from user >>> agent may >>> include providng information to other technologies for production in >>> alternative media." >>> >>> GR: if you print something and it is too big for the page, it >>> still needs to >>> go somewhere and not be lost. >>> >>> JA: When I print from my browser, some text is lost off the right of the >>> page. >>> >>> <AllanJ> jeanne: also an authoring problem, if css used properly it will >>> reflow, if not printing breaks >>> >>> JA: Still need to define passive reflow. Any ideas on a definition? >>> >>> action JR will draft a definition >>> >>> scribe: of passive reflow >>> >>> <scribe> ACTION: JR will draft a definition of "passive reflow" >>> [recorded in >>> http://www.w3.org/2008/05/15-ua-minutes.html#action03] >>> >>> JR: Horizontal flow, do we also need to consider vertical flow to >>> accommodate the direction of the language flow. >>> >>> <scribe> ACTION: GR will re-examine CSS 2.1 on flow. [recorded in >>> http://www.w3.org/2008/05/15-ua-minutes.html#action04] >>> >>> <scribe> ACTION: GR will post information on the Test Suite. [recorded in >>> http://www.w3.org/2008/05/15-ua-minutes.html#action05] >>> >>> <AllanJ> -q >>> >>> JA: CSS has language tags for left and right, but I have never >>> seen anything >>> for vertical. >>> >>> JB: I18l can fill us in on any requirements for print direction. >>> >>> JR: There is language that is appropriate. >>> >>> JA: What's the success criteria? >>> >>> <AllanJ> +1 level 1 >>> >>> GR: PR 1. Many examples of people who need it. >>> >>> KF: we need to think about the process of assigning priorities rather than >>> throwing out use cases. >>> >>> JA: table this to two weeks. >>> >>> <scribe> scribe: jeanne >>> >>> Jim Allan, Webmaster & Statewide Technical Support Specialist >>> Texas School for the Blind and Visually Impaired >>> 1100 W. 45th St., Austin, Texas 78756 >>> voice 512.206.9315 fax: 512.206.9264 http://www.tsbvi.edu/ >>> "We shape our tools and thereafter our tools shape us." McLuhan, 1964 >>> >>> >>> >>> >>
Received on Tuesday, 20 May 2008 13:58:06 UTC