This section lists all versions of webProg3, together with any relevant release notes.

In general, you should try to use the latest version if you can, because it is likely to contain bug fixes and improvements. However, it might be that the latest version becomes incompatible with the (old) version of Firefox you are using for example, and you would prefer not to adopt the "latest and greatest" just yet.

Versions are listed below according to release date. Just click on the date link to execute.

Although its products should run on any browser, webProg 3.383 has to use Firefox only. Why is that? Why can't you run it in Chrome for example, which is a highly popular browser?

In fact, webProg3 was produced on Google Chrome as well as Mozilla Firefox, until two showstoppers were encountered in Chrome. It seems that Google have had problems with their editable DIVs for years in one way and another, and that the problems have not ever been entirely resolved. In webProg3, the "Code Editor" was originally an editable DIV, but after opening it, if you tried to actually do any editing, the browser would go into an endless loop. So I exchanged the editable DIV for a textarea, and the same thing happened! After many days trying to diagnose the problem, I found the cause: the Chrome spell checker! If I turned off the spell checker, the problem disappeared completely. But of course I couldn't ask my users to turn off their spell checker, just to use WP3, could I? The second showstopper was the usage of the hacked Rich Text Editor described above. Using pixels to define the font size, employing the best hack I could lay my hands on, just does not work at all in Chrome. Pity.

Please note that in order to preserve the smooth running of webProg3, you should increase the quota of domain storage available in Firefox. If you do not do this, Firefox will run out of sufficient memory sooner or later, and all sorts of unexpected behaviour and/or stoppages will occur. It is quite easy to do, and all you have to do is follow the instructions here in the webProg3 Help.

The FULL HELP has been updated with details of the new builds, but it is also worth looking back at the previous notes given in the Javascript/JQuery Tools & Tips section for a better understanding.

Build 3.391, although it has some officially deprecated content, currently continues to work just fine.

So please use it if you prefer, but do give build 3.421 (below) a try as well. Its products should be perfectly compatible with whatever you have produced so far, and you might find that it has a few advantages.

There is an important addition to the main app. Although previously it was able to produce PC-Friendly and Printer-Viewport-Friendly scripts, it was only able to upload Standard scripts, so "friendly" scripts had to be converted first, using the "Defriendify Utility" if necessary (see the Javascript/JQuery Tools & Tips section). ["Friendly" just means that the script uses VW (Viewport Width) units instead of fixed PX (pixel) units so that it can adjust automatically to the size of the screen/printer port it is displayed on.] The Defriendify Utility has now been EMBEDDED in the main app so that PC- (but not MOBILE-) friendly scripts can be uploaded directly. You just need to make sure that the widgets of your PC/Printer Viewport scripts OCCUPY THE ENTIRE WIDTH OF THE EDITING SCREEN in some way, if necessary by providing an invisible text widget on the right-hand side which touches the 1920 pixel mark.

03/04/2021

Changes to Firefox, specifically to the "close.Window" spec, caused webProg3's main page to disappear after loading images, editing text, and so on, making the program unusable. Build 3.391 restores WP3 to a usable state.

30/09/2025

Build 3.421 has been produced in anticipation of possible future failures as a result of official deprecation and lack of support, particularly with regard to the Rich Text Editor which was based on the so-called "execCommand". The new Rich Text Editor is entirely independent of the execCommand. It has a few advantages too. You can now produce text boxes with rounded corners! Hitherto, upon re-editing, you had to be careful to remove any links you might have inserted in the text first, in order to avoid creating a mess of the HTML. No longer! If the Editor finds any links in the text, they will be removed automatically, but of course they can be introduced again afterwards if required, as before.

13/08/2020

Version 3.383 is generally stable.

However, for reasons which are largely out of the author's hands, the Rich Text Editor remains problematic.

Originally, the Rich Text Editor was published by Mozilla as an example of how to deal with rich text, using what is known as the "execCommand". Even up to the present time, this is the only way rich text can be produced, but it is hopelessly out of date. That is why apparently all rich text editors on the world market are so limited. Nevertheless, in previous versions of webProg, even with the extension of providing Google fonts in addition to system fonts, and sticking to the 7 font sizes made available by the execCommand, the Editor worked satisfactorily. For example, font size "5" displayed the text in similar fashion over all browsers. So much so, for example, that text "links" for navigation were entirely unnecessary: all you had to do was place a hotspot on top of the words to be linked, and the position was sufficiently correct. But alas, no longer! Displaying rich text with Google fonts of a given size renders completely differently among the browsers!

So in order to provide a decent RT Editor for WP3, it had to be hacked, citing PIXELS for font sizes rather than just the numbers 1-7 which is a VERY old way of doing it that has been deprecated for years. Thus, using pixels, the size of whatever font is the same in all browsers, but it comes at a cost. It causes the editor to become unstable. The best hack available (?) has been used, but it is not sufficient.

Consequently, if you use the webProg3 Rich Text Editor as simply and modestly as possible, you can avoid trouble. This entire web site was created with its use. And usually, if a problem occurs, you can find a workaround. Also, the fact that problems with the RT Editor provoked the production of the Link Editor is a distinct advantage. Nevertheless, at this moment, until the browser producers get their act together and give us a method of producing truly rich text that is compatible with their browsers, the carefree production of rich text in webProg3 remains in limbo. So save your work frequently!

23/10/2020

Build 3.386 includes an extension for the production of mobile-friendly web pages.

This upgrade increases the power and versatility of webprog3 quite considerably I believe, in a way which is quite simple.

Check out the details in the Full Help!

To bring the bugfixes described above into effect, please empty the webprog3 site cache and re-load the main editor. The build number is now 26.7.

A more convenient Rich Text Editor for 2026 is on its way.

The main editor of 30/09/2025 has undergone two bugfixes in order to avoid difficulty after the user has cleared the webProg3 site cache:

1. Previously, the grid would not appear and the operator needed to reset the height value in the Grid menu in order to get it to appear. This should no longer be necessary. After clearing the site cache, the main editor's grid should appear immediately with a default value of 10000 pixels. Subsequently, the value can be altered in the menu again according to need.

2. Previously, clearing the site cache was able to change the default canvas colour from white to black, and a background colour of "#0" instead of "#ffffff" could escape into the page's output script. This has now been fixed. Whatever you choose in the "Background Colour..." menu should appear correctly in the output script, and if the menu is not used at all, then the default colour of white ("#fffffff") should be used automatically upon output.

When uploading PC-friendly scripts into the main editor, the Defirendify routine was able to reject perfectly valid scripts on some occasions, in which case the operator needed to defirendify the scripts in the independent Defriedify Utility to make them acceptable to the main editor. This has now been fixed. If PC-friendly scripts contain a widget (even an invisible dummy) on their extreme right-hand side, the main app should accept them without further ado.