 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible escreveu:
> 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. (!)
of course, if you want the spec, you need to go to the source over at
w3.org. I gave you a link to the DOM spec already some time ago...
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
pretty friggin' cool web application, dude! IE users won't see it
though. Hopefully, some day this kind of open web techs mashup will be
the rule indeed, rather than some html to load a Flash object...
Should have your name there somewhere, possibly in the header, meta tag...
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le_Forgeron escreveu:
> 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.
even more elegant would have lisp processing s-expressions to produce
xml... ;)
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New escreveu:
> 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
html5 canvas is for bitmap drawing. Vector drawing with SVG will be as
much of a getto as Adobe Illustrator is next to Photoshop...
you're only annoyed that IE never got around at implementing it...
BTW, vector graphics vs bitmap graphics remind me of functional vs
imperative programming: in bitmap, you have global state (the canvas)
which is directly modified each time an operation occurs; in vector
drawing, the canvas is updated (evaluated) by the result of the
(out-of-order) evaluation of element-drawing functions.
Imperative, somehow, is much more popular than functional style, despite
not (automatically) allowing for undo, reproduceability (??) and
non-destructive editing. My guess is that such features in software
like Gimp and Photoshop are basically a twisted realization of
"Greenspun's tenth rule":
"Any sufficiently complicated imperative program contains an ad hoc,
informally-specified, bug-ridden, slow implementation of half of the
features of a functional program."
This preference seems to go well even among artists!, who would guess? :p
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis <nam### [at] gmail com> wrote:
> pretty friggin' cool web application, dude! IE users won't see it
> though.
That's what makes it so good.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
