HTML & CSS - - By Louis Lazaris

CSS is not an overly complex language. But even if you’ve been writing CSS for many years, you probably still come across new things — properties you’ve never used, values you’ve never considered, or specification details you never knew about.

In my research, I come across new little tidbits all the time, so I thought I’d share some of them in this post. Admittedly, not everything in this post will have a ton of immediate practical value, but maybe you can mentally file some of these away for later use.

1. The color Property Isn’t Just for Text

Let’s start with the easier stuff. The color property is used extensively by every CSS developer. Some of you not as experienced with CSS may not realize, however, that it doesn’t define only the color of the text.

Take a look at the demo below:

See the Pen CtwFG by SitePoint (@SitePoint) on CodePen.

Notice in the CSS, only one color property is used, on the body element, setting it to yellow. As you can see, everything on the page is yellow, including:

  • The alt text displayed on a missing image
  • The border on the list element
  • The bullet (or marker) on the unordered list
  • The number marker on the ordered list
  • The hr element

Interestingly, the hr element, by default does not inherit the value of the color property, but I had to force it to do so by using border-color: inherit. This is kind of odd behaviour to me.

All of this is verified by the spec:

This property describes the foreground color of an element’s text
content. In addition it is used to provide a potential indirect value
… for any other properties that accept color values.

I can’t think of anything else that would qualify as ‘foreground’, but if you do, let us know in the comments.

2. The visibility Property Can Be Set to “collapse”

You’ve probably used the visibility property hundreds of times. The most commonly used values are visible (the default for all elements) and hidden, which makes an element disappear while allowing it to still occupy space as if it was there (which is unlike display: none).

A third and rarely used value for the visibility property is collapse. This works the same way as hidden on all elements except table rows, table row groups, table columns, and table column groups. In the case of these table-based elements, a value of collapse is supposed to work similar to display: none, so that the space occupied by the collapsed row/column can be occupied by other content.

Unfortunately, the way browsers handle collapse is not consistent. Try the following demo:

See the Pen visibility: collapse by SitePoint (@SitePoint) on CodePen.

The CSS-Tricks Almanac advises never to use this, due to the browser inconsistencies.

From my observations:

  • In Chrome, it makes no difference if you apply collapse or hidden (See this bug report and comments)
  • In Firefox, Opera, and IE11, collapse seems to respond exactly as it should: The row is removed and the row below moves up.

Admittedly, this value is probably rarely ever going to be used, but it does exist, so if you didn’t know about it before, I guess in some odd way you are now smarter.

3. The background Shorthand Property Has New Values

in CSS2.1 the background shorthand property included 5 longhand values – background-color, background-image, background-repeat, background-attachment, and background-position. In CSS3 and beyond, it now includes three more, for a total of up to 8. Here’s how the values map:

background: [background-color] [background-image] [background-repeat]
            [background-attachment] [background-position] / [ background-size]
            [background-origin] [background-clip];

Notice the forward slash, similar to how font shorthand and border-radius can be written. The slash allows you to include a background-size value after the position in supporting browsers.

In addition, you also have up to two optional declarations for background-origin and background-clip.

So the syntax looks like this:

.example {
  background: aquamarine url(img.png)
              no-repeat
              scroll
              center center / 50%
              content-box content-box;
}

Test it in your browser using this demo:

See the Pen New background shorthand values by SitePoint (@SitePoint) on CodePen.

As for browser support, these new values seem to work fine in all modern browsers, but it’s likely you’ll have to provide good fallbacks for any nonsupporting browsers so it degrades gracefully.

4. The clip Property Works Only on Absolutely Positioned Elements

Speaking of background-clip, you’ve likely also seen clip before. It looks like this:

.example {
    clip: rect(110px, 160px, 170px, 60px);
}

This will ‘clip’ the element at the specified locations (explained here). The only caveat is that the element to which you apply clip must be positioned absolutely. So you have to do this:

.example {
    position: absolute;
    clip: rect(110px, 160px, 170px, 60px);
}

You can see how clip is disabled in the demo below when position: absolute is toggled:

See the Pen siFJu by SitePoint (@SitePoint) on CodePen.

You could also set the element to position: fixed, because, according to the spec, fixed-position elements also qualify as ‘absolutely positioned’ elements.

5. Vertical Percentages are Relative to Container Width, Not Height

This one is a tad bit confusing at first, which I’ve written about before. While you might know that percentage widths are calculated based on the width of the container, percentages on properties like top and bottom padding and top and bottom margins are likewise calculated based on the width of the container, rather than the height.

Here’s an example that you can adjust with a range slider, so you can see the effect:

See the Pen qLnpm by SitePoint (@SitePoint) on CodePen.

Notice that there are 3 “vertical” percentages declared on the inner box (top and bottom padding, and bottom margin). When the slider moves, it changes only the container width. But the other values change in response to this, as the output on the page shows, showing that these values, when declared as percentages, are based on container width.

6. The border Property is Kind of Like Inception

We’ve all done this at some point:

.example {
  border: solid 1px black;
}

The border property is a shorthand property that sets border-style, border-width, and border-color — all in a single declaration.

But don’t forget that each of the properties that the border property represents is itself a shorthand property. So border-width alone can be declared:

.example {
  border-width: 2px 5px 1px 0;
}

This will set different widths for each of the four borders. And the same is true for border-color and border-style, as shown in this awful demo:

