«

This stuff is getting on my nerves ;/

I am trying to create a graphical variable size "button" that encapsulates a
fixed position ul for a menu. I cannot get it to work at all.


The button consists of 2 images for the right corners, one images for the
bottom, one for the right most side, and the last for the filler.

You can check it out by hover over one of the links at

http://www.jonslaughter.com/MyPage.html


I want to add corners to the sub menu along with a shadow at the bottom.

I have the graphics and I've been trying for the last 2 hours to get
something to work but everything comes out wrong because I cannot position
absolutely to the fixed position container that holds the ul.

http://www.jonslaughter.com/Test.html


What I need to know is how nested containers with different combinations of
positions work. On my sub menu with a position:fixed and if I do
position:absolute on any element contained in it then my coordinates always
end up relative to viewport.

I've tried many things..

if I do something like

<div style="position:fixed">
<div style="position:relative">
</div></div>

and in the second div dot he coordinates refer relative to the fixed
container of the first? When I do stuff like that in my original code it
totally screws up the menu. That is, I have to have the sub menu as fixed
but when I try to create a container inside that that has relative coords it
then screws up.

Maybe I need to specify something else besides display:inline or block?

This crap is driving me nuts ;/

Thanks for any help,
Jon

On 2007-04-16, Jon Slaughter <> wrote:
[...]
> What I need to know is how nested containers with different combinations of
> positions work. On my sub menu with a position:fixed and if I do
> position:absolute on any element contained in it then my coordinates always
> end up relative to viewport.
>
> I've tried many things..
>
> if I do something like
>
><div style="position:fixed">
><div style="position:relative">
></div></div>
>
> and in the second div dot he coordinates refer relative to the fixed
> container of the first? When I do stuff like that in my original code it
> totally screws up the menu. That is, I have to have the sub menu as fixed
> but when I try to create a container inside that that has relative coords it
> then screws up.
>
> Maybe I need to specify something else besides display:inline or block?

If you set position: fixed or position: absolute, you get display: block
whatever you specify.

absolute: origin is containing block infimum point (containing block is
generally nearest ancestor with position of anything except static)

fixed: origin is viewport infimum.

relative: origin is infimum of normal-flow box.

Yes the terms are very confusingly named. Relative is the odd one out--
the box is flowed normally, and then offset at the last minute from its
normal-flow position, leaving a gap where it was.

http://www.jonslaughter.com/Test2.html

The boxes represent the partition that I need. The issue seems to be that I
have to specify a height for it or it doesn't work. I thought that the
outer most div would calculate the height but it doesn't seem to do this.

For my application I can't(or don't) want to specify the height because it
should be able to compute it automatically. Its just the height of the ul
inside the divs + a few pixels for the border(in the example its 20px +
height of ul).

