Sent by Gunlaug_Sørtun on 28 December 2007 15:03
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-REMOVED]]
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/
