Chapter 1 - HTML

We start the Practical Workshop series with a chapter on HTML, which although a broad subject, needs no special hardware and aims to impress.

No assumptions are made about prior knowledge or experience, but you are expected to have already installed Annex-Wifi Basic.

The working principle of the Basic interpreter is to parse through the Annex-Wifi Basic script and execute its instructions.

If the script contains any 'webby' output it is 'served up' to make it available for viewing in any browser on any device that can connect to it.

Web output is viewed in the Output page (opened by default when connecting), but script development and testing is done from the Editor page.

The default HTTP port is 80, but can be changed in the Config page if wished.

Only 1 open port is required because websocket connections share the same HTTP port.

Browsers

Web pages can be a thorny issue because different browsers interpret some of the html and css instructions differently (or ignore them completely), causing the same web page to appear differently in different browsers.

Browse to https://www.w3schools.com/css/css3_gradients.asp

Scroll down a bit until you see Browser Support section. Don't worry about it, but take note that all those browsers interpret 'Gradients' a little differently (the Annex-Wifi Basic meter$ web component uses a green gradient).

They all nearly recognise a common language sufficient to fool a casual glance of most things, but big companies and big heads have big ego's, so they each have their own eccentricities which they try to impose on 'the' world.

I choose to use Firefox because it is the only remaining independent mainstream browser which doesn't have a parent corporate axe to grind... so I feel I should be able to 'trust' it more than corporate honey-traps with vested interests and 'beyond-the-law' arrogance. That's just my personal opinion, but which I need to point out because everything I present here has been developed using Firefox... (Firefox is free, so use it if needed).

Coloured syntax highlighting is great for making the ingredients shine out from the stew. But I find the dim grey flashing cursor is very difficult to locate under the blue haze of the currently selected line - especially on a long line with no clue to its whereabouts - so I often click the tool icon (paintbrush?) to the left of font size to "toggle syntax highlight on/off".

Script Feedback

Annex-Wifi Basic error messages are sent to the serial port AND to the wlog (stands for Weblog) window of the browser editor, which means it is possible to monitor errors either with a hardwired serial port connection OR with a wifi connection, but you obviously need one or the other.

User output goes to wherever the user sends it, which can be Serial or Serial2, or UDP network message, or wlog, or browser web page... this chapter is about html so we will focus on sending output to a web page.

Input

User input can be obtained from serial monitor, UDP network message, web browser, the script, or 'Immediate' window of the Editor page.

Each type of input is read differently, serial and UDP are read using program code, while a script must be RUN, but the 'Immediate' facility allows typing instructions directly into it's window then pressing Enter to read and process them.

This offers 2 forms of console for interacting with an ESP device depending on whether the device is serial hard-wired or wifi network connected.

• • For local console use a hardwired serial port monitor (via your USB) for input and output of non-networked devices.

  • For a remote console use the Editor page Immediate window for keyboard input and the wlog window for output.

Web Console

Each type of output is addressed differently even though the message content may be the same.

If you type "Hello" into the Immediate window then press enter, the wlog window above it will show 'Syntax error' because it is not a valid instruction that Annex-Wifi Basic can recognise.

The message content needs to be 'steered' somewhere recognisable - so type PRINT "Hello" in Immediate and press Enter (which in future will be abbreviated to: Immediately enter 'PRINT "Hello"').

Notice that wlog shows no new error message, and the serial monitor (assuming it is connected) shows your message.

Back in the Immediate window, click the cursor at the end of your PRINT "Hello" entry, then press Enter, then repeat it again.

Notice that your message has been repeated on new lines in the serial monitor.

Back in the Immediate window, Immediately enter wlog "Hello", and notice that this time the message has been steered to the wlog.

The wlog is the browser web log where all browser output code is logged to, whereas the Output page is where the browser output code is actually displayed after being interpreted by the browser.

If you do not yet have a separate Output browser tab or window open, right-click the Output window button and open in a new tab.

