This will be a talk about two small elements on a Web page: the button and the hyperlink. They are small, but very important. Hyperlinks, of course, are the main way people find information on the Web. In fact, they are also the main way spiders find information. Buttons here stand for forms and all they enable.

Both hyperlinks and buttons work, of course, and have worked for many years, but there are gaping holes in what you can do with them. CSS1 and 2 allowed to add some styling to the hyperlink source anchor, but the behavior of the link was hardcoded in the browser: the target replaces the current document. Styling of buttons wasn't defined at all.

In CSS3 we plan to change that. The first steps have been taken and those are the subject of this talk.

Let's look at the button first. There are two questions here:

1. how much of the behavior is style and how much is semantics, and
2. is it better to make a button look like other buttons on the desktop, or style it like the rest of the page?

For the first question, CSS wants to have an answer. The changing mouse pointer is style, the URL of the target is semantics, the border is somewhere in between.

For the second question, CSS prefers to leave the answer to the users. This is something the author and the reader can determine together. CSS provides both possibilites and even mixtures of the two.

The two buttons on the slide demonstrate that mixture. The buttons are still recognizable as

One side of the argument can be summarized as: consistency between sites is more important than the style of a page. People don't visit just one site.

The power of the Web is the amount of information available in a single system. If you know how to use a browser, you can find all of it. If knowing a browser isn't enough anymore, i.e., if the UI metaphor changes from one page to the next, finding information becomes much harder. As you can see when you visit sites that use Javascript or Flash, even when you turn Flash and Javascript on, you either lose a lot of time or get to a dead end: information cannot be compared, cannot be bookmarked, cannot be cut and pasted.

In other words, if you make a button but it doesn't behave like one, or make something that behaves like a button but doesn't look like one, you put a barrier between the user and the information he seeks.

The third point says that half a solution is worse than no solution. If you can make something behave like a push button but not like something more complex, people will have to use some other technology anyway, so they can use that for the pushbutton, too.

If a page has round shapes and the button is square, the page looks unprofessional and readers may even wonder if the button really belongs to the page or is the result of some error.

Different buttons may have different functions, that are best expressed by different colors and shapes. Just like the buttons on a physical device are different one from the other, to help clarify their functions, buttons on the Web should also should also be allowed to differ.

Browsers know HTML and can render it without a style sheet, but the same isn't true of all other formats. To display such formats correctly, the browser needs extra information, such as a style sheet.

A style sheet won't be enough: a button not only changes visually, but normally also does something else, such as submit a request to a server. But the style sheet contains part of the information required.

The more common a function is, the shorter it should be to invoke it. That saves typing and bandwidth.

Also, if the behavior can be expressed as a keyword (rather than, e.g., a program), it becomes possible to automatically infer information, or intercept the behavior and replace it. It becomes higher-level information that allows automation, and no longer requires human intelligence to interpret the behavior as belonging to a certain class.

The new Candidate Recommendation only provides basic support for form controls, but that is still a significant step forward since CSS2, where CSS provided no control over their look and behavior at all.

The module provides support for the situation where you basically want a GUI element such as it is provided by the reader's platform, but with small modifications to the style. Obviously, that means there are limitations over the case where CSS (or SVG or something else) would be used to define the look completely and platform-independently.

In the case of XForms controls, the Basic UI module provides selectors for parts of a control that one can expect to be present in most implementations, while omitting selectors for parts that may only exist on some platforms. For example, you can set a style for the currently selected choices in a selection list, for a radio button that is in the off state, for a control that is currently disabled or for the text that the user typed into a text field.

The 'appearance' property allows the designer to give an element the colors, fonts, borders etc., that the platform would have given to a GUI element of the given type. The designer can also set the color, font, border, background, etc., but their effect may be limited by what the platform GUI toolkit supports. If a button is natively transparent, e.g., it may not be possible to set a background and if a native button uses a color gradient, the color the designer sets may be interpreted as one point on such a gradient.

The 'icon' property associates an icon (image) with an element. The icon can be shown in place of an element, either permanently or under certain conditions. E.g., the browser can use it when dragging & dropping an element or, in the future, it may be used to indicate a collapsed element that can be expanded to show its contents.

The 'cursor' property alread existed in CSS2. It has acquired a few extra values.

Keyboard control is limited to specifying a navigation order. It doesn't currently allow a designer to say which keys on the keyboard have which functions. Maybe that will be possible in the future, but it is a hard problem, given the many different platforms and devices a document may be displayed on.

Navigation order allows the designer to specify the order in which the Tab key (or whatever key the browser uses, if any) visits elements. There are also properties that give for each element what other element will be visited if the reader navigates up, down, left or right (by means of error keys, a joystick, or some such device). In most cases, the automatic algorithm will be fine, but is can bo overridden if necessary.

