Severe and very basic bugs showing up (tests attached)

I've found some quite serious bugs, some of them in Amaya's most core,
basic HTML processing abilities (on MacOS X, anyway), which is pretty
bad given that this is not only the reference standard, but people
basing their own stuff on Amaya's code are given blanket license
(according to the FAQ anyway) to claim full W3C HTML standards
compliance.  Amaya itself, even as of the latest public build I know of
(from a few weeks ago), which is what I'm running, doesn't qualify
itself because of bugs like this.  I'm not trying to be mean here, just
accurate.

Anyway, the serious bugs I've encountered so far (which I am reporting
here because the site says that's what this list is for, in part, and
because they are not listed in the bug tracking page) are listed below.

Conditions:
Amaya Release Number: 8.6 (August 23, 2004)
Platform: MacOS X (Darwin BSD) "Panther" 10.3.5, Amaya running in Apple's
  (not Fink's or anyone else's) X11, version 1.0 using XFree86 4.3.0
  (More specifically, the Amaya I am using is the one, and only one,
  currently available via Fink.  The FAQ incorrectly [presently; it probably
  was correct at some point] suggests that Fink provides two variants, one
  for GTK and one for Motif. If this was the case at some point, it no longer
  is today.)

A clear test case, stripped of everything irrelevant, is attached,
including all required files (the stylesheet and two images).  In case
this list, or any Amaya developer recipient, does not receive
attachments, the test case is also viewable at
http://www.well.com/~mech/.AmayaTest/, and I will leave it there pretty
much indefinitely unless (*until*, I hope) the issues are resolved.

It seems likely to me that these problems affect all versions, since there is
no core difference between Amaya built for MacOS X (BSD) and Amaya built for
any other flavor of *n*x, be it Solaris, or Red Hat Linux, or whatever;
unlike, say, Mozilla built for Linux and Mozilla built for MacOS X's
non-X11 proprietary GUI; those 2 Mozillas are very different
applications from eachother that simply use the same core library code.
(I suppose the *n*x Amaya and the Windows version ARE that different,
so these issues may not show up the same or at all in the Windows
version, now that I think about it.)

The bugs:

