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