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.

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. ;-)

Post a reply to this message

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

>> 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

Le 15/10/2010 11:20, Invisible a écrit :

>> 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?

I do not know, but it would be more elegant to have xml processing xml
to produce xml.

For instance, you could make a picture of the actual xml tree/structure
(a.k.a the current page) to provide an overview with links to each
sub-section (floating over the page, as you scroll it...)
Now, why make that a picture rather than a simple set of lists & items,
that's a personal taste.

The global xsl transformation would be to echo the document (so the page
is displayed) and adding nodes to the navigation division on the fly
(well, if it is a picture, it's not a division anymore).

You would be immune to "allow javascript" box bad effect.
(but need a modern browser)

(so far, I only used xsl to generate xhtml with far more readable data &
style from raw xml code... and yet, the generated xhtml get some
javascript to fold & expand some parts of the displayed tree; but it
make an easy way to pretty show the dedicated xml automatically
(including multiple views of the same dataset with different angles): a
single reference to the xsl, nothing more and it's done.)

-- 
Real software engineers work from 9 to 5, because that is<br/>
the way the job is described in the formal spec.  Working<br/>
late would feel like using an undocumented external procedure.

Post a reply to this message

>>> 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?
>
> For instance, you could make a picture of the actual xml tree/structure
> (a.k.a the current page) to provide an overview with links to each
> sub-section (floating over the page, as you scroll it...)

Mmm, yes, that sounds like something that could be useful...

Post a reply to this message

On 15/10/2010 09:52 AM, Invisible wrote:

> What this means is that, in theory, it ought to be possible to write
> some JavaScript which *draws pictures* inside a web page.
>
> 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. ;-)

Almost unbelievably, this insanity actually works!

There are several snags along the way, however.

First, I was using the w3schools DOM reference, which helpfully omits 
several utterly critical API calls. For example:

http://www.w3schools.com/jsref/dom_obj_document.asp

Note how there's absolutely no mention of createElement() and friends. 
You're really not going to get very far without that. (!)

Instead I turned my attention to the Gecko DOM reference (which 
unfortunately lists Gecko-specific extensions as well). Here I can at 
least look up the correct damned method names! So that fixes that.

Next problem is that I can delete SVG elements, and they vanish from the 
screen, however calling createElement() followed by appendChild() 
doesn't appear to work at all. Works just fine for HTML, fails miserably 
for SVG. So, what, maybe Firefox doesn't support that yet?

Nope. It turns out you have to use createElementNS() instead. And you 
have to supply the entire 20-mile namespace string every single 
god-damned time you call it. Even though it's declared as a prefix in 
the root of the XML document. Apparently W3C did this on purpose. Isn't 
that wonderful? >_<

Fortunately I can just drop the (huge) namespace string into a global 
variable and access it from there. But I ask you! Why do it this way?

The next problem is with trying to add text. It turns out that the 
innerHTML property only works for... HTML. (Surprise!) Yeah, it's right 
there in the name. If you're working on HTML, you can use the innerHTML 
property to quickly and easily construct static document fragments. But 
if you're working on any other type of data (for example... SVG), this 
apparently stops working completely. Fortunately, in this instance I 
just need to quickly call createTextNode() and I'm golden.

The final problem is positioning text. Usually when you do this, there 
is either some way to specify sophisticated layout constraints, or else 
some way to query the font metrics so you can do the positioning 
yourself. SVG appears to provide neither of this. The result is that 
it's highly non-trivial trying to center my text...

Other than that, everything works perfectly. :-|

Post a reply to this message

Invisible wrote:
> On 15/10/2010 09:52 AM, Invisible wrote:
> 
>> What this means is that, in theory, it ought to be possible to write
>> some JavaScript which *draws pictures* inside a web page.
>>
>> 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. ;-)

I spent a fair amount of last year working on a UI in javascript, that 
among other things allowed you to draw diagrams of how you wanted your 
system's configured. You can do pretty much anything in javascript if 
you feel like it. The time was mostly spent getting the app nicely 
translated with proper logging etc and making the back end do it's thing 
and configure the various server's as requested. The graphics was the 
simple fun bit.

> Almost unbelievably, this insanity actually works!
> 
> There are several snags along the way, however.
...
Several of these issues are solved by using a js library such as dojo 
which aims to make it simpler to do decent ui stuff and makes it easier 
(slightly less hard) to get stuff to work in the various different 
browsers. The dojo test pages (that I can't currently find :- ( ) 
showoff a variety of effects.

Post a reply to this message

On 15/10/2010 09:52 AM, Invisible wrote:

> 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. ;-)

OK, so here is what I've made so far. All 9KB of hand-typed source code. 
Mental, eh?

(If you don't know what a Huffman tree is, this is going to make 
absolutely no sense to you at all...)

Post a reply to this message

Attachments:
Download 'huffman1.xhtml.txt' (9 KB)

Invisible wrote:
> but only textual. Not graphical.

You might want to google "html5 canvas".  It's all the rage now, and will 
probably mean svg becomes a getto

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

Invisible wrote:
> OK, so here is what I've made so far. All 9KB of hand-typed source code. 
> Mental, eh?

300 lines. Now do you agree that 600 lines of C would be considered trivial? :-)

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message