2.0

This is the 2.0 release that incorporates several weeks of effort and improvement. Here are some highlights of this release:

• Added a full screen mode and user interface.
• Various parts of the website were broken out into individual WebComponents. These components are now hosted in a separate repository.
• jQuery is no longer required.
• Major code restructuring and refactoring for legibility and clarity.
• ECMA 6 classes used when appropriate.

One notable change is that the use of .wiki files in the 1.x series has been replaced with .html files for individual articles (wiki formatting is still used within a DIV on the page). Although this change increases the amount of boilerplate code that is required, it does solve several problems present with the original approach: it does not require server side URL rewriting and is fully compatible with search engines. The current approach also vastly simplified the internal implementation of the navigator.

Final in 1.x Series

Original Design (this release)

This is the final release of the original design which consisted of a single HTML landing page and several non-HTML ".wiki" files. This design relied heavily on JavaScript to retrieve ".wiki" files via XHR and format them in an iframe. Because this behavior mimicked an embedded web browser, albeit for special ".wiki" files, it was nicknamed the "retroweb-browser".

This design had an advantage of making the ".wiki" files simple and uncluttered, but required complex JavaScript and server-side processing to allow a single landing page to present itself to the user as a collection of pages. The illusion was effective, but had several technical disadvantages:

• It was potentially unfriendly to search engines
• Required the use of server side URL rewriting rules
• Required complex JavaScript to manage the browser address bar and browser history
• Required complex URL parsing magic to allow bookmarking and hyperlinking of individual "pages"

One of the initial goals of the retroweb-browser was to allow ".wiki" files to be hosted by third-party sites, but restrictions on cross-origin resource sharing (CORS) made it unlikely that a retroweb-browser web app hosted on one site would be able to reach content outside of that site.

As such, it is the author's opinion that the original design cannot meet its goal and should be replaced with a simpler design that addresses the many disadvantages.

Future Design (branch wikiToHtmlConversion)

Subsequent releases will replace each ".wiki" files with a seperate, independent ".html" file. This will unfortunately require the addition of some boilerplate HTML to each page, but this will be kept at a minimum. The current wiki formatting will be preserved inside a custom HTML tag which will be processed and rendered by JavaScript.

Since each .html page will have the corresponding wiki content inside it, this content will be accessible by search engines. Bookmarking and hyperlinking will work naturally (as each article will be a real, separate web page) and there will be no need for special server-side URL rewriting or complex client-side address bar manipulation.

Original design

Original Design (this release)

This is the final release of the original design which consisted of a single HTML landing page and several non-HTML ".wiki" files. This design relied heavily on JavaScript to retrieve ".wiki" files via XHR and format them in an iframe. Because this behavior mimicked an embedded web browser, albeit for special ".wiki" files, it was nicknamed the "retroweb-browser".

This design had an advantage of making the ".wiki" files simple and uncluttered, but required complex JavaScript and server-side processing to allow a single landing page to present itself to the user as a collection of pages. The illusion was effective, but had several technical disadvantages:

• It was potentially unfriendly to search engines
• Required the use of server side URL rewriting rules
• Required complex JavaScript to manage the browser address bar and browser history
• Required complex URL parsing magic to allow bookmarking and hyperlinking of individual "pages"

One of the initial goals of the retroweb-browser was to allow ".wiki" files to be hosted by third-party sites, but restrictions on cross-origin resource sharing (CORS) made it unlikely that a retroweb-browser web app hosted on one site would be able to reach content outside of that site.

As such, it is the author's opinion that the original design cannot meet its goal and should be replaced with a simpler design that addresses the many disadvantages.

Future Design (branch wikiToHtmlConversion)

Subsequent releases will replace each ".wiki" files with a seperate, independent ".html" file. This will unfortunately require the addition of some boilerplate HTML to each page, but this will be kept at a minimum. The current wiki formatting will be preserved inside a custom HTML tag which will be processed and rendered by JavaScript.

Since each .html page will have the corresponding wiki content inside it, this content will be accessible by search engines. Bookmarking and hyperlinking will work naturally (as each article will be a real, separate web page) and there will be no need for special server-side URL rewriting or complex client-side address bar manipulation.