 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 15/10/2010 06:29 PM, nemesis wrote:
> of course, if you want the spec, you need to go to the source over at
> w3.org.
Yes. I was eventually forced to do this. Which is a shame, because the
W3C spec for most XML-related things is utterly incomprehensible (and
mostly devoid of examples).
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> pretty friggin' cool web application, dude! IE users won't see it
>> though.
>
> That's what makes it so good.
+1
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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? :-)
After the hours of development work I put into this? How dare you
suggest such a... oh, alright then. ;-)
I think a more rigorous conclusion would be "LoC is a really vague way
to measure 'complexity'", but we knew that already...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 15/10/2010 07:25 PM, nemesis wrote:
> pretty friggin' cool web application, dude!
Meh, I try.
It'll be "pretty friggin' cool" when it actually shows the tree
construction steps, takes the original input, compresses it, neatly
prints out the result, and tells you how many bits you just saved...
As I say, I've written many little demos like this. But it looks so much
better with real graphics rather than crude ASCII art. (!)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 escreveu:
> On 15/10/2010 07:25 PM, nemesis wrote:
>> pretty friggin' cool web application, dude!
>
> Meh, I try.
>
> It'll be "pretty friggin' cool" when it actually shows the tree
> construction steps, takes the original input, compresses it, neatly
> prints out the result, and tells you how many bits you just saved...
for now, just being able to show the whole tree would be great: for as
small as 2 paragraphs of text, the container clips the diagram and
you're not able to see the whole tree. Redimensioning the container or
scroll bars would be nice... :)
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> for now, just being able to show the whole tree would be great: for as
> small as 2 paragraphs of text, the container clips the diagram and
> you're not able to see the whole tree. Redimensioning the container or
> scroll bars would be nice... :)
Redimensioning won't help you. If the tree gets to more than about 4
levels deep, the nodes become so densely packed as to be unreadable anyway.
Fixing this would presumably require a *real* node layout algorithm...
(The thought just flickered through my mind: Maybe I should have used
Google Charts inside of all this JavaScript DOM SVG craziness. But I
don't think Google Charts can do node graphs yet...)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> html5 canvas is for bitmap drawing. Vector drawing with SVG will be as
> much of a getto as Adobe Illustrator is next to Photoshop...
Oh. I thought it also did 3D stuff, or at least had lines. I know there's
some sort of extension for 3D stuff too, webgl or something?
> you're only annoyed that IE never got around at implementing it...
No, just ignorant.
> Imperative, somehow, is much more popular than functional style,
Not in lots of graphic stuff like animation.
> This preference seems to go well even among artists!, who would guess? :p
I've seen very few animation programs doing imperative stuff, beyond
simulations of real-life things that can't easily be expressed in closed form.
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> After the hours of development work I put into this?
I realized after I posted this that I failed to say that actually *is*
pretty cool, btw. :-)
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 15/10/2010 09:55 PM, Darren New wrote:
> I realized after I posted this that I failed to say that actually *is*
> pretty cool, btw. :-)
Heh. What did you *think* I wanted programmatically-drawn vector
graphics for? ;-)
I'm pretty sure I posted a full, *working* Huffman encoder/decoder here
before. (If I didn't, I definitely did implement it.) And another for
LZW. And yet another for arithmetic coding. Unfortunately I am too
stupid to implement PPM correctly.
I've implemented other things too, but I can't remember what off the top
of my head.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Selecting the text in a <textarea> is a HTML5 feature?
Seriously, you're kidding me, right?
I'm sure that can't be correct... Surely such a trivial feature has been
present for years!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
