On 2012.07.16. 20:03, Robert Hanson wrote:

So I say there is no problems with writing simple HTML with data attributes containing some hard core scripts. Maybe, if you have some really nasty examples, that have strict indenting and line breaks, that you could show me and I could test them, then, please, show me them.

We just can't put scripts in HTML as tag attributes. Period. Find some other way. Trust me on that one.
I'm still sceptical about that, I really need to do some proof of concept testing, that it does not work, because it's thee data, that HTML is all about.

It's possible that it's no problem any longer. especially if you aren't actually calling JavaScript in an href tag. So, for example, we try to avoid this:

<a href="javascript:Jmol.script(jmol, &quot;load &#92;&quot;my file.xyz&#92;&quot;&quot;)">my file</a>
Not on my watch :)

I guess in this context that would  become something like this:

<a data-script="load &quot;my file.xyz&quot;">my file</a>
Yes it looks more like that, but for loading I've come up with even better solution:

<a href="my file.xyz" class="jmol-load">my file</a>
And I just use the magic of jQuery's selectors to add this:
    $('#jmol').jmol('load "' + $(this).attr('href') + '"');

This is the one solution, that gives user an opportunity to download a file directly weather JavaScript is running (right click -> save as...) or if it's disabled (default action of a link click). And you can even insert an image in between <a> tags so that's a beautiful solution to degrade gracefully.

so that helps some. But it is a real pain for page developers, and we've tried to avoid it as much as possible. Since it's easy enough to do, it seems to me it should at least be an option to replace that with something like:

<a data-scriptid="loadmyfile">my file</a>

and then allow definition of that script id as ' load "my file.xyz" '
I see that actually best part of using a small library just for initialization is to allow a developer to choose his own solution, like I did in my examples. And for seasonal developers, of course, there should be fully featured Jmol library, with internal script caches etc. (maybe).

As for quotes - always escape them. If the site is running with some kinda CMS, that can be done automatically in WYSIWYG, if the site is prepared with some authoring tool, like, for example, Dreamweaver, then it will also do it for you.

First of all, scripts could run hundreds of lines. Second, we have tried escaping these, and besides being a royal pain, mostly it hasn't worked. HTML tags and <param.  values are just not adequate for holders of scripts. It's totally unnecessary anyway, I think. the solution has been around for years, and we have had no problem with it. It seems to me you will quickly find a different way. Perhaps the "data-script" simply points to a key in an associative array that is created in the head using an API, for example.
This still breaks the separation attempt. I know that it would be a painfull, in case, if somebody would like to write HTML by hand, but with authoring tools today it should not be that kind of pain anymore, especially when HTML5 introduced special attributes for raw and crazy data to be held inline.

Why do you say that? If the body code would just refer to a user-defined name, then that's equivalent to a script. They can then define the script in the head, prior to after attaching the other business to the link.
I'm starting to think, that there should be at least two clear layers in the API. One for the hard core developers, for example, just jQuery.Jmol.js, for the ones that wish to do everything themselves, and the second one should be fully featured library for seasonal developers or complete amateurs. Last ones could use data-scriptid in conjunction with something like Jmol.storeScript('myScript', 'load "some file.xyz"'), while hardcore guys just go with the Jmol.bindLoader('.jmol-load') or just simply use jQuery.

By the way, what is Jmol spt file? It's Jmol's script file source, what about the same use case as in my <a href="file.mol" class="jmol-load">Load my file</a>, just with a prepared script file <a href="wireframe.spt" class="jmol-load">Wireframe</a>. It creates a separate request to the server, but it would really separate HTML even from Jmol's scripts. One more option to think about.
Q: Is jQuery XHTML compliant?
I think yes, because, it doesn't really matter, as JavaScript is working with DOM, and if DOM has been initialized as XHTML then JavaScript will work with it. If I'm not mistaken, the same innerHtml, just sends some kind of eval() to the browsers DOM parser, where it turns into a DOM fragment, whereas it really does not matter anymore weather it is XHTML or just plain old HTML.

I'm not finding support for that on the web. Depends on things like namespaces and, for example, whether data-xxxx is in a dictionary, I think.
Aah, you mean XML namespaces? Well HTML5 came with XHTML5, dropping the attempt to create XHTML 2 as it was going in completely wrong way (I wouldn't say that, but there were people who thought so). So there should be no problems with that (but I have to double check the W3C then).

In any case, no one wants to download a pdb file as last resort. That's way too esoteric. (Anyone who could read that file will not want it this way.) If the applet doesn't load, the best solution is to provide an image. That's what JmolApplet.js does, upon request. 
I'd propose a different approach and throw in one more buzzword - accessibility :) neither Flash nor Java is good with all the screen readers for blind people, but they are not my main concern here. My approach would be to show a static image in the placeholder in the first place and then gradually replace it with Jmol applet (instantly or with a mouse click). By the way, it's the approach http://www.pdb.org/ are using, which, I must say, is really thought trough. I think it's called degrading gracefully. And throwing in an option for file download if Jmol could not be started is one of them.

yes, thank you.  Glad you like the http;//www.pdb.org solution. 
Anyway, that's what we have going with JmolApplet.js now. Exactly that. Did you try http://chemapps.stolaf.edu/jmol/docs/examples-12/simple2.htm on your smart phone?
Yes, just right now. But it does only draw a static 3D image, right? Or should it be interactive, like rotation and zoom? And loading buttons don't do anything on my iPhone.

You would be surprised how many people in Russia disable JavaScript in their browsers, I was visiting St. Petersburg two years ago and this guy, I stayed with, told me that they are kind of paranoid about the hacker scene there.

So for that to work, don't you have to hard-code into your page a <noscript> tag? I guess anyone could do that if they cared to now as well, with JmolApplet.js or with Jmol.js. I'm not seeing the difference between jQuery and not jQuery on that one. So we could recommend some sort of boilerplate for that, but that really isn't relevant to this discussion, is it?
Well, except maybe that with placeholder approach there is no need for <noscript> or we can use placeholder to signal problems with Java and <noscript> for disabled JavaScript messages. Like that:

<div id="my-jmol">
    <p>You do not have a Java installed</p>
    <noscript><p>And you do not have JavaScript enabled</p></noscript>

Anyway it might not be relevant here.


Gusts Kaksis