Since the 'appearance' property tries to allow a designer to use the platform-native look and influence that look, it is tricky to specify. For the designer, what counts is to know that the 'appearance' property changes the font, color and cursor (even though on some platforms you can't see that change on screen). This is important, because any child elements will inherit those properties. The designer can set those properties explicitly and they will be taken into account, if they apply to the platform. Ditto for the background, border, etc., but since they are not inherited, they don't influence the children anyway.

To make sure designers can rely on the space an element takes up, properties like 'margin', 'display' and 'height' apply normally, even though an element might not visually take up all the space (e.g., if the button is circular).

In the future, there will also be borders consisting of images, so if the native look of the platform is not what you want, you can make your own "skins." Be careful, though, your fancy button may look so fancy, that none of your readers realizes it is a button...

If this is the basic UI module, where is the advanced one? There isn't one yet. It consist as a concept only, no as an actual draft. It contains all the ideas proposed but rejected for the basic UI module, plus all the solutions that we don't know yet for problems that we think we should be able to solve with CSS.

E.g., CSS has sophisticated layout models for words on a line, lines in a paragraph and paragraphs in a text, but applying those to a dialog box with various buttons, fields and menus isn't easy. Even table layout isn't quite what you want. The constraints on what moves and what resizes when the window changes size are difficult to translate to the models for floats, tables and absolutely positioned element. We may want to look for a model where sizes and positions are expressed as a grid with contraints, rather than as margins and coordinates.

Key bindings is a, as already said above, a very difficult problem, because it is is more device-specific than the level at which CSS usually operates. Within a single media type, such as 'handheld' there is already so much variation that a simple scheme with fall backs, as for fonts or cursors, is not adequate.

But the interest in highly platform-independent Web-based applications, similar to Java, but that are as easy to create as HTML + CSS, is rising. W3C has organized a workshop for next week to discuss the requirements and opportunities.

With all the attention on animation, graphics, web services, etc., we would almost forget that the basic navigation on the Web is by means of hyperlinks. But hyperlinks haven't improved anything since the almost the start of the Web. Still no stretch text, tooltips are not under the control of the style sheet, no pop-ups (unless hacked by means of JavaScript, which sensible people have turned off).

Hyperlink is an interactive link. A reference to a book in the library is a link, but not a hyperlink, because it cannot be followed instantly. A footnote is close: you can follow the link to read the footnote very quickly, but it is not interactive. Reading hypertext is non-linear reading and going to the target of a link should be almost as fast as going to the next paragraph.

And just like reading, following hyperlinks is free of side-effects (other than acquiring information). You don't buy a car by following a link.

HTML has some crude control over opening a document in a new window, but that is precisely the type of behavior you normally don't want.

All the other attention so far has gone to link semantics (XLink, HLink), not to their presentation as hyperlinks or transclusions. But those aspects (hyperlinks and transclusions) are now on the agenda of CSS3.

Transclusions are the subject of the CSS3 Generated and Replaced Content Module, which we won't deal with in this talk.

You can distinguish three distinct states in the rendering of a hyperlink: before it is activated, while it is being activated (fetched) and after the result appears.

To be effective, the source anchor needs some style that allows the reader to recognize it as a link. That includes fonts, color, decoration, pointer style when the pointer hovers over the link, outline style, when the element has the focus, and possible other changes when the pointer hovers over the element or th eelement has the focus.

The user also needs feedback upon activating the link, to show that the system has recognized his action.

The target will then appear somewhere, which need not always be the same window.

The ':link' and ':visited' pseudo-classes have been in CSS since the start. ':active' was added in CSS2, as was the 'cursor' property.

CSS doesn't control everything, of course. The browser's status line may show information about the link and there may be a "tooltip" as well. When the link is activated, the browser typically also shows some indication that it is waiting for the network, e.g., a spinning globe.

The Hyperlink Presentation Module deals mostly with how the target is displayed.

"Replace current document" is what browsers do by default.

"Make a new window/new tab" is probably only useful for kiosk-type applications, when readers cannot control the browser and may not have a right mouse button. Users will normally want to override this in their user style sheet or elsewhere, so that they themselves create a new window if they want one.

A transitory window is useful for a short explanation or message, e.g., after which the next document will appear in the main window again.

Inserting a document in the current document is one of the original hypertext techniques. If the inserted text isn't too long, the advantage is that the context remains on screen and the reader doesn't have to remember it. When used well, this provides ted Nelson's "stretch text," where you can read a document of the length you want it to be: just the outline, if you are in a hurry; a little longer, if you want to know more; or with all the details, if you are really interested.

[previous talk: Steven, XForms]

[next talk: Dean, mixed mark-up]