CUAP Note Comments


The CUAP Note was written to track some of the few errors made in the implementations of user agents (browsers, etc.). The first draft version was written by Hugo Haas. It was completed and written jointly with Karl Dubost and Ian Jacobs. The note is not exhaustive, but we try to track the comments and may give a new version in the future. The Note would have not been possible without the help of the whole W3C Team.

The comments address the version:

A French translation of the note is available at

Bugs in the CUAP Note itself ;)

We may have bugs in the CUAP Note itself, let us know. But please, double check before.

Comments about CUAP

List of received comments.

Old checkpoints

1.11, 1.12, 1.13, 3.4

Koen Holtman <>

Allow configuration to highlight (e.g., graphically, through audio cues) the target location.

Michael Harings <>

1.5, 4

reference instead of referencing RFC 1717 and the IANA registry. I don't mind the reference as such, its just that its never stated very specifically what the processes are.

Michael Mealling <>

3.5 multiple DNS

that seems a bit quick for me : you could add reference to the libwww implementation, which not only do what you are recommending, but check the response time of all ip address and sort all the address to get the best one. linking to our open source implementation is quite a good example about how to use the right way

Stephane Boyera <>

3.6 supported media types

Point 3.6 in your note says to only list supported media types in an HTTP Accept header rather than just listing '*/*'. While this is a step in the right direction, it conflicts with your point 1.3 (Allow the user to retrieve web resources even if the browser cannot render them).

Often a server will not return an content type if you do not advertise that you handle it. Thus, in your example where a server prefers to send SVG instead of PNG, the user would get nothing if the browser doesn't understand any of the available content types (SVG and PNG in this case).

So, OmniWeb ( sends a Accept header that has '*/*' at the end, after all of the supported content types. This way, the server is free to send us something which we can then allow the user to save to disk to process with some other tool.

Even if you don't agree with this approach, you might want to update your Note to present the problem and whatever approach you prefer.

It might be nice if, in addition to Content-Type, there was an 'Available-Content-Types' header that the server would return allowing the user to bring up a context menu on an item to switch content types in this case. Thus, if they have a PNG viewer as an external program and their browser doesn't understand PNG or SVG, they would have some means to get the PNG representation of the object rather than just getting the SVG version.

"Timothy J. Wood" <>

New checkpoints

If the browser traverses a redirect, it should remember both the original URI and the target URI for marking links as visited.

Martin Duerst <>

unclosed tags, local storage, font sizes and colours

Paul Mansfield <>

Doctype issues, namespaces processing

"Simon St.Laurent" <>

Javascript windows

addon: javascripts open window functions should be handled like cookies: always open, ask, never open. this is NOT for links, but for automatic scripting. if a user clicks he usually wan't it open.

Armin Obersteiner <>

Don't advertise an encoding in Accept-encodings: that you don't really accept

I've worked with a number of web sites suffereing from bandwidth overload. By altering their PHP servers to support encoding compression or inserting a compressing proxy we have dramatically reduced their operating costs. The down side is that a number of browsers advertise that they can handle gzip or deflate and they really can't. Both IE and Mozilla have this problem with different versions.

Jim Studt <>

Unsorted comments

Ian Hickson <>

Discussion on Slashdot

Valid XHTML 1.0!
Created: 2001/02/09 - Last modified $Date: 2001/05/10 07:59:22 $ by $Author: hugo $
Karl Dubost, Hugo Haas

Copyright © 2001 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.