[css-d] height: 1% versus min-height: 1px in IE7?
Hello all!
Someone poked me with this question, and I can't seem to give a clear
answer, so I would like to ask you all for some advise.
To trigger a hasLayout MSproperty to true, I used to always use
the Holly hack {height: 1%} . But now that IE7 recognises
{min-height}, and that {min-height: 1px} also seems to trigger
hasLayout, which one is better to use for IE7?
One would think that logically, {min-height:1px} is more appropriate,
but I'm a person who likes to use Tried, Tested and True road.
Thanks in advance for sharing any ideas!
Cheers,
- Sharon
__
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] height: 1% versus min-height: 1px in IE7?
Sharon Go wrote:
One would think that logically, {min-height:1px} is more appropriate,
but I'm a person who likes to use Tried, Tested and True road.
This should fit the bill then...
http://onhavinglayout.fwpf-webdesign.de/hack_management/
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/
[css-d] IE Printing Problem
Hi everyone, I'm running into a problem getting a site to print out correctly in IE. The first page is okay, but the succeeding pages are a disaster (the main content is broken into several pages and then disappears). We created a print style sheet that hid mostly everything but the main content, but the client wants the appearance of the screen styles to persist in printouts:-(. Research indicates that removing floats should fix this problem, but that's not working for me - and I don't know how I'm going to be able to retain the layout if I lose the floats. Does anybody have any experience with this issue? Thanks, John John Gribben Pedrera, Inc. 215 348 7446 [EMAIL PROTECTED] http://www.pedrera.com/ http://www.pedrera.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/
[css-d] Site Check Please?
Greetings all,
I'm wondering what's up with my page: http://test.nprb.org/new/index.htm
Specifically, the three buttons in upper right corner. They are a Library
item, in their own div that's set to float: right. The span text that shows
up on hover is positioned correctly, but those three buttons are not
flush-right with them. What gives? CSS:
div#buttons {
width: 240px;
z-index: 100;
background-color: none;
margin-bottom: 40px;
float: right;
margin-left: 40px;
margin-top: 10px;
padding: 0;
margin-right: -5px;
}
Thanks - hope this is enough information!
Cheers,
Carolyn
__
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] Site Check Please?
On Wed, Mar 19, 2008 at 12:02 PM, Carolyn Rosner [EMAIL PROTECTED]
wrote:
Greetings all,
I'm wondering what's up with my page: http://test.nprb.org/new/index.htm
Specifically, the three buttons in upper right corner. They are a
Library item, in their own div that's set to float: right. The span text
that shows up on hover is positioned correctly, but those three buttons are
not flush-right with them. What gives? CSS:
Carolyn,
You can either change the width of your div#divButtons to approximately
215px { width:215px; } or right align the text in that div {
text-align:right; }.
You are also including a couple of CSS files more than once.
--G
__
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-d] IE8 and easy clearing
hi all. did someone make some tests about? I'd like to see a wiki page on incutio. G. -- http://www.css-zibaldone.com/ http://www.css-zibaldone.com/test/ (English) http://mimicry.css-zibaldone.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/
[css-d] IE6/7 funky flickering behavior
Hi All, On page load the H2 Tags (post tiles) cause the page background image to disappear intermittently. Refresh fixes the ones in the viewport, but not others, and sometimes scrolling tweaks it. It's very weird. Any ideas on this? http://www.goehnergroup.com/gg/donscorner/ T __ 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-d] Arbitrary extra space above element in Moz/Webkit goes away when bordered?
I've got a page in which I get about 80 pixels of apparently arbitrary space inserted between two sections of a page in Firefox and Safari. http://weston.canncentral.org/web_lab/MozArbSpaceAboveBlock/problem.html http://weston.canncentral.org/web_lab/MozArbSpaceAboveBlock/TopGun.css The extra distance is between the navigation and the photo in the middle of the page -- in other words, the top photo should be up against the bottom of the nav. There's no margin set on the nav, the photo or the photo's containers. The photo (#photo) is floated left, if that's relevant. In trying to assess where the actual space is being added (the photo actually has two containers, #content1 and div classed with constraint below that) I tried putting borders on the photo's immediate container. Interestingly, this makes the problem go away: http://weston.canncentral.org/web_lab/MozArbSpaceAboveBlock/fix1.html At least, the border seems to remove the arbitrary extra space. Placing a border on #content1 doesn't seem to have the same effect, and reveals the space inside #content1. Interestingly, the border trick works even if you only apply border-top. This made me think of trying something else: placing an element inside #photo's container above #photo. And, sure enough, if it's a visible statically or relatively positioned block-level element: http://weston.canncentral.org/web_lab/MozArbSpaceAboveBlock/fix2.html Any idea what's going on here? This appears to be a bug -- but it happens across Safari and Moz which makes me think this might be one of the places where the standard is vague enough non-intuitive behavior gets implemented in browsers. Any fix ideas are also appreciated! Thanks, Weston __ 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] Arbitrary extra space above element in Moz/Webkit goes away when bordered?
Weston C wrote:
I've got a page in which I get about 80 pixels of apparently arbitrary
space inserted between two sections of a page in Firefox and Safari.
http://weston.canncentral.org/web_lab/MozArbSpaceAboveBlock/problem.html
http://weston.canncentral.org/web_lab/MozArbSpaceAboveBlock/TopGun.css
Weston
It may be collapsing-margins [1], try:
.constraint {
padding-top: 1px; :: add ::
width: 1033px;
margin: 0 auto;
text-align: left;
}
[1] http://www.w3.org/TR/CSS21/box.html#collapsing-margins
--
http://chelseacreekstudio.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] IE8 and easy clearing
Gabriele Romanato wrote:
hi all. did someone make some tests about? I'd like to see a wiki
page on incutio.
I'd like to see some tests on that too.
IE8b1 adds in line-height for the generated content - 'height: 0' means
nothing to it in practice, so there will be big gaps in layouts in some
cases.
Haven't gotten around to create my own test-cases to cover all
situation, but zeroing out line-height by adding...
.clearfix:after {
font-size: 1px;
line-height: 0;
}
...solves the problems in all situations I've encountered so far. This
is a harmless but illogical fix, so IE8 should be fixed.
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/
[css-d] menus with uneven placements
I am trying to make a menu on the steps of the stairs. I want the individual menu items centered with the steps. Please help. I am close on my mac, but a disaster on windows. URL: http://www.adrianavargasdesign.com/indexsk.html thank you. --s __ 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] Arbitrary extra space above element in Moz/Webkit goes away when bordered?
On 3/19/08, Valerie Wininger [EMAIL PROTECTED] wrote:
Well, the space is coming from the 81px top margin on the #banner div... Can
you
make the banner float next to the photo instead of taking up the full width
behind it?
Thank you! This works:
http://weston.canncentral.org/web_lab/MozArbSpaceAboveBlock/fix3.html
It's much less hackish than anything other solution I've seen. The
only problem with it is that it requires retooling the width of
#banner if the photo's changed. Not horrible, but it's a little
convenience drag.
On 3/19/08, David Laakso [EMAIL PROTECTED] wrote:
It may be collapsing-margins [1], try:
#content1 .constraint {
padding-top: 1px;
}
Thank you as well! This works:
http://weston.canncentral.org/web_lab/MozArbSpaceAboveBlock/fix4.html
And combined with margin-top: -1px; makes a fairly neat solution.
But I still don't understand what about the margin-collapsing part of
the spec shoves the image down flush with the blue banner if there's
no padding or border to interfere.
-Weston
__
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-d] Foxability - WCAG1.0 - CSS font size
I was wondering how many have heard of this Firefox extension, who uses it, and their opinion of it. http://foxability.sourceforge.net/ I have a question concerning PX with Fonts and WCAG 1.0 Should fonts declared with a size in Pixels fail a WCAG 1.0 test? I find a lot of references that font size must be in a relative unit i.e; EM or Percent but W3 says px IS a relative unit, though relative to the device it's displayed on. TYIA, G7W __ 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] menus with uneven placements
Stuart King wrote: I am trying to make a menu on the steps of the stairs. I want the individual menu items centered with the steps. http://www.adrianavargasdesign.com/indexsk.html You must absolute position them then, and subtract half the line-height and half the text-width of each list-item to compensate for font-resizing. Otherwise it'll break in all major browsers, on all OSes, when subjected to the slightest amount of stress. 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] menus with uneven placements
Stuart, http://www.adrianavargasdesign.com/indexsk.html I've got to play devil's advocate on this one. What you want to do is possible, but you are dealing with a pixel-perfect type of placement. Is there a reason you wouldn't just use image slices with rollovers or Flash? Again, you can do this with CSS, but you'll likely end up with a stack of AP divs to make it work.. with the least amount of headache. There will still be some level of inconsistencies due to font rendering differences. In the long-run image slices or Flash would be less maintenance, because they would be less likely to break as new browsers hit the street. Just my two-cents worth! ...Rob Rob Emenecker @ Hairy Dog Digital www.hairydogdigital.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] IE6/7 funky flickering behavior
Timothy Martens wrote: Hi All, On page load the H2 Tags (post tiles) cause the page background image to disappear intermittently. Refresh fixes the ones in the viewport, but not others, and sometimes scrolling tweaks it. It's very weird. Any ideas on this? http://www.goehnergroup.com/gg/donscorner/ T Hi Timothy, I think this is something peekaboo related. Try adding hasLayout [1] [2] to the affected #pageWrapper divs. The sure way to establish peekaboo activity is is to resize a Notepad to 100px by 100px and move it over the affected regions. [1] http://www.satzansatz.de/cssd/onhavinglayout.html [2] http://onhavinglayout.fwpf-webdesign.de/hack_management/ Alan http://css-class.com/test/ __ 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] Foxability - WCAG1.0 - CSS font size
Gate Wizard wrote: I have a question concerning PX with Fonts and WCAG 1.0 Should fonts declared with a size in Pixels fail a WCAG 1.0 test? I find a lot of references that font size must be in a relative unit i.e; EM or Percent but W3 says px IS a relative unit, though relative to the device it's displayed on. The CSS pixel is/can be/is supposed to be mapped to various screen resolution - dpi, so it is relative in that sense. Somewhat inconsistent implementation though, so what is/should be according to W3C may not necessarily be true in the real world of UA software and devices. Text size is treated different from the CSS pixels mentioned above, which makes the relativity of the whole issue even more relative (and a lot of fun), but not more consistent. Reality check: - IE/win can't resize text with font-sizes declared in pixels - only ignore all font-sizes declared in web pages. - IE/win can neither resize nor ignore line-heights declared in pixels. - Opera can't resize line-heights declared in pixels, but will otherwise resize all text when told to. - Most other browsers can resize text with both font-sizes and line-heights declared in pixels. The above results in inconsistent presentation of text with font-size and/or line-height declared in pixels under user-induced stress - font-resizing, 'ignore font-size', 'minimum font size' etc, and may result in pretty inaccessible content and low usability-factor. This should in itself make the use of pixels for text sizing a less than optimal solution. Add in inconsistencies when it comes to how browsers map anything to various screen resolutions, and pixels for text size may start to look as an even less optimal solution. Since WCAG tends to focus on reality (I think) - as those behind it know it at the time of writing, I guess they may let font-sizes declared in pixels fail for the same reason as conscious designers do - because they may not work well, or at all, for end-users who need/want to introduce text size changes. Try asking on http://www.webaim.org/discussion/ or http://www.accessifyforum.com/ for more WCAG focused responses. 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] Foxability - WCAG1.0 - CSS font size
Should fonts declared with a size in Pixels fail a WCAG 1.0 test? No they should not fail. Though browsers do provide mechanisms for adjusting default font sizes, users may adjust the default font resolution on their system. For example, I have a laptop that has a 14 screen with a native resolution of 1600x1200. After about 1/2 hour I start suffering from eye strain on that puppy at default settings. So, I set my default font size to be about 120 pixels. Since I'm setting my system default font size, I leave my browsers set to default sizes. In this regard, pixels are relative. Even though pixels are considered relative, I still think it's important for you to think about web pages with user-adjustable units at the browser level, which pixels does not give you. The reason I say that is that over-riding the default font size in your system causes many applications to break. That is, text fields in applications and such are often designed to fit a specific pixel dimension. When you alter the system from the default 96 pixels (on Windows) you start seeing wonky things with dialog boxes, labels on tool palettes, etc. For that reason, users may leave their system set to the default settings and adjust the default font sizing in their browser. Since you don't have a way of knowing if the user has adjusted their default font size at the OS level or at the browser level, it's usually best to avoid pixels, even if they are considered relative, unless you have a specific reason to use them. ...Rob __ 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] menus with uneven placements
On 20/03/2008, at 12:13 PM, Stuart King wrote: http://www.adrianavargasdesign.com/indexsk.html Sturt, my first thought was imagemap ... so I Googled css imagemap to see what the current state-of-play is with the imagemap concept and found this: http://www.alistapart.com/articles/imagemap It reads like it's written for situations like yours. Cheers, KathyW. __ 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] Arbitrary extra space above element in Moz/Webkit goes away when bordered?
Weston C wrote:
On 3/19/08, Valerie Wininger [EMAIL PROTECTED] wrote:
Well, the space is coming from the 81px top margin on the #banner div... Can
you
make the banner float next to the photo instead of taking up the full width
behind it?
Thank you! This works:
http://weston.canncentral.org/web_lab/MozArbSpaceAboveBlock/fix3.html
It's much less hackish than anything other solution I've seen. The
only problem with it is that it requires retooling the width of
#banner if the photo's changed. Not horrible, but it's a little
convenience drag.
On 3/19/08, David Laakso [EMAIL PROTECTED] wrote:
It may be collapsing-margins [1], try:
#content1 .constraint {
padding-top: 1px;
}
Thank you as well! This works:
http://weston.canncentral.org/web_lab/MozArbSpaceAboveBlock/fix4.html
And combined with margin-top: -1px; makes a fairly neat solution.
But I still don't understand what about the margin-collapsing part of
the spec shoves the image down flush with the blue banner if there's
no padding or border to interfere.
We will both require the assistance of someone of a linear mind set
to answer your very good and valid question
-Weston
--
http://chelseacreekstudio.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] Foxability - WCAG1.0 - CSS font size
Somehow I don't think this is on topic, but I'll leave it up to the mods to determine that with certainty. On 2008/03/19 20:26 (GMT-0500) Gate Wizard apparently typed: I was wondering how many have heard of this Firefox extension, who uses it, and their opinion of it. http://foxability.sourceforge.net/ I have a question concerning PX with Fonts and WCAG 1.0 Should fonts declared with a size in Pixels fail a WCAG 1.0 test? Without a better recollection or review of WCAG 1, I can't say whether they should or not. However, if they would not fail, I'd have to call the WCAG fatally flawed. IIRC, this is what I decided on first exposure to it, which is why I've rarely revisited or paid much attention to it. I find a lot of references that font size must be in a relative unit i.e; EM or Percent but W3 says px IS a relative unit, though relative to the device it's displayed on. Relative to the viewing device is not relative in any meaningful sense. What relatively boils down to is the standard used to measure, being either relative or not relative - or both. The only relativity that should matter regarding text size is the relationship to 1 em. A px is a purely arbitrary size in relation to what's most important to a web user - that size of 1 em, which is presumptively the user's preferred text size. That might be any number of px from about 9 up into triple digits, depending on px size and density and viewing distance to the display device. The density of px in relation to each *actual* 1 em is an unknown and unknowable value. There has been a rather predictable relationship between the number of px in 1 *default* em over the years, usually 16ppem if not a laptop, 20ppem if a modern laptop, but the physical size of that default em has been steadily decreasing for over a decade as technological advancement has been increasing average display PPI. For example, 800x600 on a viewable 14 screen, typical in 1998, is about 71 PPI. 1024x768 on 18 actual viewable is about the same 71. Contrast those to current displays, where 1280x800 on a 14 laptop is 108 PPI, 1280x1024 on a 17 LCD is 96 PPI, 1920x1200 on 24 is 94 PPI, and 1920x1200 on a 17 laptop is 133 PPI. Even without considering the wider range encompassed by little PDAs and big screen TVs or projection displays, you can see a more than 40% variation in just the the 4 unit sample I've listed, which doesn't even consider the common but dwindling population of 1024x768 or soon to be extinct 800x600 users lingering at the lower end of the real world PPI range. To better visually this impact of PPI on the size of px, visit: http://mrmazda.no-ip.com/auth/Font/fonts-pt2px-tabled.html and/or http://mrmazda.no-ip.com/auth/dpi.html -- Let us not love with words or in talk only. Let us love by what we do. 1 John 3:18 NLV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.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/
