Showing posts with label common. Show all posts
Showing posts with label common. Show all posts

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]>).

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

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]>).

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;
}

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%;
}

Thursday, September 30, 2010

DEALING WITH BROWSER QUIRKS : Weeding out common errors

Testing in browsers isn’t everything; in fact, you may find that your site fails to work for no
reason whatsoever, tear your hair out, and then find the problem lurking in your code
somewhere. With that in mind, you should either work with software that has built-in and
current validation tools (many have outdated tools, based on old versions of online equivalents),
or bookmark and regularly use the W3C’s suite of online tools: the Markup
Validation Service (http://validator.w3.org/), CSS Validation Service (http://jigsaw.
w3.org/css-validator/), Feed Validation Service (http://validator.w3.org/feed/),
Link Checker (http://validator.w3.org/checklink), and others (www.w3.org/QA/Tools/)
as relevant.
Other useful online services include WDG Link Valet (www.htmlhelp.com/tools/valet/),
WDG HTML Validator (www.htmlhelp.com/tools/validator/), and Total Validator (www.
totalvalidator.com/). Accessibility-oriented services include HP’s Color Contrast Verification
Tool (www.hp.com/hpinfo/abouthp/accessibility/webaccessibility/color_tool.html);
Etre’s Colour Blindness Simulator (www.etre.com/tools/colourblindsimulator/); and
the Cynthia Says Portal Tester (www.cynthiasays.com/fulloptions.asp), which can
aid you in Section 508 and WAI (Web Accessibility Initiative—see www.w3.org/WAI/)
compliance.
Here are some of the more common errors you might make that are often overlooked:

Spelling errors: Spell a start tag wrong and an element likely won’t appear; spell an
end tag wrong and it may not be closed properly, wrecking the remaining layout. In
CSS, misspelled property or value names can cause rules—and therefore entire layouts—
to fail entirely. British English users should also remember to check for and
weed out British spellings—setting colour won’t work in CSS, and yet we see that
extra u in plenty of web pages (which presumably have their authors scratching
their heads, wondering why the colors aren’t being applied properly).

Incorrect use of symbols in CSS: If a CSS rule isn’t working as expected, ensure
you’ve not erred when it comes to the symbols used in the CSS selector. It’s a
simple enough mistake to use # when you really mean . and vice versa.

Lack of consistency: When working in XHTML, all elements and attributes must be
lowercase. In CSS, tag selectors should also be lowercase. However, user-defined id
and class values can be in whatever case the author chooses. Ultimately, decide
on a convention and stick to it—always. If you set a class value to myvalue in CSS
and myValue in HTML, chances are things won’t work. For the record, I prefer
lowerCamelCase, but there’s no reason for choosing a particular case.

Not closing elements, attributes, and rules: An unclosed element in HTML may
cause the remainder of the web page (or part of it) to not display correctly.
Similarly, not closing an HTML attribute makes all of the page’s content until the
next double quote part of the attribute. Not closing a CSS rule may cause part or
all of the style sheet to not work. Note that CSS pairs that aren’t terminated with a
semicolon may cause subsequent rules to partially or wholly fail. A good tip to
avoid accidentally not closing elements or rules is to add the end tag/closing
bracket immediately after adding the start tag/opening bracket. This also helps to
avoid incorrect nesting of elements.

Multiple rule sets: In CSS, ensure that if you use a selector more than once, any
overrides are intentional. It’s a common error for a designer to duplicate a rule set
and have different CSS property values conflicting in different areas of the CSS.
Errors with the head and body elements: As stated earlier in the book, HTML content
should not appear outside of the html element, and body content should not
appear outside of the body element. Common errors with these elements include
placing content between the closing head element tag (</head>) and the body start
tag (<body>), and including multiple html and body elements.

Inaccessible content: Here, we’re talking in a more general sense, rather than about
accessibility for screen reader users. If you create a site with scrollable areas,
ensure users can access the content within, even if browser settings aren’t at their
defaults. Problems mostly occur when overflow is set to hidden. Similarly,
textarea elements that don’t have properly marked-up cols and rows settings
will often be tiny when viewed without CSS (these attributes are functional as well
as presentational). The same is true for text input fields without a defined size
attribute.

Dead links: These can take on many forms, such as a link to another page being
dead, an image not showing up, or external documents not being accessible by the
web page. If a JavaScript function isn’t working for some reason, try checking to see
whether you’ve actually linked it—in some cases, the simpler and most obvious
errors are the ones that slip through the net. Also, if things aren’t working on a live
site, check the paths—you may have accidentally created a direct link to a file on
your local machine, which obviously won’t be accessible to the entire Internet.
Spaces within href values or the original file names can also be accidentally overlooked.

Whitespace errors: In CSS, do not place whitespace between class/id indicators and
the selector name, or between numerals and units for measurements. However, do
not omit whitespace from between contextual selectors, otherwise you’ll “combine”
them into a new, probably unknown, one.

Using multiple units: In CSS, a value can only accept a single unit—the likes of
50%px can cause a rule to partially or wholly fail.