Le 15/10/2010 10:52, Invisible a écrit :
> Here's a thought...
> 
> XHTML is an XML language. SVG is an XML language. Theoretically that
> means you could be able to embed SVG inside XHTML. So far so good.
> 
> By writing a little JavaScript, you can use the DOM to modify an
> existing XHTML document, or even to generate entirely new content within
> it. And since you can generate arbitrary XML content this way, that
> means it should be possible to generate, say, SVG.
> 
> 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 ?

> 
> Now I can go off, try this, waste several hours of my life, and discover
> that it doesn't work at all. See you in a few hours. ;-)

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

Now, what pieces of information does javascript have access to that does
not depend on the actual page but on the actual computer it is running
on ? (without resorting to an ActiveXObject, of course!) and in a
portable way...

navigator.userAgent
navigator.appName
navigator.vendor
and so on for navigator.*

screen (.width & .height) also

-- 
A: Because it messes up the order in which people normally read text.<br/>
Q: Why is it such a bad thing?<br/>
A: Top-posting.<br/>
Q: What is the most annoying thing on usenet and in e-mail?

Post a reply to this message