|
![](/i/fill.gif) |
>> 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
|
![](/i/fill.gif) |