Giuseppe Craparotta wrote: > Georg, > > thank you very much, your tooltip code works amazingly well in all > browsers apart from... Opera 9.10!, where the tooltip still looks > terribly buggy and the position:static to the <li> moves the "works" > links in a improbable spot... Besides, in all browsers apart from IE > the tooltip is abruply interrupted when the ul ends. Any remedy for > that? :-)
Yes, don't declare 'overflow: hidden' on the ul, as it will of course hide the overflow in all decent browsers. As for Opera: that browser has a few bugs related to pop-ups. There are a few fixes that usually work well, but they are case-dependent - I don't know which one to apply for your case since you are still applying changes to that layout. > But hey, I'm still very grateful! Are you maybe curious to see what > the fixes can be? If I discover something I'll let the list know. > > Go to the page from here: > http://www.giuseppecraparottacv.co.uk/work-web-test-works-absolute.html > > Now Georg, let me make you few questions for the Knowledge... > > 1) USE OF STATIC POSITIONING your fix revolves around the use of > position:static . To make you laugh I quote here David Sawyer Mc > Farland, whose I've read the very good CSS book: "Why would you want > to assign an element static positioning? The short answer: You > probably never will" (CSS The Missing Manual, Chapter 12). Is there > any rationale behind the use of static? Isn't static the default > value? Why does it make the tooltip display on top? 'position: static' resets the relevant elements to neutral stacking, and I declared it to "force" the containers back to default for that effect. I overrode your styles instead of replacing them, and I expected you to go through your styles and change the relevant ones, after which the 'static' value becomes completely redundant in your case. Default-values should definitely not be written off for any property. There are actually quite a few cases where I would declare 'position: static', even though it is the default-value. - One such case is related to some variants of "hover-freeze" and "stacking" bugs in IE/win when absolute and relative positioning is used, where I'd change the position-value to 'static' on ':link' and ':visited' to break the bugs. - Another case is when I use selectors to target nested elements, like... #ID * {position: relative;} #ID * * {position: static;} #ID * * * {position: absolute;} #ID * * * * {position: static;} ...where I have to declare values on all elements down the chain in order to hit only the right ones with the intended positioning-value. - Yet another case is when an element is positioned "off screen" using something like 'position: absolute; top: -10000px; left: -10000px'. Changing that to 'position: static' - maybe on ':hover' - is an efficient short-cut for pulling the element back onto the screen and make it fill up its space in the content or menu, since static elements ignore positions. I can then for example float the element, and pull in backside margins to perfectly control how much space is occupied by the element when it _is_ visible on screen - something that is impossible with 'position: absolute'. All this is possible because certain properties/values take precedence over other properties/values. Changing the value for one property is thereby enough to turn on or off a whole range of properties/values that only work when specific properties/values are "true" - in accordance with CSS standards. > 2) DISPLAY:INLINE TO THE "WORKS" <A> Any particular reason to specify > that? <a> is inline as default. On the other hand, the floating > transforms it in a block element. I removed display:inline and the > code still works. Any comment? 1: I floated '.works', and floats _always_ become 'block-level'. 2: the addition of 'display: inline' does not change the float from 'block' to 'inline', but it "kills" IE6' "margin-doubling on floats" bug. In short: 'display: inline' doesn't make sense here, but it works :-) > 3)HEIGHT:AUTO!IMPORTANT IN .POPUP SPAN I also got rid of that, > assuming you added it to correct the aspect of the tooltip, due to > the height value given by me. But that was just provisory :-) . Yes, once the original value is changed or removed, the !important becomes unnecessary. > 4) MARGIN: -1.4EM 10% 0 0 Why do you place the .works using both ems > and percentages? Any advantage from the promiscuity? I think so - and I use such combinations regularly. 1: '.works' will be moved up depending on font-size, making its position relatively stable under font-resizing stress. (Necessary in the original case, but not now.) 2: '.works' will stay "10% of the width of its container" away from the right edge of same container, independent of font-size. Now, it looks like you have altered quite a lot since I added fixes to the original, so most of my fixes don't suit the case anymore and have to be redone anyway. regards Georg -- http://www.gunlaug.no ______________________________________________________________________ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
