W3C home > Mailing lists > Public > www-amaya-dev@w3.org > March 2001

early version 4.3 evaluation

From: John Russell <ve3ll@rac.ca>
Date: Thu, 1 Mar 2001 16:55:45 -0500
To: www-amaya-dev@w3.org
Message-ID: <3A9E7F11.30887.22A174@localhost>
Of all the bugs I am tracking only one got squashed.
The positioning of character data with rowspan > 1 is
now appropriate ie at first row of the span.   I didn't check to
see if alignment worked when defined though .. will do now.

Please look at my list, especially T#, F#, D# and E#.  
All of these are old html4 and standard editing issues.
Nothing fancy -- hope they get some priority next round 
as html4 and css1 are old specs and most browsers are
expected to deal with them correctly by now.

Some areas that are still causing problems within Amaya 4.3
    (as of March 01, 2001) 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: Remove network cable connection and start browser with
    home page located 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. I suspect a check is being done but on 
    a greater than condition rather than a NOT EQUAL condition.
    This is important if an isp has not set its clock correctly.

Table Display -- http://www.cgocable.net/~jrussel/am_table.htm
T1] Thin table frames (border="1") do not have the proper 't' and
    'x' elements which cause broken lines. Using border="2" displays
    ok but this is not the ideal solution to the problem.
T2] If align="center" is used within a table element
    (a deprecated attribute in this case), it is interpreted as
    an instruction for the cell entries as well.  This is incorrect!
T3] Table cell border properties are not observed correctly
    when frame and rules attributes included. Test using my sample
    file and compare the display with that of MSIE 5.
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] The colspan attribute causes cell data to be omitted in calculation
    of cell widths when width is not forced.
T6] Table width is miscalculated in some cases in no width= given
    See Amaya Configuration help document -- Amaya Home Directory
T7] 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.
T8] Errors in mathematics during table construction that are editor
    detectable, should be flagged to author.

Form Display/Action -- http://www.cgocable.net/~jrussel/formtest.htm
F1] Fieldset doesn't draw container box and legend doesn't title it.
    This is important for visual look of form to client.
F2] Size = x is not acted upon which yields awkward screens.
F3] Tab button does not move focus of cursor from entry to entry.
F4] Disabled form entry areas are not grayed out or differentiated 
    from enabled form entry areas.
F5] Disabled form entry areas are still able to be used. 
F6] Pressing reset clears radio buttons but does not clear checkbox
    or text input area.
F7] The reset button caption is wider than the button itself.
F8] Alignment of adjacent buttons is incorrect when combo of list
    and image button captions used (perhaps floating image issue).

Other Display Problems -- http://www.cgocable.net/~jrussel/am_dsply.htm
D1] CSS1 property font-family does not include correct renderings for
    the generic fonts 'cursive' and 'fantasy'.
D2] CSS1 property text-transform is not functional.
D3] CSS1 property white-space:pre is not functional.
D4] When lists are included in blocks that are centered, the
    list bullets are not centered but the text is.
D5] 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.
D6] Image tags with height expressed as a percentage do not scale
    correctly. Is % considered as a fraction of full page or a fraction
    of a displayed window. The spec seems vague here but BIG 2 browsers
    seem to agree in how to render.
D7] 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.  
D8] Images are not floated correctly although this is part of
    HTML 4.0 specification.
D9] 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.
D10]Many color-picker selected colors do not look like the ones
    displayed in the picker swatches. This is 256 color mode related!!

Editor Problems
E1] If one starts with edit mode off, it takes two toggles to switch
    edit mode on.  Thereafter the editor mode toggle functions correctly.
E2] Shft-End and Shft-Home do not highlight text for cut/copy operation.
E3] Shift-DownArrow includes first character of next line in highlight
    when it should not do so.

User Interface Problems
U1] 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.
U2] After scrolling to bottom of document, scrolling up to top
    overscrolls on many documents using an image watermark background.
    And scrolling down overscrolls on some documents using an image
    watermark background.
U3] 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 &shy; 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, 1 March 2001 16:53:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:31:04 UTC