Bob Hanson wrote:
> Toby, what exactly are you meaning by "tag-soup" mode? I'm sure you
> don't mean "quirks" mode, but I'm not sure what you do mean.
I do mean quirks mode, yes. If your web-server is serving
pages as text/html, then almost certainly your browser is
in quirks mode. To get it working in xhtml mode, you need
to be serving application/xml, application/xhtml+xml or
similar.
> But the reason for using Jmol.js is more significant than that. The
> reason is that Jmol.js AS IT STANDS NOW, can be used with no
> document.write(). So that allows any functionality that you can think of
> to dynamically present the page in some DOM-directed fashion. That's the
> big change as of this week -- no longer a document.write() dependence in
> Jmol.js. Is that your only objection?
No - the point is that Jmol.js is generating html as strings(*), which
are then piped out to the document. Whether this is done directly
by Jmol.js itself, or whether the functions return strings that
you then pipe by document.write or innerHTML is immaterial - this
is never going to work in XHTML mode - there is simply no way to get
the browser to render dynamically generated HTML from a string.
(*At least, that's my understanding - I haven't actually tried the
new Jmol.js yet)
Dynamic XHTML must be done through the DOM interface - what Jmol.js
needs to do is return DOM nodes, that the user can then insert
into their document.
>> where I want a jmol
>> applet to be available, I have this:
>>
>> <div id="parent_id">
>> <input type="button" value="Activate Jmol viewer"
>> onclick="javascript:toggleJmol([400,400],"parent_id")">
>> <applet style="display:none;"/>
>> </div>
>
>
> How does this use of <applet> pass the XHTML validator? I get:
Sorry, I was doing that off the top of my head. Clearly the
input tag should be terminated properly, and it should be
object not applet. (Although I'm still using applet in my
own code at the moment - it's working & I haven't got round
to converting to object yet.)
>>
>> with toggleJmol defined as:
>>
>> function toggleJmol(sz, parentId) {
>> // Grab parent node of structure we'll manipulate
>> var parentNode = document.getElementById(parentId);
>> // Find the applet & div nodes to be used.
>> for (child = parentNode.firstChild; child != null; child =
>> child.nextSibling) {
>> switch(child.localName) {
>> case 'input' :
>> var inputNode = child;
>> break;
>> case 'applet' :
>> var appNode = child;
>> break;
>> }
>> }
>
>
> Why not just give the input and applet tags ids directly? This seems
> very round-about going through the parent. I'm sure you have your reason...
To reduce the number of arguments being passed around - I just find it
easier to hide the complexity in toggleJmol; then when I need a jmol
instance in my xhtml, I only need one id. I agree that you could do it
with multiple ids if you wanted.
> Can you point us to your modified Jmol.js that has JmolAppletNew() in it?
My current version is at http://www.uszla.me.uk/jmol/Jmol.js - it's
not completely converted to DOM node usage yet - I've only converted
the functions I use - and it still uses
applet tags rather than object at the moment, since that worked
for me. At some point I'll get round to converting it to use object
throughout.
It illustrates the principle, though, and has been working fine for me
with recent versions of Mozilla, Firefox, Opera, and Konqueror.
(* and it's not actually called JmolAppletNew in my Jmol.js - the function
you want to look at is _jmolAppletNew, which all my other functions
call.)
> The reason that most of us use Jmol.js is that then we have the
> framework in place so that, should browsers move generally in this XML
> direction, then we don't have to do anything more then drop in a new
> Jmol.js or a DOM version of that. For the masses, the alternative is not
> to do what you are doing -- hardly any of us have your expertise -- the
> alternative is to use hard-coded HTML code.
>
> So I really don't see your point here. Clearly, while I am moving in the
> direction of XML, Jmol.js is of use. Why wouldn't be? The whole idea is
> to abstract out the operation of generating the applet. If this is
> through your "extension of the DOM" method or not, that abstraction is
> good for me.
I wasn't intending to say that there was no use for a Jmol.js interface
hiding the complexity - I was just warning you that as it stands now,
its method of operation fails in XHTML mode. I entirely agree that it's
nice to have something to present a clean interface for the most common
case.
And indeed much of the operation of abstracting out applet generation
can be hidden. However, for XHTML, the current interface is not
sustainable - you can't use strings, you need to use DOM nodes. Certainly
much of the complexity of building up the nodes can be hidden, but the
end user is going to have to call some element.append() functions
themselves.
Static HTML generation is more complicated - because you can't
just say "insert this node here". You need to say "insert this
node as a child of this other node". And if you're trying to
run the javascript while the browser is still rendering the page,
then the DOM tree is not complete, so your parent node may not
yet exist in the browser's DOM.
However, you'll probably get away with saying "append to the last
node in the currently-generated DOM tree, which should have the
required effect. (Although this is not guaranteed to work,
I expect most browsers will make sure it does, since it's a
rather useful feature.)
> Can you give a few example pages that use your DOM model so we can see
> how those run on various browsers?
I can - but I should note that I've not been concerned with
cross-browser compatibility. The pages I'm working on at the
moment will not work properly on anything which doesn't fully
support inline mixed-mode xml (xhtml / svg / cml), which is
only Mozilla Deer Park & Opera 8 at the moment.
But you can have a look at the sort of thing I'm doing at
http://www.uszla.me.uk/example/4CDF.xhtml
(sorry - it's autogenerated by xslt at the moment; so is
probably rather dense. - I might try and pull together
a smaller example later.
--
Dr. Toby White
Dept. of Earth Sciences, Downing Street, Cambridge CB2 3EQ. UK
Email: <[EMAIL PROTECTED]>
Tel: +44 1223 333464
Fax: +44 1223 333450
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jmol-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-users
