after numerous complaints (discourse) about the html-code that's exported by processing not
being web standards compliant i decided to do some testing. results show that <applet> can
and should be replaced with <object> for upcoming releases.

detailed report is here:
http://bezier.de/processing/xhtml/

here are the templates i used for testing (will attach them here too):
http://bezier.de/processing/xhtml/applet_templates.zip

F

edit]
xhtml-1.0-strict and transitional templates for export-to-web

4 templates:
<applet> xhtml-1.0-transitional (almost valid)
<applet> for openGL xhtml-1.0-transitional (almost valid)
<object> xhtml-1.0-strict
<object> for openGL xhtml-1.0-strict

is there any benefit to keeping the <applet> version of the tag instead of
using <object>? from your notes it appeared that <object> worked as good or
better.

once we figure it out, we can include these shortly--it's a separate issue
from the loading stuff which is why i wanted to separate. this is more
straightforward, the loading is more experimental.

> is there any benefit to keeping the <applet> version of the tag instead of
> using <object>? from your notes it appeared that <object> worked as good or
> better.

right, better actually.

well, the files with <applet> are a bit smaller and easier on the eyes (editable for
beginners).
<applet> does not set a minimum java-version, so if a lower version than 1.3 (processing
minimum) is installed the applets should just fail, right? i actually think that's bad. with
<object> i've set the minimum java-version to 1.4.2 for IE-win, that forces a win user to
run at least that version. did that because it introduced the load-icon and bar ... haven't
testet my <object> with a lower java-version though. my test-setup was: no java, java
disabled and 1.4.2 (on both linux and win-xp).

> once we figure it out, we can include these shortly--it's a separate issue
> from the loading stuff which is why i wanted to separate. this is more
> straightforward, the loading is more experimental.

sure, got that ... i think it's ready for prime-time

re: the auto-install cab stuff, see bug #181, which includes a link to the
.cab file for a more recent java 1.4.2. for now, we should use 1.4.2_09,
which is what's currently included on macosx, and therefore it's what we
include with the default java download.

apple will be updating Java 1.4.2 and Java 5 momentarily, at which point
we'll roll over to that release of 1.4.2 on the Windows download as well.

re: minimum version, 1.4.2 is correct as you assumed, and i think we're
gonna kill off support for anything before java 1.4. it takes too much time
to deal with it, and we'd be better off supporting 1.5/1.4 better (and god
forbid, 1.6). for people not using windows, is there any way for us to
catch this in the html code rather than having the applet load "broken"?
there's still 10-20% of the web that are using java 1.1 (though i guess
that's windows) and older versions of firefox (and really crusty safari)
that use java 1.3.

and we'll get rid of the applet tag. the 'editable' thing isn't as
important as compatibility and things being solid. it's not as though
embedding other stuff with the object tag (i.e. flash or specialized video
plugins) is any prettier.

super. bye-bye <applet>, hello <object>!
i will make update the templates later today.

edit]
new templates for export to web

altered the .cab line inside the <object> tags to match the version in bug #181

are you confident that these are tested thoroughly enough that they should
go into a release?

0124 is all about bug fixes, and this is 60% feature 40% bug fix. i'd like
to include it if it's ready to go, however.

well, the original version i posted is tested on 28 different setups. all platforms (on virtual pc
though) and all most popular older and current browsers. but if you wanna make super-super-
sure, give me a week, than i'm gonna be back in frankfurt and can do some more testing (on
real, not virtual pcs).

btw. this would be great to include too into the next version. fixes the encoding problem
(umlauts & co) with the descriptions / comments:
http://dev.processing.org/bugs/show_bug.cgi?id=474

edit]
version 3 of the applet.html templates

xhtml-1.0-strict and xhtml-1.0-transitional templates for export-to-web,
version 3

changed to latest java 1.4.2_12 .cab auto-update files for windows, changed
some css in the transitionals.

ok. i did a lot more testing and still the <object> templates give better results in many cases
(mostly for fallbacks, installs). so, i think they are ready for primetime.

F

we need it to just be 1.4.2_09 so that it's identical to macosx and linux,
at least until apple updates 1.4.x (should be any week now). but once we're
set with that, i'll make them part of 0125.

edit]
same as version 3, except for jinstall_1_4_2_09 .cab files

ok. attaching a 1_4_2_09 version for you.

is there any specific reason to use 1.4.2_9 related to Processing besides
having the same version on all platforms?
because the version set in the .cab file is only relevant to explorer on
windows. any other browser will just ignore it (they use the outer <object>
tag). it's the version we offer people to install if they don't have java at
all.
just wondering ...

having the same version on all platforms is extremely important, there are
too many versions of java, and too many platforms. this is one way we can
attempt to minimize the ridiculous matrix of machines that i have to support.

k, sorry, had to my mind on this one. we just found a bug with older
versions of 1.4.2_xx so i think we're better off updated to _12 after all.
it's also what osx will be running once apple's "release 5 for java on os x
10.4" comes out of testing. so i'll use the previous version, and maybe
move 0125 to _12 as well, in hope that apple will get things updated soon.

alright, now added for 0125, going with 'strict'. thanks for all your help.

btw, please test! we're messing with lots of stuff like this for 0125, so
we need to avoid it being a total disaster :)