Styling a horizontal box

I have finished repairing the code for the 1940s_to_designer page.

There is one version that is checkerboard compatible with IE9+ and falls back to a single column of images for IE8 with the same background color for all products. It is very easy to maintain by hand.

There is a second version that is fully checkerboard compatible with IE8+. However, unless the HTML is generated by a CMS, it is tedious to maintain.

Both versions require a server side JavaScript, respond.js, to enable IE8 to respond to media queries.

You can download the files from here: https://www.dropbox.com/sh/8nk4sqbgqbzjo55/sNOYbQEll8

Most of the time, I enjoy publishing pages that are IE8 compatible. In this case, however, I would recommend forgoing the designer checkerboard look for IE8 because of the HTML maintenance involved and live with the plain fallback look.

Your call.

We can work on the logo, banner, and menu next.

Ron,
I have downloaded the html page and the css page. I’ve printed out the css page. However, the style sheet is not being applied to the html page even though I have the stylesheet path correct.
So I will have to type in your style sheet code by hand to recreate another stylesheet and see if that works.

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.

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.

Ron,
The design (IE9+) looks very good!
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.)

cma6,

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

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.

I think you might have stated that backwards :slight_smile:

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?

“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 :slight_smile:

“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.

The only change on the HTML page for the (IE9+) version is:


<!--[if lt IE 9]>
    <script type="text/javascript" src="js/respond.min.js"></script>
    <style type="text/css">
[color=red][s].item {border-bottom:1px solid #888;}[/s][/color]
[color=blue].item {border-top:1px solid #888;}
.item:first-child {border-top:0;}[/color]
    </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:


.outer {
    width:90%;
    [color=blue]background-color:#fdd;[/color]  /* example only */
    margin:0 auto;
}
.item {
    [color=blue]background-color:#fdd;[/color]  /* example only */
    overflow:hidden;
}
.item:nth-child(even) {
    [color=blue]background-color:#fdd;[/color]  /* 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.


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

“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.

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?

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 :slight_smile:
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?

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

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.

Yes, perfectly! :slight_smile: To recap, the odd rows are gray in IE9+. All rows are white in IE8.

First, the page is completely fluid. No matter how verbose you become, no text will overflow the boundaries of its container. :slight_smile:
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.

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

“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:

@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?

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

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.

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.

I have not tested yet, but it seems reasonable. :slight_smile:

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

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

  .item p {margin:.25em 12px 1.1em;}  

Two other questions.

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

   .item .image { padding-right:20px;}  

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.


.item .imagebox {
    [color=blue]background-color:pink;   /* TEST background-color. TO BE DELETED. */[/color]
    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.


@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]
}

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

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.
  2. 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. :slight_smile:

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.

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:

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

body{background-color:#fff; font:medium Verdana,Tahoma,Helvetica,sans-serif;}

There does not seem any conflict with your 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:

.logo {
    text-align:center;
    margin-bottom:20px;  /* space below the logo image (6px with vt.gif) */
}
<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”.

Yes, that is the most important thing to me, too, that you understand and can work with the code. :slight_smile:

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.

Good, glad to hear that it works for you.

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

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

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

Cool. It never hurts to offer users an easy way to find “Home”. :slight_smile:

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

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.

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

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

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.

Yes.

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.

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.

Exactly!