Christian Mattar wrote:
>
> I don't understand how this is supposed to work.
> Perhaps the location where the anchor would lead to could blink on the
> scrollbar.
Does Mozilla still allow javascript to overwrite this location? If so,
putting the js status message somewhere else (so the target is *always*
visible) might be worth doing.
> > 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.
We could put a broken chain symbol next to the link, or next to the
status bar message.
> > 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.
I wonder if this is expecting <address> to be rendered in some way other
than just italic (which I believe is the usual rendering). Or perhaps
have it extracted, so that anything in the <address> section also
appears in the "page info" somewhere...
> > 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.
I don't think they are - I think you can only have userContent.css which
is always in force.
> > 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?
Yes.
(And it's been in limbo WAY too long, imho, although as a
non-contributor I don't have any right to that opinion...)
> > 3. Protocols implementation
> >
> > 3.1 Save resources retrieved from the Web on the local system using the
> > appropriate system naming conventions.
> >
<snip>
> > 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.
I noticed Mozilla M18 (yes, I know it's old) downloaded the tarballs of
0.7 (which are tar.gz files) and saved them with the extension tar.gz,
BUT it automatically did gzip decoding. It should have either not
decoded them or used just tar as the extension.
Similarly, I have a cgi script that returns type audio/mpegurl. If I
name it with a .cgi extension, Mozilla (at least last time I checked)
would save it with extension .cgi. If you make xmms your helper
application, it requires an m3u extension on playlist files. So I have
to name the cgi script .m3u, which is wrong. Mozilla should translate.
> > 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.
I'm not sure I believe (or agree with) this. Most page authoring
software doesn't let you distinguish, and as an author I can certainly
think of situations where I want the other behavior.
Stuart.
