Thanks for the explanations, which are quite clear.
I was clutching at straws when the only “content” I saw was in the menu style sheet:
.nav li:first-child:before {
content:"";
padding:0;
}
but that is a property and obviously has nothing to do with the selector “content”.
However, this is very important for me to understand:
"The class ‘content’ is not used at this time. The div that it’s associated with IS required, however. "
What is that <div> doing?
Goofy me. I searched forties10a.htm and cma10a.css, but didn’t search menu10a.css for “content”. Sorry. 
Excellent question. The <div> creates a context, a reference, a starting point, for the “nth-child” property assigned to the inner <div>s. That’s the property that alternates the background colors. Without it, “nth-child” would not target the “items” as intended.
EXPERIMENT: Make a copy of forties10a.htm and delete <div class=“content”> … </div> (but not the “items”) and see what happens. 
EDIT: I just tried the experiment and the page renderes correctly. Odd because it failed while I was working on the code a few days ago. Perhaps it was before I added the <h2> above “content” and maybe I had an unnecessary <div> around the menu, too. Who knows. In any event, the “content” container is harmless and potentially useful if you decide to jazz up your design, so I’d not recommend deleting it.
I don’t have a <div> around the nav menu, which is within <ul> tags.
It seems that without the extra “content” <div>s, the context for the various “.item: nth-child” selectors is provided by the “outer” <divs>. So I’d like to delete the "content <divs>.
BTW, I have only a vague idea of the purpose of the js file. Why is this needed?
<!--[if lt IE 9]>
<script type="text/javascript" src="js/respond.min.js"></script>
<style type="text/css">
.item {border-bottom:1px solid #888;}
.item + .item {margin-top:6px;}
</style>
<![endif]-->
You can delete <div class=“content”> if you wish. Doing so will not cause any ill effects to the current layout.
Personally, I would not delete it. I tend to “containerize” sections of content in order to avoid interaction between them. It has proven time and again to be a good strategy. Keeping the container <div class=“content”> may be useful in the future should you redesign your menu. Likewise, the page could be a useful model for similar layouts in the future. Keeping <div class=“content”> is harmless. Relying on <div class=“outer”> to be the parent container for the <div class=“item”> would not be my choice.
respond.min.js is required to give IE8 the ability to respond to simple media queries. Since IE8 is a desktop browser and the media queries target smaller window widths, it is unlikely to matter if you decide not to bother with it. IE8 would never display the 3 column pattern anyway.
.item p { font-size:.9375em;
margin-left:20px; /* at 700px we apply a left margin to the text */ }
Don’t we also inherit this style?
.item .imagebox { padding-right:20px;}
But it does not look as if we have–and we don’t want–a total of 40px between .item.imagebox and .item.descript
I assume we inherit from the 721-900px styles this one:
.item + .item {margin-top:6px;} /* space between .items */
But on the smaller tablet, vertical spacing between .items looks more like 1-2px. Apparently, the above style has been overriden?
In any case, where would I increase the verical spacing a bit, e.g., to 2 or 3px.?
At a window width greater than 900px, you can see that the text in the .descript box is vertically centered {vertical-align:middle}. It is not so obvious that the image in .imagebox is vertically centered also. To prove that the image is also vertically centered, increase the amount of text in a .descript box until it pushes the height of the box taller. You will see the image vertically center. The left edge of the text (which has zero padding and margin) rests against the right edge of .imagebox which in turn has the {padding-right:20px} that creates the space between text and image (which was colored pink in the last version).
At 900px the three column design is changed to the two column layout. It is at that width that you said that you liked the white space between .items. .item + item {margin-top:6px} adds the white space by separating the .item boxes. There are no other properties to override that setting. If 6px still looks like 6px when the width of the desktop browser is reduced to less than 700px, then the “problem” is in the way the tablet is rendering the page. If it looks like only 1 or two pixels on the smaller tablet, then perhaps the content is being zoomed smaller than normal. I suggest that you check the zoom setting of your tablet; then consider the screen density (dpi) of the tablet. Are all of the contents smaller in the tablet? It should be 6px in all viewports unless content is zoomed smaller or some other factor is in play.
You can increase 6px to a larger value at your pleasure. If you are happy with 6px at 900px but wish it to be greater at narrow device widths, then copy and paste the line from the 900px media query into the 700px media query and increase the margin-top as desired.
@media screen and (max-width:900px) {
.item:nth-child(even) {margin-left:0px;}
.item:nth-child(odd) .descript {padding-left:0;}
[color=blue].item + .item {margin-top:6px;} /* space between .items */[/color]
}
@media screen and (max-width:700px) {
.item .imagebox {float:left;}
.item .descript {display:block;}
.item p {
font-size:.9375em;
margin-left:20px; /* at 700px we apply a left margin to the text */
}
h1 {text-align:center;}
[color=blue].item + .item {margin-top:12px;} /* space between .items */[/color]
}
At 700px the structure of the layout changes again. .imagebox gets {float:left} and .descript becomes {display:block;}. The image moves from vertically centered to the top of the column (if there’s enough text in .descript). Likewise, the text in .descript becomes top aligned (by default). Why do we add .item p {margin-left:20px} and why don’t we see it between the text and the image?
{margin-left:20px} provides space between the text and the left edge of .item.
It is not seen beside the image because .imagebox is floated and margins or padding applied to the text flow beneath the float. Remember that floats are removed from the normal flow of the page. In this case, that characteristic enables text to flow beside and wrap below the bottom of image. The space (margin apparent) to the left of the text has to be applied via the image (in this case, .imagebox). In summary, {margin-left:20px} provides the left margin to the text as if there were no image in the .items and the padding in .imagebox provides the appearance of a margin between the image and the text.
You can see what {margin-left:20px} is doing by narrowing the window until some text wraps beneath the image. Note the space between the text and the left edge of .item. Then comment out {margin-left:20px} and watch the space between the text and the left edge of .item will vanish.
Thanks for the explanations of fairly complex CSS issues. My belief is that the DW 5.5 implementation at some screen widths, e.g., a viewport of 521-700px, are unreliable.
I don’t own or table or smart phone, so I have to rely on DW 5.5. Even putting this style into the small tablet style:
.item + .item {margin-top:6px;
did not change the apparent 1px vertical item separation. However, the problem is undoubtedly the DW 5.5 implementation. In any case, that style was inherited from the larger tablet.
Likewise, commenting out this style:
.item p {margin-left:20px;
did not result in causing the space between text and left edge of .item to vanish.
Ron, thank you for your amazing CSS design. The design and explanations are complete and A+!
I have two remaining minor questions:
<!doctype html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<title>1940s to Designer high-style vintage clothing at Vintage Textile</title>
<meta name="description" content="1940s & 1950s high-style vintage clothing and Designer fashion for the discriminating collector at Vintage Textile.com" />
<meta name="keywords" content="party dress" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<link href="style_sheets/cma10a.css" rel="stylesheet" type="text/css" />
<link href="style_sheets/menus10a.css" rel="stylesheet" type="text/css" />
<!--[if lt IE 9]><script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script><![endif]-->
<!--[if lt IE 9]>
<script type="text/javascript" src="js/respond.min.js"></script>
<style type="text/css">
.item {border-bottom:1px solid #888;}
.item + .item {margin-top:6px;}
</style>
<![endif]-->
</head>
In the <head> section, when I update the design of a page, I normally turn it into HTLM 5 by using
<!doctype html> and also adding the first “if lt IE 9” script.
Do you see any conflict with your script?
What is your take on the use of “only”?
David Powers in his articles states:
“It is recommended to prefix media queries with “only” if you want to hide the styles from other, less common browsers” giving this example:
@media only screen and (max-width:400px)
cma6, I think I must not express myself very clearly at all.
First, in post #33, I thought that I clearly explained that Dreamweaver Design View was not a browser and was not to be relied on as a medium for testing one’s code. It is not a real browser. It is as buggy as Hades. I am disappointed, of course, that I have been trying to offer suggestions to remedy “problems” that are nothing more than manifestations of bugs in Dreamwisher’s flawed Design View; because if perchance some change DOES fix a Design View “issue”, then the result will be code that does NOT work correctly in REAL BROWSERS. I have been wasting time and energy. So I must not have explained that very well since your last post describes how Dreamwisher’s Fantasy View does not render the code correctly in its tablet views. Well, it’s not a browser, and it’s even further from being a tablet.
If you have a real browser on your computer, use it for testing your code. Double-click the actual file and open it in your browser. Drag the edge of the browser window to narrow widths to test media query triggered layout changes. ALWAYS use a real, up-to-date browser for testing. NEVER use “you-know-what”.
In post #46, you asked about {margin-left:20px} being applied to the paragraph at 700px and narrower.
You also asked about the {margin-top:6px} being applied to .items below 900px.
It appears that I did not explain the code very clearly in post #47, either, because you were unable to duplicate the behavior that I claimed you should see. I’ll give that another try…
I prepared two images; screenshots of a text editor and a real browser (Firefox).
At the top of each image is the CSS that the browser is rendering.
Regarding {margin-left:20px} assigned to the paragraph in (line 95) of the CSS:
The left image shows that the margin provides space between the left edge of .items and the left edge of the text. (References are in Blue). The right image shows that if {margin-left:20px} were not applied, the left edge of the text would touch the left edge of .items. The first image also demonstrates that the left margin does not add space between the right edge of the image and the text; it only affects the edge of the paragraph that is near the edge of .items. That’s how text behaves around floats.
Regarding increasing the vertical space between .items (.item + .item {margin-top:6px} ):
The left image shows spacing of 6px and the code in the 900px query that supplies it (line 88). The right image shows a separation of 12px between .items. In the code at the top, in the 700px query, you can see where the line of copied code was added (line 98) and see that 6px was changed to 12px.
I do hope that these images clarify what I was unable to articulate clearly, especially about the difference between Design View and Real Browsers. You DO have a choice. If you do not know how to un-maximize your browser so you can drag the window edge and resize it, just ask.
If you would like to discuss any more existing issues, please specify the BROWSER in which you see them; if IE, please include the version number.
The HTML5 header that you have written could be modernized a little:
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>1940s to Designer high-style vintage clothing at Vintage Textile</title>
<meta name="description" content="1940s & 1950s high-style vintage clothing and Designer fashion for the discriminating collector at Vintage Textile.com">
<meta name="keywords" content="party dress">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<link href="style_sheets/cma10a.css" rel="stylesheet" type="text/css">
<link href="style_sheets/menus10a.css" rel="stylesheet" type="text/css">
<!--[if lt IE 9]>
<script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<script type="text/javascript" src="js/respond.min.js"></script>
<style type="text/css">
.item {border-bottom:1px solid #888;}
.item + .item {margin-top:6px;}
</style>
<![endif]-->
</head>
There is no requirement in HTML(5) to use the XHTML closing slash on empty elements.
I am not familiar with David Powers. He seems to be a Dreamweaver author. If you can provide a link to his article, I’ll read it. We can also ask @ralph_m for his opinion about the use of “only” in media queries.
It’s quite standard and I find the queries work better with it in there, but I’ve not read up on it so am quite ignorant, really. 
Ron,
Thank you for the further clarification as well as the modernization of my HTML5 header section.