Re: Initial approach to the reading order issue

to follow up on what Dave Raggett, Jason White, and T. V. Raman said:

[To address the general process issues first]

Raman>
> In the run upto the October deadline, let's try and do the following:
> 
> 1) Clearly identify suggestions as
> a) Wish list in an ideal world
> b) For consideration for our current deadline
> c) Whether feasible within the constraints of HTML4 and CSS1.X as currently
> defined.
> 

We will be making decisions about what is and is not reasonable to
consider in this cycle -- item b.  However, even on our timetable
it is possible to make those decisions too fast as well as too slow.

Desirability, item a, we consider tentatively for confirmation in
the discussion with the Interest group after the 15th.
Feasibility, item c, we consider tentatively for confirmation in
the discussion with the HTML and CSS working groups.

Raman>
> This is not to dissuade speculation about what ideal solutions would look
> like; but
> at this point we risk missing our stated goals for the end of October if we
> put up ideas that are not based on an understanding and acceptance of what
> HTML4 and CSS are capable of.
> 

For this work item, the definition of HTML4 and CSS2 are not the
constraints.  We are tasked to challenge, not accept, the
documented definitions of these two formats where they violate
critical requirements of access.

By the same token there are constraints; we cannot radically
re-define these formats.  These contstraints, on the other hand,
are not documented.  Clarifying what is feasible is the other
half of our work along with clarifying what is desirable.  We
should be making continuing progress in this area throughout our
brief lifespan as a team.

[To return to more specific issues]

> All of the reading order transformations (and more) were part of AsTeR.
> 
> Doing such things requires a generic tree transformation language, and CSS is
> in general not capable of such tree transformations.
> 

We may not be able to match the capabilities of AsTeR.  On the other
hand, if all the elements that one wants to sequence are give IDs in
the HTML, it is reasonable to ask if [I don't know] CSS2 can sequence
them and if not, why not.

How would you characterize the capabilities of CSS2 to sequence
elements of an HTML document?  How far are we from being able
to do that?  If this is not a priority issue, why is it not?

What I am wrestling with is how to split the "reading order" topic
and identify two different issues, which I think have a different
level of urgency attached to them.

On the one hand, current Web technology is turning text into 
gibberish.  We have situations as bad as text placed in two
columns by table formatting and read in 

	Line one of column one
	Line one of column two
	Line two of column one
	etc.

order.  Related to this but at a slightly lower disaster level is
when a continuous text is cut and pasted into a variety of cells
in a table and there is no record or implication in the HTML of
the sequence-of-cells that comprise one continuous text.

Both of those to me are violations of the intrinsic semantics of
the text content and merit our vigorous attention.  Although I
suspect that most of the repair is a matter of browser
guidelines, I further expect that the browser guidelines will
need some support in markup and I am not yet comfortable that the
HTML language as drafted lets us supply the necessary markup.
An example of how this could be marked up using HTML and processed
by a browser with that information would clear this up and
remove the concern.

I would like to distinguish this matter of connecting the
cut pieces of a single text from a total ordering of all
elements withing a document.  Dave asked "what if we just
let you add reading-sequence numbers?"  My problem with that
is that there often is not an intrinsic linear order for
all the components of an HTML document.  The intrinsic
semantic structure is freer than that.

So I see the capability to re-sequence elements as a styling
capability, desirable for audio, and possibly for other media.
We can then question how feasible it is to get that in the
combined capabilities of HTML and CSS.

But to preserve the connection and sequence among cut pieces
of one text is to me an essential content-preserving markup
and needs to be in HTML.  Again, I am not sure that it can't
be done today.  But I do want to distinguish this capability
from placing all elements in the document in one sequence.

There can be multiple text sequences in a document which are
appropriate to sequence differently in different contexts, but
each of which only makes sense if its cut parts are read in a
given order.  I think we should strive to make sure that it is
feasible in HTML4 to know the proper [i.e. intrinsic] order
within a set of text fragments appearing in the HTML which are
logically subsegments of one continuous text.

--
Al Gilman

Received on Tuesday, 30 September 1997 12:17:24 UTC