Presented at Opera Software
Oslo, 15 August 2001
Opera under Linux:
CUAP = Common User Agent Problems
Explains what a user agents (browser or otherwise) should do, given the current state of the art on the Web. A very interesting list of things, highly recommended. This talk is a sort of complement: it talks about the future, and some of the presented ideas are still questions.
What one might like to be able to do with CSS
There are some suggestions for doing this in the draft of the CSS3 Box model.
Expanding text can literally expand the text (as in traditional hypertext systems, such as Xanadu and Guide), but it could also create overlapping text, similar to rollovers or drop-down menus (by means of CSS absolute positioning).
Pop-ups can be used for small things, that don't merit a complete page, but that do not belong in the first page either. For example, the link "read more" could pop-up a small dialog with five subjects from which you can choose, and after clicking on one of them, the pop-up disappears and the chosen subject appears in the main window.
Confirmations can be used for little warnings: "This computation can take several minutes. Do you want to continue?" or "This message is there just to annoy you. Do you still like us? (If you say no, we won't let you leave.)"
Discussion still open...
Two possible syntaxes: CLink (implemented by Opera) and @link (neither yet complete)
There are some formats that don't use XLink (HTML, WML) and there are URIs in other formats that are not marked with XLink attributes (RDF, any Namespace URIs). If the UA only expects to handle a few well-know formats, it could have information about those links hard-coded (as browsers currently know about <a> in HTML).
On the other hand, most links, even with XLink, have a fairly simple structure, and two or three CSS-like properties could capture them. If UA's don't expect to handle very complex links, implementing those properties would allow them to handle HTML, WML, and everything with XLink, without having to hardcode any knowledge about those formats or about XLink.
Apart from efficiency and ease of use, there is the more fundamental argument: how much about a link should be considered structural and how style? Is the URL the only thing that needs to be in the mark-up, or are the other attributes of XLink also part of the structure?
Note that the CSS selectors ':link' and ':visited' are independent of this discussion. They selects anchors, independent of how the UA knows that it is an anchor.
Why is it so hard to do this?
Travel . . . . . . . 3070 Hotels . . . . . . . 845 Food & drink . . . . 198 Miscellaneous, including presents . . . . . . 80
I would like to simply do this:
span.amount {tab: 100% right / ". "}
There are several reasons why tabs are better in this case: the aligned elements don't necessarily form a complete column, tables don't allow leaders and tabs are easier than turning the elements into table cells with 'display: table-cell'.
A right aligned signature on the last line of a paragraph is quite easy to get with tabs: 'signature {tab: 100% right}
From CUAP:
Allow configuration to highlight (e.g., graphically, through audio cues) the target location. Ensure that highlight mechanisms do not rely on color alone and are distinguishable from other highlight mechanisms.
In CSS3 (see Selectors):
*:target {text-decoration: blink}
What one might like to be able to do with a browser
... and of targets in a document
1994 paper
From CUAP:
allow users to "flush" [...] authentication information on request.
One can logout from a computer and login again under a different name. The same should be possible with a Web site.
From CUAP:
user agents should interpret them in useful ways. For instance, the start, next, prev, and contents link types may be used to build a table of contents, or may be used to identify the print order of documents, etc.
These links are better than navigation bars encoded in the document body, because
Lynx and navipress/aolpress implement(ed) them, but Mosaic and its descendants have always ignored them.
What services one might like to access with a browser
But the best would be a Freenet-like system that used HTTP.
You don't want to upload a file to a server to publish it, just dropping it on your browser should be enough to make it available to the whole Web. Inventing a URL for a document should also not be necessary. The URL conveys very little useful info. It is much better to describe the document with some metadata (the more the better) and use that to identify and link to the document.
Annotea is an RDF-based annotation system, built into Amaya
From CUAP:
If the user wants to save a resource locally, the user agent should respect the system naming conventions for files (e.g. PNG images usually have a .png extension).
Many URLs end in "/", ".pl" or ".cgi", but they are not directories, Perl scripts or CGI scripts...
When I asked Håkon what his colleagues would be interested in, he suggested that I explain why I prefer Konqueror over Opera. That's actually quickly explained, and some of it has to do with the unfinished state of the Linux version of Opera. Here are the main points.
But I'd like to take the opportunity to talk about what I would like to see in a browser, any browser, not just Opera. Some of it is details, that don't require any new technology; some of it is what I expect (or hope) the Web to become in the future.