Hi!
> After reading W3C's "Common User Agent Problems"
> (http://www.w3.org/TR/2001/NOTE-cuap-20010206) - which of these "issues"
> are (still) present in your Zilla ?
I took the liberty to convert the HTML-file into plaintext, so we can
comment on this in the newsgroup.
If you know any bug numbers of the issues described here, please share
them with the rest of us :-)
> 1. Usability
> 1.1 When the user follows a link to a target anchor, highlight the
> target location.
> Techniques:
>
> Put the target location at a consistent location in the viewport (e.g.,
> at the top of a graphical viewport). Allow configuration to highlight
I think pretty much every browser does this.
> (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.
I don't understand how this is supposed to work.
Perhaps the location where the anchor would lead to could blink on the
scrollbar.
> 1.2 If the user attempts to follow a link that is broken because it
> designates a missing anchor, let the user know it is broken.
>
> There are many ways to indicate to the user that a link is broken.The
> recommended behavior is as follows:
> Do not scroll or otherwise change the viewport. This could make the user
> believe the link is not broken.
Mozilla does this right.
> Indicate to the user (e.g., via a text message in the status bar) that
> the link is broken. If no message is given to the user, they will not
> understand why the viewport didn't move.
> Ensure that any non-text message to the user has a text equivalent; text
> may be rendered as visually displayed text, synthesized speech, and
> braille.
> Audio cues or visual cues may be used in addition to text messages.
This is missing I think.
> 1.3
> Allow the user to retrieve Web resources even if the browser cannot
> render them.
> User agents may not be able to render certain types of content on the
> Web either natively or through a plug-in (e.g., XML content, XSLT style
> sheets, RDF documents, DTDs, XML schemas, etc).
> User agents should allow users to retrieve and save these resources,
> otherwise users may not be able to access this Web content at all.
I think Mozilla opens the download-dialog for any non-XML content it
cannot interpret.
XML-content is displayed and can be saved through the file-menu.
> 1.4
> When the user requests to print a frameset, allow the user to select to
> print an individual frame or the frameset.
>
> The presentation of the frameset could be achieved, for example, by:
> a)proposing a list of frames to the user
> b)using a graphical representation of the organization of the frames.
This is a known RFE, i think.
> 1.5
> Allow the user to add new URI schemes in a straightforward way.
>
> For instance, allow users to associate external programs with URI
> schemes. The user agent should inform the user when it does not
> recognize a URI scheme in content.
I don't know if Mozilla gives any opportunity to plug in non-Mozilla
applications to URI-schemes.
> 1.6
> Allow the user to override any mechanism for guessing URIs or keywords.
>
> Many user agents compensate for incomplete URIs by applying a series of
> transformations with the hope of creating a URI that works.
> For example, many user agents transform the string www.w3.org into the
> URI http://www.w3.org/. The user should be able to control whether, for
> example, typing a keyword should invoke a Web search or whether the user
> agent should prepend http://www. and append .org/.
Altough the user can disable Smartbrowse or whatever it's name is, he
doesn't AFAIK have 100% percent control of incomplete URIs.
> 1.7 Warn users about incomplete documents and transfers.
> Rendering an incomplete document as though it were complete is very
> likely to confuse users. Part of the document is missing, hence some
> anchors might not be present, possibly breaking some links.
> The user agent should notify the user that the document is incomplete.
> The HTTP/1.1 specification describes this behavior for caches at the
> protocol level. Partial responses should also be made obvious to the
> user with a warning.
I think Mozilla gives the standard "missing document" warning if a page
isn't rendered completely.
This could be improved to give more specifics (how many KBs are missing
etc)
> 1.8 Provide a mechanism to allow authentication information to expire.
> Many browsers allow configuration to save HTTP authentication [RFC2616,
> RFC2617] information ("remember my password"). They should also allow
> users to "flush" that authentication information on request.
> For instance,the user may wish to leave the user agent running but tell
> it to forget the password to access the user's bank account.
>
> Wrong: Most user agents consider that authentication information (e.g.,
> password) provided by a user for a server/realm pair during a session is
> immutable for the duration of the session.
I have no idea how Mozilla handles this.
> 1.9 When a Web resource includes metadata that may be recognized by the
> user agent, allow the user to view that metadata.
> Metadata – data about data – can provide very useful context
> to users about information on the Web. For instance, metadata about a
> book might include the book's author, title, publication date,
> publisher, etc. (refer to the Dublin Core [DC] for information about
> library-type metadata).
> Authors include metadata in HTML documents through a variety of elements
> and attributes (e.g., the TITLE and ADDRESS elements, the "alt",
> "title", and "summary" attributes, etc. Languages such as the Resource
> Description Framework [RDF] allow users to populate the web with rich
> metadata. User agents should provide a user interface to allow users to
> view metadata. The user interface may vary according to the underlying
> markup language. For instance, many graphical browsers render the HTML
> "title" attribute (e.g., as a tool-tip) when the user selects or hovers
> over an element with that attribute specified.
This is pretty unspecific, but Mozilla displays alt and title
appropiately.
> 1.10 Allow the user to keep track of completed HTTP POST requests.
> Users may wish to track and archive HTTP POST requests for the same
> reasons they wish to track and archive email.
> For instance, if the user places a book order through a form, and that
> form uses a POST request, the user should be able to store information
> about that transaction.
This is implemented somewhat in session history, I think.
Still, there could be better implementation, something like the
cookie-manager perhaps.
> 1.11 Allow the user to bookmark negotiated resources.
> The HTTP/1.1 protocol [RFC2616] allows the client to request a
> representation of a resource which is best suited to its needs
> (language, media type, etc); this mechanism is called "content
> negotiation".
> When a resource is negotiated, the user might want to bookmark a
> particular version. For example, a document might be available in
> several languages under the same URI, and the user might want to point
> somebody to the Canadian version of this document, which has a different
> URI.
> In such a case, it should be possible to bookmark either the original
> URI or the URI of the view that the user got. The original URI can be
> interpreted as being the generic object and the retrieved document as
> one view of this object.
I think this would be a bit clumsy to implement, and most folks won't
get the difference between "bookmark negotiated content" and "bookmark
original URI" anyway.
That's my opinion, anyway.
> 1.12 Allow the user to choose among supported transfer encodings.
> HTTP/1.1 [RFC2616] allows transfer encoding. An example of encoding is
> data compression, which speeds up Web browsing over a slow connection.
> The user agent should allow the user to set the transfer encoding in the
> HTTP requests sent out.
I think this can be adjusted in the preferences.
> 1.13 Use the user interface language as the default value for language
> negotiation.
> The user should be allowed to specify the set of languages that the user
> agent may use for language negotiation.
> In case the user does not specify any language, the user agent may use
> the language of its user interface as the value sent out. The user agent
> should allow the user to override this behavior.
Don't know about this one.
> 2. Rendering
>
> 2.1 Implement user style sheets. Allow the user to select from author
> and user style sheets or to ignore them.
>
> A style sheet is a set of rules that specifies how to render a document
> on a graphical desktop computer monitor, on paper, as synthesized
> speech, etc.
> A document may have more than one style sheet associated with it, and
> users should be able to select from alternative style sheets.
Alternative stylesheets are selectable, don't know about user
stylesheets.
> 2.2 Respect media descriptors when applying style sheets.
> Some markup and style sheet languages allow authors (e.g., @media
> construct in [CSS2], media attribute in [HTML 4.01]) to design documents
> that are rendered differently according to the characteristics of the
> output device: whether graphical display, television screen, handheld
> device, speech synthesizer, braille display, etc.
I'm not sure if this is implemented yet.
> 2.3 If a style sheet is missing, ignore it and continue processing.
> Users must be able to view content even without style sheets.
I think there's a timer after which the document is rendered, even when
the stylesheet isn't received.
> 2.4 Implement the HTML 4 recognized link types.
> Section 6.12 of the HTML 4.01 Recommendation[HTML 4.01] lists some link
> types that may be used by authors to make assertions about linked Web
> resources. These include alternate, stylesheet, start, next, prev,
> contents, glossary, and others.
> Although the HTML 4.01 specification does not specify definitive
> rendering or behavior for these link types, 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.
Is this bug 2800?
> 3. Protocols implementation
>
> 3.1 Save resources retrieved from the Web on the local system using the
> appropriate system naming conventions.
>
> The media type of a resource retrieved by HTTP [RFC2616] is determined
> by the content type and encoding returned by the server in the response
> headers.
>
> 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).
>
> Example:
>
> http://www.w3.org/TR/1999/REC-html401-19991224/html40.ps is a view of
> the gzip'ed PostScript version of the HTML 4.01 specification. The HTTP
> headers sent by the server include:
>
> Content-Type: application/postscript; qs=0.001
> Content-Encoding: gzip
>
> If saved locally, the filename on most computers should be html40.ps.gz
> for the applications to recognize the file type.
>
> Wrong: Saving this compressed PostScript document as html40.ps is likely
> to confuse other applications.
Mozilla gets the extension right, at least on Windows.
I think all content is automatically decompressed before saved on disk.
> 3.2 Respect the media type of a resource if one is explicitly given
> using the Content-Type HTTP header.
> Example:
> If an HTML document is returned with a Content-Type value of text/plain,
> the user agent must render the document as plain text without
> interpreting HTML elements and attributes (i.e. the HTML source must be
> displayed).
Mozilla does this (although this breaks some pages)
> 3.3 Respect the character set of a resource when one is explicitly
> given.
> User agents must respect the character set when it is explicitly
> specified in the response. The character set can be given by the HTTP
> Content-Type headers and/or by the document-internal fallback (HTML meta
> element, etc).
Mozilla does this.
> 3.4 Do not treat HTTP temporary redirects as permanent redirects.
> The HTTP/1.1 specification [RFC2616] specifies several types of
> redirects. The two most common are designated by the codes 301
> (permanent) and 302 or 307 (temporary):
>
>
> A 301 redirect means that the resource has been moved permanently and
> the original requested URI is out-of-date.
>
> A 302 or 307 redirect, on the other hand, means that the resource has a
> temporary URI, and the original URI is still expected to work in the
> future.
> The user should be able to bookmark, copy, or link to the original
> (persistent) URI or the result of a temporary redirect.
>
> Wrong: User agents usually show the user (in the user interface) the URI
> that is the result of a temporary (302 or 307) redirect, as they would
> do for a permanent (301) redirect.
> 3.5 If a host name has multiple DNS entries, try them all before
> concluding that the Web site is down.
>
> Many Web sites have a single hostname like www.example.org resolve to
> multiple servers for the purpose of load balancing or mirroring.
> If one server is unreachable, others may still be up, so browsers should
> try to contact all the servers of a Web site before concluding that the
> Web site is down.
Don't know about these two.
> 3.6 List only supported media types in an HTTP Accept header.
> HTTP/1.1 [RFC2616] defines content negotiation. The client sending out a
> request gives a list of media types that it is willing to accept; the
> server then returns a representation of the object requested in one of
> the specified formats if it is available.
>
> When entities are embedded in a document (such as images in HTML
> documents), user agents should only send Accept headers for the formats
> they support.
>
> Example:
> If a user agent can render JPEG, PNG and GIF images, the list of media
> types accepted should be image/jpeg, image/png, image/gif.
>
> Wrong: User agent agents should not send an HTTP header of Accept */*
> since the server may support content types that the user agent does not.
> For instance, if a server is configured so that SVG images are preferred
> to PNG images, a user agent that only supports PNG, GIF, and JPEG will
> receive (unsupported) SVG rather than (supported) PNG.
Mozilla does this "Accept */*"-thingy. I think it's for
backward-compatibility.
> 4. URI handling
>
> 4.1 Handle the fragment identifier of a URI when the HTTP request
> is redirected.
>
> When a resource (URI1) has moved, an HTTP redirect can indicate its new
> location (URI2).
> If URI1 has a fragment identifier #frag, then the new target that the
> user agent should be trying to reach would be URI2#frag . If URI2
> already has a fragment identifier, then #frag must not be appended and
> the new target is URI2.
>
> Wrong: Most current user agents do implement HTTP redirects but do not
> append the fragment identifier to the new URI, which generally confuses
> the user because they end up with the wrong resource.
> Example:
>
> Suppose that a user requests the resource at
> http://www.w3.org/TR/WD-ruby/#changes and the server redirects the user
> agent to http://www.w3.org/TR/ruby/.
> Before fetching that latter URI, the browser should append the fragment
> identifier #changes to it: http://www.w3.org/TR/ruby/#changes.
Don't know about this one.