Click the 'Clear' button just under the wlog window to avoid any confusion from clutter, then Immediately enter HTML "Hello"

Check that your message was displayed in the browser Output window, then check the wlog entry which shows what code was sent to the browser.

(as things become more familiar you can use the wlog entries to debug why your html is not displaying as intended)

Use the Immediate history again by clicking the cursor at the end of the last entry then press enter, noting the ability to move back through previous Immediate sent message history if wished (so re-typing same messages as previous is not necessary).

Look at how the last message was displayed in the Output window, and notice how subsequent html messages get 'concatenated' to previous messages, unlike serial and wlog messages which by default append a carriage-return/linefeed after them which causes subsequent messages to print to a new line.

This is because unlike most other languages, HTML (HyperText Markup Language) is purely text-based, and not intended for any particular types of output device, so it has no notion of typewriter carriages or keyboard Enter keys - therefore does not use nor recognise any non-printable special characters such as ASC(13) carriage-return and ASC(10) line-feed.

All the diversity of life is coded in gene sequences comprised of just 4 different letters (bases), and those genes do not exhibit their coded traits, they only form the instructions for producing those traits.

Similarly, the output diversity of HTML is achieved using just the standard printable text characters coded into string sequences.

Therefore HTML is not 'WizzyWig' (What You See Is What You Get), it is an abstract stream of text instructions useful for any type of html output device to interpret and 'render' into an appropriate output format, irrespective of display size.

Why so complicated? Actually, it's not so complicated as it appears, once you know how it works...

Think of a travelling magician touring the country putting on shows in tents which are supplied and erected by the local town prior to his arrival.

He won't know in advance the exact size and shape of the tents, and doesn't really care, so long as they meet his specifications of how many seats are required, what size of demonstration area is needed, how much distance between the display table and the audience, what access is needed to the display area, and the minimum space around the display area.

Given that information, the local town will erect an appropriate sized tent, set up the demonstration area, then add as many rows of chairs as are needed to fit in the required number of seats.

That is basically how html works, using a system of matching 'start' and 'end' tags to enclose the specified layout and content details...

<head>

<title>Magic Tent</title>

<style>

colour: red carpet; side aisle borders: 2; display size: 8 wide 4 high; display padding: 1

</style>

</head>

<body>

<p> (The 'p' denotes a 'paragraph' of text) This content represents the required chairs. It does not matter how wide the tent is, because when a row is filled, the content will continue to form the new row, until all the contents are accomodated. A narrow tent will have more rows of fewer tents, and vice versa... which is the same sort of effect that happens to this content if you resize the window... try it to see the effect for yourself.

</p>

</body>

So although the html system looks cumbersome and non-intuitive, it is not actually difficult. It is only daunting because of the large number of different commands available with their appropriate specific syntax... but that is the same when faced with ANY new language (and few others have such a wealth of help material available for them like html does).

What makes html so special is that those few simple plain text characters can provide such huge diversity and capability by the simple means of having some open-ended 'expansion' tags which allows almost anything else to be included.

The <style> </style> tags can specify the styling of any and all content. Small amounts of styling can be included inline with the content, alternatively all styling can be neatly declared in the <head> area, or can be saved into a separate CSS stylesheet.

A matched pair of <script> </script> tags can enclose complete working code snippets from other languages - famously javascript, but also others - thereby offering open-ended power to html. Javascript can alternatively be loaded from an external file.

But don't worry about all of that ... you don't need to become a web developer or javascript programmer to achieve your desired html results, you just need to know a few key tips about how to make things work for you.

And that's what this chapter is all about, helping YOU display YOUR Annex-Wifi Basic web content HOW you want and WHERE you want.

First though, let's demonstrate how Annex-Wifi Basic blurs the boundaries between its built-in web features and internet web content, by using its 'incidental' capability to act as a web server for 'serving' raw web content - which is a triumph in it's own right.

Demo - Web Server