> The source code for > http://jmol.sourceforge.net/tracedemo/ > > has "mayscript" as an attribute with no value. > It is (should be) common practice nowadays to validate all HTML using > eg Tidy (or even better a schema based validation, which Jidy > emulates) I feel properly chastized :(
I suggest that you use mayScript='true' I will adopt this in my pages. > Doing so of course immediately tells one that mayscript is not a > valid attribute of applet (according to the XHTML schema). Hmmm ... Houston we have a problem. I just took a look at the W3C specifications ... and mayscript is not listed as a valid attribute for <applet> tags. (Of course, the <applet> tag itself is deprecated, but we won't go there :) But I assure you that I did not make it up. It has been a real thorn in my side and I wish it did not exist. All the documentation for LiveConnect and all the articles I read on the web make reference to this tag. And emperical evidence shows that, on at least some browsers (especially the Netscape browsers), you *cannot* call JavaScript from Java without it. > If it were, it > would have to have a value, as shown below. Does your code handle the > "correct" way of expressing it? Yes, as I mentioned above, I suggest mayScript="true" > Is the presence of mayscript imposed by the browser? I have not done an exhaustive search. But - I *know* that NS4 does not work without it - I *strongly suspect* that IE does not work without it (I tried it but I don't remember the results) - I *think* that modern releases of Mozilla require it > I ask since if there is any way at all of not having > it, we should, since that would then enable users to write absolutely > valid formal XHTML (which they could not if they include it). I may be wrong but ... I tested this once upon a time, and I think that if you write valid XHTML that it will not work on some old browsers. My recollection is that if you terminate tags with the terminating slash that some old browsers don't work. As in: <tag .... /> I know that I stopped putting in the terminating slash because some old browser I was using did not accept it. *Please* educate me on this, because I want my example code (and the code generated by chime2jmol.pl) to be clean. But it is more important to me that it work on old browsers. (That is why I have been using <applet> instead of <object>) > Also, any more thoughts on how we might pass in-lined CML to the > applet in a valid way? I have learned a few things about parameters that are passed to applets. The problem I was trying to solve is that newline characters get removed. I cannot find the reference right now, but about a month ago I read some "specification" which explicitly said that, within the context of a quoted attribute value, 'carriage return should be replaced with space and newlines should be removed'. I went looking for this specification because I was having problems passing multi-line scripts and simple .xyz files as parameters. What I observed is that all the browsers were indeed ripping out the newlines. The solution for the scripts is to enforce semicolons as statement terminators. My plan for chemical models is to say that the backslash character gets replaced with newline characters when I read the model in. So, getting back to your question ... CML This would be a kludge but ... if you want to pick another pair of characters I could easily change them to '<' and '>' as I read in the inline model. What is the interest in 'inline' models anyway? I don't understand the attraction/value. > The obvious way would be to escape the < etc > first. The example at http://jmol.sourceforge.net/applet.html > is of course formally invalid XML (its amazing any browser allows > it). Now, I'm not an XML guy but ... It seems perfectly reasonable to me that it would work with the < and > characters within the double quotes. I don't think they should be messing with the contents of *my* string ... that is what the quotes are for. But remember that I am already upset that they are ripping out *my* newline characters within *my* quoted string, so I guess I shouldn't be surprised that they want to rip out *your* angle bracket characters from *your* quoted string :) > One might think the formal way is to include the CML with its > own namespace, which would avoid validation clashes with HTML (use > openbabel > -x1n or -x1an to generate namespaced CML) but I think the browsers > simply would not handle this, or pass it to the applet. They are > simply not able to handle "datuments" (ie multi component documents) > (or am I wrong? Perhaps Mozilla can, since at one stage it was meant > to be able to handle SVG as a component, along with HTML). This is well beyond me. > > Peter, any thoughts? > > Old: > > <applet name="jmol" code="JmolApplet" archive="JmolApplet.jar" > width=400 height=400 align="LEFT" mayscript > > <param name=emulate value=chime> > <param name=load value=1crn.pdb.gz> > </applet> > > Tidied: > > > <applet name="jmol" code="JmolApplet" archive="JmolApplet.jar" > width="400" height="400" align="left" mayscript="mayscript"> > <param name="emulate" value="chime" /> > <param name="load" value="1crn.pdb.gz" /> > </applet> I agree that this is more tidied. I would prefer mayscript='true' What is the XML recommendation on the case of attribute names ... I have been thinking of switching to 'mayScript' instead of 'mayscript' ? So, does 'tidy' not complain about mayscript not being officially recognized by w3c? Miguel > > -- > > Henry Rzepa. Imperial College, Chemistry Dept. > +44 0778 626 8220 +44 020 7594 5804 (Fax) -------------------------------------------------- Miguel Howard [EMAIL PROTECTED] c/Pe�a Primera 11-13 esc dcha 6B 37002 Salamanca Espa�a Spain -------------------------------------------------- telefono casa 923 27 10 82 movil 650 52 54 58 -------------------------------------------------- To call from the US dial 9:00 am Pacific US = home 011 34 923 27 10 82 12:00 noon Eastern US = cell 011 34 650 52 54 58 6:00 pm Spain -------------------------------------------------- ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php _______________________________________________ Jmol-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-developers