1) If you have a table with two or more cells in one row, and set one
cell's width to 100% (regardless what the other is), and have an
<IMG...> in it, and make that cell ALIGN="RIGHT" (or make the image
ALIGN="RIGHT" and don't specify an ALIGN in the <TD>) the image in that
cell will be rendered partially out-of-window to the right, and this
will also shift the content of the matching cell(s) in row(s) below
this out of the window, too, if it is wide enough to reach that far.

[The conditions are unlikely to even be this specific; e.g. maybe the
content in the second cell doesn't need to be a wide image as it is in
my attachments; it might affect text also.  Or maybe the ALIGN
attribute is irrelevant. What is attached here is just the test case
I'm presenting you with, since it is the specific circumstance that has
been boogering my pages in Amaya, plus some followup experiments I've
done. :-]

Setting the width to 100% should not be problematic in any way.  What
100% means in this context is "100% of the available, remaining width
in the window (or inside the smaller element containing me)".  That's
what it ALWAYS means, regardless of what element it is applied to and
in what context.  The only time it means "100% of the entire window
width [other than any margin space reserved by the user agent or
dictated by a stylesheet]" is here:

Example 1:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD [DTD name]" "[DTD URL]">
<HTML><HEAD><TITLE>Title</TITLE></HEAD><BODY>
<TABLE WIDTH="100%"><TR><TD>[something]</TD></TR></TABLE>
</BODY></HTML>

because there isn't anything else requiring space.

By contrast, a shortened summary of the attached proof-of-bug example
(the more complex one in TEST.html) is like so:

Example 2:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD [DTD name]" "[DTD URL]">
<HTML><HEAD><TITLE>Title</TITLE></HEAD><BODY>
<TABLE WIDTH="100%"><TR><TD>[something1]</TD><TD
WIDTH="100%">[something2]</TD></TR>
</TABLE></BODY></HTML>

What Amaya appears to be doing is misinterpreting "100%" in the context
of the attached TEST.html example (and example 2, above) to mean
"calculate what 100% of the width of the window is and then ADD the
width of everything else (e.g. another table cell) that is also
requiring some space, and push the content rightward, so that the
present table cell has 100% of what the visible window width is, even
though this may push it outside the window or push something else
outside the window."  This is clearly, undeniably, totally wrong.
Percentage widths are relative, and only refer to the AVAILABLE space
within a) the window width, b) what the window width would be if some
element (like a super-wide banner) were not making it wider than
possible already to fit within the window width, requiring one to side
scroll, or c) the window-width-or-smaller higher element containing the
element in question.  (I guess I should be saying "canvas width" where
I'm saying "window width", but you can probably follow my meaning).
Relative width is emphatically NOT additive.  <TR><TD
WIDTH="30%">[something1]</TD><TD WIDTH="100%">[something2]</TD> does
NOT make for content that is 130% the width of the window!  W3C
provides no published algorithm for settling the conflict that I can
recall (though they do for some circumstances, especially with columns
and *-specified relative widths, if I remember correctly), but somehow
EVERY other browser in the world, even WebTV for crissakes, manages to
handle this gracefully from a usability standpoint.  The typical
algorithm generally seems to be to reduce each competing portion by an
equal proportion until 100% of total available width is arrived at
(making adjustments where necessary; e.g. if the reduction in question
would make the one cell too small to display an image it contains, then
the reduction stops for that cell and continues only for the other
cell[s]; and so on).  When one competing element is specified in pixels
(or via CSS in inches or otherwise specified in a non-proportional
manner), the answer is even easier: Give the item that requested the
non-proportional space exactly what it asked for, and give the
proportional (percentage) one[s] what is left; that is, what is left
over AFTER the non-proportional elements have been assigned their
strictly-delimited space is the new "available space" to which "100%"
(or whatever) now applies.  In essence, something like 'WIDTH="100%"'
and 'WIDTH="327"' are never actually in competition with each other,
period.  The "100%" is never even applied until AFTER the "327" has
been subtracted from the original available space; if the window width
is 1000px, then the "100%" in this case means "100% of the 673 pixels
remaining".  Likewise, one can apply this relative, proportional width
inside other elements, e.g. a  <TD WIDTH="100%" inside a table that is
itself inside a <TD WIDTH="30%"> proportional cell, or a <TD
WIDTH="250"> non-proportional cell, inside a higher-level table.
Again, here as elsewhere, "x%" means "x% of the available space in
context, not of the total space of the document window".

Anyway, this misinterpretation of what "100%" means SEEMS to be what
Amaya is doing here.  No other explanation presents itself to me
immediately.  TEST4.html offers near-certain proof that this is what
the problem is.  If you give WIDTH="100%" to each <TD> (there are two)
in the first <TR>, instead of negotiating for 50% each of the window
width, the browser assigns 100% of the actual window width to EACH <TD>
and doubles the width of the document canvas (without changing the
actual window size of course).

Fortunately for site developers right now, there is a work-around:
Surround the offending table with another table, with a single cell
containing everything else on the page (you can make this new table
WIDTH="100%" or its single <TD> have WIDTH="100%" if you want, but if
you don't the workaround still works.  That is, simply surrounding the
bug-triggering table with <TABLE BORDER="0" CELLPADDING="0"
CELLSPACING="0"><TR><TD> and </TD></TR></TABLE> works around the bug.
Attachment TEST2.html demonstrates this workaround in action.

TEST3.html further demonstrates that this workaround DOES require an
additional table around the original.  Simply making the original table
also have WIDTH="100%" does NOT work around the bug.

TEST5.html demonstrates that the bug occurs regardless of the order of
the cell that has WIDTH="100%" (in this case, it is the first of three
in the top row).

2) The next glaring bug is Amaya's utterly inconsistent bordering
around viewable/usable part of the page/window (the "canvas").  In the
attached examples (TEST.html or any of the others) you can see that
that the ENTIRE content of the page consists of a single BORDER="0"
table.  But Amaya can't seem to decide what to do with the edges of the
page.  The top of the canvas has no margin (border consisting of
whitespace) whatsoever.  The left side has not just a margin, but a
rather large one.  From a design standpoint, Amaya forcing this useless
whitespace there would drive me crazy.  Even worse goes for the bottom
when you put enough content in the central content cell to force
vertical scrolling (that's the purpose of all the "Here's some dummy
text..." content in the test pages).  Why is that BIG whitespace
appearing at the bottom if I didn't tell the user agent to put it
there?!  The right-hand side (once you are forced to scroll over to it
by bug #1!), like the top, has no border (as it shouldn't since I
didn't tell it to have one).  Also, please note that the whitespace at
left and bottom are NOT part of the table or any other content on this
page, it is being created out of thin air by Amaya.

The HTML specs do not mandate anything in this regard, as far as I
recall (though CSS certainly does, by allowing stylesheets to dispense
with borders entirely in graphical user agents if the stylesheet author
tells them to), but regardless, this "let's just be totally random and
inconsistent about borders" behavior of Amaya is clearly not a Good
Thing, even if some border was intentional by default.  If so, it
should be on all four sides, and consistent in size.

But this brings me to:

3) Amaya is ignoring my CSS's @page (see attached TEST.css) which is
telling it very, very explicitly to NOT put any border on any edge.
Bug, bug, BUG.  And a really bad one, given that Amaya is supposed to
be THE reference implementation of HTML, XHTML and CSS!  Even if Amaya
is intended to have a whitespace border around content by default
(which, as noted, it is doing in a haphazard, inconsistent way), it
should NOT have any such borders on any side when CSS tells it not to!
Slightly in Amaya's defense, some other browsers do this too, including
MSIE and Safari.  Doesn't make it right, though.  And at least their
artificial CSS-violating borders are consistent in side around the
entire document.

4) Amaya has a table border overlapping bug (or it might be thought of
as a CELLSPACING collapsing to a negative space bug).  TEST6.html
demonstrates it on the right-hand side.  TEST6.html introduces a new
table inside the main content area (the "Here's some dummy text..."
cell). This new table now contains all of the dummy content there plus
another copy of the banner.  [Note that it again demonstrates that one
can have a WIDTH="100%" table cell next to other table cells in the
same row and NOT trigger bug #1 as long as the table this appears in is
inside another table.]  What my markup (specifically the BORDER and
CELLSPACING on this new table) in this test page shows is another bug,
in which Amaya not only collapses the CELLSPACING on the right-hand
side of the table, it actually *overlaps* the table borders such that
the *inside* border (the border of the cell) is farther right than the
*outside* border (the border of the table)!  Clearly a bug (and one
shared in some circumstances by MSIE, at least  ver. 5.x on MacOS X).
If you look closely, the too-far-rightward inside border is so far
rightward it is actually outside the bounds of the what Amaya considers
to be the document, by several pixels into the whitespace margin
(which, as noted, shouldn't be there in the first place).  As
TEST6.html also shows, right-aligned content, which butts up against
the right-hand cell border, also overlaps the outer table border, as
does the 2nd banner in this example.

5) Amaya seems to be violating tables' CELLPADDING, vertically.  It is
improperly padding both the top and the bottom around text, as is
clearly visible in the main text area (where the dummy text is) in all
of the attached TEST[*].html files.  This may not be a bug, though, but
rather something to do with Amaya's default styles for text in absence
of a stylesheet telling it to do something specific and different.  As
long as this effect doesn't happen with images it shouldn't be a
problem. TEST7.html establishes that it does not (the third banner
image, at page bottom, is flush with the bottom and right margins as it
should be.)  TEST7.html also reinforces bug #4, however, as the very
rightward edge of the bottom-of-page banner is slightly outside the
boundary of the document again.

6) Amaya is violating the defined behavior for images and text flow
around them.  The second banner in TEST6.html is ALIGN="RIGHT" followed
by a <BR> (with *no* CLEAR attribute).  The text should be flowing
around it, not beginning underneath it.  TEST7.html which aside from
the above test for bug #5, also has removed the <BR> from after the 2nd
banner, demonstrating that Amaya's error here is really pretty severe.
It's not even a mistake in the handling of <BR> but a mistake in the
overall handling of images and text.  Curiously, this bad behavior is
not broadly consistent.  For example, this much more complex page:
http://www.well.com/~mech/Blackbird/aboutus.html does not exhibit this
problem.  TEST8.html is precisely the same as TEST7.html except that
the <P> before the dummy text has been moved to enclose the second
banner image, which this text should flow around.  And now it does!
This identifies the bug pretty clearly.  While the strict DTD I think
requires <IMG> to be inside <P> or an equivalent element, this is
emphatically NOT the case with the loose DTD, which is what this
document is using.  Amaya may be misidentifying the DTD which would be
an even more serious problem than the problem of text not wrapping
around images.  At any rate, I'll have to look into the strict
interpretation later, but I'm almost dead certain that even in strict,
IMG does not have to be inside the *same* block element for text to
wrap around it.  Unless I'm badly mistaken there is no reason that <IMG
ALIGN="RIGHT"...><P>some text</P><P>more text</P> should not have both
"some text" and "more text" wrapping around the image, in strict, as
long as all three are inside a larger block element. But I could be
mistaken.  I don't frequently use the strict DTD.  Who does? >;-)

