Background-related propositions

Complementary background-related propositions.

There are a number of proposed extensions to HTML which complement the algorithmic texture proposals outlined elsewhere on this site.

These include:

Background watermark images and logos.
Edges and borders.
Background tables.
Structural proposal.

Background watermark images and logos.

It is common for background images on the web to contain company logos and pictorial information in addition to a texture.

With the use of algorithmic textures, this is not so easily realized. The solution is to allow multiple layers of backdrop images. Using this method has some advantages and disadvantages.

Advantages:
- Bandwidth efficient: as the texture is specified algorithmically, the watermarked image can often be a largely transparent image with a small number of pastel colours. Such images can be compressed extremely efficiently.
- Flexibility: images can be places singly, aligned with any of the edges of the document, repeated in lines, or tiled (with left, right or central alignment).
- Appearance: Images are no longer forced to align with the tesselation pattern of the backdrop texture. This reduces the effect of any repetitive patterns involved. The 'repetition rate' of the image may also be made very large if required, as the background of the image may be made transparent, it can take up no space and use no bandwidth.
- Edges and borders become more practical with the ability to use more than one layer of backdrop.
- Gimmick: animated images on the background become much more practical in terms of bandwidth, and speed of redraw on the part of the browser if the images are small and widely spaced.
Disadvantages:
- More complex: the quantity of code required in the browser to render the background increases.
- Slower: as more than one layer of background is involved, the browser needs to redraw each layer before rendering any content. It is possible, if the textures repeat rate is a small multiple or divisor of the size of the backdrop image, to eliminate this process at the possible cost of cacheing a larger area of the background.
- Like an ordinary backdrop, background watermark images should be loaded after most of the page has been redrawn. This means they will not be able to appear immediately on top of the algorithmic texture.

Details: the background image could be implemented in two possible ways: see the structural proposal for details of the short- and long-term options.

Edges and borders.

Possibilities for implementing edges and borders emerge very simply and easily when more then one watermark background image layer is allowed.

Edges are simply an image aligned with one side of the window and repeated along it.

Borders are edges along all the window's sides with the possibility of including additional corner images to improve the appearance of these. With the addition of the HFlip and VFlip <IMG> tag attributes, these can be transmitted very rapidly indeed.

Most people with 21" monitors are painfully aware of the shortcomings of the commonly used method of putting a stripe down the left-hand side of existing web pages. This method uses a very wide image, and hpes that it is wide enough for the next horizontal tesselation to be off the right-hand side of the browser's window. Using GIF compression, this blank area of the image is not too expensive in terms of bandwidth. Using this method means that the main body of the web page cannot have a proper background, however.

Background tables.

To provide the ultimate in flexibility of placement of images on the backdrop of web pages, the use of a protocol similar to the table is recommended.

As algorithmic textures may be generated inexpensively, it becomes possible to have chequered backdrops and mozaics as backgrounds with very little additional complexity.

Images may be placed in these backdrop cells as required.

Structural proposal.

When backgrounds were first introduced into HTML by Netscape, they chose to add the specification of the background in to the <BODY> tag as just an attribute. This did not introduce any immediate complications and seemed painless.

When it was realised that a background implied a number of other attributes, namely those that specified the colours of text and links on the specified background, these were also added in.

In order to hasten the adoption of the algorithmic texture proposals presented here, these too have been presented as simple attributes to the <BODY> tag.

However, the body tag is getting crowded. As a simple example of this the body tag of this document reads: <body background="bg/g.jpg" text="#FFFFFF" bgcolor="#101010" link="#8080FF" vlink="#4040C0" alink="#FF4040">. There already exists a BGProperties attribute to the <BODY> tag, and things look set to become more complex still.

All the proposals presented in this document could be implemented as additional <BODY> tag attributes. However, this is a short-sighted approach. As HTML's syntax has evolved rather than being designed, one has to careful not to allow restrictions in previous design elements to influence the future evolution of the standard.

To avoid the standard getting trapped in a syntactical straitjacket, it is proposed that the complexity of backgrounds is recognised, and that measures are taken now to create space for future developments along the lines proposed in this document.

In particular it is proposed the a new section be added to HTML. This would go between the <HEAD>...</HEAD> and <BODY>...</BODY> sections and would be called the <ENVIRONMENT> </ENVIRONMENT> section. This new tag pair is designed to contain among other attributes, information about how the page's background is to be displayed.

In order to maintain backwards-compatibility with existing browsers, and to enable these to fail gracefully, there are a number of factors which deserve consideration.

The natural syntax for the background watermark images and edges and borders described here would be to use the vanilla <img> tag and provide this with VRepeat, HRepeat, VFlip and HFlip attributes.

This natural syntax would have a disadvantage for browsers which were not aware of the developments described here. These would ignore the <ENVIRONMENT> tags, but may display the images designed for the background despite the fact that they are outside the file's <BODY> tag. All browsers tested behave in this manner, and it does conform to the existing specifications.

In order to maintan backwards compatablility, there are two main options:

Use new tag names for the commands involved;
Place the commands involved inside comments.

Although the first option is neater in some ways, there is some historical precedent for following the course signified by the second option. This is what is often used (for example) to stop JavaScript from being interpreted by browsers whose parsers are unaware of the <SCRIPT> tag.

Perhaps a more relevant example would be from the <STYLE> tag, used to describe style sheets.

Traditionally, UAs have silently ignored unknown tags. As as result, old UAs will ignore 'ENVIRONMENT' elements, but its content, in the region delimited by the <ENVIRONMENT> / </ENVIRONMENT> tag pair, will be treated as part of the document body, and rendered as such. During a transition phase, 'ENVIRONMENT' element content may be hidden using SGML comments ().

When the 'ENVIRONMENT' element is declared as CDATA in the DTD, conforming SGML parsers will not consider their contents to be a comments destined to be removed.

This has the advantage that existing commands may be freely used. The main difference in interpretation of the commands would be to the <IMG> tag attribute align, if set to align=bottom or align=middle. In order to position the watermark image aligned with the bottom edge or the middle of the document (which is how these commands should be interpreted in this context), the whole of the HTML page has to be downloaded and parsed before any such background images are displayed.

The format for algorithmic textures would then be to use the algorithmic texture commands inside the <ENVIRONMENT> tag, and to place the default bitmap in the <BODY> tag to maintain support for old browsers. If algorithmic textures are available, then of course these will take priority over any bitmaps. provided. It is not necessary for the browser to support some kind of altimg tag X-Src, or LowSrc attribute for this to be able to operate.

To <IMG> tag proposals | To <BODY> tag proposals