Re: Block level elements

I would prefer to rewrite 6.2.2, currently allow the user to view a
document outline so that is allowed navigation of the semantic document
tree structure - ie headers, paragraphs, lists, etc.

I have assumed that this is primarily a concern for HTML and that
well-written XML schemata will not have the same split between the
semantic and the syntactic structures. Which could well be wrong.

Charles McCN

On Wed, 10 Mar 1999, Jon Gunderson wrote:

  Thank you for your contribution to this section.
  
  I disagree though about removing the checkpoint.  I think we need a way for
  users to navigate sequentially through each block of the document.
  Especially naive users need a means to easily move through all the content
  of the document.   I think this is a checkpiont for AT and its priority
  should be raised to priority 1.  This complements the sequential active
  element checkpoint.  If both these checkpoints are implemented the user has
  a means with two keyboard commands to access all the active elements and
  the contents of the document.    
  
  Jon
  
  
  
  At 06:27 PM 3/9/99 -0500, Charles McCathieNevile wrote:
  >I took an action to exmine the definition of Block-level elements in HTML
  >4, and discovered that they are defined at
  >http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.3 as
  >
  > 7.5.3 Block-level and inline elements
  >   
  >   Certain HTML elements that may appear in BODY are said to be "block-level"
  >   while others are "inline" (also known as "text level"). The distinction is
  >   founded on several notions:
  >   
  >   Content model
  >          Generally, block-level elements may contain inline elements and
  >          other block-level elements. Generally, inline elements may contain
  >          only data and other inline elements. Inherent in this structural
  >          distinction is the idea that block elements create "larger"
  >          structures than inline elements.
  >        
  >   Formatting
  >          By default, block-level elements are formatted differently than
  >          inline elements. Generally, block-level elements begin on new
  lines,
  >          inline elements do not. For information about white space, line
  >          breaks, and block formatting, please consult the section on text.
  >       
  >   Directionality
  >          For technical reasons involving the [UNICODE] bidirectional text
  >          algorithm, block-level and inline elements differ in how they
  >          inherit directionality information. For details, see the section on
  >          inheritance of text direction.
  >              
  >   Style sheets provide the means to specify the rendering of arbitrary
  >   elements, including whether an element is rendered as block or inline. In
  >   some cases, such as an inline style for list elements, this may be
  >   appropriate, but generally speaking, authors are discouraged from
  >   overriding the conventional interpretation of HTML elements in this way.
  >         
  >   The alteration of the traditional presentation idioms for block level and
  >   inline elements also has an impact on the bidirectional text algorithm.
  See
  >   the section on the effect of style sheets on bidirectionality for more
  >   information.
  >  
  >In an appendix to the CSS2 entitled a sample style sheet for HTML 4 to
  >following elements are given as block-level:
  >
  >ADDRESS, BLOCKQUOTE, BODY, DD, DIV, DL, DT, FIELDSET,
  >FORM, FRAME, FRAMESET, H1, H2, H3, H4, H5, H6, IFRAME,
  >NOSCRIPT, NOFRAMES, OBJECT, OL, P, UL, APPLET, CENTER,
  >DIR, HR, MENU, PRE, LI, TABLE, TR, THEAD, TBODY, TFOOT,
  >COL, COLGROUP, TD, TH, CAPTION
  >
  >from http://www.w3.org/TR/REC-CSS2/sample.html
  >
  >The context was the checkpoint "allow the user to navigate among block
  >elements" (6.2.5 in the 9 march 1999 draft).
  >
  >My suggestion would be to remove this checkpoint since the required
  >functions are already covered by other checkpoints in the same section.
  >
  >Charles McCN
  >
  >--Charles McCathieNevile            mailto:charles@w3.org
  >phone: +1 617 258 0992   http://www.w3.org/People/Charles
  >W3C Web Accessibility Initiative    http://www.w3.org/WAI
  >MIT/LCS  -  545 Technology sq., Cambridge MA, 02139,  USA
  > 
  Jon Gunderson, Ph.D., ATP
  Coordinator of Assistive Communication and Information Technology
  Division of Rehabilitation - Education Services
  University of Illinois at Urbana/Champaign
  1207 S. Oak Street
  Champaign, IL 61820
  
  Voice: 217-244-5870
  Fax: 217-333-0248
  E-mail: jongund@uiuc.edu
  WWW:	http://www.staff.uiuc.edu/~jongund
  	http://www.als.uiuc.edu/InfoTechAccess
  

--Charles McCathieNevile            mailto:charles@w3.org
phone: +1 617 258 0992   http://www.w3.org/People/Charles
W3C Web Accessibility Initiative    http://www.w3.org/WAI
MIT/LCS  -  545 Technology sq., Cambridge MA, 02139,  USA

Received on Thursday, 11 March 1999 15:18:18 UTC