7) An interface bug:  If you click on the URL bar (or "Open" bar in
Amaya terms) above the content display window, the insertion point is
correctly placed.  I'll use the "|" character as a token for the
insertion bar here in these ASCII examples.  I'm using local paths on
my hard drive, not full URLs:

Place insertion point (so far so good):

/Users/mech/Documents/TEST/TEST|6.html

If you now type something, e.g. "x", it works fine:

/Users/mech/Documents/TEST/TESTx|6.html

But, if you use the forward-delete key to remove the 6 (which DOES get
correctly removed) the insertion point jumps to the end of the line:

/Users/mech/Documents/TEST/TEST.html|

Or if you use the mouse to highlight the 6 (I'll represent that with
square brackets), like so:

/Users/mech/Documents/TEST/TEST[6].html

and then delete it (use delete/backspace or forward-delete), again the
cursor jumps to end of line after deleting the selection:

/Users/mech/Documents/TEST/TEST.html|

Worst of all, if you type a replacement character ("y" in this example)
instead of hitting del or backspace, the highlighted "6" is deleted,
the cursor jumps to the end of the line, and THEN it puts in the y!

/Users/mech/Documents/TEST/TEST.htmly|

Needless to say, this is rather "user-hateful".

8) Serious speed problem.  Amaya has some kind of very problematic
speed issue.  Even loading these TINY example pages is unbearably slow
(on a 733MHz G4, pulling them off the local drive, with no network
activity required).  Amaya reports "Finished!" in its status bar at the
bottom pretty much instantly, but it can take up to 25 seconds (I've
counted) for the content to actually render.  That's very, VERY poor
performance.  This even happens if you hit the "back" button and then
the "forward" one to go back to the same page.  There is obviously some
serious problem Amaya has with efficiently rendering even the simplest
code like these examples.

