>> What this means is that, in theory, it ought to be possible to write
>> some JavaScript which *draws pictures* inside a web page.
>
> If the transformation is the same for all viewers, what is the interest
> of that approach (which consumes resources each time the page is viewed)
> compared to a static svg ?

It means that the pictures can change based on user input.

I've written a lot of demonstrations consisting of a static HTML page 
with some JS inside it. The HTML presents a form of some kind, and as 
you fill in the form and press buttons, the JS updates the contents of 
some read-only form fields to produce a result. (In the simplest case, 
you have a big read-only <textarea> element, and you print to that, 
terminal-style.)

The next level of sophistication is to use the DOM to modify the actual 
HTML rather than just using read-only form elements. This way, I can 
present arbitrarily sophisticated textual output - but only textual. Not 
graphical.

If it were somehow possible to make SVG work, I could do things like 
actually *draw* a Huffman tree on screen, rather than print out a bunch 
of text with some crude ASCII-art representation of one.

> It would be more interesting if instead of javascript, you used xsl
> referenced in the xhtml to produce the svg.

Uh... what would you use that for?

Post a reply to this message