See the Pen multiple border shorthands by SitePoint (@SitePoint) on CodePen.

In addition, each of those properties can be broken down even further with border-left-style, border-top-width, border-bottom-color, and so on.

But the catch is that you cannot use the regular border shorthand to set different values for different sides. So it’s shorthand inside of shorthand inside of shorthand, but not exactly.

7. The text-decoration Property is Now a Shorthand

I knew something on this list would blow your mind.

This is now standard, according to the spec:

a {
  text-decoration: overline aqua wavy;
}

This property now represents 3 properties: text-decoration-line, text-decoration-color, and text-decoration-style.

Unfortunately, Firefox is the only browser that supports these new properties, and (I’m assuming, for backwards compatibility), doesn’t support them in the shorthand yet.

Try the demo below in Firefox:

See the Pen HapgB by SitePoint (@SitePoint) on CodePen.

The demo is using the longhand values to do this. This ultimately will be a tough one because currently any browser that sees an extra value in text-decoration will nullify the entire declaration, which is clearly not good for backwards compatibility.

8. The border-width Property Accepts Keyword Values

Not exactly earth-shattering, and this isn’t new, but, in addition to standard length values (e.g. 5px or 1em), the border-width property accepts three keyword values: medium, thin, and thick.

In fact, the initial value of the border-width property is “medium”. The demo below uses “thick”:

See the Pen border-width keyword “thick” by SitePoint (@SitePoint) on CodePen.

When browsers render these keyword values, the spec doesn’t require that they map them to specific length values, but, from what I can see, all browsers seem to use 1px, 3px, and 5px.

9. Nobody Uses border-image

I wrote about the CSS3 border-image property on SitePoint a while back. The feature is supported in all modern browsers except IE10 and below. But does anybody care?

It seems like a really neat feature, allowing you to create border images that are fluid. Use the resize handle in this demo to test it out:

See the Pen border-image demo by SitePoint (@SitePoint) on CodePen.

Unfortunately, border-image seems like a novelty that not many people are using. But maybe I’m wrong. If you know of any examples of border-image in use on a real project, or if you’ve used it, please let us know in the comments and I’ll be happy to admit I was wrong.

10. There’s an empty-cells Property

This one has support everywhere including IE8, and it looks like this:

table {
  empty-cells: hide;
}

As you probably figured out, it’s used for HTML tables. It tells the browser whether to show or hide table cells that have no content in them. Try the toggle button in this demo to see the effect of changing the value of the empty-cells property:

See the Pen empty-cells demo by SitePoint (@SitePoint) on CodePen.

In this case, I had to ensure the borders were visible and not collapsed and I had to add some spacing between the cell borders. In some cases, this property would have no visual effect because there needs to be something visible on the table for this to make any difference.

11. The font-style Property Accepts a Value of “oblique”

Just about every time you see the font-style property, it’s used either with a value of “normal” or “italic”. But you can also give it a value of “oblique”:

See the Pen italic vs. oblique by SitePoint (@SitePoint) on CodePen.

But what exactly does that mean? And why does it look the same as italic?

The spec explains that the value “oblique”…

“…selects a font that is labeled as an oblique face, or an italic face if one is not.”

The description of “italic” in the spec is basically the same. The word “oblique” is a typographic term that basically represents slanted text, but not a true italic.

Due to the way CSS handles oblique text, it’s interchangeable with italic unless (as the spec explains) the font being used has a face that is identified as oblique.

I’ve never heard of a font that actually has an oblique face, but maybe I’m wrong. From the research I’ve done, it seems that it’s wrong for a font to offer both italic and oblique faces, because oblique is supposed to be a faux version of italic on fonts that don’t have a true italic.

So, if I’m not mistaken, what this means is if a font does not have a true italic face, setting the CSS to font-style: italic will actually display the font as font-style: oblique.

12. word-wrap is the Same as overflow-wrap

The word-wrap property is not used too often, but it’s very useful in specific circumstances. One often-used example is to help long unbroken strings of text (like URLs) to wrap, rather than break out of their container. Here’s an example:

See the Pen word-wrap demo by SitePoint (@SitePoint) on CodePen.

Because this was originally a Microsoft creation, this property is supported in all browsers including Internet Explorer all the way back to IE5.5.

Despite cross-browser and, from what I can see, consistent support, the W3C decided to replace word-wrap with overflow-wrap — I’m guessing due to the former name being considered a misnomer. overflow-wrap has the same values as word-wrap, and word-wrap is now considered “an alternate syntax” for overflow-wrap.

While a few new browsers do support overflow-wrap, it seems pointless to bother with it since old browsers handle word-wrap just fine, and all browsers are required to continue to support word-wrap indefinitely, for legacy reasons.

We can start using overflow-wrap when all in-use browsers auto update — but until then, I don’t see a point in changing from the old syntax.

How Many of These Were New To You?

Did you learn anything from this post? I hope so. Probably most experienced CSS developers knew many, if not all, of the above points. But likely those newer to CSS would benefit more from these.

It would be interesting to see how many of these points were new to our readers. Post a comment below telling us how many were new to you (e.g. 6/12, 4/12, or whatever).

Pick up loads more CSS hints and tips with a Learnable membership. You’ll get access to dozens of books and courses, including best-sellers like Jump Start CSS, The CSS Anthology and more.

Sponsors