Re: W3C: Common User Agent Problems...

[Clarence (Andreas M. Schneider)]

Christian Mattar wrote:
> 
> > 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.

Not if the target is near the bottom of the document.

> > (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.

It could be the same method which is used to highlight search
results with <ctrl>-f.

> > 1.9 When a Web resource includes metadata that may be recognized by the
> > user agent, allow the user to view that metadata.
[...]
> 
> This is pretty unspecific, but Mozilla displays alt and title
> appropiately.

There is a bug for this, but I don't remember the #.

> > 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.

No, we even lack the basics.
See e.g. http://bugzilla.mozilla.org/show_bug.cgi?id=20843 .

> Still, there could be better implementation, something like the
> cookie-manager perhaps.

That would be hard to do (although I would like it). It would
be silly to track *each* POST, since it is used by some search
engines and at other places you hardly want to track.

We could add a context menu entry "track this request" to form
submit buttons. But what about submits via JS? Should there be
a dialog which asks wheather to track this POST (possibly with
the option "never ask again for this page/site")?

If we track a POST, we should save (1) the originating page,
(2) the post data, (3) the resulting page (1 & 3 as MHTML with
all images). There would be a need for an advanced UI to
access the collected data.

This would be a nice feature, but it needs further discussion
and it is far beyond 1.0.

> > 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.

For server-driven negotiation we always bookmark negotiated
resources (unless the Accept-* headers are changed). I see no
sense in storing the actually used Accept-* headers.
Anyway, different results of server-driven negotiation do not
have different URIs the user agent is aware of.

For agent-driven negotiation: Do we support that? Is there any
standard for it (HTTP/1.1 does not define one)? Does any server
support it?

> > 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.

This is in the "Debug Networking" preferences, but I do (assuming
"Content-Encoding" and not "Transfer-Encoding" was meant).
But there are bugs with it, e.g.
http://bugzilla.mozilla.org/show_bug.cgi?id=35956 .

> > 1.13 Use the user interface language as the default value for language
> > negotiation.
[...]
> Don't know about this one.

AFAIK Moz does this right, as 4.x does.

> > 2.1 Implement user style sheets. Allow the user to select from author
> > and user style sheets or to ignore them.
[...]
> Alternative stylesheets are selectable, don't know about user
> stylesheets.

AFAIK ok, but we have no documentation about it.

> > 2.2 Respect media descriptors when applying style sheets.
[...]
> I'm not sure if this is implemented yet.

I think so.

> > 3.1 Save resources retrieved from the Web on the local system using the
> > appropriate system naming conventions.
[...]
> Mozilla gets the extension right, at least on Windows.

No, see e.g. http://bugzilla.mozilla.org/show_bug.cgi?id=35956
and try to save a URI ending with "/" (don't have a bug #).

> > 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):

We do not recognize 307 at all, see
http://bugzilla.mozilla.org/show_bug.cgi?id=48202 .

> > 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.

That would require another dialog and I don't think it is very
useful. If the user wants to bookmark the original URI he/she
can do so by hand.

> > 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.

IMHO, that is right, not wrong.

> > 4.1 Handle the fragment identifier of a URI when the HTTP request
> > is redirected.
[...]
> Don't know about this one.

Moz does this right (at least with 301).

Clarence