It looks like I'm going to have to do that though for each sub menu I have.
Is there any way to get the user agent to calculate it for me? (specifying
anying absolute fixed height isn't good as I have to do it for each time I
use the box. Specifying auto doesn't work either)

Thanks,
Jon

"Ben C" <> wrote in message
news:...
> On 2007-04-16, Jon Slaughter <> wrote:
> [...]
>> What I need to know is how nested containers with different combinations
>> of
>> positions work. On my sub menu with a position:fixed and if I do
>> position:absolute on any element contained in it then my coordinates
>> always
>> end up relative to viewport.
>>
>> I've tried many things..
>>
>> if I do something like
>>
>><div style="position:fixed">
>><div style="position:relative">
>></div></div>
>>
>> and in the second div dot he coordinates refer relative to the fixed
>> container of the first? When I do stuff like that in my original code it
>> totally screws up the menu. That is, I have to have the sub menu as fixed
>> but when I try to create a container inside that that has relative coords
>> it
>> then screws up.
>>
>> Maybe I need to specify something else besides display:inline or block?
>
> If you set position: fixed or position: absolute, you get display: block
> whatever you specify.

? You mean as a default or that I cannot change it? If I use display:inline
it works and looks different, atleast in FireFox, than display:block. The
block shifted down while the inline is not.


> absolute: origin is containing block infimum point (containing block is
> generally nearest ancestor with position of anything except static)
>
> fixed: origin is viewport infimum.
>
> relative: origin is infimum of normal-flow box.
>
> Yes the terms are very confusingly named. Relative is the odd one out--
> the box is flowed normally, and then offset at the last minute from its
> normal-flow position, leaving a gap where it was.

What I'm having trouble is, is how they inherit the positioning from there
parent containers. I wasn't sure if it was inheriting or not before but my
simple example seems to work(See other post). The issue seems to be that I
have to specify the height because the user agent isn't calculating it for
me the way I thought it would. I can specify the height but I'd rather not
if possible.

Thanks,
Jon

Jon Slaughter wrote:
> "Ben C" <> wrote in message
> news:...
>> On 2007-04-16, Jon Slaughter <> wrote:

>>>
>>> Maybe I need to specify something else besides display:inline or block?
>> If you set position: fixed or position: absolute, you get display: block
>> whatever you specify.
>
> ? You mean as a default or that I cannot change it? If I use display:inline
> it works and looks different, atleast in FireFox, than display:block. The
> block shifted down while the inline is not.
>

Floats, absolutely positioned elements, inline-blocks, table-cells,
table-captions, and elements with 'overflow' other than 'visible'
(except when that value has been propagated to the viewport) establish
new block formatting contexts.

http://www.w3.org/TR/CSS21/visuren.html#q15

You could save yourself and us a lot of grief if you study up a bit on CSS.


--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

Jon Slaughter wrote:
> http://www.jonslaughter.com/Test2.html

Why don't you use border properties for the bars across the top/bottom
and down the sides? It would be much simpler than using all those divs.
They're only pretending to be borders anyway.

--
Berg

"Jonathan N. Little" <> wrote in message
news:6d47f$4623f2d1$40cba7c7$...
> Jon Slaughter wrote:
>> "Ben C" <> wrote in message
>> news:...
>>> On 2007-04-16, Jon Slaughter <> wrote:
>
>>>>
>>>> Maybe I need to specify something else besides display:inline or block?
>>> If you set position: fixed or position: absolute, you get display: block
>>> whatever you specify.
>>
>> ? You mean as a default or that I cannot change it? If I use
>> display:inline it works and looks different, atleast in FireFox, than
>> display:block. The block shifted down while the inline is not.
>>
>
> Floats, absolutely positioned elements, inline-blocks, table-cells,
> table-captions, and elements with 'overflow' other than 'visible' (except
> when that value has been propagated to the viewport) establish new block
> formatting contexts.
>
> http://www.w3.org/TR/CSS21/visuren.html#q15
>
> You could save yourself and us a lot of grief if you study up a bit on
> CSS.
>
>

****. I'm reading the css spec now. You seem to have to point out every time
someone wants some help(or just me specifically) to go somewhere else. If
you don't like me asking questions then thats just tough cause you can't do
a damn thing about it but bitch.

"Bergamot" <> wrote in message
news:...
> Jon Slaughter wrote:
>> http://www.jonslaughter.com/Test2.html
>
> Why don't you use border properties for the bars across the top/bottom
> and down the sides? It would be much simpler than using all those divs.
> They're only pretending to be borders anyway.
>

Yes but it doesn't look as good. I went ahead and sorta hard coded the stuff
and the results are almost exactly what I want:

http://www.jonslaughter.com/MyPage.html



But I need to somehow shift the sub menu boxes up a few pixes to make them
look better. Every time I do something like top:-10px it absolutely offsets
it from the top of the browser. Its so damn annoying.



Thanks,

Jon

"Jon Slaughter" <> wrote in message
news:FFTUh.17144$. net...
>
> "Bergamot" <> wrote in message
> news:...
>> Jon Slaughter wrote:
>>> http://www.jonslaughter.com/Test2.html
>>
>> Why don't you use border properties for the bars across the top/bottom
>> and down the sides? It would be much simpler than using all those divs.
>> They're only pretending to be borders anyway.
>>
>
> Yes but it doesn't look as good. I went ahead and sorta hard coded the
> stuff and the results are almost exactly what I want:
>
> http://www.jonslaughter.com/MyPage.html
>
>
>
> But I need to somehow shift the sub menu boxes up a few pixes to make them
> look better. Every time I do something like top:-10px it absolutely
> offsets it from the top of the browser. Its so damn annoying.
>
>

OK, nevermind. I got it. CSS is a ****ing mess. I don't know why I have to
nest divs of different position types just to get a relative addressing in
absolute mode off the current content block.

To shift the things I had to encause the menu's in two divs, on in relative
positioning and the other in absolute. If I just did one or the other it
wouldn't work ;/


crap... in IE the shifting screws it up. IE seems to only shift 1/2 of what
firefox does ;/ guess I can solve it with a conditional shift.


Thanks,
Jon

Jon Slaughter wrote:
> "Jonathan N. Little" <> wrote in message
> news:6d47f$4623f2d1$40cba7c7$...
>> Jon Slaughter wrote:
>>> "Ben C" <> wrote in message
>>> news:...
>>>> On 2007-04-16, Jon Slaughter <> wrote:
>>>>> Maybe I need to specify something else besides display:inline or block?
>>>> If you set position: fixed or position: absolute, you get display: block
>>>> whatever you specify.
>>> ? You mean as a default or that I cannot change it? If I use
>>> display:inline it works and looks different, atleast in FireFox, than
>>> display:block. The block shifted down while the inline is not.
>>>
>> Floats, absolutely positioned elements, inline-blocks, table-cells,
>> table-captions, and elements with 'overflow' other than 'visible' (except
>> when that value has been propagated to the viewport) establish new block
>> formatting contexts.
>>
>> http://www.w3.org/TR/CSS21/visuren.html#q15
>>
>> You could save yourself and us a lot of grief if you study up a bit on
>> CSS.
>>
>>
>
> ****. I'm reading the css spec now. You seem to have to point out every time
> someone wants some help(or just me specifically) to go somewhere else. If
> you don't like me asking questions then thats just tough cause you can't do
> a damn thing about it but bitch.
>
>
1) This is not a help desk but a discussion group.
2) I have been trying to direct you to where you might learn something
that could help you.
3) Just love your bubbly cheerful demeanor!

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com