Re: [css-d] overflow boxes next to floats
2010/3/22 Bruno Fassino fass...@gmail.com: ... The spec deliberately not very precise about these cases. At http://www.w3.org/TR/CSS21/visuren.html#bfc-next-to-float there is CSS2 does not define when a UA may put said element next to the float or by how much said element may become narrower So the UA are allowed to make those bfc narrower as they like :-) The other day, Tab Atkins Jr. explained what that means Often, does not define in CSS 2.1 means browsers did all sorts of crazy things, and we decided not to try and stabilize the behavior at this time. http://www-style.markmail.org/thread/f54zkhvd2jvrtzd6 Ingo __ css-discuss [cs...@lists.css-discuss.org] 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/
Re: [css-d] overflow boxes next to floats
On Tue, Mar 23, 2010 at 1:20 AM, Philippe Wittenbergh e...@l-c-n.com wrote: On Mar 23, 2010, at 12:27 AM, Bruno Fassino wrote: Moreover, the spec now says: the _border box_ of a table, block-level replaced element, or element in the normal flow that establishes a new block formatting context must not overlap any floats in the same block formatting context. They mention the border box and not the margin box, so at least on the same side of the float, ignoring a negative margin is probably not so wrong? That part is the correct behaviour, I think. If you give the box a (small) positive margin on the same side of the float, it will be ignored. If that margin is larger than the width of the float, it will be visible (Firefox 2.0 , IE 7 were all wrong; to be fair to Fx 2.0, the spec changed after it was released). Yes, with positive margins there is more consistency amongst modern browsers. The only anomaly that I see, with positive margin on the same side of the float, is that Safari 4 makes the b.f.c. box narrower than necessary, so there is a gap on the other side of the float, see http://brunildo.org/test/FloatMarginOverflow.html . Of course this is allowed by the spec. Thierry wrote: The problem for us is that this behavior is different across browsers (but what else is new?). and Ingo: The other day, Tab Atkins Jr. explained what that means Often, does not define in CSS 2.1 means browsers did all sorts of crazy things, and we decided not to try and stabilize the behavior at this time. Well, at least I see now a bit more consistency than few years ago :-) Bruno -- Bruno Fassino http://www.brunildo.org/test __ css-discuss [cs...@lists.css-discuss.org] 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/
Re: [css-d] overflow boxes next to floats
On Mar 23, 2010, at 11:46 PM, Bruno Fassino wrote: Yes, with positive margins there is more consistency amongst modern browsers. The only anomaly that I see, with positive margin on the same side of the float, is that Safari 4 makes the b.f.c. box narrower than necessary, so there is a gap on the other side of the float, see http://brunildo.org/test/FloatMarginOverflow.html . Of course this is allowed by the spec. The phantom margin/gap on the opposite side of the float (on the right of the BFC with your left-margin + float:left) ? I don't think that is allowed by the spec. And it is considered a bug by at least some people of the WebKit community. http://bugs.webkit.org/show_bug.cgi?id=19123 Philippe --- Philippe Wittenbergh http://l-c-n.com/ __ css-discuss [cs...@lists.css-discuss.org] 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/
Re: [css-d] overflow boxes next to floats
On Tue, Mar 23, 2010 at 4:02 PM, Philippe Wittenbergh e...@l-c-n.com wrote: On Mar 23, 2010, at 11:46 PM, Bruno Fassino wrote: Yes, with positive margins there is more consistency amongst modern browsers. The only anomaly that I see, with positive margin on the same side of the float, is that Safari 4 makes the b.f.c. box narrower than necessary, so there is a gap on the other side of the float, see http://brunildo.org/test/FloatMarginOverflow.html . Of course this is allowed by the spec. The phantom margin/gap on the opposite side of the float (on the right of the BFC with your left-margin + float:left) ? I don't think that is allowed by the spec. And it is considered a bug by at least some people of the WebKit community. http://bugs.webkit.org/show_bug.cgi?id=19123 Yes, exactly that (and your bug report is almost two year old :-) It is surely undesirable. The reason I said it is allowed is that the spec at http://www.w3.org/TR/CSS21/visuren.html#bfc-next-to-float, says CSS2 does not define ... by how much said element may become narrower. So making a b.f.c. arbitrarily narrower than defined by section 10.3.3 is not prohibited (and when the box is made narrower than strictly required by the presence of float and margins, we have those phantom margins/gaps on one side or another, ). Of course this is an attempt of a formal reading of the spec. I consider that a bug :-) Best, Bruno -- Bruno Fassino http://www.brunildo.org/test __ css-discuss [cs...@lists.css-discuss.org] 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/
Re: [css-d] overflow boxes next to floats
Bruno Fassino wrote: The behavior of 'block formatting context roots' in presence of float is not exactly defined in the spec, however all modern browsers usually display them beside the float, making them narrower. I've recently noticed a strange behavior, both in Firefox 3+ and IE8, occurring with boxes having overflow different from visible. Assume there is a right float and then an overflow box with a negative left margin. The box is rendered beside the float, but its margin is ignored in Firefox 3+ and IE8. More details and test cases here [1]. I don't see any reason for such behavior, which looks simply wrong. The strange thing is that it did not occur in Firefox 2 and IE7, so I wonder if it could be intended. Has someone any ideas? Regards, Bruno [1] http://brunildo.org/test/bfc-neg-marg-float.html I not sure why this happens. I see that moving the position of the overflow box by a top margin (positive or negative) causes the overflow box to not ignore the left margin with -100px and for the overflow box not to be shorten by the float [1]. The last test with the overflow box with margin-top:-0.01em doesn't seem to be any lower visually. 1. http://css-class.com/test/temp/overflow-floats-neg-margins.htm -- Alan http://css-class.com/ Armies Cannot Stop An Idea Whose Time Has Come. - Victor Hugo __ css-discuss [cs...@lists.css-discuss.org] 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/
Re: [css-d] overflow boxes next to floats
Hi Bruno, The behavior of 'block formatting context roots' in presence of float is not exactly defined in the spec, however all modern browsers usually display them beside the float, making them narrower. I've recently noticed a strange behavior, both in Firefox 3+ and IE8, occurring with boxes having overflow different from visible. Assume there is a right float and then an overflow box with a negative left margin. The box is rendered beside the float, but its margin is ignored in Firefox 3+ and IE8. More details and test cases here [1]. I don't see any reason for such behavior, which looks simply wrong. The strange thing is that it did not occur in Firefox 2 and IE7, so I wonder if it could be intended. Has someone any ideas? [1] http://brunildo.org/test/bfc-neg-marg-float.html Thanks for this. It is really strange/weird and seems to be the case for *both* sides of the box, not just the one opposite to the float. Did you try to apply a negative margin on the right *and* left sides of these block formatting contexts? -- Regards, Thierry www.tjkdesign.com | articles and tutorials www.ez-css.org | ultra light CSS framework __ css-discuss [cs...@lists.css-discuss.org] 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/
Re: [css-d] overflow boxes next to floats
Hi Alan, The behavior of 'block formatting context roots' in presence of float is not exactly defined in the spec, however all modern browsers usually display them beside the float, making them narrower. I've recently noticed a strange behavior, both in Firefox 3+ and IE8, occurring with boxes having overflow different from visible. Assume there is a right float and then an overflow box with a negative left margin. The box is rendered beside the float, but its margin is ignored in Firefox 3+ and IE8. More details and test cases here [1]. I don't see any reason for such behavior, which looks simply wrong. The strange thing is that it did not occur in Firefox 2 and IE7, so I wonder if it could be intended. Has someone any ideas? [1] http://brunildo.org/test/bfc-neg-marg-float.html I not sure why this happens. I see that moving the position of the overflow box by a top margin (positive or negative) causes the overflow box to not ignore the left margin with -100px and for the overflow box not to be shorten by the float [1]. The last test with the overflow box with margin-top:-0.01em doesn't seem to be any lower visually. 1. http://css-class.com/test/temp/overflow-floats-neg-margins.htm Another weird one. The top margin seems to disabled the block formatting context (it does not make the box shorter for the float). Imho, that one goes against the spec. -- Regards, Thierry www.tjkdesign.com | articles and tutorials www.ez-css.org | ultra light CSS framework __ css-discuss [cs...@lists.css-discuss.org] 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/
Re: [css-d] overflow boxes next to floats
Hi Alan and Thierry, On Mon, Mar 22, 2010 at 4:13 PM, Thierry Koblentz thierry.koble...@gmail.com wrote: Hi Alan, The behavior of 'block formatting context roots' in presence of float is not exactly defined in the spec, however all modern browsers usually display them beside the float, making them narrower. I've recently noticed a strange behavior, both in Firefox 3+ and IE8, occurring with boxes having overflow different from visible. Assume there is a right float and then an overflow box with a negative left margin. The box is rendered beside the float, but its margin is ignored in Firefox 3+ and IE8. More details and test cases here [1]. I don't see any reason for such behavior, which looks simply wrong. The strange thing is that it did not occur in Firefox 2 and IE7, so I wonder if it could be intended. Has someone any ideas? [1] http://brunildo.org/test/bfc-neg-marg-float.html I not sure why this happens. I see that moving the position of the overflow box by a top margin (positive or negative) causes the overflow box to not ignore the left margin with -100px and for the overflow box not to be shorten by the float [1]. The last test with the overflow box with margin-top:-0.01em doesn't seem to be any lower visually. 1. http://css-class.com/test/temp/overflow-floats-neg-margins.htm Another weird one. The top margin seems to disabled the block formatting context (it does not make the box shorter for the float). Imho, that one goes against the spec. Yes, in the case with small negative top margin, Firefox seems to no more see the float. And this seems against the spec. (the case with top margin greater that the float, it's OK because the box is already below the float). Best, Bruno -- Bruno Fassino http://www.brunildo.org/test __ css-discuss [cs...@lists.css-discuss.org] 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/
Re: [css-d] overflow boxes next to floats
On Mon, Mar 22, 2010 at 4:00 PM, Thierry Koblentz thierry.koble...@gmail.com wrote: Hi Bruno, I've recently noticed a strange behavior, both in Firefox 3+ and IE8, occurring with boxes having overflow different from visible. Assume there is a right float and then an overflow box with a negative left margin. The box is rendered beside the float, but its margin is ignored in Firefox 3+ and IE8. More details and test cases here [1]. I don't see any reason for such behavior, which looks simply wrong. The strange thing is that it did not occur in Firefox 2 and IE7, so I wonder if it could be intended. Has someone any ideas? [1] http://brunildo.org/test/bfc-neg-marg-float.html Thanks for this. It is really strange/weird and seems to be the case for *both* sides of the box, not just the one opposite to the float. Did you try to apply a negative margin on the right *and* left sides of these block formatting contexts? I see indeed that Firefox ignores a negative margin on the same side of the float as well. The spec deliberately not very precise about these cases. At http://www.w3.org/TR/CSS21/visuren.html#bfc-next-to-float there is CSS2 does not define when a UA may put said element next to the float or by how much said element may become narrower So the UA are allowed to make those bfc narrower as they like :-) Moreover, the spec now says: the _border box_ of a table, block-level replaced element, or element in the normal flow that establishes a new block formatting context must not overlap any floats in the same block formatting context. They mention the border box and not the margin box, so at least on the same side of the float, ignoring a negative margin is probably not so wrong? Best, Bruno -- Bruno Fassino http://www.brunildo.org/test __ css-discuss [cs...@lists.css-discuss.org] 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/
Re: [css-d] overflow boxes next to floats
I see indeed that Firefox ignores a negative margin on the same side of the float as well. The spec deliberately not very precise about these cases. At http://www.w3.org/TR/CSS21/visuren.html#bfc-next-to-float there is CSS2 does not define when a UA may put said element next to the float or by how much said element may become narrower So the UA are allowed to make those bfc narrower as they like :-) Moreover, the spec now says: the _border box_ of a table, block-level replaced element, or element in the normal flow that establishes a new block formatting context must not overlap any floats in the same block formatting context. They mention the border box and not the margin box, so at least on the same side of the float, ignoring a negative margin is probably not so wrong? I see... This is very interesting. They can't use the term margin box since it is the implicit *margin* that escapes the float, but then the term border box explains this behavior pretty well (at least according to the spec). The problem for us is that this behavior is different across browsers (but what else is new?). -- Regards, Thierry www.tjkdesign.com | articles and tutorials www.ez-css.org | ultra light CSS framework __ css-discuss [cs...@lists.css-discuss.org] 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/
Re: [css-d] overflow boxes next to floats
On Mar 23, 2010, at 12:27 AM, Bruno Fassino wrote:
The behavior of 'block formatting context roots' in presence of float
is not exactly defined in the spec, however all modern browsers
usually display them beside the float, making them narrower.
I've recently noticed a strange behavior, both in Firefox 3+ and IE8,
occurring with boxes having overflow different from visible. Assume
there is a right float and then an overflow box with a negative left
margin. The box is rendered beside the float, but its margin is
ignored in Firefox 3+ and IE8. More details and test cases here [1].
I don't see any reason for such behavior, which looks simply wrong.
The strange thing is that it did not occur in Firefox 2 and IE7, so I
wonder if it could be intended. Has someone any ideas?
[1] http://brunildo.org/test/bfc-neg-marg-float.html
I not sure why this happens. I see that moving the position of the
overflow box by a top margin (positive or negative) causes the
overflow box to not ignore the left margin with -100px and for the
overflow box not to be shorten by the float [1]. The last test with
the overflow box with margin-top:-0.01em doesn't seem to be any lower
visually.
1. http://css-class.com/test/temp/overflow-floats-neg-margins.htm
Another weird one. The top margin seems to disabled the block formatting
context (it does not make the box shorter for the float). Imho, that one
goes against the spec.
Yes, in the case with small negative top margin, Firefox seems to no
more see the float. And this seems against the spec.
(the case with top margin greater that the float, it's OK because the
box is already below the float).
That is not limited to only Gecko (tested 1.9.2/Fx3.6 and the latest nightly
1.9.3a pre). I see the same behaviour with recent WebKit nightly builds, Safari
4.05 and Opera 10.5.
I tested this with
.box { margin-top:-.1em; }
Two other observations:
1. When I make the window small enough, Gecko moves the blue BFC box that has a
width applied to the left/right (test case 6a/6b). The window must be small
enough that the width of the box is larger than the available space.
2. Nightly WebKit builds: the blue BFC box with auto width and negative margin
is dropped below the floated box. This is different from what Safari 4.05 does
(this is also visible with the latest Chrome build on OS X - 5.0.356.2).
Bruno:
I see indeed that Firefox ignores a negative margin on the same side
of the float as well.
...
Moreover, the spec now says:
the _border box_ of a table, block-level replaced element, or element
in the normal flow that establishes a new block formatting context
must not overlap any floats in the same block formatting context.
They mention the border box and not the margin box, so at least on
the same side of the float, ignoring a negative margin is probably not
so wrong?
That part is the correct behaviour, I think. If you give the box a (small)
positive margin on the same side of the float, it will be ignored. If that
margin is larger than the width of the float, it will be visible (Firefox 2.0 ,
IE 7 were all wrong; to be fair to Fx 2.0, the spec changed after it was
released).
With a negative margin, WebKit and Safari 4.05 do some strange things.
I don't have any good explanation for all that negative margin behaviour. Yet…
Philippe
---
Philippe Wittenbergh
http://l-c-n.com/
__
css-discuss [cs...@lists.css-discuss.org]
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/
Re: [css-d] overflow not working with column heights fix - all browsers
I'm working on a local machine with a local web server installed, so I won't be able to show you what I have so far, sorry. I can certainly put up more code if you think it helps. Eugene On Tue, Feb 23, 2010 at 6:53 PM, Philippe Wittenbergh e...@l-c-n.comwrote: On Feb 24, 2010, at 3:04 AM, Eugene Hourany wrote: The issue isn't the equal height columns, it's that I can't get the inner div to have its own scrollbar without having the browser window be scrollable. I'm trying to replicate this http://theportalgrp.com website. can you post of url of what you currently have ? That might easier to work with. The url you link to is an all flash site, can't view it. sorry. ps- bottom posting please. Philippe --- Philippe Wittenbergh http://l-c-n.com/ __ css-discuss [cs...@lists.css-discuss.org] 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/
Re: [css-d] overflow not working with column heights fix - all browsers
The issue isn't the equal height columns, it's that I can't get the inner div to have its own scrollbar without having the browser window be scrollable. I'm trying to replicate this http://theportalgrp.com website. Thanks, Eugene On Mon, Feb 22, 2010 at 11:32 PM, Philippe Wittenbergh e...@l-c-n.comwrote: On Feb 23, 2010, at 4:25 AM, Eugene Hourany wrote: I am using the overflow property on a container div to get the css same height trick http://www.ejeliot.com/blog/61 to work. It works, but now I can't have the div itself have the scrollbar visible when content overflows. Instead, what happens is that the whole browser window is scrollable, which in IE 6/7 not only breaks the equal height column trick, but also prevents me from having that inner content div from scrolling. I tried setting the overflow-x and y properties to hidden and auto, respectively, but that didn't solve the problem either. Try this http://www.positioniseverything.net/articles/onetruelayout/equalheight but read this also http://www.positioniseverything.net/articles/onetruelayout/appendix/equalheightproblems or try this http://www.satzansatz.de/cssd/companions.html Philippe --- Philippe Wittenbergh http://l-c-n.com/ __ css-discuss [cs...@lists.css-discuss.org] 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/
Re: [css-d] overflow not working with column heights fix - all browsers
On Feb 24, 2010, at 3:04 AM, Eugene Hourany wrote: The issue isn't the equal height columns, it's that I can't get the inner div to have its own scrollbar without having the browser window be scrollable. I'm trying to replicate this http://theportalgrp.com website. can you post of url of what you currently have ? That might easier to work with. The url you link to is an all flash site, can't view it. sorry. ps- bottom posting please. Philippe --- Philippe Wittenbergh http://l-c-n.com/ __ css-discuss [cs...@lists.css-discuss.org] 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/
Re: [css-d] overflow not working with column heights fix - all browsers
On Feb 23, 2010, at 4:25 AM, Eugene Hourany wrote: I am using the overflow property on a container div to get the css same height trick http://www.ejeliot.com/blog/61 to work. It works, but now I can't have the div itself have the scrollbar visible when content overflows. Instead, what happens is that the whole browser window is scrollable, which in IE 6/7 not only breaks the equal height column trick, but also prevents me from having that inner content div from scrolling. I tried setting the overflow-x and y properties to hidden and auto, respectively, but that didn't solve the problem either. Try this http://www.positioniseverything.net/articles/onetruelayout/equalheight but read this also http://www.positioniseverything.net/articles/onetruelayout/appendix/equalheightproblems or try this http://www.satzansatz.de/cssd/companions.html Philippe --- Philippe Wittenbergh http://l-c-n.com/ __ css-discuss [cs...@lists.css-discuss.org] 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/
Re: [css-d] overflow problem in IE
Georg,
Thank you very much. It is already good enough, i am satisfied with the
result. Thank you!
Paul
- Original Message -
From: Gunlaug Sørtun gunla...@c2i.net
To: Paul Jung et...@hotmail.com
Cc: css-d@lists.css-discuss.org
Sent: Thursday, December 25, 2008 12:17 AM
Subject: Re: [css-d] overflow problem in IE
Paul Jung wrote:
[...] As I observe it, it looks like that the long url address was
regarded as one inseparable word and thus was not text wrapped
according to the table width.
Browsers ability to break long words on certain characters varies, but
we can at least prevent the entire table from being expanded - in most
browsers - by adding something like...
.thrColFixHdr #sidebar2 .newreply table {
table-layout: fixed;
width: 100%;
}
Seems to have a reasonably good effect on your case in all browsers, so
at least all breakable text stays visible and readable within the width
of the column.
God Jul.
Georg
--
http://www.gunlaug.no
__
css-discuss [cs...@lists.css-discuss.org]
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/
__
css-discuss [cs...@lists.css-discuss.org]
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/
Re: [css-d] overflow problem in IE
Thank you very much, but it didn't solve the problem, please look
http://www.europeeurope.net/index.php?pageNum_Recordset2=8totalRows_Recordset2=4913
the same problem appears, is it a flowout problem? or text wrap problem? it
seems to me, that it can not deal with text wrap correctly, for example
there is a long url address
http://www.europeeurope.net/bbs/showthread.php?t=1... and it doesn't know
where to wrap the text
Thank you!
- Original Message -
From: David Laakso da...@chelseacreekstudio.com
To: Paul Jung et...@hotmail.com
Cc: css-d@lists.css-discuss.org
Sent: Tuesday, December 23, 2008 12:22 AM
Subject: Re: [css-d] overflow problem in IE
Paul Jung wrote:
I have a problem, it appears only in IE, here,
http://www.europeeurope.net/index.php?pageNum_Recordset2=7totalRows_Recordset2=4919
in this page, the layout just broken, the maincontent sank to the bottom.
Paul
It helps to state what browser version (there are a lot of them) of IE is
giving a problem. I guess you mean IE/5.01.
Try changing the CSS in the IE 5 conditional comment to read:
.thrColFixHdr #header {height: 1%;}
.thrColFixHdr #sidebar1 { width: 180px; }
.thrColFixHdr #sidebar2 { width: 190px; margin-left: 0; }
.thrColFixHdr #mainContent {width:520px; margin-left: 290px;margin-right:
20px;}
__
css-discuss [cs...@lists.css-discuss.org]
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/
__
css-discuss [cs...@lists.css-discuss.org]
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/
Re: [css-d] overflow problem in IE
Paul Jung wrote:
Thank you very much, but it didn't solve the problem, please look
http://www.europeeurope.net/index.php?pageNum_Recordset2=8totalRows_Recordset2=4913
the same problem appears, is it a flowout problem? or text wrap problem?
it seems to me, that it can not deal with text wrap correctly, for
example there is a long url address
http://www.europeeurope.net/bbs/showthread.php?t=1... and it doesn't
know where to wrap the text
Thank you!
Hello Paul, as David has suggested, it helps to indicate which version
of IE you are seeing the bug in since all versions of IE have different
bugs.
In you case, the bug is the IE expanding box bug [1]. I would say that
feeding IE6 and earlier this fix should solve the problem.
.row2 {width:200px} /* adjust width to suit */
I have not tested the fix.
[1] http://www.positioniseverything.net/explorer/expandingboxbug.html
--
Alan http://css-class.com/
Armies Cannot Stop An Idea Whose Time Has Come. - Victor Hugo
http://www.wearechange.org/
__
css-discuss [cs...@lists.css-discuss.org]
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/
Re: [css-d] overflow problem in IE
Paul Jung wrote:
Thank you very much, but it didn't solve the problem, please look
http://www.europeeurope.net/index.php?pageNum_Recordset2=8totalRows_Recordset2=4913
Note that IE5.0 won't react on zoom: 1; as 'hasLayout' trigger - it
needs a dimensional trigger like height: 1%;.
IE5.0 needs the 'hasLayout' trigger to #header David gave you, as a
stabilizer to avoid the dropped page problem.
You should also restrict the last conditional comment so it doesn't end
up styling all future IE/win versions.
For IE7 down through to IE5.01, you need (only) these basic corrections...
!--[if IE 5]
style type=text/css
.thrColFixHdr #sidebar2 { margin-left: 0;}
.thrColFixHdr #sidebar2 .newreply {width: 100%;}
/style
![endif]--
!--[if lte IE 7]
style type=text/css
.thrColFixHdr #mainContent, #header { height: 1%; margin: 0;}
.thrColFixHdr #sidebar1, .thrColFixHdr #sidebar2 {display: inline;}
#sidebar2 .newreply {width: 99%;}
/style
![endif]--
...and you will probably want to fix the width of the table in .newreply
to prevent it from overflowing its container and get cut off, which
seems to be a problem in all browsers.
regards
Georg
--
http://www.gunlaug.no
__
css-discuss [cs...@lists.css-discuss.org]
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/
Re: [css-d] overflow problem in IE
Georg,
Thank you very much in this Christmas season to help me! The codes you wrote
really solve the problem, but
...and you will probably want to fix the width of the table in .newreply
to prevent it from overflowing its container and get cut off, which
seems to be a problem in all browsers.
THat is another problem. I really have no idea how to fix. Do you have any
clue? As I observe it, it looks like that the long url address was regarded
as one inseparable word and thus was not text wrapped according to the table
width.
Such a normal action as text wrapping become a drag in dreamweaver.
Thank you! Merry Christmas!
Paul
- Original Message -
From: Gunlaug Sørtun gunla...@c2i.net
To: Paul Jung et...@hotmail.com
Cc: css-d@lists.css-discuss.org
Sent: Wednesday, December 24, 2008 2:22 PM
Subject: Re: [css-d] overflow problem in IE
Paul Jung wrote:
Thank you very much, but it didn't solve the problem, please look
http://www.europeeurope.net/index.php?pageNum_Recordset2=8totalRows_Recordset2=4913
Note that IE5.0 won't react on zoom: 1; as 'hasLayout' trigger - it
needs a dimensional trigger like height: 1%;.
IE5.0 needs the 'hasLayout' trigger to #header David gave you, as a
stabilizer to avoid the dropped page problem.
You should also restrict the last conditional comment so it doesn't end
up styling all future IE/win versions.
For IE7 down through to IE5.01, you need (only) these basic corrections...
!--[if IE 5]
style type=text/css
.thrColFixHdr #sidebar2 { margin-left: 0;}
.thrColFixHdr #sidebar2 .newreply {width: 100%;}
/style
![endif]--
!--[if lte IE 7]
style type=text/css
.thrColFixHdr #mainContent, #header { height: 1%; margin: 0;}
.thrColFixHdr #sidebar1, .thrColFixHdr #sidebar2 {display: inline;}
#sidebar2 .newreply {width: 99%;}
/style
![endif]--
...and you will probably want to fix the width of the table in .newreply
to prevent it from overflowing its container and get cut off, which
seems to be a problem in all browsers.
regards
Georg
--
http://www.gunlaug.no
__
css-discuss [cs...@lists.css-discuss.org]
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/
__
css-discuss [cs...@lists.css-discuss.org]
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/
Re: [css-d] overflow problem in IE
Paul Jung wrote:
I have a problem, it appears only in IE, here,
http://www.europeeurope.net/index.php?pageNum_Recordset2=7totalRows_Recordset2=4919
in this page, the layout just broken, the maincontent sank to the bottom.
Paul
It helps to state what browser version (there are a lot of them) of IE is
giving a problem. I guess you mean IE/5.01.
Try changing the CSS in the IE 5 conditional comment to read:
.thrColFixHdr #header {height: 1%;}
.thrColFixHdr #sidebar1 { width: 180px; }
.thrColFixHdr #sidebar2 { width: 190px; margin-left: 0; }
.thrColFixHdr #mainContent {width:520px; margin-left: 290px;margin-right:
20px;}
__
css-discuss [cs...@lists.css-discuss.org]
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/
Re: [css-d] Overflow and no
Jack Blankenships wrote: Any ideas on how to have an element's overflow property apply to some children but not to others? For example, I have a div that contains a table/grid that I want to have set to overflow: auto on a specific height. This way the results stay within a specific set of dimensions and do not push the rest of the layout into undesirable locations. The problem is that I also want to include some css tooltips for specific cells in this table/grid, some of which are large enough that I would like to expand them out of this standard boundary because they would be displayed above the layout content and disappear when :hover is not activated. Thanks, Jack Don't know out of my head. If the tooltip is absolutely positioned and the containing block (for example, another div with position:relative) for this absolute positioning is outside of the overflow-div ... but I fear the table limits that, since positioning inside a table is difficult ... we need an example page. It depends. Scrollbars on a block inside a browser window with scrollbars could be worse than pushing the layout a bit. Ingo -- http://www.satzansatz.de/css.html http://www.dolphinsback.com __ 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/
Re: [css-d] Overflow and no
At 11:14 AM -0600 on 10/7/08, Jack Blankenships wrote about [css-d] Overflow and no: Any ideas on how to have an element's overflow property apply to some children but not to others? For example, I have a div that contains a table/grid that I want to have set to overflow: auto on a specific height. This way the results stay within a specific set of dimensions and do not push the rest of the layout into undesirable locations. The problem is that I also want to include some css tooltips for specific cells in this table/grid, some of which are large enough that I would like to expand them out of this standard boundary because they would be displayed above the layout content and disappear when :hover is not activated. Thanks, Jack You might try creating a Class definition with the overflow setting you want for the special cells and add the class= parm to those cells. This SHOULD override the setting inherited from the div. -- Bob Rosenberg RockMUG Webmaster [EMAIL PROTECTED] www.RockMUG.org __ 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/
Re: [css-d] overflow: auto does not behave as I thought it would
Olivier Sannier wrote:
Well, yes, if I remove the padding, it shows up in SeaMonkey, but I need
the padding.
And I also checked the page on IE, it works just fine as I expect it to
work.
The issue I'm having is with SeaMonkey, so I suspect it is also showing
with FireFox 2
Anyone has any idea?
Answering myself here, I found the solution. The style was this :
div.miniadmin-content {
font-size : .9em;
max-height : 80px;
overflow : auto;
}
I simply added a width statement to get this :
div.miniadmin-content {
font-size : .9em;
max-height : 80px;
width: 100%;
overflow : auto;
}
And now the display is the same in IE and SeaMonkey.
You can see the result here:
http://obones.free.fr/cssbox/
Regards
Olivier
__
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/
Re: [css-d] overflow: auto does not behave as I thought it would
Well, yes, if I remove the padding, it shows up in SeaMonkey, but I need the padding. And I also checked the page on IE, it works just fine as I expect it to work. The issue I'm having is with SeaMonkey, so I suspect it is also showing with FireFox 2 Anyone has any idea? Thanks Olivier Susan Grossman wrote: On Wed, Sep 10, 2008 at 1:15 PM, Olivier Sannier [EMAIL PROTECTED] wrote: Hi all, I have a test page here: http://obones.free.fr/cssbox/ The miniadmin box should contain links that are visible inside an inner div that shows up a vertical scroll bar. However, as it is, the links are not visible at all and I don't really know how to make it behave the way I want. Any help would be much appreciated. Regards Olivier I think the issue is in box-title h1 If you remove padding: 10px;, then the text is visible.(you have padding declared, which covers right, and then padding-right declared again BTW) There's probably another issue since I don't know why. HTH Susan -- Susan R. Grossman [EMAIL PROTECTED] __ 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/ __ 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/
Re: [css-d] overflow: auto does not behave as I thought it would
On Wed, Sep 10, 2008 at 1:15 PM, Olivier Sannier [EMAIL PROTECTED] wrote: Hi all, I have a test page here: http://obones.free.fr/cssbox/ The miniadmin box should contain links that are visible inside an inner div that shows up a vertical scroll bar. However, as it is, the links are not visible at all and I don't really know how to make it behave the way I want. Any help would be much appreciated. Regards Olivier I think the issue is in box-title h1 If you remove padding: 10px;, then the text is visible.(you have padding declared, which covers right, and then padding-right declared again BTW) There's probably another issue since I don't know why. HTH Susan -- Susan R. Grossman [EMAIL PROTECTED] __ 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/
Re: [css-d] Overflow: hidden in IE?
On 3 Aug 2008, at 00:21, Jeff Ferrell wrote: On this page, again: http://www.rchseaglesnest.org -- about midway down is a sports section. It's using Bill Scott's ycarousel code (http://billwscott.com/carousel/ ) to do the sliding from side-to-side. The problem is, it works as expected in Firefox and Opera (the sliding boxes should be cut off before the sidebar) -- but in IE7, the div that *should* be hidden appears all the way across the page. (Well, that's inaccurate. It's actually hidden on the left side, but not on the right, which makes things more confusing, I think.) In Safari (Mac, at least), there's a different problem -- the sliding boxes appear as a 50px slice at the left-hand side of the Sports div. Hardly any of it is visible at all! Safari 2 Mac looks OK here. Which version shows the problem for you? The IE7 problem appears to stem from the widths generated as inline styles to the following divs div class=carousel-component id=mycarousel div class=carousel-clip-region In Firefox, Firebug shows width: 820px. In IE7 the developer toolbar shows width:1205px. If I remove the inline width property using the IE bar toolbar the carousel shows the correct width. I'm out of time this morning so will leave it for someone else to track where these widths are being calculated. Jonny __ 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/
Re: [css-d] Overflow: hidden in IE?
On 3 Aug 2008, at 09:39, Jonny Stephens wrote:
The IE7 problem appears to stem from the widths generated as inline
styles to the following divs
div class=carousel-component id=mycarousel
div class=carousel-clip-region
In Firefox, Firebug shows width: 820px. In IE7 the developer toolbar
shows width:1205px. If I remove the inline width property using the
IE bar toolbar the carousel shows the correct width.
I've had a spare couple of minutes to revisit this. It may be that
adding the following will bring IE7 into line, though it'd be good to
know what's causing the different widths to be generated.
div#mycarousel { width:800px!important; }
IE7 has another issue: the carousel's TDs display wider, so they
don't fit evenly.
Jonny
__
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/
Re: [css-d] Overflow: hidden in IE?
On Aug 3, 2008, at 8:21 AM, Jeff Ferrell wrote: In Safari (Mac, at least), there's a different problem -- the sliding boxes appear as a 50px slice at the left-hand side of the Sports div. Hardly any of it is visible at all! The source code (through webkit inspector) shows me this: div id=mycarousel class=carousel-component style=width: 25px; display: block; The inline style is script generated. Something not well detected ? Safari 3 and latest nightly WebKit build. Philippe --- Philippe Wittenbergh http://l-c-n.com/ __ 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/
Re: [css-d] Overflow: hidden in IE?
Jonny,
Thanks for the second look! Your comments helped me track down the
problem -- though I'm not quite sure how I'm going to handle it at
present... It seems like the script doesn't include an explicit width
for the carousel-clip-region. (We knew that already, I suppose.)
Rather, it's generated by a parameter in the script: numVisible,
which I had set to 5.
You pointed out the fact that the tables were (much!) wider in IE than
in Firefox, and I had been considering that a separate problem. (I was
going to get to it later, because it looked really bad!) As it turns
out, it's the SAME problem. I had calibrated the numVisible based on
what I was building in Firefox, so IE was doing what it was supposed
to: showing 5 tables, plus change. It's just that those same 5 tables
took up 1205 pixels in IE.
I'm going to have to get those tables pulled together in IE one way or
another, since they just look bad, but perhaps setting some kind of
explicit div#mycarousel { width:800px!important; } might help adjust
for width variations.
I suppose the script is geared more toward images with fixed widths,
rather than tabular data!
Thanks a LOT for the input, it's put me on a trail I couldn't have
found otherwise!
Jeff.
On 3 Aug 2008, at 09:39, Jonny Stephens wrote:
The IE7 problem appears to stem from the widths generated as inline
styles to the following divs
div class=carousel-component id=mycarousel
div class=carousel-clip-region
In Firefox, Firebug shows width: 820px. In IE7 the developer toolbar
shows width:1205px. If I remove the inline width property using the
IE bar toolbar the carousel shows the correct width.
I've had a spare couple of minutes to revisit this. It may be that
adding the following will bring IE7 into line, though it'd be good to
know what's causing the different widths to be generated.
div#mycarousel { width:800px!important; }
IE7 has another issue: the carousel's TDs display wider, so they
don't fit evenly.
Jonny
__
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/
__
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/
Re: [css-d] Overflow: hidden in IE?
Phillipe, Thanks a lot for taking a look for me! I wasn't aware there was an inspector for Safari -- am downloading webkit now -- thanks for that. I'm not sure at present where that 25px could be coming from. Seems the IE problem is going to be easier to straighten out than the Safari one, for a change! I'll have to dig further and see if I can track down that style declaration, I guess. Jeff. On Aug 3, 2008, at 7:37 AM, Philippe Wittenbergh wrote: On Aug 3, 2008, at 8:21 AM, Jeff Ferrell wrote: In Safari (Mac, at least), there's a different problem -- the sliding boxes appear as a 50px slice at the left-hand side of the Sports div. Hardly any of it is visible at all! The source code (through webkit inspector) shows me this: div id=mycarousel class=carousel-component style=width: 25px; display: block; The inline style is script generated. Something not well detected ? Safari 3 and latest nightly WebKit build. Philippe --- Philippe Wittenbergh http://l-c-n.com/ __ 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/
Re: [css-d] overflow bg image
Yes, it should. In FF though, if the content doesn't go all the way to the
bottom of the window, it interprets bottom right as being the bottom right
of the content INSTEAD of the bottom right of the browser window...
Not sure if I understand what you want. The background-image should
always be at the bottom right corner of the window ? No matter how
much content or how tall the window is?
body {background: #ccc url(../path/to/image.png) no-repeat 100% 100%
fixed;}
out to do just that.
Philippe
__
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/
Re: [css-d] overflow bg image
Matt Tibbits wrote:
Yes, it should. In FF though, if the content doesn't go all the way to the
bottom of the window, it interprets bottom right as being the bottom right
of the content INSTEAD of the bottom right of the browser window...
Not sure if I understand what you want. The background-image should
always be at the bottom right corner of the window ? No matter how
much content or how tall the window is?
body {background: #ccc url(../path/to/image.png) no-repeat 100% 100%
fixed;}
out to do just that.
Actually, it wouldn't. You're running XHTML Strict. In Strict mode, the
body sizes differently, hence the need for the 100% on the html element.
I'm not sure what you mean when you say it doesn't stop when it reaches
the TOP of the view port. You have the image set not to repeat. If you
want it to stay in place, adding fixed to the rules for the background
image would do that, right?
It's hard to see exactly what the problem is. I'm 78% colorblind, so I
can only barely see the image in the background to begin with.
--Bill
__
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/
Re: [css-d] overflow bg image
Matt Tibbits wrote: In FF though, if the content doesn't go all the way to the bottom of the window, it interprets bottom right as being the bottom right of the content INSTEAD of the bottom right of the browser window... If this is more like what you want... http://www.gunlaug.no/tos/alien/mt/test_08_0611.html ...try introducing the style changes / additions I've used... http://www.gunlaug.no/tos/alien/mt/test_08_0611_files/default0.css 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/
Re: [css-d] overflow bg image
Yes, that is exactly it... little tricky but that does the job. Thank you, for your help. Matt If this is more like what you want... http://www.gunlaug.no/tos/alien/mt/test_08_0611.html ...try introducing the style changes / additions I've used... http://www.gunlaug.no/tos/alien/mt/test_08_0611_files/default0.css __ 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/
Re: [css-d] overflow bg image
If you compare how it looks in IE and FF you should see what I mean. Adding
the styles you recommended:
html{height:100%;margin:0;padding:0;}
...fixed the problem at the bottom of the screen, but introduced a new
behaviour at the top. It's hard to explain but basically if I resize the
browser window height (using IE7) the bg image stops moving when that image
reaches the top of the view port.
If I use FF and resize vertically it will continue moving the bg image up
even AFTER the top of the bg image reaches the top of the view port.
I'm not sure if I made any sense or not, but by comparing in the two
browsers you should see what I mean. If this is just how FF behaves then
I'll accept that as an answer and move on...
Thanks,
Matt
I'm not sure what you mean when you say it doesn't stop when it
reaches
the TOP of the view port. You have the image set not to repeat. If you
want it to stay in place, adding fixed to the rules for the background
image would do that, right?
It's hard to see exactly what the problem is. I'm 78% colorblind, so I
can only barely see the image in the background to begin with.
--Bill
__
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/
Re: [css-d] overflow bg image
On Jun 12, 2008, at 1:21 AM, Matt Tibbits wrote:
Yes, it should. In FF though, if the content doesn't go all the way
to the
bottom of the window, it interprets bottom right as being the bottom
right
of the content INSTEAD of the bottom right of the browser window...
body {background: #ccc url(../path/to/image.png) no-repeat 100% 100%
fixed;}
out to do just that.
A fixed positioned image is always placed in reference to the
*viewport* (that is: the window). The code given works perfectly fine
in Gecko 1.8 and Gecko 1.9 (Fx 2 and Fx3 rc), Opera, WebKit (Safari) -
and IE 6, IE 7 [1].
The code above would fail, however, if you also put a background on
the root element (html).
If what you actually want is:put the image at the bottom of the window
if there is not much content, but at the bottom of the content if it
overflows the window (long page), then Georg's solution of using min-
height is the way to go.
[1] little demos
http://dev.l-c-n.com/_temp/bg-fixed1.html
http://dev.l-c-n.com/_temp/bg-fixed2.html
Philippe
---
Philippe Wittenbergh
http://l-c-n.com/
__
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/
Re: [css-d] overflow bg image
Matt Tibbits wrote:
I have a bg image on a body tag that is positioned bottom, right. In IE7
the bg image is actually stuck to the bottom right of the viewing port, but
in FF the bottom, right of the content or body tag.
You can view this at http://www.tchh.org/new/
Hi Matt,
This should help:
html{height:100%;margin:0;padding:0;}
Good luck,
Bill Brown
TheHolierGrail.com
__
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/
Re: [css-d] overflow bg image
Almost, although now the bg image will not stop when it reaches the TOP of
the view port in FF. It keeps being pushed up as the window is resized...
Matt
Hi Matt,
This should help:
html{height:100%;margin:0;padding:0;}
__
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/
Re: [css-d] overflow bg image
On Jun 11, 2008, at 9:06 AM, Matt Tibbits wrote:
Probably an easy fix but I'm not sure how to do it:
I have a bg image on a body tag that is positioned bottom, right.
In IE7
the bg image is actually stuck to the bottom right of the viewing
port, but
in FF the bottom, right of the content or body tag.
You can view this at http://www.tchh.org/new/
Not sure if I understand what you want. The background-image should
always be at the bottom right corner of the window ? No matter how
much content or how tall the window is?
body {background: #ccc url(../path/to/image.png) no-repeat 100% 100%
fixed;}
out to do just that.
Philippe
---
Philippe Wittenbergh
http://l-c-n.com/
__
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/
Re: [css-d] Overflow Hidden Headache
Chris Akins wrote: From my not-so-advanced vantage point, it appears that the overflow:hidden is not being used so much to contain floats as there isn't but float in the #container div. On Tue, May 6, 2008 at 4:41 PM, Ingo Chao [EMAIL PROTECTED] wrote: ... Did not look into it, but if overflow:hidden is meant to contain floats in these layouts (instead of literally cutting what is overflowing), then overflow:hidden could (and probably should) be replaced by an easyclearing method. You are right, the overflow cuts the padding/margin excess (one true layout-style), and is not used to contain floats here. I probably should have opened the page before starting to debug. http://www.springfieldmo.gov/newSite/index7b.html Well, a while ago I developed another method without overflow hidden. See a discussion here. http://www.satzansatz.de/cssd/companions.html I think any other 3-col-layout will do, our wiki has a long list. Maybe http://www.tjkdesign.com/articles/3cols.asp by Thierry does what you want. Remember that the term Holy Grail means something that cannot be found. Sorry for my bottom-posting habit. thanks, Ingo -- http://www.satzansatz.de/css.html http://www.dolphinsback.com __ 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/
Re: [css-d] Overflow Hidden Headache
Chris Akins wrote: If I take out the overflow:hidden from the #container rule, then the top looks fine, but the bottom of the page goes haywire. Did not look into it, but if overflow:hidden is meant to contain floats in these layouts (instead of literally cutting what is overflowing), then overflow:hidden could (and probably should) be replaced by an easyclearing method. Ingo -- http://www.satzansatz.de/css.html http://www.dolphinsback.com __ 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/
Re: [css-d] Overflow Hidden Headache
From my not-so-advanced vantage point, it appears that the overflow:hidden is not being used so much to contain floats as there isn't but float in the #container div. On Tue, May 6, 2008 at 4:41 PM, Ingo Chao [EMAIL PROTECTED] wrote: Chris Akins wrote: If I take out the overflow:hidden from the #container rule, then the top looks fine, but the bottom of the page goes haywire. Did not look into it, but if overflow:hidden is meant to contain floats in these layouts (instead of literally cutting what is overflowing), then overflow:hidden could (and probably should) be replaced by an easyclearing method. Ingo -- http://www.satzansatz.de/css.html http://www.dolphinsback.com __ 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/
Re: [css-d] Overflow bug?
On 5/26/07, Martin Paton [EMAIL PROTECTED] wrote: Hi I've got a flash movie as a header in my three column container layout which I want to set overflow:hidden when the page is resized so it doesn't blow out of the side of the page. I've set overflow:hidden on all containers that the flash movie would push past - it works superbly in all IE versions, but not in Firefox/Opera/NS, etc... Is there a known problem with overflow:hidden? No, but there is a philosophical argument about whether or not embedded content should be allowed to interact with (and passing behind the border of a container with overflow set is interacting the host page, given that the standards state fairly clearly that they may not interact when the embedded content is another html document. Hence some browsers give embedded media an infinite z-index. But, thanks to the pushiness of advertisers, I think there is a workaround - google for wmode transparent. -- Richard Grevers, New Plymouth, New Zealand Hat 1: Development Engineer, Webfarm Ltd. Hat 2: Dramatic Design www.dramatic.co.nz Lost yet? http://www.lost.eu/3d33f __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7 information -- http://css-discuss.incutio.com/?page=IE7 List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] overflow: hidden doesn't crop inner divs in IE
Alexander Munro wrote: I've been trying to solve this problem for a few hours. Here is my code: [code stripped] Now, in FF, Opera and Konqueror everything is ok, that is the divs inside #headlines are one below another and only the first of them is visible, the rest is hidden by the overflow property. But in IE ALL the divs inside #headlines are visible! Just as there was no overflow: hidden property. I don't get it. Please help me. This is a bug in IE 6 and 7 (when in standards mode). Descendants of a box with overflow:hidden are not cropped if they have position:relative (as in your case.) If you cannot remove the relative positioning from your descendants, you can try giving position:relative to the box with overflow:hidden, this should give the correct behaviour in IE (hoping that no other bugs will show up :-) Bruno __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7 information -- http://css-discuss.incutio.com/?page=IE7 List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Overflow problem in IE
Mike Davies wrote:
www.deveron-arts.com/new/artists.htm
[...] I have used overflow:auto on the #coretop div and a width on
the #content div inside it which exceeds the page width. IE doesn't
respect the overflow rule but just puts a horizontal scroll bar on
the whole page. Can anyone suggest how I can sort this?
Add...
#coretop {width: 100%;}
...so IE knows how wide that element is supposed to be. Otherwise the
'auto-expansion' bug will make it as wide as the element(s) inside - in IE.
Also, in Opera and Firefox, the font-family on either body or
#container does seem to work but it does in IE - any suggestions?
Delete the color-value at the end of those 'font' rules, and they will work.
regards
Georg
--
http://www.gunlaug.no
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
IE7 information -- http://css-discuss.incutio.com/?page=IE7
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] overflow: hidden not inherited?? (was - site check (IE7 please!))
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Gunlaug Sortun
Keepin existing styles as is, and placing the following addition _after_
existing styles for #SOWrap, should fix IE6 and IE7 - without disturbing
any other browser...
* html #SOWrap {overflow-y: hidden; /* for IE6 */}
*:first-child+html #SOWrap {overflow-y: hidden; /* for IE7 */}
...but I can only confirm that IE6 is doing fine with it.
Yes, that worked for XP/ IE6, thank you!
I am wondering why I wouldn't add this to my pageWrap div, which already has
the overflow set to hidden. To ask differently, why didn't the SOWrap
inherit this rule from the pageWrap or should I add these fixes to the
pageWrap instead of the SOWrap??
Inherited rules are very confusing.
Robin~
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
IE7 information -- http://css-discuss.incutio.com/?page=IE7
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] overflow: hidden not inherited?? (was - site check (IE7 please!))
Wonderbaby Designs wrote: I am wondering why I wouldn't add this to my pageWrap div, which already has the overflow set to hidden. To ask differently, why didn't the SOWrap inherit this rule from the pageWrap or should I add these fixes to the pageWrap instead of the SOWrap?? Inherited rules are very confusing. Yes, and not many rules are inherited down the nesting-chain. The rule in question: 'overflow: hidden', is not inherited. I didn't go back to check all variables, but there is one additional problem with IE that is probably affecting the result and how applied fixes work. - You have several 'position: relative' in there, and elements with that 'property: value' will overflow their container if they are too large - even if we declare 'overflow: hidden' on the container. The effect in IE6 is that the container stops growing - which is otherwise a big problem with IE6' auto-expansion bug, but the too large elements will appear visible beyond the edge of the container. Nested elements/containers, where some have 'position: relative' and some have not, can be a nightmare to control overflow-wise in IE6 (and older versions). Don't know about IE7, but I have the impression that it isn't improved much. So, I added the fix where it worked as intended in IE/win, and just checked for unintended side-effects in that and other browsers. Firefox didn't like 'overflow-y: hidden' there, so the IE-targeting hacks was necessary. regards Georg -- http://www.gunlaug.no __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7 information -- http://css-discuss.incutio.com/?page=IE7 List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] overflow: auto elements receiving focus when tabbing
To: CSS List Subject: [css-d] overflow: auto elements receiving focus when tabbing I have a form that I structured using a div wrapped around each label-input pair. I floated the labels, so in order to make the divs contain the floats, I added overflow: auto to them. This worked fine, but it resulted in the divs receiving focus as I tried to tab from form field to form field in Firefox. This was mildly annoying, so I replaced it with floating the divs, which also contained the floats and didn't have such a side effect. But I'm curious whether Firefox's behavior is correct. Are elements with overflow: auto supposed to receive focus? Or are they not? I am not qualified to answer that, but the divs work without the overflow:auto. Ian -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.12.6/453 - Release Date: 20/09/2006 __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- http://css-discuss.incutio.com/?page=IE7 List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] overflow: auto elements receiving focus when tabbing
On 9/21/06, Zoe M. Gillenwater [EMAIL PROTECTED] wrote: But I'm curious whether Firefox's behavior is correct. Are elements with overflow: auto supposed to receive focus? Just a random guess, but maybe here's the explanation for firefox's behavior: https://bugzilla.mozilla.org/show_bug.cgi?id=97283 Check after comment #50. I didn't read it all, but it seems focusing is needed to make scrolling work within the overflowing element. -- Manuel Razzari http://ultimorender.com.ar/funkascript __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- http://css-discuss.incutio.com/?page=IE7 List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] overflow: auto elements receiving focus when tabbing
Ian Young wrote: To: CSS List Subject: [css-d] overflow: auto elements receiving focus when tabbing I have a form that I structured using a div wrapped around each label-input pair. I floated the labels, so in order to make the divs contain the floats, I added overflow: auto to them. This worked fine, but it resulted in the divs receiving focus as I tried to tab from form field to form field in Firefox. This was mildly annoying, so I replaced it with floating the divs, which also contained the floats and didn't have such a side effect. But I'm curious whether Firefox's behavior is correct. Are elements with overflow: auto supposed to receive focus? Or are they not? I am not qualified to answer that, but the divs work without the overflow:auto. I know that, Ian. :-) As I said, I replaced the overflow with something else. My question was whether elements with overflow: auto set on them should automatically receive focus when tabbing. By the way, Ian, since I have your attention, can you please format your mail client to put greater than signs before each line of text of the previous poster's text? This is an established way of marking quoted text. As you can see from the quoted text above, without those your text blends in completely with my text, making it impossible to see where my text ends and yours begins. This makes reading your messages to the list extremely difficult, and I'm sure I'm not the only member of the list who would appreciate it if you formatted your replies better. Thanks, Zoe -- Zoe M. Gillenwater Design Services Manager UNC Highway Safety Research Center http://www.hsrc.unc.edu __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- http://css-discuss.incutio.com/?page=IE7 List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] overflow: auto elements receiving focus when tabbing
Not sure myself Zoe, seems like should be a bug, but if you need contain those div's, i think overflow can have any value other than visible. So instead of auto, try hidden... it seems to let you focus correctly while still keeping containing the boxes in FF. Arian __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- http://css-discuss.incutio.com/?page=IE7 List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] overflow: auto elements receiving focus when tabbing
I would expect, based on absolutely no formal spec but just user intuition, that the presence of a scrollbar should place the scrolling element into the tab list. So the tab key should take you to the element in question when overflow is set to scroll, or when it's set to auto *and* there's actual overflowing content. (Or when it's set to inherit and the inherited value matches those criteria, of course). Setting it to visible or hidden should by itself never make the affected element tabbable-to. __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- http://css-discuss.incutio.com/?page=IE7 List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] overflow: auto elements receiving focus when tabbing
Mark J. Reed wrote: I would expect, based on absolutely no formal spec but just user intuition, that the presence of a scrollbar should place the scrolling element into the tab list. So the tab key should take you to the element in question when overflow is set to scroll, or when it's set to auto *and* there's actual overflowing content. Well, I agree with you, but that's hardly relevant. Firefox doesn't do what we think it should do, and my question, again, is whether it is correct for it to do what it is doing. Zoe -- Zoe M. Gillenwater Design Services Manager UNC Highway Safety Research Center http://www.hsrc.unc.edu __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- http://css-discuss.incutio.com/?page=IE7 List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] overflow: auto elements receiving focus when tabbing
On 9/21/06, Zoe M. Gillenwater [EMAIL PROTECTED] wrote: Well, I agree with you, but that's hardly relevant. I dunno. Independently coming up with the same expectation goes toward the validity of that expectation . . . Firefox doesn't do what we think it should do, and my question, again, is whether it is correct for it to do what it is doing. Correct according to what, though? CSS doesn't even specify what user agents are supposed to do with overflow: auto; getting down to how keyboard shortcuts behave is way out of scope. Is there a formal spec for Gecko? -- Mark J. Reed [EMAIL PROTECTED] __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- http://css-discuss.incutio.com/?page=IE7 List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] overflow: auto elements receiving focus when tabbing
Mark J. Reed wrote: On 9/21/06, Zoe M. Gillenwater [EMAIL PROTECTED] wrote: Well, I agree with you, but that's hardly relevant. I dunno. Independently coming up with the same expectation goes toward the validity of that expectation . . . Not necessarily. Take margin collapsing, for instance. Almost no one would think it's intuitive until it was explained to them, and many still wouldn't agree with it. Just because we think elements with overflow: auto that don't actually overflow shouldn't receive focus when tabbing doesn't mean the standards writers or browser developers agree with us. In fact, the Firefox developers obviously don't! So again, I'm not interested in what people think should happen -- and that's not on-topic for this list -- but rather what really should happen. Or, as I said in my original email, I would like to know if this is something that no one has specified what should happen, and it's just completely up to the browsers (very possible). Firefox doesn't do what we think it should do, and my question, again, is whether it is correct for it to do what it is doing. Correct according to what, though? CSS doesn't even specify what user agents are supposed to do with overflow: auto; getting down to how keyboard shortcuts behave is way out of scope. Is there a formal spec for Gecko? Yes, the W3 specs. :-) Again, though, I've acknowledged that there may be no spec that specifies what a browser should do in this case, and thus it would be up to the browser to decide. I just want to know if this is or isn't the case. Does everyone finally understand my question? I didn't think it was that complicated. :-) Zoe -- Zoe M. Gillenwater Design Services Manager UNC Highway Safety Research Center http://www.hsrc.unc.edu __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- http://css-discuss.incutio.com/?page=IE7 List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] overflow: auto elements receiving focus when tabbing
Manuel Razzari wrote: On 9/21/06, Zoe M. Gillenwater [EMAIL PROTECTED] wrote: But I'm curious whether Firefox's behavior is correct. Are elements with overflow: auto supposed to receive focus? Just a random guess, but maybe here's the explanation for firefox's behavior: https://bugzilla.mozilla.org/show_bug.cgi?id=97283 Check after comment #50. I didn't read it all, but it seems focusing is needed to make scrolling work within the overflowing element. I read everything from comment 50 on, and I'm just more confused. :-) First of all, I'm not clear if this fix is even in current versions of Firefox. Do you know? The last comments are still people complaining about the fix only being available in the nightlies and asking when it will be added to the released browser. So I can't tell if this bug fix is in the current browser. If it is in the current browser, it probably is the explanation for why the overflow: auto elements receive focus. Comment 50 suggests that Firefox implemented the tabbing focus for overflow elements to fix this bug. This suggests that there is no spec that governs this behavior, but that it was purely a browser-based decision. If this is true (I still don't know), that's good to know, because that means that I can file my own bug about it to request that they stop this behavior. Focusing elements with overflow on them, even when they don't generate scrollbars, has the ability to affect a lot of pages if they use overflow for float containment. So I'd like to get that behavior changed. Thanks, Zoe -- Zoe M. Gillenwater Design Services Manager UNC Highway Safety Research Center http://www.hsrc.unc.edu __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- http://css-discuss.incutio.com/?page=IE7 List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] overflow: auto elements receiving focus when tabbing
On Thursday 2006-09-21 11:43 -0400, Zoe M. Gillenwater wrote: I have a form that I structured using a div wrapped around each label-input pair. I floated the labels, so in order to make the divs contain the floats, I added overflow: auto to them. This worked fine, but it resulted in the divs receiving focus as I tried to tab from form field to form field in Firefox. This was mildly annoying, so I replaced it with floating the divs, which also contained the floats and didn't have such a side effect. But I'm curious whether Firefox's behavior is correct. Are elements with overflow: auto supposed to receive focus? Or are they not? Or is it just one of those things not specified and left up the browsers themselves? I couldn't find anything about it on w3.org, but I'm admittedly not the best at looking around there. Given that receiving focus is the only way for a user to scroll an element without a mouse, I think they should receive focus. Our current behavior is that elements with 'overflow: scroll' or 'overflow: auto' receive focus, but elements with 'overflow: hidden' do not. It would be possible to make elements with 'overflow:auto' focusable only if there was actually overflow. However, I think this would be a bad idea for users, since users get used to keyboard navigation patterns on pages they visit regularly. Whether something has enough content to overflow can vary depending on varying content (such as news content changing over time) or changing conditions (different browser window widths). On Thursday 2006-09-21 13:08 -0300, Manuel Razzari wrote: Just a random guess, but maybe here's the explanation for firefox's behavior: https://bugzilla.mozilla.org/show_bug.cgi?id=97283 Check after comment #50. That was a side discussion on a mostly unrelated bug; the bug about making them focusable was elsewhere: https://bugzilla.mozilla.org/show_bug.cgi?id=254966 (I just changed the summary of the bug to reflect what it was really about. Bugs often end up keeping the original summary given by the reporter before the problem was well understood, which can make them harder to find.) On Thursday 2006-09-21 13:01 -0400, Zoe M. Gillenwater wrote: I read everything from comment 50 on, and I'm just more confused. :-) First of all, I'm not clear if this fix is even in current versions of Firefox. Do you know? The last comments are still people complaining The fix to 97283 is in Firefox 1.5, but not 1.0. The fix to 254966 was in Firefox 1.0. -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgp5fc2OTS09X.pgp Description: PGP signature __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- http://css-discuss.incutio.com/?page=IE7 List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] overflow: auto elements receiving focus when tabbing
No, the question is not difficult to understand at all (the example provided is excellent) but it is not easy to answer, and as I've seen so far, not the easiest topic to research either. I also read most of the comments from #50 on and the only thing that appears to be clear-cut is that this is eaither a bug or how Firefox was intended to work. Of utmost interest is whether or not there are published Firefox specs that can be perused at will. I would think that would put this to rest right quick! Ralph - Original Message - From: Zoe M. Gillenwater [EMAIL PROTECTED] Date: Thursday, September 21, 2006 12:55 Subject: Re: [css-d] overflow: auto elements receiving focus when tabbing To: css-d@lists.css-discuss.org Mark J. Reed wrote: On 9/21/06, Zoe M. Gillenwater [EMAIL PROTECTED] wrote: Well, I agree with you, but that's hardly relevant. I dunno. Independently coming up with the same expectation goes toward the validity of that expectation . . . Not necessarily. Take margin collapsing, for instance. Almost no one would think it's intuitive until it was explained to them, and many still wouldn't agree with it. Just because we think elements with overflow: auto that don't actually overflow shouldn't receive focus when tabbing doesn't mean the standards writers or browser developers agree with us. In fact, the Firefox developers obviously don't! So again, I'm not interested in what people think should happen -- and that's not on-topic for this list -- but rather what really should happen. Or, as I said in my original email, I would like to know if this is something that no one has specified what should happen, and it's just completely up to the browsers (very possible). Firefox doesn't do what we think it should do, and my question, again, is whether it is correct for it to do what it is doing. Correct according to what, though? CSS doesn't even specify what user agents are supposed to do with overflow: auto; getting down to how keyboard shortcuts behave is way out of scope. Is there a formal spec for Gecko? Yes, the W3 specs. :-) Again, though, I've acknowledged that there may be no spec that specifies what a browser should do in this case, and thus it would be up to the browser to decide. I just want to know if this is or isn't the case. Does everyone finally understand my question? I didn't think it was that complicated. :-) Zoe -- Zoe M. Gillenwater Design Services Manager UNC Highway Safety Research Center http://www.hsrc.unc.edu __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- http://css-discuss.incutio.com/?page=IE7 List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/ __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- http://css-discuss.incutio.com/?page=IE7 List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] overflow: auto elements receiving focus when tabbing
L. David Baron wrote: It would be possible to make elements with 'overflow:auto' focusable only if there was actually overflow. However, I think this would be a bad idea for users, since users get used to keyboard navigation patterns on pages they visit regularly. Whether something has enough content to overflow can vary depending on varying content (such as news content changing over time) or changing conditions (different browser window widths). Yes, it's definitely a sticky situation, but I can't agree that it would be bad for users to not let an element with no scrollbars receive focus. If the element does not have scrollbars, there is no way for the user to have any idea that it has overflow set on it, and thus there is not expectation on the part of the user that they should be able to tab to it. Indeed, in my example, the user's expectation was that the tab would progress from form field to form field, not stop along the way to focus invisible divs. However, a discussion of how browsers ought to work is best left off-list. Your post has pretty much answered my question: this is not part of the CSS spec, but a browser decision. Thanks! Thread can end now. Zoe -- Zoe M. Gillenwater Design Services Manager UNC Highway Safety Research Center http://www.hsrc.unc.edu __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- http://css-discuss.incutio.com/?page=IE7 List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Overflow: hidden? not hiding in IE
Silk-Works wrote: I have large bottom padding and large negative bottom margin applied to a sidebar navigation and an inner content area, contained in a wrapper with overflow set to hidden, to keep my columns the same length for different content, which seems to be fine in opera and FF, but ignored in IE. http://www.silk-works.com IE does hide overflow on #divWrapper, but a bug makes it render the overflowing parts of any container that has 'position: relative' declared on it. We use this IE-bug combination to make IE /show/ overflow at times - just like other browsers do, but in your case the effect is quite unintentional and unwanted. Thus, the solution is to delete 'position: relative' on... #divWrapper #divSidebar ...and... #divWrapper #divContainer ...and IE will stop showing parts of those containers sticking below the footer. regards Georg -- http://www.gunlaug.no __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- http://css-discuss.incutio.com/?page=IE7 List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Overflow: hidden? not hiding in IE
Gunlaug Sørtun wrote: http://www.silk-works.com IE does hide overflow on #divWrapper, but a bug makes it render the overflowing parts of any container that has 'position: relative' declared on it. Thus, the solution is to delete 'position: relative' on... Forgot... :-) IE has many bugs, so you will then have to add 'position: relative' to some elements inside... #divWrapper #divSidebar ...and... #divWrapper #divContainer ...or else IE gets the stacking wrong and will prevent links from being at the top and act as proper links. Georg -- http://www.gunlaug.no __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- http://css-discuss.incutio.com/?page=IE7 List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Overflow: hidden? not hiding in IE
http://www.silk-works.com
To save you some time - and grey hair...
The addition of...
#divWrapper #divSidebar a {position: relative;}
#divWrapper #divContainer a {position: relative;}
...will do the trick in IE, once the 'position: relative' on the
containers themselves (as described in the first response), are deleted.
Georg
--
http://www.gunlaug.no
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
IE7b2 testing hub -- http://css-discuss.incutio.com/?page=IE7
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Overflow: hidden? not hiding in IE
Silk-Works wrote: Hello all, I'm a new one here, hope I'm doing this right? I know this is a common problem, and is listed on the wiki, but I seem to be going round in circles.. I am not a web developer Me either. - I've just opened a shop and wanted to do a small site to promote it.. More fool me.. I know exactly what you mean. Regards, James Georg Sortun can fix anything. I start from scratch and hope for the best (and hope Georg will fix it :-) ). http://www.chelseacreekstudio.com/ca/cssd/layout26.html Regards, ~dL -- http://chelseacreekstudio.com/ __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- http://css-discuss.incutio.com/?page=IE7 List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] overflow and z-index
On Jun 1, 2006, at 7:51 PM, Roger Roelofs wrote:
Christy,
On Jun 1, 2006, at 2:57 PM, Christy Collins wrote:
I have a page with overlapping elements that work properly until I
apply overflow: auto to one of the elements. Then it seems to throw
the z-index off. This is happening in Firefox but not Safari. Any
suggestions?
We will need a url to look at your code to be much help. My first
guess is that the overflow rule is creating a new positioning context
and thus a new base for the stacking order. I could be way off
though.
--
Roger Roelofs
In replying, I figured it out. I had:
#text_box{
width: 745px;
height: 202px;
background: url(i/opacity_bkg.png);
z-index: 20;
overflow: auto;
}
#text_box p{
position: relative;
z-index: 30;
}
#townhomes_on{
z-index: 1;
position: absolute;
top: 110px;
left: 43px;
}
I switched position: relative to #text_box and Firefox is happy.
Thanks!
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
IE7b2 testing hub -- http://css-discuss.incutio.com/?page=IE7
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Overflow problems in absolute bottom dimensioned DIV
Hello,
This is my first post, I hope I'll do it OK and make myself
as clear as possible.
I'm having quite some difficulty in managing this problem.
I have this simples HTML page withs a container div, centered
in the page through margin: auto.
Inside it there are the other divs, one for the header, on
for the menu, one for the content (the troublesome one) and
one for the footer with the logos.
[snip]
Bruno Bergher
Designer
www.brunobergher.com
Hi Bruno.
What you're trying to accomplish can be managed only in IE5(.5) and up. You
can do this with CSS expressions, which are technically javascript embedded
in style rules. It's true that this solution will still not work for users
with js disabled (even if they even figured out how to do that), but then
again, neither will any other solution that I know of. I tried to embed this
in your code so I could send you a proper working example, but my Spanish is
a little rusty and I was getting frustrated. ;)
Anyway, here's a small template which emulates your template. The key line
is the height setting for the content. Essentially, that rule grabs the
height of the parent contained, subtracts the header and footer and then
sets the height to the remainder.
Hope it does the trick for you. Relevant code is below.
Bill Brown
Webmaster, MacNimble.com
!-- Code snippet begins here --
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
html
head
titleUntitled/title
style type=text/css
/* ![CDATA[ */
html,body {
height: 100%;
margin:0;
overflow-y: hidden;
padding: 0;
width: 100%;
}
#siteShell {
border: 2px solid #000;
height: 96%;
margin: 1% auto;
overflow: hidden;
position: relative;
width: 750px;
}
#header {
background: #dedede;
border-bottom: 1px solid #000;
height: 200px;
text-align:center;
}
#content {
background: #fff;
height:
expression(x=(document.all.siteShell.offsetHeight-(document.all.header.offse
tHeight+document.all.footer.offsetHeight)+px));
overflow: auto;
}
#footer {
background: #f1f1f1;
border-top: 1px solid #000;
height: 100px;
text-align:center;
}
p {
margin: 0 0 1em 0;
}
/* ]] */
/style
/head
body
div id=siteShell
div id=header
h1header/h1
/div
div id=content
p
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Maecenas
dignissim nulla a tellus ultricies convallis. Sed malesuada tristique
orci. Integer suscipit risus eu est. Ut interdum, tellus et ornare
fermentum, enim augue lacinia enim, eget fringilla nunc nunc vitae
odio. In nonummy metus sit amet risus. In sed tortor at urna lacinia
vulputate. Etiam congue urna vel risus. Aliquam erat volutpat.
Integer fringilla rutrum arcu. Lorem ipsum dolor sit amet,
consectetuer adipiscing elit. Cras a ligula nec risus tempor
hendrerit. Maecenas eu elit nec ipsum fermentum egestas. Cras in wisi
in libero feugiat bibendum. Donec ornare.
/p
p
Ut ac magna. Sed et nisl vitae lectus porttitor interdum. Proin
scelerisque aliquet sem. Ut mollis sem a risus. Sed vel leo a ante
viverra scelerisque. Maecenas pharetra eleifend leo. Quisque velit.
Etiam sed ipsum non dolor consequat dignissim. Fusce dignissim.
Praesent ipsum. Cras rutrum bibendum risus. Nullam pede ligula,
vulputate nec, dictum vitae, egestas quis, dolor. Nullam eu lorem.
Pellentesque pellentesque orci vel lectus. Aenean pulvinar. Quisque
a nulla quis magna eleifend commodo. Vestibulum ante ipsum primis in
faucibus orci luctus et ultrices posuere cubilia Curae; In sem.
/p
p
Quisque turpis odio, consectetuer et, pretium eu, pulvinar non, urna.
Donec purus erat, lobortis at, faucibus et, nonummy a, mi. Duis
dapibus. Phasellus luctus, massa vitae ornare accumsan, pede tellus
molestie neque, et mattis justo arcu vel tortor. Maecenas magna quam,
condimentum vel, vehicula ut, consectetuer in, felis. Pellentesque
quis nulla non massa volutpat convallis. Sed sollicitudin lectus
vitae lacus. Vivamus mi tellus, sodales commodo, malesuada nonummy,
hendrerit lacinia, nulla. Quisque nibh odio, sagittis in, interdum
at, cursus id, dolor. Cras quam tellus, pulvinar a, dignissim ut,
fringilla ac, leo. Morbi lacinia. Cras urna lorem, rutrum id, pretium
vel, lacinia ut, ipsum. Ut est libero, tempus eget, blandit nec,
iaculis vitae, lectus. Aenean quis enim. Suspendisse lacinia eleifend
sem. Sed ac massa. Aenean ultricies sapien at orci. Proin dolor enim,
luctus in, consequat sit amet, semper at, turpis. Nam lacinia mi
vitae dolor.
/p
p
Etiam consequat orci nec lacus. Duis porttitor pharetra quam.
Suspendisse ipsum. Nunc vestibulum ipsum eget diam. Donec lacinia,
risus nec fermentum volutpat, turpis sem egestas dolor, eget molestie
sapien velit ornare velit. Sed pharetra est vel nibh. Quisque nec
justo. Class aptent taciti sociosqu ad litora torquent per conubia
nostra, per inceptos hymenaeos. Phasellus feugiat dictum velit. Donec
metus velit, malesuada non, blandit elementum, accumsan ac, ante.
Pellentesque ultrices
Re: [css-d] overflow: inheritance?
David McFarland wrote: I was just looking over the CSS 2.1 specs and see that some properties that aren't inherited accept a value of 'inherit' When the spec shows Inherited: No it simply means that the property is not inherited by default. It does not mean that the property can never be inherited. Granted, the spec language is unclear on this precise point, but it is easily inferred from the fact that the properties you point out, among others, explicitly take the inherit keyword as a valid value. For example, the overflow property accepts 'inherit' as a valid value. What exactly can this property inherit from? The spec defines this here: http://www.w3.org/TR/CSS21/cascade.html#value-def-inherit. To quote directly: Each property may also have a specified value of 'inherit', which means that, for a given element, the property takes the same computed value as the property for the element's parent. HTH, -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- http://css-discuss.incutio.com/?page=IE7 List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] overflow: inheritance?
Re: inheritance: I meant to also note that IE/Win doesn't always adhere to the spec, and in particular does not support the 'inherit' keyword at all. Just a tiny little gotcha there. My understanding is that this is high on the CSS fix list for IE7, but that it is not yet implemented. So, sometimes I hit the send button a little too soon. -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- http://css-discuss.incutio.com/?page=IE7 List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Overflow and inheritance problems with a 2-column layout
Right first this first the reason the menu overlaps is that your
content div has finished so it just wraps round. What would be better
is if you put the left column as a div i.e:
#leftClm {
width: 33%;
float: left;
display: block;
padding: .. etc.
}
Here is a good example: http://www.thenoodleincident.com/tutorials/
box_lesson/basic2_fluid.html
James MacLeod
On Feb 16, 2006, at 09:28, John Latter wrote:
Hi,
I'm new to css and would appreciate some help with the following two
problems I've encountered in setting up a blog which can be seen here:
http://evomech2.blogspot.com/2006/02/re-evomech-re-peer-review-and-
genetic.html
Its a 2 column layout and I think the relevant css code is:
div#mainClm{float:right;width:66%;padding:30px 7% 10px
3%;border-left:dotted 1px #E0AD12;}
div#sideBar{margin:20px 0px 0px
1em;padding:0px;text-align:left;width:100%;}
The first problem (which occurs on Firefox but not IE6) can be seen at
the bottom of the above page where the sidebar text overflows into main
content area. I have tried to fix it myself but with many other things
to do I'm really stumbling about in the dark.
The second problem isn't readily apparent because I've tidied the main
column content up:
Entries in the main column are auto-added from a yahoo group and contain
tt tags which are then carried over into the sidebar and change the
text font. A similar effect is caused by posters using a variety of
composing programs. Is there any code I can add to the end of the main
div to stop _anything_ being inherited by the sidebar div?
John Latter
[NB This is a repost of the first message I sent to this list. The first
one was sent in HTML/Plain Text format and I'm not sure if it got
through - my apologies if you've received this twice!]
--
*Model of an Internal Evolutionary Mechanism*:
http://members.aol.com/jorolat/index.html
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
IE7b2 testing hub -- http://css-discuss.incutio.com/?page=IE7
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
IE7b2 testing hub -- http://css-discuss.incutio.com/?page=IE7
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Overflow and inheritance problems with a 2-column layout
Thanks for the help James - I'm just going offline but I'll look at the
link you gave later!
John Latter
On 16/02/2006 James MacLeod wrote:
Right first this first the reason the menu overlaps is that your
content div has finished so it just wraps round. What would be better is
if you put the left column as a div i.e:
#leftClm {
width: 33%;
float: left;
display: block;
padding: .. etc.
}
Here is a good example:
http://www.thenoodleincident.com/tutorials/box_lesson/basic2_fluid.html
James MacLeod
On Feb 16, 2006, at 09:28, John Latter wrote:
Hi,
I'm new to css and would appreciate some help with the following two
problems I've encountered in setting up a blog which can be seen here:
http://evomech2.blogspot.com/2006/02/re-evomech-re-peer-review-and-genetic.html
Its a 2 column layout and I think the relevant css code is:
div#mainClm{float:right;width:66%;padding:30px 7% 10px
3%;border-left:dotted 1px #E0AD12;}
div#sideBar{margin:20px 0px 0px
1em;padding:0px;text-align:left;width:100%;}
The first problem (which occurs on Firefox but not IE6) can be seen at
the bottom of the above page where the sidebar text overflows into main
content area. I have tried to fix it myself but with many other things
to do I'm really stumbling about in the dark.
The second problem isn't readily apparent because I've tidied the main
column content up:
Entries in the main column are auto-added from a yahoo group and contain
tt tags which are then carried over into the sidebar and change the
text font. A similar effect is caused by posters using a variety of
composing programs. Is there any code I can add to the end of the main
div to stop _anything_ being inherited by the sidebar div?
--
*Model of an Internal Evolutionary Mechanism*:
http://members.aol.com/jorolat/index.html
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
IE7b2 testing hub -- http://css-discuss.incutio.com/?page=IE7
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Overflow problem in FF
Well Damn wrote: When the outer div is smaller than the larger div, i'd like it to hide the text -- not wrap. The code below works fine in IE, can anyone suggest what I'm doing wrong for firefox? div id=testdiv style=border:1px solid blue; width:200px; overflow:hidden div width=100% ul li A test div.A test div.A test div.A test div.A test div.A test div.A test div./li li A test div.A test div.A test div.A test div.A test div.A test div.A test div./li li A test div.A test div.A test div.A test div.A test div.A test div.A test div./li li A test div.A test div.A test div.A test div.A test div.A test div.A test div./li li A test div.A test div.A test div.A test div.A test div.A test div.A test div./li /ul /div /div That code looks the same to me in FF 1.5 and IE6, even if I write it so the inner div uses a style declaration instead of a width attribute. The inner div holds at the 198px content width and expands vertically to accommodate the wrapping list items. This is the behavior I would expect. If I make the inner div a width of 100em (instead of 100%) then the list items don't wrap and the content to the right is hidden. But this behavior, too, is identical in both browsers. What differences do you see? Perhaps you might post a complete page, in case something else is interfering. -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Overflow problem in FF
That's the complete page (minus html/body and doctype tags). What I deleted by accident prior to posting is placing nowrap within the inner div -- that changes the behavior between the two browsers. My intent here is to have a div that doens't wrap content based on the width of the div. I understand the 'em' solution works.. however, I thought the em unit was based on the font size of the container. I don't know how feasible that solution is for a div. Basically I'm trying to animate a div to 'close' and 'open' and not have the content wrap is what I'm after.. Any other ideas? On 1/23/06, Adam Kuehn [EMAIL PROTECTED] wrote: Well Damn wrote: When the outer div is smaller than the larger div, i'd like it to hide the text -- not wrap. The code below works fine in IE, can anyone suggest what I'm doing wrong for firefox? div id=testdiv style=border:1px solid blue; width:200px; overflow:hidden div width=100% ul li A test div.A test div.A test div.A test div.A test div.A test div.A test div./li li A test div.A test div.A test div.A test div.A test div.A test div.A test div./li li A test div.A test div.A test div.A test div.A test div.A test div.A test div./li li A test div.A test div.A test div.A test div.A test div.A test div.A test div./li li A test div.A test div.A test div.A test div.A test div.A test div.A test div./li /ul /div /div That code looks the same to me in FF 1.5 and IE6, even if I write it so the inner div uses a style declaration instead of a width attribute. The inner div holds at the 198px content width and expands vertically to accommodate the wrapping list items. This is the behavior I would expect. If I make the inner div a width of 100em (instead of 100%) then the list items don't wrap and the content to the right is hidden. But this behavior, too, is identical in both browsers. What differences do you see? Perhaps you might post a complete page, in case something else is interfering. -Adam Kuehn __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Overflow problem in FF
On 24 Jan 2006, at 11:01 am, Well Damn wrote:
That's the complete page (minus html/body and doctype tags). What I
deleted by accident prior to posting is placing nowrap within the
inner div -- that changes the behavior between the two browsers. My
intent here is to have a div that doens't wrap content based on the
width of the div.
#testdiv li {white-space:nowrap}
should do what you are after.
and you can delete that inner div imho, just use the ul.
Philippe
---
Philippe Wittenbergh
http://emps.l-c-n.com/
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] overflow strategy for a fixed width table?
Cool technique! I don't think (on first glance) it will work in this
particular case - the programmers on the back end will cringe if I
suggest a jump to another page for the full details.
But this example:
http://www.satzansatz.de/cssd/tmp/dropitII.html
gives me an idea for letting users know immediately that a long table
(ie. taller than the viewport) has triggered a horizontal overflow
(overflow: auto;) without seeing the horizontal scroll bar (which
would be below the bottom of the viewport). Imagine the little arrow
icon appearing at the top right of the table if there is horizontal
overflow. This could be really useful...
On my original problem, though, it occurs to me that using the text-
overflow: ellipsis; might be at least a partial solution for some of
the data columns (especially the first column) which are actually
links, if I add the title attribute... won't the title attribute
trigger a tooltip-like popup on hover with the full title text?
Haven't played with it yet but remember seeing it discussed recently.
Rolf
On Dec 30, 2005, at 6:43 PM, Ingo Chao wrote:
[EMAIL PROTECTED] wrote:
I've got a fixed width table (750px) with 10 columns on a fixed
width page. I've been asked to squeeze an additional 2 or 3
columns of data into the same space. In some cases, the data
simply won't fit horizontally in the space allotted at readable
font sizes. I know the arguments for allowing the page and the
table to expand, but I'm trying to explore other options due to
other constraints.
One option is that I simply use
{overflow: auto;}
on the table (or perhaps, the div that contains the table).
Is there another way?
For example, I could use
{ text-overflow: ellipsis; }
on certain columns, but how do I make that hidden data visible if
a user wants to see it?
In May 2005, we discussed a question how to wrap long URL's [1].
Paul Novitski explained his idea to let long URLs be partially
hidden with an ellipsis, and I suggested a pure CSS solution for
his idea.
The method uses a float that drops into view once an preceding
float gets too wide and is hidden by an overflown container.
Recently, I thought about other problems that this solution could
address, and talked with Georg Sørtun about other possibilities [2]
[3].
So, I hope, yes, this could be another way:
http://www.satzansatz.de/cssd/dropit.html
(A change to the May attempt is the link that is absolutely
positioned in a 1x1px right float to keep the dropping float itself
small, while the a.p.link physically does not take space)
Technically, it looks promising in Fx1.5, IE6/Win, Opera8, Safari
2.0.2. IE5.23Mac shows the link, but adds some transparency to it.
Critique and suggestions appreciated.
Does it solve the problem? Is it accessible?
Regards,
Ingo
[1] http://archivist.incutio.com/viewlist/css-discuss/57426
[2] http://www.satzansatz.de/cssd/tmp/dropitII.html
[3] http://www.gunlaug.no/tos/alien/test_8770.html
--
http://www.satzansatz.de/css.html
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] overflow strategy for a fixed width table?
Rolf Mortenson wrote: Cool technique! I don't think (on first glance) it will work in this particular case - the programmers on the back end will cringe if I suggest a jump to another page for the full details. You might promise this kind of longdesc technique would allow for adding as much columns as they like to add ;) and your design could help visitors not being equipped with wide screens to access the page. One the other hand, my proposal can be seen as a misuse of CSS. Anyway, there might be a better scripting solution to your problem, others will have more ideas. On my original problem, though, it occurs to me that using the text- overflow: ellipsis; might be at least a partial solution for some of the data columns (especially the first column) which are actually links, if I add the title attribute... won't the title attribute trigger a tooltip-like popup on hover with the full title text? Haven't played with it yet but remember seeing it discussed recently. text-overflow: ellipsis; restricts this functionality to IE6, as it is a MS extension to CSS (and it leaves IE5.5 out), when I am not entirely wrong. CSS3Text Module CR [1] has an example with text-overflow-mode:ellipsis, this does not work in any of my browsers. Ingo [1] http://www.w3.org/TR/2003/CR-css3-text-20030514/#text-overflow-props -- http://www.satzansatz.de/css.html __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] overflow strategy for a fixed width table?
[EMAIL PROTECTED] wrote:
I've got a fixed width table (750px) with 10 columns on a fixed width
page. I've been asked to squeeze an additional 2 or 3 columns of data
into the same space. In some cases, the data simply won't fit
horizontally in the space allotted at readable font sizes. I know the
arguments for allowing the page and the table to expand, but I'm
trying to explore other options due to other constraints.
One option is that I simply use
{overflow: auto;}
on the table (or perhaps, the div that contains the table).
Is there another way?
For example, I could use
{ text-overflow: ellipsis; }
on certain columns, but how do I make that hidden data visible if a
user wants to see it?
In May 2005, we discussed a question how to wrap long URL's [1].
Paul Novitski explained his idea to let long URLs be partially
hidden with an ellipsis, and I suggested a pure CSS solution for his
idea.
The method uses a float that drops into view once an preceding float
gets too wide and is hidden by an overflown container.
Recently, I thought about other problems that this solution could
address, and talked with Georg Sørtun about other possibilities [2][3].
So, I hope, yes, this could be another way:
http://www.satzansatz.de/cssd/dropit.html
(A change to the May attempt is the link that is absolutely
positioned in a 1x1px right float to keep the dropping float itself
small, while the a.p.link physically does not take space)
Technically, it looks promising in Fx1.5, IE6/Win, Opera8, Safari
2.0.2. IE5.23Mac shows the link, but adds some transparency to it.
Critique and suggestions appreciated.
Does it solve the problem? Is it accessible?
Regards,
Ingo
[1] http://archivist.incutio.com/viewlist/css-discuss/57426
[2] http://www.satzansatz.de/cssd/tmp/dropitII.html
[3] http://www.gunlaug.no/tos/alien/test_8770.html
--
http://www.satzansatz.de/css.html
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
RE: [css-d] overflow prob in IE6.0 no scrollbars for overflow:scroll/auto
Hi Latika, snip overfolw:auto; snip overfolw:auto; snip overfolw:scroll; snip I hope the overfolw is a typo! :) You might like to change that first. Tim __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] overflow prob in IE6.0 no scrollbars for overflow:scroll/auto
Thanx Tim, Its just a typo in my post. The spelling is correct in the stylesheet. Archer, Tim wrote: Hi Latika, snip overfolw:auto; snip overfolw:auto; snip overfolw:scroll; snip I hope the overfolw is a typo! :) You might like to change that first. Tim __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
