Re: meeting happenings

> With regard to the SPEAKROW issue, I do not fully appreciate how it could
> be regarded as falling within the purview of the DOM specification. 

I'll try to expose my view. 

This is an important topic of discussion and we should have a clear
and common model of understanding.

> As I understand it, the purpose of DOM is to expose markup and style
> information to external programmes, including access software and
> scripting languages, and to allow these applications to modify the
> document in prescribed ways.

Correct.

> The SPEAKROW capability, on the contrary, is
> supposed to be a stylistic device available to the author, whereby he or
> she can exert a high degree of influence over the audio rendering of each 
> row and cell in the table. Thus, it would appear to belong in CSS rather
> than DOM.

The important word in your sentence above is "author".

If we think a feature is indeed important for authors, then yes, CSS
or XSL is the place, but if it can be argued that a feature is mostly
to be used by user agents when rendering the info to the end users,
then doing it thru DOM local to the browser is a valid option.

The issue is really about interoperability: we want the authors and
the browsers to use the same language when bits of this language are
exchanged. If the language is only used on one side (say, like CGI on
the server side, or plug-in API on the browser side, to give two
examples), then, it's less important.

There is a price in extending CSS, delaying it, or making it more
complex and we should not ignore it while caring about accessibility,
since on the overall, it might cost us more than what it brings us.

Received on Monday, 17 November 1997 11:38:34 UTC