[All text from this marker down to the next
one, inclusive, can be removed and the bugs are still there.
This
text does not affect them in any way.]
These ones are
self-documenting! :-)
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.
This code has been validated (both HTML and CSS)
with the W3C validators.
Issues (probably all to do
with the same bug):
- 1) Apparent document width is
ridiculously wide, yet there are no elements or content making it so.
Just an Amaya bug. It's not even the document canvas, which ends at
the right side of the visible page as it first appears, which is proven
by the termination of the HR. This extra space is just something Amaya
invented out of nothing.
- 2) The images in the table cells, all
ALIGN="right", appear at the far, far right edge of the document (you
have to side scroll about 3x the width of the visible page to find
them. They're not just out of their cells and out of their table,
they're out of the entire document canvas (which again is shown by
where the HR terminates.)
- 3) The outer 5px-border table's
CELLSPACING has collapsed on the right for no reason.
- 4) The
DIV's ALIGN="center" is being violated. The 1px-border subtable (the
content that is subject to the DIV) is not centered at all, but shifted
a bit toward the right.
- 5) the ALIGNs of the individual TDs in
the subtable are being being honored, which is good, and they
demonstrate that space for the images has in fact been reserved. If
you compare Amaya's rendering with that of any other browser, you'll
see that the arrangement of the text in the blue table cells is
precisely the same. There is enough room for the text and the ....'s
that follow it AND the image. But the image just isn't there, it's way
off in right-field. The text in the white cells helps show this,
too.
- 6) The images' ALIGN attributes are being violated. NO
MATTER WHAT the TD chooses for its own ALIGN, and ALIGN="right" on an
image means the images goes as far right as possible. But you can see
that the TD ALIGN attributes of the first three blue cells have in fact
altered the relative positions of the images, all of which should be
flush right inside their table cells, and even within the overall bug
of them not being in the table and being off in a strange far-right
space, they should be flush-right against the edge of that right-hand
limbo.
- 7) Removal of the outer 5px-bordered table has a very
interesting effect. It not only doesn't make the problem go away, it
makes it worse! All of a sudden the inner (now sole) table leaps to
the far right of the ACTUAL canvas, stopping where the HR did!
Removing the DIV as well as no additional effect.
- 8) If you
have removed the outer table and reloaded the document, if you reload
it again, the page lurches downward just a little, occluding part of
the "Home" cell. This behavior has been 100% repeatable for me. Moving
back up to the top and reloading doesn't help.
- 9) On putting
the outer table back in and reloading the same thing happens, but if
you scroll back to the top of the document (not very far - what, maybe
30 pixels?) and THEN reload, the document displays normally again and
this downward mini-jump doesn't happen any more.
- 10) If you
change the HREFs of the images to point to non-existent files, the core
problem still happens - the document is about 3x wider than it should
be with "dead space" that isn't actually a part of the document at all.
And another problem shows up: The ALT text (just "<" or ">"
depending on which cell you are looking at) shows up to the LEFT of the
document. ALT text is supposed to take the exact place and position of
the image it is substituting for. I've yet to ever see any other
browser mess this one up. I tested this very coder in 18 other
browsers today (effectively more like 9 or 10 - a bunch were Mozilla
variants and a bunch more were Safari variants), and not one of them
put the ALT text on the left of the menu text.
- 11) If you
change all the images' ALIGNs to "left", the document does size
normally, but again we see that Safari is not honoring the image's
ALIGN attribute, which supercedes that of the TD - the cell with
ALIGN="center" has illegally pulled the image in that cell toward the
center.
- 12) And finally removing all the SPAN elements makes
the problem go away
completely. The images show up precisely where
they should, the document is the correct width, the table isn't
mangled, etc. This seems to demonstrate that Amaya has a serious CSS
bug here. The entire stylesheet consists of a single class that sets
font options for text that it applies to. There is no reason at all
for this to affect the placement of images! The way Amaya is behaving
now, if you were to create a DIV or SPAN for font-related hooey to
apply to some text and you happen to have an image inlined in the same
paragraph, all hell's going to break loose. Well, at least I tracked
it down even if I can't fix it.
- NOTE: The last blue cell puts
the IMG and the text inside a P container. I tried this as a test to
see whether the problem I reported yesterday might be involved, but it
doesn't seem to be (namely, that Amaya appeared to be applying the "IMG
must be inside a block element such as P" rules of the strict DTD to
the loose DTD by mistake.) Doesn't seem to be the issue, or that
cell's image should be where it belongs.
- NOTE:) The
penultimate blue cell is different from the others, too, in having no
ALIGN and no NOWRAP attributes. These changes have no
effect.
[All text from
this marker back up to the first one, inclusive, can be removed and the
bugs are still there.
This text does not affect them in any
way.]
Home....
Menu Widget....