W3C home > Mailing lists > Public > w3c-wai-er-ig@w3.org > June 2000

Re: Blocks and browser support

From: Chris Ridpath <chris.ridpath@utoronto.ca>
Date: Fri, 30 Jun 2000 09:23:56 -0400
Message-ID: <004201bfe296$71ae8de0$b040968e@ic.utoronto.ca>
To: "Michael Cooper" <mcooper@cast.org>, <w3c-wai-er-ig@w3.org>

>I'm attaching a zip
>collection to this message (hss.zip), and the documentation for
>understanding them (2 years old) in an html file (hss.html).

Thanks for sharing these files with us. It must have been a real chore to make them up.

  ---- Original Message ----- 
  From: Michael Cooper 
  To: w3c-wai-er-ig@w3.org 
  Sent: Thursday, June 29, 2000 7:07 PM
  Subject: Blocks and browser support

  Hi - I was asked to pass on Bobby's browser compatibility information. It's
  actually available in any local copy of Bobby, but I'm attaching a zip
  collection to this message (hss.zip), and the documentation for
  understanding them (2 years old) in an html file (hss.html).

  I also have a very old action item to propose a technical-ish definition of
  "blocks of content" for the purpose of then deciding if a block is "large".
  Just for the sake of argument, to throw something out there, I would say:

  Most generally, a block is a sequence of similar elements (especially ones
  that are defined as block-level elements, such as <p>), delimited by
  elements of some other type. So one or more <p> elements in a row is a
  contiguous block, ideally delimited on both sides by any heading element, or
  the opening/closing body tag.

  Other elements define blocks more by virtue of being containers of other
  elements. So, and <div> defines a block, as does any list (<ul>, <ol>,
  etc.). All the <li> children of a list are members of a block. It gets
  trickier when there are nested lists - I would say a nested list both
  creates a new sub-block, and is a member of its parent block, but at any
  rate does not begin a new block at the same level as its parent.

  <div> elements are tricky too because they might include anything. In the
  best case, a <div> defines a logical block. In reality, they might encompass
  the whole page, or much smaller chunks, down to a single word or character
  if they're confused for <span> which I often see. So, I would say that
  whether a <div> defines a block depends on the diversity of elements inside
  it. If there are a bunch of the same kind of element within a <div>, or
  anonymous text (text not even in a <p> element), that <div> defines a block.
  But, if there's a bunch of different kinds of elements, especially otherwise
  block delimiters such as headings, it may not be useful to think of that
  <div> as a block but as a formatting agent. Within it, there would be
  several blocks defined by other means. I would say though that a block would
  never span across a <div>'s boundaries, so if I had a bunch of <p> tags,
  then a closing or opening <div> tag, then more <p> tags, those paragraphs
  would be members of different blocks.

  Tables also complicates the issue. First, I would say that overall, a data
  table is its own block, and a layout table is not (but should be treated as
  I do <div> above, as a container element). So, generally, if you had a bunch
  of paragraphs, then a data table, then more paragraphs, the data table would
  be its own block, and would also delimit the paragraphs before and after it
  into distinct blocks. However, I would say this is only true for "large"
  data tables. A "small" table might be considered to be a "for example"
  within the block of text and not rightfully considered its own block. (The
  same would be true of a <blockquote>, by the way). So I have to define
  large. That's another discussion, but maybe for now if the table has more
  than 20 cells, it's "large".


  Michael Cooper
  Bobby Project Manager
  Technical Designer
  CAST, Inc.
  39 Cross St.
  Peabody, MA  01960
  Tel +1 978-531-8555 x265
  TTY +1 978-538-3110
  Fax +1 978-531-0192
  Email mcooper@cast.org
Received on Friday, 30 June 2000 09:24:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:30 UTC