SitePoint Sponsor

User Tag List

Page 2 of 3 FirstFirst 123 LastLast
Results 26 to 50 of 51
  1. #26
    SitePoint Mentor bronze trophy
    ronpat's Avatar
    Join Date
    Jun 2012
    Location
    NJ, USA
    Posts
    2,509
    Mentioned
    61 Post(s)
    Tagged
    2 Thread(s)
    cma6,

    Quote Originally Posted by cma6 View Post
    In Dropbox, I was able to open the stylesheet and copy the text to a new style sheet on my system. However, with Productpage8.html it did not open in Dropbox. When downloaded, it appears to be a js file, not an html file.
    Quote Originally Posted by cma6 View Post
    I figured out how to get the Dropbox html file and will start reviewing it today. I'm looking only at the IE9 files. I guess I have to link the js file to the html page.
    I double-checked the files and can read the css files online or download them to my PC. The html files have to be downloaded to the PC. Both are intact (no garbage) and, after downloading/copying, the css files are read by the html files. I found that I had to use Chrome instead of Firefox to read the css file. Too many protection addons in FF, probably . Nevertheless, Dropbox's behavior surprised me since both files contain ascii text with windows CRLFs.

    The main thing you need to do is place the JavaScript file, respond.min.js, on the server so IE8 will honor the media queries. The link to the expected location of the respond.min.js file is already at the top of the HTML files (you can change it if needed).

    Personally, as I said before, I think that the IE9+ page with the respond.min.js file on the server for a token of IE8 support is the better choice.

    PS: I fixed a small oversight in the files so you should download them again.

    Quote Originally Posted by cma6 View Post
    Just as an aside, I should mention that while the design falls back to a single column of images in FF, in IE10 the design retains the checkerboard effect as I zoom in (increase content size.)
    I think you might have stated that backwards

    Most browsers zoom content only. Firefox allows the user to zoom text-only or content. In Firefox, when zooming text-only, the images are not resized on the screen.

    The advantage to the coder of zooming text-only is that s/he can see how the page might behave if the user has chosen a larger font size or is using a different platform that has different fonts than the coder.

    Zooming content effectively magnifies the content within the confines of the page. The checkerboard layout cannot but collapse when zoomed larger in a 980px window. That's the way my layout is designed.

    HERE's WHY: Your home page is designed for a maximum width of 980px. Although my layout does not have a max-width, I imagine that you are expecting/testing the page to fit within 980px. OK. Let's look at the width of the images... 209px each... a predictable 418px. To that we add paragraph margins of 40px. Now we are up to 458px of inflexible space. Approximately 980px - 458px = 522px for the actual text. That's about 45:55 ratio. I also considered that the height occupied by your sample text would begin pushing the items taller if the width allowed for the text were less than ~522px. You see this happen in the narrower views; and, in the narrower views, the text is allowed to wrap beneath the images to reduce the increase in height. Designer's decision time.... Do I want the images and the empty space required for a three column layout to take up 50% or more of the width of the page and push the height "prematurely" taller? My choice was NO. So the media query says "at max-width:900px, change the layout to two columns" thereby allowing more room for the text. 980px - 900px is only 80px of difference; so, YES, the change to two columns takes place rather soon when the content is zoomed. Remember, zooming content magnifies the dimensions of the content but not the window. If your page allowed a wider minimum width (as mine layout does), the change to two columns would not have to happen so quickly.

    EXPERIMENT: If you have a widescreen monitor, do the following: Zoom the content in IE10. Just after the layout changes to two columns, extend the width of the browser window. You'll see the three column (checkerboard) layout return.

    How else would you expect your design to behave in a 980px width window? Images and text have to go *somewhere* when zoomed.

    Do you have a different behavior in mind?

    Does this help or hinder?

  2. #27
    SitePoint Enthusiast
    Join Date
    Sep 2004
    Location
    USA
    Posts
    71
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    "The main thing you need to do is place the JavaScript file, respond.min.js, on the server so IE8 will honor the media queries. The link to the expected location of the respond.min.js file is already at the top of the HTML files (you can change it if needed)."
    I will be waiting to go live only when I have everything set and understood.


    "Personally, as I said before, I think that the IE9+ page with the respond.min.js file on the server for a token of IE8 support is the better choice."
    I agree and have downloaded only the IE9+ pages. As you can tell, I am a total newbie on Dropbox

    "PS: I fixed a small oversight in the files so you should download them again."

    I started to go over your stylesheet this morning and had some changes and questions but will start again on Friday as I just downloaded your latest .html page and stylesheet.

    What changes did you make in the .html code?

    My only change so far in the styles was to add a body tag with white background color and my preferred fonts.
    However, I noticed that your latest style sheet achieved the white background color for the even rows, although I don't see how it is done in cma6.css

    "I think you might have stated that backwards."

    You are right about zooming text-only in FF. However, zooming content is the default. Also, I've found that setting FF to zoom font results in bad formatting on certain web pages, at least for my uses.
    I tested your latest pages and will amend my comments about retaining the staggered checkerboard look in IE10 vs. FF to this: as one zooms content, both browsers eventually collapse the design back to two rows. However, FF does that almost immediately as one zooms content. In IE10, I had to zoom content a great deal before the collapse occurs. At least that happens on my 19" monitors.
    In any case, I'm happy with your design solution and am quite comfortable with the current behavior on zoom, even though I don't understand the exact mechanics.

  3. #28
    SitePoint Mentor bronze trophy
    ronpat's Avatar
    Join Date
    Jun 2012
    Location
    NJ, USA
    Posts
    2,509
    Mentioned
    61 Post(s)
    Tagged
    2 Thread(s)
    The only change on the HTML page for the (IE9+) version is:
    Code:
    <!--[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 {border-top:1px solid #888;}
    .item:first-child {border-top:0;}
        </style>
    <![endif]-->
    IE8 does not get a gray background-color on the odd rows; all rows are white. I had initially added a gray line beneath each row in IE8 which meant that there was a gray line at the bottom of the page. This change places the gray line between the rows by moving the gray border to the top (above each row) then removing the topmost border. The result is that there is no "extra" line at the top or at the bottom. A trivial change, really. And now you know what it does and how it works (the mechanics) !!!

    I'm at a loss to explain the difference that you see between IE10 and Firefox. Are the images exactly the same size in Firefox and IE10 when the page is first loaded?

    The white background-color on the even rows is the absence of a background-color. If you change the background-color on the body tag, it will also become the background-color of the even rows. If you want to specify the background-color for the even rows, you can add a background-color in any of three places:
    Code:
    .outer {
        width:90%;
        background-color:#fdd;  /* example only */
        margin:0 auto;
    }
    .item {
        background-color:#fdd;  /* example only */
        overflow:hidden;
    }
    .item:nth-child(even) {
        background-color:#fdd;  /* example only */
        margin-left:209px;
    }
    .outer applies the background color to the entire container which includes the space to the left of the product image in even rows.
    .item applies the background color to all rows beneath and to the right of the thumbnail image. The space to the left of the thumbnail image in even rows is not colored.
    .item:nth-child(even) does the same thing as .item except that it only targets even rows.
    Code:
    .item:nth-child(odd) {
        background-color:#e5e5e5;
    }
    The rule above is applied later than the previous three rules and is more specific than the first two; therefore, it overrides whatever background-color may be applied to those containers, thus producing alternately colored rows.

    IE8 does not recognize :nth-child() which is why alternating colors cannot be easily applied in IE8 without classing the items to be colored.

    Hope this is useful/helpful.

  4. #29
    SitePoint Enthusiast
    Join Date
    Sep 2004
    Location
    USA
    Posts
    71
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    "I'm at a loss to explain the difference that you see between IE10 and Firefox. Are the images exactly the same size in Firefox and IE10 when the page is first loaded?"

    In IE10, the images are smaller when first loaded.

    The reason I needed to add the white color in the body tag is that in the outside margins (5% on either side) the background was yellow in your first version. It seems to me that absence of color is not reliable enough to provide white, since who knows what settings each viewer has in his browser for background color.

    Code:
    body{background-color:#fff;font:medium Verdana,Tahoma,Helvetica,sans-serif;}
    .item:nth-child(odd) { background-color:#e5e5e5;}
    Since the nth child background color comes later, it will override for odd rows, exactly what we want.
    To handle the problem with IE8, should I then add the bg color redunduntly to "outer" as well as body?

  5. #30
    SitePoint Enthusiast
    Join Date
    Sep 2004
    Location
    USA
    Posts
    71
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Continuing my review of the latest iteration of your stylesheet, here are some fairly picky comments and questions: I suppose that great CSS styles is by defnition being picky
    It is great that you are addressing the IE8 issue, but I won't get bent out of shape if some aspects of the styling don't work quite right in IE8 or earlier. What seems to work on my desktop in FF is to have a white background styled in the body tag and also in the "outer" tag (for IE8). The odd rows are appear gray. Is this a reasonable approach?

    Code:
    .item {overflow:hidden;}
    
    .item > div {
        display:table-cell;
        vertical-align:middle;
        padding:0;
    }
    .item .image {
        padding-right:20px;
    }
    .item:nth-child(odd) .details {
        padding-left:209px;
    }
    .item img {
        width:209px;
        height:325px;
        vertical-align:top;
        border:0 none;}
    	 
    .item:nth-child(even) {margin-left:209px;}
    
    .item:nth-child(odd) { background-color:#e5e5e5;}
    For .item , overflow:hidden : why that style? Does it not risk losing text if I am too verbose?

    In .item img , why is background color a different gray (ccc) from the one used for the rest of the page (#e5e5e5)? and why does <img> need any background color?

  6. #31
    SitePoint Mentor bronze trophy
    ronpat's Avatar
    Join Date
    Jun 2012
    Location
    NJ, USA
    Posts
    2,509
    Mentioned
    61 Post(s)
    Tagged
    2 Thread(s)
    Regarding the difference between IE10 and FF.... Because .outer has a width of 90%, the page stretches to 90% of the width of the browser window. If you are opening both browsers in the same monitor, then IE10 may be scaling the content down (zooming smaller) when the page is first opened (perhaps the default zoom level is an IE option). If you have two monitors and are opening IE10 and FF in different monitors, then the monitor with IE10 may be operating at a higher rez, therefore the images and indeed the browser chrome should appear smaller.

    Quote Originally Posted by cma6 View Post
    What seems to work on my desktop in FF is to have a white background styled in the body tag and also in the "outer" tag (for IE8). The odd rows are appear gray. Is this a reasonable approach?
    Yes, perfectly! To recap, the odd rows are gray in IE9+. All rows are white in IE8.

    Quote Originally Posted by cma6 View Post
    For .item , overflow:hidden : why that style? Does it not risk losing text if I am too verbose?
    First, the page is completely fluid. No matter how verbose you become, no text will overflow the boundaries of its container.
    So why is it there? Between 520px and 700px we are floating the images to the left so the text can flow beneath them as needed. Floated objects are removed from the normal flow. Overflow:hidden is added to their parent container (.item) so .item will expand vertically to contain the floats and text margins. See the description part of: http://reference.sitepoint.com/css/overflow
    EXPERIMENT: To see what this means in real life, scroll to the bottom of the page then narrow the window until it between 520 and 700px. Next, disable overflow:hidden either with Firebug or by commenting it out in the CSS and reloading the page. You should see the layout of those last two rows collapse vertically. If you scroll up the page, you will also observe other rows where the image is no longer against the left edge of the page... it may be snagged against the right edge of the image above it. If you continue to narrow the window to less than 520px, you will see white space at the bottom of each .item where there are text margins. overflow:hidden also contains these margins and allows the background color to completely fill the odd .items.

    Quote Originally Posted by cma6 View Post
    In .item img , why is background color a different gray (ccc) from the one used for the rest of the page (#e5e5e5)? and why does <img> need any background color?
    <img> does not need a background-color. I applied it as a "placeholder" so it would be obvious if an image were missing from the server. It is normally covered by the image. You can leave it or delete it... your preference.

  7. #32
    SitePoint Enthusiast
    Join Date
    Sep 2004
    Location
    USA
    Posts
    71
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    "Between 520px and 700px we are floating the images to the left so the text can flow beneath them as needed. Floated objects are removed from the normal flow. Overflow:hidden is added to their parent container (.item) so .item will expand vertically to contain the floats and text margins. Scroll to the bottom of the page then narrow the window until it Between 520 and 700px. Next, disable overflow:hidden. You should see the layout of those last two rows collapse vertically. If you scroll up the page, you will also observe other rows where the image is no longer against the left edge of the page... it may be snagged against the right edge of the image above it. If you continue to narrow the window to less than 520px, you will see white space at the bottom of each .item where there are text margins. overflow:hidden also contains these margins and allows the background color to completely fill the odd .items."

    I don't have a tablet or smartphone so I used DW 5.5 Media Queries and set the viewport to 520px X 700px. After commenting out "overflow" and reloading, I did not see the layout of the last two rows change. The images were in the center of the screen both with and without "overflow:hidden".
    In the smartphone viewport, I did see white space at bottom of each .item with "overflow:hidden". I liked that effect as the .items need some separation on a small screen.
    I take your word for it that on a true tablet both defects of not clipping overflow would appear. DW5.5 was Adobe's first attempt at showing smaller viewports and it might not as accurate as what would be seen in a true tablet view.
    BTW, the font-size seemed too large in my tablet view so I made this change in your styles:

    Code:
    @media screen and (max-width:700px) {
        .item .image {float:left;}
        .item .details {display:block;}
        .item p {margin-left:20px;font-size:.85em;}
    }
      using .85em instead of 1em.  Do you see any problem with that change?

  8. #33
    SitePoint Mentor bronze trophy
    ronpat's Avatar
    Join Date
    Jun 2012
    Location
    NJ, USA
    Posts
    2,509
    Mentioned
    61 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by cma6 View Post
    I don't have a tablet or smartphone so I used DW 5.5 Media Queries and set the viewport to 520px X 700px. After commenting out "overflow" and reloading, I did not see the layout of the last two rows change. The images were in the center of the screen both with and without "overflow:hidden".
    NEVER rely on DW for testing a layout. ALWAYS test in a real browser.

    All you have to do is open the page in your normal browser and drag the edge of the browser window to make it narrower.

    FWIW: I do not own DW or any other such gadget. I use a text editor for writing code and ordinary browsers for testing.
    If you need to test in a smartphone, there are simulators available on-line. (I've not used one, though.)

    Quote Originally Posted by cma6 View Post
    In the smartphone viewport, I did see white space at bottom of each .item with "overflow:hidden". I liked that effect as the .items need some separation on a small screen.
    If you want additional white space below the .items, then it should be coded in properly. In that demo, it is an unwelcome side effect of not containing the margins. Ie. if you look carefully, you will see that white space is not actually being *added*, instead the gray background-color is "shrinking"... it not being applied behind the bottom margin area of the last line of text.

    Quote Originally Posted by cma6 View Post
    I take your word for it that on a true tablet both defects of not clipping overflow would appear. DW5.5 was Adobe's first attempt at showing smaller viewports and it might not as accurate as what would be seen in a true tablet view.
    You don't have to take my word for it. You should be able to see it yourself as I explained. Just open the page in a real browser for testing.

    Quote Originally Posted by cma6 View Post
    BTW, the font-size seemed too large in my tablet view so I made this change in your styles:

    Code:
    @media screen and (max-width:700px) {
        .item .image {float:left;}
        .item .details {display:block;}
        .item p {margin-left:20px;font-size:.85em;}
    }
      using .85em instead of 1em.  Do you see any problem with that change?
    I have not tested yet, but it seems reasonable.

  9. #34
    SitePoint Mentor bronze trophy
    ronpat's Avatar
    Join Date
    Jun 2012
    Location
    NJ, USA
    Posts
    2,509
    Mentioned
    61 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by cma6 View Post
    BTW, the font-size seemed too large in my tablet view so I made this change in your styles:

    Code:
    @media screen and (max-width:700px) {
        .item .image {float:left;}
        .item .details {display:block;}
        .item p {margin-left:20px;font-size:.85em;}
    }
      using .85em instead of 1em.  Do you see any problem with that change?
    I gave it a look, and it seems OK. Personally, I would choose .9375em as the next smaller increment. If you prefer .85em or thereabouts, then I recommend increasing the line-height a tad... the text seems a bit cramped to me.

    I generally choose font sizes that do not require the user to zoom larger. I don't like to annoy them. If they want to zoom smaller, fine; but forcing them to zoom larger is an imposition, so I avoid small font sizes.

    Be sure you are aware of your browser settings when coding a page.

  10. #35
    SitePoint Enthusiast
    Join Date
    Sep 2004
    Location
    USA
    Posts
    71
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I will go with your recommendation of .9375em especially as I have zero experience with small screens and you obviously have a wealth of experience in that area.

    "In the smartphone viewport, I did see white space at bottom of each .item with "overflow:hidden". I liked that effect as the .items need some separation on a small screen."
    On reconsideration, your styling already handles this issue most efficiently with .75em margin-bottom on smartphone for .item p However, I would like to increase margin-bottom to 1.1em
    Code:
      .item p {margin:.25em 12px 1.1em;}
    Two other questions.
    Code:
    <div class="pid"><b>#7416</b><b>$975</b></div>
    Why the seemingly redundant closing and opening bold tags? I assume it has to do with getting the proper spacing for the price block by using margin-left (and right) of 24px on the price block, which will not be overriden by margin-left=0 ?

    Code:
      .pid b {
        display:inline-block;
        vertical-align:top;
        margin:.25em 24px;
    }
    .pid b:first-child {
        margin-left:0;
    }
    I am not sure if you explained this but I don't understand the purpose of this rule:
    Code:
       .item .image { padding-right:20px;}

  11. #36
    SitePoint Mentor bronze trophy
    ronpat's Avatar
    Join Date
    Jun 2012
    Location
    NJ, USA
    Posts
    2,509
    Mentioned
    61 Post(s)
    Tagged
    2 Thread(s)
    cma6,

    This is the full page. I changed a couple of classnames. Because of that and the new stuff, this code is not compatible with previous demos.

    HIGHLIGHTS:

    You asked about padding-right:20px applied to .image. (Class .image has been changed to .imagebox so it's purpose is clearer.) The padding creates the space between the image and the text at all widths greater than 520px. I added a line of CSS that colors .imagebox pink so the padding is apparent.
    Code:
    .item .imagebox {
        background-color:pink;   /* TEST background-color. TO BE DELETED. */
        padding-right:20px;    /* This creates the appearance of a left margin between text and image. */
    }
    The seemingly redundant <b> tags are appropriate. If you are a semanticist, you should replace them with <strong> tags and change the CSS accordingly. I'm happy using <b> tags for the time being. Technically, they are inline tags like <span>, <strong>, <em>, <a>, and others. By default, <b> and <strong> apply a bold weight to the enclosed font, <em> applies italics. I am using the <b> tags as text containers and changed their box property from inline to inline-block. You could use <p> tags but would need to negate undesired paragraph styles. The <b> tags are a desirably bold and otherwise blank slate.

    The font size is reduced to .9375em at a window width of 700px and narrower.

    .items become separated by {margin-top:6px} in the 2 column mode (900px and narrower).
    I had already added 6px of white space between the .items by the time I read your post. I am leaving it in place for you to evaluate. If you prefer to increase the bottom margin on the paragraph as indicated in your post, then delete the line from CSS that adds the white space... it's marked "/* space between .items */" and increase the bottom margin as you wrote.
    Code:
    @media screen and (max-width:900px) {
        .item:nth-child(even) {margin-left:0px;}
        .item:nth-child(odd) .descript {padding-left:0;}
        .item + .item {margin-top:6px;}   /* space between .items */
    }
    The title bar has no fixed height. It's text is free to wrap.
    The text in the title bar is left aligned when the window is wider than 700px; it is center aligned when 700px or narrower.

    The "Vintage Textile" logo image is a clickable link to the index page.
    The logo image will resize at the narrowest window widths. (You could substitute the larger logo image, if you wish.)

    I remember that you talked about arranging the nav menu items in columns. However, your original design is by far the easiest design to code for a fluid environment so this is a useful place to start. If you want columns, please show how you want them to look at different window widths. For the above reason, the nav menu CSS is in a separate file. Easily replaced.

    The general "look" of the the nav menu is unchanged, but the HTML and behavior are quite different.
    1. Menu items with more that one word wrap as a group.
    2a. The menu at the top uses exactly the same code as the menu at the bottom.
    2b. Adding the class "head" or "foot" to the <ul> assigns the bronze border appropriately.
    3. The behavior of the "current page" button is activated by the unique ID in the body tag of the current page. The ID in the <body> tag of each page must match an ID in the CSS menu file.
    4a The "button" for the "current page" is not clickable. (Very Significant!)
    4b. Each list item in the HTML for the nav menu contains a set of <span> tags with the same text as the anchor tags. The <span> tags are used to make the "current page" button non-clickable.
    5a. Coloring: The text in the "current page" button is colored black and given your background-color.
    5b. The text in unvisited and visited "buttons" is brownish.
    5c. Hovered "buttons" are given your background-color and an underline.
    5d. Active "buttons" are given your background-color, an underline, and the text turns red.

    You can make copies of this latest HTML page, give the copies new names that match links in the HTML menu, then assign an ID to the <body> tag of each copy that matches one of those in CSS, then see how the "current page" button in the nav menu behaves.

    The technique I have used to code the menu uses an extra set of tags, <span> tags, that contain exactly the same text as the <a> tags. This is not a semantically cool technique, but it is the easiest and most bullet-proof that I know of. Don't feel obligated to like it. We can use a more modern technique (without the <span> tags) if you prefer.

    NOTE: If you use PHP, then one menu file can be applied to all related pages, top and bottom. In other words, there would be just one actual menu file shared by all pages. The treatment of the "current page" button would be automatic (as coded in menu.css).

    Please be aware that this page behavior can be achieved using other combinations of tags and properties. This same page written by another coder, or written by me from scratch next month, would probably be coded somewhat differently. In other words, there's usually more than one way to skin a cat.

    https://www.dropbox.com/sh/8nk4sqbgqbzjo55/sNOYbQEll8

  12. #37
    SitePoint Enthusiast
    Join Date
    Sep 2004
    Location
    USA
    Posts
    71
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ronpat:
    Thanks for the tremendous effort and accomplishment from a CSS Mentor like yourself. I will download the files tonight and get started at the end of the week in reviewing and analyzing your latest version, as I have other business obligations in the beginning of the week.

  13. #38
    SitePoint Enthusiast
    Join Date
    Sep 2004
    Location
    USA
    Posts
    71
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ronpat, I have finished reviewing "menu10a.css"--what an ingenious job of styling, especially how you use both <span> and <a> within .nav!
    Having reviewed "menu10a.css", but not yet "cma10.css", I am more than happy with the results as well as my ability to understand your CSS methods in "menu10a.css". The latter is very important so that I can maintain the category pages.

    "4a The 'button' for the 'current page' is not clickable. (Very Significant!)":

    This makes a great deal of sense, but why is it "very significant"?

    "You talked about arranging the nav menu items in columns. However, your original design is by far the easiest design to code for a fluid environment so this is a useful place to start."

    Your adaptation of my original design works just fine. The only reason I suggested stacking the category links was that I had read in online articles about designing for small screens that one should do that. Your adaptation works better than stacking would have.

    "If you use PHP, then one menu file can be applied to all related pages, top and bottom. In other words, there would be just one actual menu file shared by all pages. The treatment of the "current page" button would be automatic (as coded in menu.css)."

    I seem to be missing something here. I don't use PHP, but I cannot see why I would not use both of your style sheets for all 6 of my category pages, and change only this code (as well as content) in each category page:
    Code:
    <body id="forties">
    My comments about the seemingly redundant <b> tags were not connected with <strong>. Your explanation re "text containers" makes sense to me, presumably along the lines of what I had guessed.

    On one of my systems, in FF only, the background of the page is yellow. So I again added this style:

    Code:
    body{background-color:#fff; font:medium Verdana,Tahoma,Helvetica,sans-serif;}
    There does not seem any conflict with your code:
    Code:
     <body id="forties">
    The header title bar and the clickable logo work very well.

    You provided an image file "vt.gif" but I cannot see where it is used in the html code, even though you commented on it in "cma10.css:

    Code:
    .logo {
        text-align:center;
        margin-bottom:20px;  /* space below the logo image (6px with vt.gif) */
    }
    Code:
    <div class="logo">
            <a href="index.html"><img src="images/NewGraphics/logohome.gif" alt="antique clothing" width="269" height="74"></a>
        </div>
    Now I move on to review "cma10.css".

  14. #39
    SitePoint Mentor bronze trophy
    ronpat's Avatar
    Join Date
    Jun 2012
    Location
    NJ, USA
    Posts
    2,509
    Mentioned
    61 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by cma6 View Post
    I am more than happy with the results as well as my ability to understand your CSS methods in "menu10a.css". The latter is very important so that I can maintain the category pages.
    Yes, that is the most important thing to me, too, that you understand and can work with the code.

    Quote Originally Posted by cma6 View Post
    "4a. The 'button' for the 'current page' is not clickable. (Very Significant!)":

    This makes a great deal of sense, but why is it "very significant"?
    Calling this feature "very significant" may be a bit of an overstatement, but it is certainly significant.

    Some users have slow connections to the internet, some pay for their service by the byte, some are on portable devices.

    Your pages tend to be very long and have lots of content including images, which translates into more server accesses, longer loading time and more bytes. It is disrespectful of users, especially those listed above, to burden them with unnecessary page reloads when they are avoidable.

    It is easy to style the button for the current page that does not show the hand and therefore suggests that the anchor is not clickable, but in fact, if a user clicks that current page button the page would reload. The code that I used avoids that.

    Quote Originally Posted by cma6 View Post
    Your adaptation of my original design works just fine.
    Good, glad to hear that it works for you.

    Quote Originally Posted by cma6 View Post
    I seem to be missing something here. I don't use PHP, but I cannot see why I would not use both of your style sheets for all 6 of my category pages, and change only this code (as well as content) in each category page...
    My comment about using PHP was basically an "aside". You are quite right that you can duplicate the menu HTML as needed an include it on every page in that group of pages. They would all use the same CSS file either way.

    Using PHP to call a common menu file is a means of "economizing" your code. In other words, by having the menu HTML in only one file, you would only need to make a menu change in one file instead of changing the HTML on all paqes. On the other hand, since you only have 6 pages in that group of pages, going the PHP route might be more trouble than it's worth. If you are using a CMS to edit you site, then code changes would most likely be propagated to all relevant pages, anyway... no PHP required. (Still, trying it would be a good learning experience! Perhaps anther day, though.)

    Quote Originally Posted by cma6 View Post
    On one of my systems, in FF only, the background of the page is yellow. So I again added this style:

    Code:
    body{background-color:#fff; font:medium Verdana,Tahoma,Helvetica,sans-serif;}
    The yellow background on one of your systems is a user setting. You are very lucky to have spotted it and absolutely correct to change the CSS code so the discolored background doesn't interfere with your design.
    Where is it being applied? In Firefox, under the Tools menu, select Options, then click Content, and finally click the "Colors..." button. In the "Text and Background" box you should find that the background color has been set to whatever shade of yellow you are seeing.

    Quote Originally Posted by cma6 View Post
    The header title bar and the clickable logo work very well.
    Cool. It never hurts to offer users an easy way to find "Home".

    Quote Originally Posted by cma6 View Post
    You provided an image file "vt.gif" but I cannot see where it is used in the html code, even though you commented on it in "cma10.css:

    Code:
    .logo {
        text-align:center;
        margin-bottom:20px;  /* space below the logo image (6px with vt.gif) */
    }
    Code:
    <div class="logo">
            <a href="index.html"><img src="images/NewGraphics/logohome.gif" alt="antique clothing" width="269" height="74"></a>
        </div>
    logohome.gif is the logo image file currently used on your page and is the one for which {margin-bottom:20px;} is applied in CSS. I mentioned in my post that you could use your other slightly larger logo file (329x100), vt.gif, if you wished. The comment suggests that with vt.gif, the margin-bottom should be changed to about 6px. I copied vt.gif from this page: http://www.vintagetextile.com/new_page_399.htm and gave it a go. I was just playing/experimenting.

  15. #40
    SitePoint Enthusiast
    Join Date
    Sep 2004
    Location
    USA
    Posts
    71
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    In "cma10a.css", I have reviewed up to the @media section. First, to recapitulate my understanding of applying the 2 style sheets to 6 category pages:

    "You can duplicate the menu HTML as needed and include it on every page in that group of pages. They would all use the same CSS file either way."
    The only change in code I can see (other than content) on each of the 6 category pages would be in
    <body id="forties">. The two attached style sheets would be the same for the 6 category pages.
    Is that a correct understanding?

    For the selector "content", I don't see any style. (There is a property "content", but that is a different thing, I assume.)

    I don't see how the <div> "descript" gets the needed left margin, especially since .item p has "0" for no (additional?) left-margin.

    Code:
    .item p {   font-size:1em;
        line-height:1.375;
        margin:.5em 20px .75em 0;  /* Notice that the text has no left margin assigned. */}
    
    .pid b {     display:inline-block;
        vertical-align:top;
        font-weight:bold;
        margin:.25em 24px;  /* Apply default margins to .pid items. */}
    
    .pid b:first-child {   margin-left:0;      /* Remove left margin from first .pid item. */}
    unless this does it:

    Code:
    .item .imagebox {
            padding-right:20px;    /* This creates the appearance of a left margin between text and image. */
    }

  16. #41
    SitePoint Mentor bronze trophy
    ronpat's Avatar
    Join Date
    Jun 2012
    Location
    NJ, USA
    Posts
    2,509
    Mentioned
    61 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by cma6 View Post
    In "cma10a.css", I have reviewed up to the @media section. First, to recapitulate my understanding of applying the 2 style sheets to 6 category pages:
    "You can duplicate the menu HTML as needed and include it on every page in that group of pages. They would all use the same CSS file either way."
    The menu at the top of the page is classed: <ul class="nav head">
    The menu at the bottom of the page is classed: <ul class="nav foot">
    That is the only difference.


    Quote Originally Posted by cma6 View Post
    The only change in code I can see (other than content) on each of the 6 category pages would be in
    <body id="forties">. The two attached style sheets would be the same for the 6 category pages.
    Is that a correct understanding?
    Yes.

    Quote Originally Posted by cma6 View Post
    For the selector "content", I don't see any style.
    The class "content" is not used at this time. The div that it's associated with IS required, however. I gave it a class of "content" so it's purpose would be obvious to you. You could delete the class and put comment marks around the container as a reminder, if you prefer. If you chose to apply some unique style to the content area, such as a different background color, the classname would be needed.

    Quote Originally Posted by cma6 View Post
    (There is a property "content", but that is a different thing, I assume.)
    I'm not sure what you mean. There is an attribute in a meta tag at the top of the page, but that's the only other use of "content" that I see.

    Quote Originally Posted by cma6 View Post
    I don't see how the <div> "descript" gets the needed left margin, especially since .item p has "0" for no (additional?) left-margin.

    Code:
    .item p {   font-size:1em;
        line-height:1.375;
        margin:.5em 20px .75em 0;  /* Notice that the text has no left margin assigned. */}
    
    .pid b {     display:inline-block;
        vertical-align:top;
        font-weight:bold;
        margin:.25em 24px;  /* Apply default margins to .pid items. */}
    
    .pid b:first-child {   margin-left:0;      /* Remove left margin from first .pid item. */}
    unless this does it:

    Code:
    .item .imagebox {
            padding-right:20px;    /* This creates the appearance of a left margin between text and image. */
    }
    Exactly!

  17. #42
    SitePoint Enthusiast
    Join Date
    Sep 2004
    Location
    USA
    Posts
    71
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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:

    Code:
    .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?

  18. #43
    SitePoint Mentor bronze trophy
    ronpat's Avatar
    Join Date
    Jun 2012
    Location
    NJ, USA
    Posts
    2,509
    Mentioned
    61 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by cma6 View Post
    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:

    Code:
    .nav li:first-child:before {
        content:"";
        padding:0;
    }
    but that is a property and obviously has nothing to do with the selector "content".
    Goofy me. I searched forties10a.htm and cma10a.css, but didn't search menu10a.css for "content". Sorry.

    Quote Originally Posted by cma6 View Post
    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?
    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.

  19. #44
    SitePoint Enthusiast
    Join Date
    Sep 2004
    Location
    USA
    Posts
    71
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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?

    Code:
    <!--[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]-->

  20. #45
    SitePoint Mentor bronze trophy
    ronpat's Avatar
    Join Date
    Jun 2012
    Location
    NJ, USA
    Posts
    2,509
    Mentioned
    61 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by cma6 View Post
    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>.
    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.


    Quote Originally Posted by cma6 View Post
    BTW, I have only a vague idea of the purpose of the js file. Why is this needed?

    Code:
    <!--[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]-->
    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.

  21. #46
    SitePoint Enthusiast
    Join Date
    Sep 2004
    Location
    USA
    Posts
    71
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Media query questions on the 521-700px viewport

    Code:
    .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?

    Code:
    .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:

    Code:
    .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.?

  22. #47
    SitePoint Mentor bronze trophy
    ronpat's Avatar
    Join Date
    Jun 2012
    Location
    NJ, USA
    Posts
    2,509
    Mentioned
    61 Post(s)
    Tagged
    2 Thread(s)
    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.
    Code:
    @media screen and (max-width:900px) {
        .item:nth-child(even) {margin-left:0px;}
        .item:nth-child(odd) .descript {padding-left:0;}
        .item + .item {margin-top:6px;}   /* space between .items */
    }
    @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;}
        .item + .item {margin-top:12px;}   /* space between .items */
    }

    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.

  23. #48
    SitePoint Enthusiast
    Join Date
    Sep 2004
    Location
    USA
    Posts
    71
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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:
    Code:
    .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:
    Code:
    .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:

    Code:
    <!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:
    Code:
    @media only screen and (max-width:400px)

  24. #49
    SitePoint Mentor bronze trophy
    ronpat's Avatar
    Join Date
    Jun 2012
    Location
    NJ, USA
    Posts
    2,509
    Mentioned
    61 Post(s)
    Tagged
    2 Thread(s)
    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.

    forties-view1.jpg forties-view2.jpg

    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:
    Code:
    <!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.

  25. #50
    It's all Geek to me silver trophybronze trophy
    ralph.m's Avatar
    Join Date
    Mar 2009
    Location
    Melbourne, AU
    Posts
    24,176
    Mentioned
    454 Post(s)
    Tagged
    8 Thread(s)
    Quote Originally Posted by ronpat View Post
    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.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •