To the Web!

by patrick ulland July 17, 2023

We've been messing with a beta version network card for a few years now. Finally, more complex parts are coming back online and we can actually make them on demand. In the meantime, Henry Strickland has nearly finished an entire network library and put it on https://github.com/strickyak/frobio/. Check out the 'built' directory! So it's time to get back on the horsey.

The old Fest demo 'www' was able to manually poke the card to life and render basic html text to screen, at that point Basic09 was out of gas. Strick's library and a little external sweetening replaced about half my original code! So with 10K free and the core features in place, the old demo is being polished into a new app. That is the next blog.

Today's problem is content for the app to display, and I've puzzled out a few things during testing. Providing basic services, like a page of download links, is simple enough. Create a nonsecure (http no s) page. This might be a dead copy of the secure https page newer computers will prefer. If it's 'CoCo tweaked', try to use shorter link text to keep the underlining from stacking up on a CoCo1 or 2. Anything beyond basic formatting (see codez) will be lost, but finding and downloading from links will be possible.

What about content made to be viewed on a CoCo? After all, html's original purpose was universal information exchange. The author/server does not format the screen, only provide text and links as a serial stream. The client formats the display to suit itself, and downloads additional assets (images,media) via a second connection. This is all good for a CoCo, we have 4 sockets and our stock text display can be as large as 106x24.

Or as small as 32x22, so the first thing to do is pull back the reading level of the source material. Horizontally, 'www' only divides by the word. Putting four 10 letter words close together is hard to justify on a CoCo1 (pun intended). In basic editing, reword, reorder, sprinkle a comma or connective so spaces come along pretty often. And they won’t be pretty at first. Character attributes are limited until someone draws a 8x6 web font. All we have is bold and italics, which is not italic, but proportional.

Same problem in the vertical space. It's hard to avoid fullscreenwallatext on a 32 col screen, but give it a shot. The paragraph is our best friend and worst enemy. Authors love wonderfully inclusive paragraphs with hundreds of flowery words. Might even work on direct read through. It will not work when scrolling around. Divide those little essays into intro, body, and conclusion by adding extra <p> tags.

Headers are recognized. Without variable sized fonts, we'll do something unique with all 6 header codes. You'll have to decide if that is a good thing.

The last text solution is HTML tables. We start with screen width divided by number of table columns. Click a column header to view that column full width. Click a single cell to see it as a tooltip. Overlay windows are the bomb!

Now we move fully into conjecture, as the file download stuff is still in progress. The plan for image support runs along these lines. An inline link to an image file will download the named file as expected. Unless the image is very small, it's displayed in a separate window. Unless the screen is very small, WWW will also look for a thumbnail image. Maybe multiple thumbnails so creators can tweak for alternate screen sizes? The 32 col folks see alt text inline in place of a thumbnail.

That covers X,Y and Z alt screens, how about navigation? On systems that support it, www uses 'MultiVue' or windint menus. Shoutout to L Curtis Boyle for fixing a longstanding bug, we have the option to mouse click and choose, or just memorize the <L>etters and ALT-L to do things as we type. Text screen users get a one line menu bar.

The page reader is on can be <B>ookmarked, or <G>oto bookmark from the list. The URL and page title will also be saved to the <H>istory file until user deleted. Finally, any 'hyperlinks' (quaint) are stored in a <L>inks file until the end of run.

The thing we don't have yet is a scrollbar. That requires a buffer to hold the rendered page as you move down. The only current option is reload the page and take it from the top. So for now, page length can be a problem. The workaround is to make shorter pages and rely on the link system to create waypoints.

You'll notice we haven't covered forms yet. Forms are important enough to get a separate process. They will always appear as a new page, on the upside developers can call this module directly from, say, an online game to get user info. Some early thinking in the next section, but we need to know, what do you guys want to see?

Codez

So what does it take to make a web page that can be served by a standard web server and works CoCo1 to Win11? We've found many modern browsers shrink down to 80 columns or so. Proofread your page at this size and it will at least be readable on any CoCo. There is usually no harm in using text attributes the CoCo doesn't have, they are ignored.

What isn't ignored? Our browser uses a tiny subset of vanilla HTML1.1, which is being expanded but will never include java&jscript&activex... Luckily, HTML5 has pulled many external functions back into HTML proper. Some of those tags might be worth adding if we have the RAM.

Current code supports a generic page outline that starts like this:

<html><head><title>The Page Title</title></head><body>

'The Page Title' starts each page and appears in bookmark and link menus. After that you have some 'vertical' basic page formatting:

 to most browsers, a comment. We could hide CoCo specific things here.
<h?>Headertext</h?> where ?=1-6 to make really arbitrary font changes
<p> Paragraph text <b>bold</b> <i>italics</i> </p> most text in paragraphs
<br> newline for more space

<table summary="Text"> - user % width RSN
<tbody><tr><td> ... </td></tr></tbody></table> - column auto width

<a href="formatlink.html"> Links</a>
<a href="#Section_further_down">TFM</a>
<a href="/files/filename.zip"> whatyoucamefor</a>

(RSN) - these are only part coded as of yet.

<img src="file.jpg" alt="some_text">
<img src="file.jpg" alt="some text" width="128" height="64">
Most images are replaced with thumbnails or alt text and displayed
in a separate window.
If image size is specified, full image appears inline if screen allows.
If an image tag inside a paragraph, flow text left or right of thumbnail/image.
If an image tag outside a paragraph, display left/center/right in whitespace.

<form action="/doPage.bin" method="get">
<label for="fname">First name:</label>
<input type="text" id="fname" name="fname">
<input type="checkbox" id="vehicle1" name="vehicle1" value="Bike">
<input type="radio" id="html" name="fav_language" value="HTML">
<input type="hidden" id="custId" name="custId" value="3487">
<input type="reset">
<input type="submit" value="Submit">
<select>
<label for="cars">Choose a car:</label>
<select name="cars" id="cars">
<option value="volvo">Volvo</option>
...
<option value="audi">Audi</option>
</select>
</form>

So that's it for now. Obviously, this first crack at CoCo HTML is a bit lame. Also obviously, there isn't room to add everything. What would help the most? Should we use html comments to add CoCo 'sugar' like 32 column screen hints? Ideas wanted!