[evsl section [ sectionset 0 [list "html Package"]]] In the now horrendously complex world of html, javascript, css, flash and other plugins it is now necessary to create a layer which completely separates look from implementation on a webpage. Content on the webpage now needs to be viewed as objects rather than as tags with various kinds of stuff attached to them. This html package seeks to achieve this as completely as possible.

Don Libes wrote a Tcl html package which is useful for using a Tcl-style invocation of html tags in Tcl scripts. In a sense it is superfluous and it is just as easy to write the tags themselves because the resulting code provides a direct view of the html being created. This is a statement of the intention - that is you can see in the code what the author intended to be generated. By using the html packge, this reference point is lost and the intent of the author removed.

However, with the addition of css style, javascript and other layers of software technology being applied to the webpage, the code that is required to be generated becomes too complex to read to determine the intent (semantics) and we are forced to express out intent at a higher level. This lever is higher than the html package provides for and so another html package is required that generates code in html, css, javascript and also with reference to available resources in Flash.

This html package views the objects on the webpage as widgets with properties and methods, much as javascript and the w3C DOM do. But with the difference that the html package uses widgets which refect the functional requirements, rather than the underlying tag system.

As an example, the html package has a submitbutton widget with associated attributes. Depending on the attributes specified an <input type=submit ...> or an <input type=image ...> tag with be generated.

Similarly, the html package bundles most of the formating and contextual objects together into a format widget which takes the required tags as attributes. This means that one widget can be used to invoke any formatting type tag for raw html usage (i.e. without using style), while css style can be used to effectively make any of these tags look like any other.

Another type of base widget is used for presenting audio and video media which may be in downloadable or streaming format.

The html package has a collection of content base widgets which relate closely to html widgets. These base widgets seek to combine commonly used properties of css and javascript associated with the use of the underlying tag functionality as well as presrving as much functionality in raw html as is possible. But of more interest the html package has megawidgets which are combinations of the base widgets.

In addition to the content base widgets which represent html features there are also secondary base widgets which provide extra features such as decorative boxes, or additional behaviours such as image swapping. These are not used alone but always in conjunction with the content base widgets either in free association, usually wrapped around the content widget, or in a megawidget which is already part of the html package. [section 0 "The content base widgets"]

[section 0 "The secondary base widgets"] [section 0 "megawidgets"] [section 0 "The skin"] The reason for using the html package is to separate look from implementation. The look gets removed from the functional code to a pagestyle object which describes how each object type or individual object should look. This is like css, but its intention is to be of use for non-css browsers and also to include new objects not recognised by css as well as common Flash objects.

The pagestyle is a combination of css, flash parameters, method parameters and raw html attributes all bundled in together. When a webpage is constructed css stylesheet, Flash objects, html tags are all generated from the pagestyle.

The structure of the pagestyle is a nested attribute array. The top level of the array is a tcl array list of (object, attribute list) pairs. Pagestyle objects are referred to in a manner similar to css usage, the object name followed by a .class or #id qualifier. There is no cascading in the pagestyle object model. Any cascading that occurs will be the result of the css cascade mechanism. Typically there may be a pagestyle(foo) specification and also a pagestyle(foo.bar) specification. If the foo object is invoked with class=bar then the foo.bar spec will be used instead of the foo spec.

The model for this is that when we ask for something we want what we ask for - not something that can be modified by global sideeffects. This could be called the control freak strategy. There are already 2 levels of attribute inheritance at work, html itself and css. Laying a 3rd level on top of this is probably counter productive. In addition one goal of the package is to produce good looking pages that do not rely on css and its cascading properties.

If you want to change any part of the way the page looks, you should be able to do it by changing the skin ( the pagestyle object) [section 0 "The skin-object relationship"] [pagefoot]