A) Another issue entirely.  The Web site needs some major work.  It
does have a recent "Last updated" date on it, but it's painfully clear
that practically nothing does get updated.  The bugs list is short and
seemingly old, the FAQ content is outdated and the overall design and
code seem to date from some time around 1996. [This is not meant to be
sarcastic or snipey.  I'm just telling what I observe, and I'm sure the
cause is that you are underfunded and understaffed and that working on
the actual browser takes precedence over working on the Web site.  But
none of that changes the simple fact that the Web site DOES still need
work.]  There are also typographical and grammatical errors all over
the place.  The organization logo that appears on some pages is even
out-of-date, and reads "W3O" instead of "W3C", and so forth.

Just to prove I'm not someone that simply likes complaining about
things  for the heck of it, I'm volunteering to at very least clean up
the content on these pages, and possibly even to do a bunch of
re-design work on them, so they have a better "look and feel".  I'm
willing to commit to a fair amount of time involvement on something
like this.  I could probably even re-do the Amaya logo so that it too
looks more modern.  I can't, of course, do anything about the updating,
since that can only come from you guys.

B) Wishlist:  Amaya needs a history feature really badly (if there is
one, I have yet to be able to find it).  It gets very tedious using the
disk "browse" feature or manually entering URLs I used just moments
ago.  I'm not talking about permanent bookmarks, just a drop-down of
the last x number of pages I've visited, whether local or remote, the
way every other browser does.

C) Lastly, I think it's a damned shame and a disgrace that W3C is not
funding you properly to turn out a world-class and truly
reference-standard browser/editor.  It blows my mind that they would
let this slip through the cracks.  The fact that there is no real,
fully functional ref-std implementation for W3C Web standards is
probably the proximate cause of the continuance of the "browser wars",
a WWW infested with millions of badly-coded Web pages, and the great
difficulty we all have in creating even simple pages that reliably work
cross-platform and cross-browser without tens or even hundreds of goofy
workarounds.  I really hope W3C's management will realize that Amaya
needs to be treated as a serious, important project and one that
requires a lot of immediate attention.  The fact that you've made this
much progress on such a shoestring is pretty amazing!

Attachments

Received on Monday, 27 September 2004 10:15:05 UTC