HB A block is a container for other blocks. At the lower level it is a paragraph, a list item, a frame?
WC This is for checkpoint Checkpoint 12.3 - Divide large blocks of information into more manageable groups where natural and appropriate
WL "block" a chunk of HTML formed by an element that begins a new line.
WC BM's proposal number was 10.
WL Doesn't understand context.
BM the consensus seems closer to 5 or 7, for lists at least.
/* BM reads from WCAG "For example, in HTML, use OPTGROUP to group OPTION elements inside a SELECT; group form controls with FIELDSET and LEGEND; use nested lists where appropriate; use headings to structure documents, etc." */
HB Doesn't like the word "block" prefers "grouping." /* reads from thesaurus */
BM Beyond what say in WCAG, "all of these grouping mechanisms should be used when appropriate and natural." Also mention tables, etc.
HB So, we're saying a group of 5-10 other things.
BM if you see more than 7 of something, you should trigger the check.
WC If you see more than 7 paragraphs?
BM Break up lines of text into paragraphs. When is a paragraph big enough? If 1,000 words, definitely "big."
WL Most of the style rules have to do with ideas being in a paragraph.
WC If more than one idea per paragraph, either manual check or someday an automatic check. Need research on the table before can make a decision. I've been looking at interface design, someone look at style and grammar?
WL We supposedly ask for proper stylistic choices to be made. There are methods for looking for that. We're going beyond that, navigation items, that don't appear in prose. However, they use the same sorts of rules.
Action WL Go through Nielsen's site to dig up info on creating groupings. esp. usability tests of certain kinds.
Action HB E-mail the group references on style, writing, and grouping.
WL I deal with each issue as it comes up, not keeping track. Therefore not one to ask.
HB Move our old log into that system.
WC We aren't expecting that the tool will magically make issue tracking a no brainer, we are hoping that it can be used by people like a bug tracking system. When someone has an issue they will add it to the system. Len and I would then keep track of its progress. We need to resolve issues. Many just peeter out. We are currently only tracking issues with AERT, those are kept within the AERT as @@'s or listed as open issues. We will have other issues raised however and need to keep track of those. Since AERT is not on the Recommendation track, I have not been as motivated to thoroughly track the issues. Regardless, we do need to track issues and make sure they are resolved. ETA has some good features for notifying people, and a format for collecting info that could help us organize our issues. It's a database so we can make queries. It helps us maintain and archive so we can avoid recycling issues.
WL What about the "until user agents" clause? Do we have a tool that says, "there is a place where you can count on CSS2 being implemented."
WC It's not just when does browser X support something, it's when do users begin using that browser. Users don't upgrade for many reasons.
WL do you read EO? From Carlos, "how do we have a tool that let's you know what is not supported."
WC TopStyle and HomeSite do a good job of showing you what is or is not supported in a variety of browsers and what is included in W3C specs and not.
WL The tool that i envision will warn you if what you've done will not work in Netscape4, for example.
WC Where fit in AERT? Checkpoint 6.3 - Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported and actually, perhaps need a new checkpoint to cover? 3.2 Create documents that validate to published formal grammars. doesn't quite cover it, b/c you could validate to a grammar but the support is not there. Need to
Action WC add to AERT a technique that notifies authors when something they have done is not supported in a browser, ala the HomeSite/TopStyle method.
Next Tuesday with AU.
$Date: 2000/11/08 08:17:43 $ Wendy Chisholm