Status of some very old bugs still unresolved!

Some areas that are still causing problems within Amaya 5.2
    (as of Oct 29, 2001) from my viewpoint [Windows 98 BINARY):

Editor Problems
E1] The shortcut procedure (shift ctrl *) for edit mode toggle does not work.
    However the menu selection method works fine!
E2] Shft-End and Shft-Home do not highlight text for cut/copy operation.
E3] Shft-Backarrow hilights entire line if at first character of line 
     when entered!  Works correctly otherwise.
E4] Shft-DownArrow includes first character of next line in highlight
    when it should not do so.
E5] Star-O does not enter Oslash as advertised.
      Perhaps this is a character mapping error!

Keyboard Shortcuts
K1] Standard shortcut nomenclature should be used in menus.
    For example Alt + P  instead of Alt p
 
CSS Display Problems -- http://www.cgocable.net/~jrussel/am_css.htm
C1] CSS horizontal formatting not done on tables for centering.
    margin-left:auto; margin-right:auto
C2] Reverse indents not placed at original margins.
C3] CSS property white-space:pre is not functional.
C4] CSS property background-attachment does not do fixed scroll correctly.
C5] CSS property list-style-type:none continues to put the default
    disc bullet in list items instead of NO bullet.
C6] CSS property text-transform is not functional.
C7] CSS property word-spacing is not functional.
C8] CSS property text-decoration:blink is not functional. Although 
    authors should be discouraged from using blink, it IS in the spec.
C9] CSS property text-decoration fails when both overline and underline
    are both required.
C10]CSS pseudo element first-letter not implemented correctly.
C11]CSS property font-family does not include correct rendering for
    the generic font 'cursive'.
C12]CSS property font-family does not include correct rendering for
    the generic font 'fantasy'.
C13]CSS margin not considered in centering process.
C14]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.
C15]CSS inline style not error checked for extraneous brace brackets.
    Hangs up Amaya if something like style="{color:red}" is used.

Form Display/Action -- http://www.cgocable.net/~jrussel/am_forms.htm
F1] Fieldset draws very thin container box with gray lines on top and
      left side. These blend into background too easily. This is important
      for visual look of form to client. Is there color control for this or 
      preset to black all around if not. Also is there a setting for thickness
      of line (ala border or frame stuff)
F2] Fieldset container box is drawn through data entry areas. Perhaps
      the algorithm assumes the data entry boxes are of correct size
      when they are not --- see next error      
F3] Size = "xx" is not acted upon which yields awkward screens.
F4] Maxsize = "xx" is not acted on at all !!!
F5] Tab button does not move focus of cursor from entry to entry
      according to tab-index attribute.
F6] Disabled form entry areas are not grayed out or differentiated 
    from enabled form entry areas.
F7] Disabled form entry areas are still able to be used. 
F8] Alignment of adjacent buttons is incorrect when combo of list
    and image button captions used (perhaps floating image issue).

Table Display -- http://www.cgocable.net/~jrussel/am_table.htm
T1] Table cell border properties are not observed correctly when
    frame and rules attributes have been included. Test by using
    my sample file and compare the display with that of MSIE 5.
T2] When rowspan is used, valign is not respected. For example
    rowspan="3" valign="middle" does not place data on the second row.
T3] 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.
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.

Other HTML Display Problems -- 
http://www.cgocable.net/~jrussel/am_other.htm
H1] Background color set to 'grey' rendered as gray. Undefined values
    should use the browser's default color!
H2] Horizontal rule does not respect the noshade attribute
H3] When lists are included in blocks that are centered, the
    list bullets are not centered but the text is.
H4] Image tags with width or 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 specification seems vague here
    but the BIG 3 browsers seem to agree in how to render.
H5] Images are not floated correctly although this is part of
    HTML 4.0 specification.
H6] 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.
H7] Spaces after a closing tag are sometimes eaten without display.
    This shows up in comment closer and mathml closers.
H8] If a document opening or closing paragraph contain font changes
    then hyperjumps to end or beginning do not work correctly.
    http://www.cgocable.net/~jrussel/home.htm displays this issue.
H9] The soft hyphen entity is not interpreted correctly. It is displayed
    all the time instead of only when the word containing it is broken
    at the hyphen. See http://www.cgocable.net/~jrussel/am_char.htm 

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.
U4] When no scrolling of text is available, the scroll bar should
    disappear but it doesn't
U5] 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.

Printing Difficulties
P1] Printing a 'selected text' portion prints the whole document.
    This occurs in both the 'browse' and 'source' views.
P2] When a print job is requested from a Show Parse Errors view,
    the printing is done correctly but Amaya is then aborted and
    one is left at the desktop.
P3] 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.

Startup Sequence or Initialization
S1] The toolbar (especially the stopsign) should display earlier in
    the start sequence. This will allow halting the request to display
    the home page. This is needed when the home page site is offline.
    At present one must abort Amaya or wait out the LONG timeout.
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.

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).
    An alternative is a preference setting using radio buttons to
    define which one user wants as default (user friendly solution)

John Russell, VE3LL@RAC.CA
http://www.cgocable.net/~jrussel

Be sure to check your HTML markup code
tags by using http://validator.w3.org or
http://www.htmlhelp.com/tools/validator/

Received on Monday, 29 October 2001 13:51:43 UTC