role of DOM vs. SPEAKROW

Why is DOM involved in pursuing SPEAKROW etc. functionality?

Daniel gave the basic story.  I want to embellish it a little.

The vendor reaction is a little like what T.V. said: if it takes
a full tree walk, it's not in scope for CSS.

Now, I believe that what one needs to do to make the net effect
of SCOPE and HEADERS available for SPEAKROW use is nothing like a
full tree walk.  It merely is walking the Web implied by the
HTML.  The threads are quite direct.  But since they cut across
the parse tree, we need to develop the secondary threads and teach
the multi-threaded nature of the DOM image of an HTML table in
order for others to comprehend the directness and simplicity of
what we are asking for.

I agree with the commentary in the CSS meeting that processing
SCOPE and HEADERS to get the effective headers of a table body
cell is more HTML post-processing than it is CSS pre-processing.

One path to implementation in CSS3 (or CSS2 for that matter)
passes through DOM on the way.  Here is a rough plan.

	first, use DOM to define the virtual script that locates
	the effective cells and gets the necessary data out of them.

	second, give the results pseudo-attribute names, and 
	get browsers to support these pseudo-attributes as
	part of their DOM interface that contains the starting
	data structure for styling.

	third, pull the pseudo-attributes by name into generated 
	text in a CSS2 generated-text insert.

This is not the only way to work the problem, but it is one way.

Another way is to use an existing scripting language to define
the SPEAKROW etc. macros and the author could still put them in a
web page.

We will probably meet more rapid understanding of the simplicity
of handling SCOPE and HEADERS by dealing with their
representatives to the DOM group than by going straight to styles
because of the way the vendors see the functionality breading
into phases or processing steps.

This is not a settled plan, just a brainstorm inspired by how
I perceived what I heard from the CSS team.

-- Al

In the long term, I believe that what the WAI needs is a Dialog
Object Model or Discourse Object Model which captures how objects
drawn from the Web resources act in the user interface.  This
then would be used as a requirements statement for HTML and CSS
and not vice versa.

In the short term, it is good to try to listen to the vendors so
that we can couch our requests in terms that they easily perceive
as easy to accomodate.  If we have to translate part of the
SPEAKROW processing to DOM terms to be understood, we should
translate.

Received on Monday, 17 November 1997 12:38:06 UTC