BORDERS FOR WIRE FRAMING

Applying simple borders to your divisions and other key elements is a brilliant way of creating a wire frame.
Wire framing a design with a thin solid or dashed line around your divs can help you understand how one
element relates to another, and also identify problems with alignment and juxtaposition.
You can apply a simple dashed line to all divs, for example, using a base selector for the <div> tag:
/* Place a thin gray border around all divisions */
div {
border: 1px dashed #CCC;
}
This rule would be placed immediately after the body selector in the style sheet, and would ensure all
divs you create inherit a thin gray border, unless you specify otherwise in that element’s rule. To apply this rule
to further base elements, simply group the selectors together:
/* Place a thin gray border around the following elements */
div, h1, h2, h3, h4, ul {
border: 1px dashed #CCC;
}
When you are satisfied that your design is hanging together correctly, just remove the relevant selectors
or the entire rule.

Css Tutorial : Indenting for Clarity

Further to sensible commenting and flags, responsible CSS developers can make their style
sheets even more legible. The following example makes use of comments and flags, but also
aims to make the layout even more legible using white space:
/* =p Default styling for paragraphs
-------------------------------------------------------- */
p {
color: #F00;
font-size: 12px;
}
/* =h1 Make all top-level headings gray and 16px high
--------------------------------------------------------------*/
h1 {
color: #333;
font-size: 16px;
}
For the purposes of this book, I’m using two-space indents for the selector and four-space
indents for the declarations. Indenting is used to provide clarity. In the real world (or your
favorite text editor, to be precise), many developers use one tab click to indent the selector, and
two tab clicks to indent the declarations and closing curly brace. This might seem arbitrary, but
such a layout makes regular searching for rules a whole lot easier. The eye can scan immediate
left for comments, next right for the selectors, and farthest right for the rules.
Embracing such methods at this stage is not essential, but doing so will certainly help
you stay focused and avoid confusion as your style sheets begin to grow. Very few developers
consider these methods as they begin to learn CSS, but thinking and coding logically from day
one are two of the things that separate a great CSS designer from an average one.

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

Outdated methods for hacking CSS documents

Historically, web designers have resorted to exploiting parsing bugs in order to get around
Internet Explorer problems. Perhaps the most famous of these is Tantek Çelik’s box model
hack, designed to get around Internet Explorer 5.x’s inability to correctly deal with the box
model: it places padding and borders within the defined content dimensions of a box,
rather than on the outside. In other words, a box with a width setting of 300px and
padding of 20px should take up a total width of 340 pixels in a compliant browser, but in
IE 5.x, it only takes up 300 pixels. Also, only 260 pixels are available for content, due to the
40-pixel padding being placed inside the defined width of the box.
Tantek’s hack works by exploiting a CSS-parsing bug. In the following code block, padding
is set in the rule, along with a width for Internet Explorer 5.x, which terminates the rule in
the voice-family lines. Compliant browsers continue reading, thereby using the second
width value to override the first. The net result is that all browsers show the box at the
correct width.
.box {
padding: 20px;
width: 340px;
voice-family: "\"}\"";
voice-family: inherit;
width: 300px;
}
A further rule is added by some designers to cater for Opera’s then-inability to read past
the voice-family lines—the “be nice to Opera” hack took advantage of Internet Explorer
5.x not understanding child selectors, and therefore used one to set the correct width in
that browser:
html>body .box {
width: 300px;
}
The box model hack itself was later simplified further, to the simplified box model hack (or
SBMH), which involved using a single backslash in the second pair to get Internet Explorer
5.x to terminate the rule:
.box {
padding: 20px;
width: 340px;
w\idth: 300px;
}
In a sense the opposite of the box model hack, the star HTML hack is also often seen, in
order to make only Internet Explorer see a rule:
* html .box {
background: #000000;
}
There are myriad other CSS hacks out there, but they won’t be explored here. Not only do
hacks mess up your otherwise clean and compliant style sheet, but they’re also not futureproof,
as evidenced when the star HTML hack stopped working upon the release of
Internet Explorer 7. Also, hacks often need overrides, as evidenced by the “be nice to
Opera” hack. A far better and more future-proof method is to ditch CSS hacks entirely,
instead making a totally clean style sheet for a website, and using conditional comments to
fix bugs in Internet Explorer

Tips And Tricks For Tables layout in Css

