Css Source Codes, Css Practical examples ,Css tutorial ,Your best resource for Learning Css
Showing posts with label Internet. Show all posts
Showing posts with label Internet. Show all posts
Friday, October 29, 2010
Friday, October 1, 2010
Common fixes for Internet Explorer 6 and 5
Internet Explorer 6 was a step up by Microsoft, away from the disaster (from a standards
point of view) that was Internet Explorer 5.x. That said, it still had plenty of shortcomings
of its own, the vast majority of which were dealt with when Internet Explorer 7 finally
jumped on in. Any fixes from the Solution sections that follow should be added to an IE
6-and-below-specific style sheet (see the conditional comment earlier that begins <!--[if
lte IE 6]>).
point of view) that was Internet Explorer 5.x. That said, it still had plenty of shortcomings
of its own, the vast majority of which were dealt with when Internet Explorer 7 finally
jumped on in. Any fixes from the Solution sections that follow should be added to an IE
6-and-below-specific style sheet (see the conditional comment earlier that begins <!--[if
lte IE 6]>).
Fixing min-width and max-width
Problem: The browser does not understand min-width and max-width, thereby causing
problems with semiliquid layouts that have minimum and maximum widths, rather than
set width values.
#wrapper {
min-width: 700px;
max-width: 1100px;
}
Solution: Use a proprietary IE expression to enable Internet Explorer to emulate the functionality
of min-width and max-width. In the code, the expression essentially states that if
the browser window width is less than 702 pixels, set the wrapper width to 700px (these
values—702 pixels and 700px—are numerically different to prevent Internet Explorer 6
from freezing); if it’s more than 1102 pixels, set the wrapper width to 1100px; and otherwise
set it to auto.
#wrapper {
width: expression(document.body.clientWidth < 702? "700px" :
å document.body.clientWidth > 1102? "1100px" : "auto");
}
Double-float margin bug
Problem: The browser doubles the value of any margin in the same direction as a float. For
example, in the following code, the right-floated boxout with a margin-right value of
30 pixels would actually be shown in Internet Explorer 6 and below to have a 60-pixel
margin-right value. Note that this problem only occurs for the first float in any float row.
.boxout {
width: 300px;
float: right;
margin-right: 30px;
}
Solution: Override the margin-right value, and halve it.
.boxout {
margin-right: 15px;
}
Alternatively, if appropriate, display: inline can be defined in the original CSS rule,
which results in the IE-specific override becoming unnecessary.
Expanding boxes
.boxout {
margin-right: 15px;
}
Alternatively, if appropriate, display: inline can be defined in the original CSS rule,
which results in the IE-specific override becoming unnecessary.
Expanding boxes
Problem: An element with a string that’s too wide for it doesn’t break out of its container;
instead, the browser stretches the container to contain it.
Solution: Use the word-wrap property with the break-word value, assigning it to the relevant
container.
#sidebar {
word-wrap: break-word;
}
Note that this is a CSS 3 property that’s not particularly well supported, and while it fixes
the layout, it doesn’t emulate the correct standards-compliant approach of the string
breaking out of the box—instead, it breaks the string into a number of separate lines. An
alternative is to set overflow on the container to hidden, thereby hiding the overflow and
returning the layout to normal, at the expense of not being able to see the long string.
Generally, when you come up against this problem, it makes sense to rework your string,
because while the layout won’t be affected in standards-compliant browsers, it will still
look bad.
Internet Explorer 5.x sometimes also expands a box when italics are used for some of the
text, although the problem is somewhat random. Setting overflow to visible for the container
often fixes the problem. Alternatively, setting the value to hidden crops the unruly
few extra pixels.
The 3-pixel text jog
Problem: Inline content next to a floated element
is pushed away by 3 pixels. In the
depicted example, the content in the dotted
line has a 3-pixel jog in the text that appears
under the floated element.
Solution: Apply the “Holly hack,” a 1% height
value to the relevant containing element(s).
See three-pixel-jog.html in the chapter 9
folder of the download files. Try removing
height: 1%; from #textWrapper to see how
the page looks without the hack.
Common fixes for Internet Explorer 5.x
A few major problems are known to affect Internet Explorer 5.x specifically, and were fixed
in versions 6 and above. When using any of the fixes from the following Solution sections,
add them to an IE 5–specific style sheet (see the conditional comment earlier that begins
<!--[if lt IE 6]>).
in versions 6 and above. When using any of the fixes from the following Solution sections,
add them to an IE 5–specific style sheet (see the conditional comment earlier that begins
<!--[if lt IE 6]>).
Box model fixes (5.x)
Problem: Internet Explorer 5.x wrongly applies padding and border values within the
defined dimensions of a box (which is what the box model specifies). In the following
example, the overall width taken up by the box should be the sum of its border, padding,
and width values (420px). (Note that when using shorthand, you need to be mindful that
the amount of space they take up is double the value. In other words, if you set padding
to 50px, 50 pixels of padding is applied to both horizontal edges. Therefore, in the following
code block, the sum to find the overall width of the values in the rule is 300 + 50 + 50
+ 10 + 10.) However, in Internet Explorer 5.x, the box is only 300 pixels wide—the padding
and border are placed inside the defined width, leaving only 180 pixels for content. This
issue tends to affect most CSS-based layouts.
.boxout {
width: 300px;
padding: 50px;
border: 10px solid #000000;
}
Solution: Override the width setting by setting a new value in the style sheet attached via
a conditional comment. The value should take into account the shortcomings listed previously
and therefore needs to equal the value of the relevant dimension (depending on
whether you’re defining a width or a height), along with the relevant padding and border
values.
.boxout {
width: 420px;
}
Centering layouts
Problem: The browser doesn’t understand margin: auto, so when, for example, a wrapper
is horizontally centered using the following code block, the resulting layout will be incorrectly
aligned to the left of the browser window.
#wrapper {
width: 700px;
margin: 0 auto;
}
Problem: The browser doesn’t understand margin: auto, so when, for example, a wrapper
is horizontally centered using the following code block, the resulting layout will be incorrectly
aligned to the left of the browser window.
#wrapper {
width: 700px;
margin: 0 auto;
}
Solution: A workaround for this problem is to use the text-align property to align everything
within the page body centrally. You then set the alignment back to the default of
left in your wrapper (or wrappers, if you’ve used more than one). If you’ve used
other/additional layout elements that have been centered (e.g., if you have separate masthead,
content, and footer containers, rather than your entire page structure placed within
a single wrapper), those elements will also need the text-align: left override.
body {
text-align: center;
}
#wrapper {
text-align: left;
}
The text-transform bug
Problem: The browser ignores a text-transform value if line-height is defined in the
same rule.
h1 {
font: bold 1.2em/1.4em Arial, Helvetica, sans-serif;
text-transform: uppercase;
}
Solution: Reconfirm the text-transform value in the style sheet linked via a conditional
comment.
h1 {
text-transform: uppercase;
}
Font-size inheritance in tables
Problem: When using relative units, text within table cells may be displayed at the wrong
size (too large).
Solution: Set font-size to 100% in a table rule in a style sheet linked via a conditional
comment.
table {
font-size: 100%;
}
font-size: 100%;
}
Thursday, September 30, 2010
Dealing with Internet Explorer bugs
As mentioned elsewhere, Microsoft made a huge leap forward with Internet Explorer 7,
but it’s still not without its problems. Also, because Microsoft’s browser enjoyed such an
immense market share for so long, older versions remain in use for years, sometimes
enjoying a share of the market that manages to eclipse every other browser apart from the latest release of Internet Explorer. With this in mind, along with the sad fact that
Microsoft’s browser has been the least compliant one out there for a long time now, this
section is dedicated to exploring how to deal with the most common Internet Explorer
bugs. These are all worth committing to memory, because if you’re working on CSS layouts,
these bugs will affect your designs at some point, and yet most of the fixes are
extremely simple.
but it’s still not without its problems. Also, because Microsoft’s browser enjoyed such an
immense market share for so long, older versions remain in use for years, sometimes
enjoying a share of the market that manages to eclipse every other browser apart from the latest release of Internet Explorer. With this in mind, along with the sad fact that
Microsoft’s browser has been the least compliant one out there for a long time now, this
section is dedicated to exploring how to deal with the most common Internet Explorer
bugs. These are all worth committing to memory, because if you’re working on CSS layouts,
these bugs will affect your designs at some point, and yet most of the fixes are
extremely simple.
Subscribe to:
Posts (Atom)