- From: John Russell <ve3ll@rac.ca>
- Date: Thu, 16 Nov 2000 15:01:50 -0500
- To: www-amaya-dev@w3.org
most interesting are T1, T2, T3 AND D1 as these look like
easy to fix errors......
Some areas that are still causing problems within Amaya 4.0
(November 14, 2000) from my viewpoint [Windows 98 BINARY):
Startup Sequence or Initialization
S1] The toolbar with the STOP icon should be displayed and enabled
earlier in the startup sequence. At present, if one has a startup
or home page on the internet and there is a service problem, there
are situations where the display hangs up searching for a site but
with no STOP or 'breakout' method available.
TEST: by removing cable connection and starting browser with home
page on the internet.
S2] Cached files are used without checking to see if it is current.
A simple timestamp check should allow changed files to be loaded
over the cached ones.
Table Display -- http://www.cgocable.net/~jrussel/am_table.htm
T1] Table borders are thin lines which can be covered up by the
cell contents. Corners are also incomplete. I have noted that
using border="2" is ok but this is not the ideal solution.
T2] If align=center is used in a table element (a deprecated attribute
in this case), it is interpreted as an instruction for the cell
entries. This is incorrect!
T3] Table cell border properties are not observed correctly. Use
my sample file and compare with MSIE 5. for border suppression.
T4] If a table has no height= attribute, the height is computed
by the browser. If a table declares height= then ????
Most browsers will check 'set' value against needed and use
the maximum of the two.
Amaya uses the height setting to be consistent with the img
height attribute which normally scales image to the speced height
but this leaves problems if speced is less than needed TEXT.
If there is no specification on how to handle this conflict,
it would be easy enough to err in favor of the user by:
a] setting height to default value
b] resetting height if height= attribute used
c] computing what is needed to prevent outside of border material
(this routine is already there for no height speced)
d] comparing needed to height
e] using the maximum of the two values NEEDED and HEIGHT
This routine would work whether or not height was speced.
and would prevent out of box messages in most cases!
TEST: by using the sample file.
T5] Tables become confused if stacked more than two levels down.
TEST: by viewing 'http://www.bahnhof.se/~chimbis/tocb/links'
where text is printed outside their associated box.
T6] Errors in mathematics during table construction that are editor
detectable, should be flagged to user.
Other Display Problems --
http://www.cgocable.net/~jrussel/am_dsply.htm
D1] When lists are included in blocks that are centered, the
list bullets are not centered but the text is.
D2] Unbreakable strings are broken (with hyphens added) whenever the
window is narrower than the string. This is in contrast to action
of other browsers and leads to unusually displays in some table
situations. Fixing the document width and forcing scrolling seems
more appropriate.
D3] The default img size is too small. This results in unnecesary
screen redraws on common screens like 'http://www.w3.org/History'
which uses icons on each line that is a file.
D4] Images are not floated correctly although this is part of
HTML 4.0 specification.
D5] CSS stylesheet rule rendering is incomplete. Two to note are colors
and line positioning. The www.w3.org/Style/CSS page is a great
demo. Observe the heading on a variety of browsers.
D6] Many color-picker selected colors do not look like the ones
displayed in the picker swatches. This is 256 color mode related!!
User Interface Problems
U1] Show log option should be on the 'VIEW' menu as all other
'show xyz' are there. Many users think view and show are synonyms.
U2] Status line now shows href URI but is incorrect when an
in-this-document link is pointed at [omits doc name].
U3] The move one page up/down scroll selection may not be adapting
to screen size. This is most noticable in the Show Source
window. For 800x600 main window, this results in jumps that do
not retain one line of last screen (for continuity) and even
more extreme, for 640x480 main window, lines are skipped entirely
when paging action selected. Algorithm must take into account
the number of lines displayed! I didnt check horizontal scroll
but this may have similar problem.
U4] After scrolling to bottom of document, scrolling up to top
overscrolls on many docs. An example of this is
'http://www.cgocable.net/~jrussel/mathsci.htm'
And scrolling down overscrolls on some documents such as
'http://www.cgocable.net/~jrussel/home.htm'
This is with a jpg image background that doesn't go completely
to the top or bottom of screen.
U5] The scroll bars can't be pulled to the very bottom or right edge.
No information is lost but this is untidy.
Printing Difficulties
P1] Amaya deadlocks during printing when document contains
the following style attribute:
<h2 style="page-break-before: always;">The Title</h2>
If the style attribute is removed, printing works ok.
Keyboard Shortcuts
K1] Standard shortcut nomenclature should be used in menus.
For example Alt + P instead of Alt p and
Ctrl + Enter instead of Ctrl Return.
NOTE: I can't find Return key on a standard keyboard ;-]
Compose Function
C1] Creating a soft hyphen adds a &173; to the document which
will not pass some validators. Should use ­ instead.
Address Dialog
A1] Currently www.w3.org will not get a page from the web
(needs http:) but \temp\foobar.htm will get one from local drive.
Either the default mode should be switched around so that
http: is assumed (to coincide with other browsers) or that
the service MUST BE declared (which is Amaya like solution).
John Russell, VE3LL@RAC.CA
http://www.cgocable.net/~jrussel
Mystery readers may want to click on DOROTHYL
Received on Thursday, 16 November 2000 15:00:19 UTC