On Mon, Jul 16, 2012 at 9:35 AM, Gusts Kaksis <gusts.kak...@gmail.com>wrote:
>
>
> --I'm more than happy to share my experience with issues. Others on this
> list know a lot about this as well. Some of these I'm sure jQuery
> addresses; maybe some (like "a div containing an applet may not ever be set
> to display:none") are less obvious.
>
> Removing the element or setting it to display=none will crash Java, am I
> right?
>
>
Not exactly. MSIE reloads the applet, and you lose whatever state it is in.
> --ChemDoodleWeb.js must not be adjusted -- or if it is, that must be done
> in collaboration with Kevin Theissen (who is probably reading this)
>
> I think I'll go for JME first, which as much as I saw, does not have a
> jQuery wrapper at all, but ChemDoodle is somewhere in between, so it can
> stay as is for now. Only afterwards we'll need some wrapper API (like Jmol
> is now). I just don't understand why it's still called Jmol, if it's so
> much more than just Jmol, it should have been named Online Chem Toolkit or
> something. :)
>
>
Branding. :)
>
>
>> 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, "load \"my
file.xyz\"")">my file</a>
I guess in this context that would become something like this:
<a data-script="load "my file.xyz"">my file</a>
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" '
>
>> 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.
> And so, innerHtml is not the same as document.write, for one, it will
> allow you to fill a specific element from different location in the source,
> where document.write on the other hand writes right in the place from where
> it was called.
>
>
exactly -- JavaScript still creating HTML. Anyway, I agree it is better
practice to avoid document.write.
> 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.
>
>
> 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?
>
> 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?
Bob
> --
> Gusts Kaksis
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Jmol-developers mailing list
> Jmol-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-developers
>
>
--
Robert M. Hanson
Larson-Anderson Professor of Chemistry
Chair, Chemistry Department
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr
If nature does not answer first what we want,
it is better to take what answer we get.
-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Jmol-developers mailing list
Jmol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-developers