This section is going to be brief, because you should avoid using tables for layout, or even
components of a layout (excepting tabular data, obviously). There are exceptions—for
instance, some web designers consider tables acceptable for laying out forms. However,
generally speaking, tables are less accessible than CSS, harder to maintain and update,
slow to render in browsers, and don’t print particularly well. More importantly, once you
know how to create CSS-based layouts, you’ll mostly find working with tables for layout
frustrating and clunky.
A common way of creating tabular layouts is to chop up a Photoshop layout and use
images to stretch table cells to the correct size. (As mentioned earlier, table cells expand
to the dimensions of their content.) Many designers then use a 1-pixel invisible GIF89
(often referred to as a spacer or shim) to force content into position or stretch table cells
to a certain size. Because the 1-pixel GIF is a tiny file that’s cached, it can be used hundreds
of times without impacting download times. However, spacer and table layout usage pretty
much destroys the idea of a semantic Web. Because so much of the layout is defined via
inline HTML, updating it requires amendments to every page on the site (which must also
be uploaded and tested in each case), rather than the simple editing and uploading of an
external CSS file.
It is possible to combine CSS and tables—something that’s usually referred to as a transitional
layout, although one might argue that the “transition” from tables to CSS layouts
should now be considered an historic event. Such layouts are usually created to ensure
layout-based backward compatibility with obsolete devices. This direction should only be
taken when the target audience is known to definitely include a significant number of
users of very obsolete browsers, and also when the layout is paramount to the working of
the site (rather than just the content). When working on such a layout, there are a few
golden rules:
Avoid nesting tables whenever possible: Although tables can be nested like any
other HTML element, doing so makes for a web page that is slow to render and
nightmarish to navigate for a screen reader. (Obviously, there are exceptions, such
as if you need to present a table of tabular data within your layout table.)
Structure the information on the page logically: When designers use tables (particularly
those exported from a graphics package), they have a tendency to think
solely about how the page looks rather than its underlying code. However, it’s
important to look at how the information appears in the HTML, because that’s how
a screen reader will see it. The content should still make sense with regard to its
flow and order even if the table is removed entirely. If it doesn’t, you need to
rework your table. (You can use Opera’s User mode to temporarily disable tables to
find out how your information is ordered without them. Chris Pederick’s Web
Developer toolbar for Firefox [www.chrispederick.com/work/web-developer/]
offers similar functionality via Miscellaneous ä Linearize Page.) Ensure that content
is immediately available; if it isn’t, provide a link that skips past extraneous content,
such as the masthead and navigation—otherwise, people using screen readers will
be driven bonkers. (See www.w3.org/TR/WAI-WEBCONTENT/ for more on web content
accessibility guidelines.)
Avoid deprecated attributes: For instance, there’s little point in setting the table’s
height to 100% when many web browsers ignore that rule (or need to be in quirks
mode to support it).
Use CSS whenever possible to position elements: To give an example—if you’re
working with a 3-cell table and want the middle cell’s content to begin 100 pixels
from the top of the cell, don’t use a spacer GIF. Instead, provide the cell with a class
or unique ID, and use CSS padding.As I keep hammering home, CSS is the way to go for high-quality, modern web page layouts,
and tables should be left for the purpose for which they were designed—formatting
data. The arguments that rumbled on for a few years after the 1990s came to a close—that
browsers didn’t support enough CSS to make CSS layouts possible, and that visual design
tools such as Dreamweaver couldn’t cope with CSS layouts—are now pretty much moot.
Even the previous major release of the worst offender (yes, I’m talking about Internet
Explorer 6) has more than adequate support for the vast majority of CSS layouts, and anything
shipping today is more than capable of dealing with CSS.
In my experience, the main reason designers avoid CSS involves their not knowing how to
work with it. Suitably, then, the next chapter deals with this very issue—showing how
to create page layout elements using CSS.
The last two of these rules are primarily concerned with ensuring that if you design for
legacy browsers, you don’t compromise your work for more modern efforts.
TABLES: HOW NATURE (AND THE W3C) INTENDED
255

How to find targets for collapsible content scripts

If you want to change your document structure when using the script from the previous
section in this chapter, you need to find the parent/sibling path, in Internet Explorer and in
other browsers. If you’ve a good grasp of JavaScript, this should be simple; however, if you
don’t—or you just want to sanity-check your values—it’s simple to find out what an element’s
parent is, what it’s next sibling is, and various combinations thereof.
First, give your clickable element a unique id value:
<p><a id="linkToggler" href="#" title="Toggle section"
å onclick="toggle(this); return false;">Toggle div 1!</a></p>
Elsewhere within the web page, add the following script:
<script type="text/javascript">
//<![CDATA[
alert(document.getElementById("linkToggler").nodeName);
//]]>
</script>
Before .nodeName, add whatever combination of .parentNode and .nextSibling you
like—here’s an example:
<script type="text/javascript">
//<![CDATA[
alert(document.getElementById("linkToggler").parentNode.
ånextSibling.nextSibling.nodeName);
//]]>
</script>
When you load the web page in a browser, an alert message will be displayed. This will
detail what the target element is, based on the path defined in the previous code block.

Enhancing accessibility for collapsible content

Although the old version of the Images from Iceland site looks good, it has a problem in
common with the previous exercise: when JavaScript is disabled, the initially hidden content
is inaccessible. The Iceland site was quickly knocked together a number of years back
and has been superseded with a new site, but for any site developed today, there should
be no excuses.
In the previous exercise, the hidden content is set to be hidden by default and the display
property is toggled via the JavaScript function. What therefore needs to be done is to
make the content visible by default and then override this, making it invisible, but only if the user has JavaScript. The first thing to do is remove the style attribute from the following
line of code:
<div id="hiddenDiv" style="display: none;">
Next, a style sheet is created (named javascript-overrides.css for this example), with a
rule that targets the relevant div and sets display to none.
#hiddenDiv {
display: none;
}
Finally, amendments are made to the JavaScript file, adding some lines that attach the new
JavaScript document to the web page:
var cssNode = document.createElement('link');
cssNode.setAttribute('rel', 'stylesheet');
cssNode.setAttribute('type', 'text/css');
cssNode.setAttribute('href', 'javascript-overrides.css');
document.getElementsByTagName('head')[0].appendChild(cssNode);
The results of this are the following:
If a user has JavaScript enabled, javascript-overrides.css is loaded, applying the
display value of none to the togglable div.
If a user has JavaScript disabled, javascript-overrides.css is not loaded, meaning
the togglable div contents are visible.
See the collapsible-div-accessible folder within the chapter 5 folder for reference
files.