Subject: Re: FW: XSL - Loss to braille style sheets? From: Paul Prescod <papresco@xxxxxxxxxxxxxxxx> Date: Fri, 04 Sep 1998 10:56:41 -0500 |
Pawson, David wrote: > > Possible, as JC suggests using DOM access is viable. > Why not from within the style sheet? I haven't heard any valid reasons not > to. Because doing it within the stylesheet using ad hoc scripting will hurt our long term goal of making Braille access ubiquitous and reliable. If every author must *choose* to copy and paste in your JavaScript code into their stylesheet, they will never end up doing so. It's a question of doing the easy thing for the short term or the easy thing for the long term. > > or the OUTPUT of XSL > No Paul. Contractions need to be applied prior to formatting. > Having laid out a paragraph on a page, there seems little point in > contracting (to half the length) then having to format _again_ The output from XSL is not a formatted page. It is a set of formatting *objects*. I expect that, like DSSSL, those formatting objects will have no knowledge about the actual layout on a particular screen or page. So the output of XSL *is* probably the most logical place to apply your processing. > Yes, we could apply prior to using a stylesheet. > Yes, Ecmascript and accessing the source grove via the DOM is viable. > We then have to ask MS/Netscape etc, to 'fit' the pre-process into their > model of operation. > > N O. The *very existance of the DOM* implies that they are already planning to give people access to XML source groves. That's what the DOM is for!! So it is merely a question of asking them whether to implement the existing standard that they ratified themselves, or invest in a *new* ad hoc Javascript-in-XML standard. If I had to bet on one or the other, I would bet on the former. > > BTW, if you get conversion to braille working as an XSL post-process, then > > you can plug your post-process onto the back of any XSL spec and open up > > the web to Braille. > Our objective. If a post-process is your objective, then why are you concerned with ad-hoc in-stylesheet scripting? > > On the other hand, if you embed it in particular > > stylesheets, then only a small fraction of the web will be available in > > Braille. > > > Illogical. In the same way that you couldn't write a stylesheet to present > any > web XML document to your tastes. I don't know what you are talking about. Presumably there is some reasonable mapping from some reasonable subset of the formatting objects in XSL to some reasonable subset of Braille. You can choose to code that mapping once, or you can write a new Braille stylesheet for every document on the Web. > > Everything I touch turns into Python. > Python would do the job, but v slowly ;-) Certainly not slower than JavaScript, which is what you seem to propose. > Sorry to be a bore to you sighted guys. Your concerns are certainly not boring. I just think that you have the wrong model for addressing them. Ad hoc JavaScript processing is what you should be running screaming from. My guess is that this type of ad hoc processing in HTML pages makes the Web difficult to view for blind people. Paul Prescod - http://itrc.uwaterloo.ca/~papresco Everything I touch turns into Python. XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: FW: XSL - Loss to braille style, Pawson, David | Thread | XSL WD1.0: Numbering in the source , Jeremy CALLES |
ActiveX/XSL, Joe Davidyock | Date | SGML/XML Web Page - New URL, Robin Cover |
Month |