Martin Colebourne

This article briefly outlines the key characteristics of HTML as a technology for creating UIs. (See Distinctive Fingerprints of UI Technologies for a background discussion.)

Note that this is not a complete list and the huge range of libraries and other resources that are available for HTML development mean that the limits of what can and cannot be implemented (or implemented easily) is not fixed. However, this should be a useful starting point. Comments and corrections are encouraged.

CONTROLS

Basic controls are requested using HTML, but actually provided by the browser. This means that the precise behaviour of controls can vary depending on the Browser and Operating System that the page is rendered in.

LAYOUT

• HTML is effectively width-biased, with a floating height, based on the content.
• HTML layout is achieved by tables, or more recently in a similar way by divs. Columns can have fixed or flexible widths. Rows tend to be sized based on their content, with content naturally wrapping to fill.
• HTML will naturally fill the full page width, but sites are often designed to a fixed width in order to simplify the overall layout design.
• Responsive design (where the layout of a page is transformed for display on smaller screens), is typically achieved by designing three separate, but related, layouts. Each design targets a specific range of widths.
• Creating multiple scrolling zones can be done, but is more complex than might be anticipated. This is especially true if trying to create large scrolling tables with frozen rows or columns (e.g. if trying to replicate spreadsheet behaviours).

INTERACTION

• Drag & drop is difficult to implement and the browser provides default drag & drop behaviours that can get in the way (e.g. clicking and dragging an image allows you to copy it to another application by default).
• By default you will get the browser’s right-click menu and it is difficult to implement an effective custom replacement.
• Menus or autosuggest drop downs can’t extend beyond the frame of the window.
• Dialogs are usually rendered as layers, not separate windows. It is relatively easy to allow these layer-based dialogs to be moved via drag & drop, but of course they can only be moved within the boundaries of the window.
• You can spread an HTML app across multiple windows, with actions in one window causing behaviours in other windows, but this is very difficult.
• Subdividing a page with draggable borders is possible, but harder than you might expect.
• HTML doesn’t provide easy methods to dynamically resize windows – e.g. allowing a dialog to resize according to the amount of content it needs to display.
• It would be very difficult to create any form of floating toolbar or inspector window solution.
• You can’t reliably create chromeless windows (i.e. windows that do not have a browser titlebar on them). It is impossible to skin a window with your own visual signature – you can only operate inside it.
• Security considerations may mean that a browser won’t let you hide the address bar or toolbar.

HTML also tends to have some interesting artefacts in terms of feel:

• Clicking and dragging selects content by default with a standard blue highlight.
• It’s hard to avoid the display blanking during refresh. By default, HTML is built as pages and each one loads relatively slowly and with an obvious delay or short period where the display is blank.
• When resizing the window, normal content tends to flow gracefully and without delay. However, more complex layouts can lag, with the rendering of the display struggling to keep up with the changing size of the window.
• By default, many browsers will show the URL of a link that you hover on – e.g. in a status bar at the bottom of the window.
• Working in the browser means that you have to decide how to interact with the back, forward, refresh and other standard browser features like history.