Re: early version 4.3 evaluation

Sorry if we didn't satisfy your all requests. I guess you forgot 
that we have a limited manpower and several different missions.

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

It's annoying to have to wait for a long time in this case, but we're not
ready to spend many efforts on that. Any external contribution is welcome
here.

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

I'm not sure it's so simple, but this should be considered.

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

These tables are well displayed

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

I see not indication in the HTML 4.0 recommendation that says that
it's 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.

I don't see what is wrong in Amaya.

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

We don't plan to add complex algorithms here. The table formatter is enough
slow today.

> T5] The colspan attribute causes cell data to be omitted in calculation
>     of cell widths when width is not forced.

This is in the todo list.

> T6] Table width is miscalculated in some cases in no width= given
>     See Amaya Configuration help document -- Amaya Home Directory

What is wrong?

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

This is in the todo list.

> T8] Errors in mathematics during table construction that are editor
>     detectable, should be flagged to author.

I'm not sure it's still true.

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

It would be better to do that but that takes time.

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

People asked the full list of what CSS rules Amaya doesn't support.
It would be helpful for us if you can provide that list.
We try to progress in each release, but it's a long long way.

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

I did you start with edit mode off?

> E2] Shft-End and Shft-Home do not highlight text for cut/copy operation.

Word selection was added, but not Shft-End and Shft-Home.

> E3] Shift-DownArrow includes first character of next line in highlight
>     when it should not do so.

It's considered as an extension to that last character, so the last character
in included.

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

No idea of what is the 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.

That occurs sometimes.

> U3] The scroll bars can't be pulled to the very bottom or right edge.
>     No information is lost but this is untidy.

We keep a space at the bottom of pages.

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

I tested on a document and it worked well. It should occur in
specific cases.

> 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 ;-]

No because Amaya needs a lot of shortcuts and so interprets differently
Alt P and Alt p. Amaya also accepts sequences of two shortcuts. It's not 
because Windows applications are limited that we should maintain the
limitation.

> Compose Function
> C1] Creating a soft hyphen adds a &173; to the document which
>     will not pass some validators.  Should use &shy; instead.

Amaya doesn't generate a &173;

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

This is in the todo list but with a low priority.

> 
> 
> John Russell, VE3LL@RAC.CA
> http://www.cgocable.net/~jrussel
> Mystery readers may want to click on DOROTHYL
> 

-- 
     Irene.

Received on Friday, 2 March 2001 09:38:17 UTC