Ever need to style an element, but only if another sibling element was present?

I hit just that scenario this morning. I’m working on a site that has a landing page for four different sections of the website. For the most part the layout of the landing pages are the same, except one or two that does not contain an area for bugs¹. At the large screen views, I want the .bugs container to be the first of three columns, followed by .col1 which usually contains events, and then .col2 which usually contains news.

At the default, small screen view these containers all stack.

By the time we hit a portrait tablet screen size, .col1 and .col2 are side by side with the .bugs container above them at full width.

To achieve this I am simply adding the following to my CSS at this media query

.col1, .col2 { width:50%; }

Please note, I’m not getting into detail on how I have these containers oriented horizontally. The easiest is to add a float parameter to each container. However, I tend to use a display:inline-block approach, which I feel has more versatility.

By the time we are hitting our larger screens and landscape tablet sizes, all three containers are side by side as three columns.

Currently my CSS looks like this for these three containers:

.bugs { width:20%; }
.col1,
.col2 { width:40%; }

This works out quite well as a good reorientation of the layout for these containers. As I said though, I have a couple pages that don’t have the .bugs containers and otherwise have the same skeletal markup. In those cases, I want to keep the widths on .col1 and .col2 at 50%. At the same time I don’t want to modify my markup on these pages if I can accomplish this with just CSS, which I can.

This is where CSS’s adjacent sibling selector come in. Essentially, this is a way to style an element, but only if it is immediately after another element. CSS-Tricks has a great rundown explaining the different child and sibling selectors available. A good way to think about the adjacent sibling selector is with an if statement. So, if .element-a is followed by .element-b then style .element-b like this.

In the situation I’m working with here is how I approached styling .col1 and .col2 if the .bugs container was present:

.bugs { width:20%; }
.bugs + .col1,
.bugs + .col1 + .col2 { width:40%; }

This is in my media query targeting screens larger than 1000px wide. This changes the widths for .col1 and .col2, but only if the .bugs container is present and proceeding them. Otherwise .col1 and .col2 retain the width:50%; from the previous media query. Also, notice in line three that we have multiple adjacent sibling selectors for one element. Without this then .col2 would still have the width:50%. Nor could we use .bugs + .col2 because those elements have .col1 between them in the markup, which negates the adjacent sibling selector.

I was pleasantly surprised to find that it was possible to have multiple adjacent sibling selectors. What makes it more useful is after a quick jump in BrowserStack, I found that the multiple adjacent sibling selectors work as far back as IE7.

The last couple of months I have been considering Fever, an RSS feed reader application by Shaun Inman. Unlike most feed readers, Fever is a self-hosted PHP application. Meaning you’ll need your own public-facing server that is running PHP and MySQL in order to use it. At $30, Fever likely has a limited audience of web developers willing to use it.

My biggest reason to use Fever was to finally drop Google Reader, the last Google app that I used on a regular, personal basis¹. As it turns out, Google started dropping Reader before I did. So, the waffling and procrastinating stopped and I bought and installed Fever this morning.

At this point I have only used Fever for about an hour or so. Overall, I’m quite pleased with it from a functionality standpoint. However, I have a hard time recommending Fever to others. While functionally, Fever is quite good, visually it is dated and not really built to spend time reading. In particular I find the body copy of feed articles to be far too small for an enjoyable reading experience.

Thankfully, this is a web app, so I can tweak styles to my liking. I dug into the application’s files and found the stylesheets. Once those were adjusted for a larger, more readable font-size, I was quite happy².

I’m very excited to explore some of the features built into Fever. For those considering Fever as a Google Reader alternative in light of the recent closure announcement, I’d recommend first looking into other options. Although, If you have some capable CSS chops and can handle the steps needed to install Fever, I think the $30 is worth the price.

The more sites I design responsively, the more I see the need for maintaining an element’s aspect ratio. The idea being that as the browser window widens and shrinks, both the element’s height and width scale proportionately.

However, there is not a clear and simple way to do this. Most solutions I’ve found require a minimum of two elements to make this type of functionality work. Other solutions require Javascript instead of straight CSS. While not nearly as bad, this feels a bit like the old way to achieve rounded corners before border-radius.

What I want is a CSS property that can maintain set proportions for any given element. Currently there is only one element that has this functionality with the least amount of CSS. An img tag with a percentage-based max-width or width property will scale the element’s height proportionate to the displayed width as the window size changes. As far as I’m aware there is no way to make an element behave like an img tag.

Maybe an expansion of the box model is in order so we can say box-sizing: img-box;, which should also inherit the properties of border-box. Another option could be a straight ratio:maintain; declaration could be added to handles this. We may need to throw in our dimensions as well, so maybe there are ratio-height and ratio-width properties added. Of course if CSS ever gains some rudimentary math functions, we might be able to take care of our ratios there.

Blah, blah, blah…how about a use case?

The biggest area I see this need is for embedded content. This is content that often ought to scale like an image, particularly videos. I also see cases where an element does nothing but display a background image, like a logo, and that element needs to scale proportionately to the window size. I’ve used methods to create proportionately scaling buttons as well.

You could just use media queries

Well, yeah…I’m still going to use media queries, but responsive design is about the in between. I might have media queries that even kill the whole proportions thing, but the ability to have it in an area where it makes sense would be nice.

Fine, fine…you said there were options for ratios now

Yes, thank you.

I have two options to show. They’re CSS only—that’s my criteria for this. So, with out further ado…

Two Elements and a :pseudo

This is probably the more common solution as far as I’m aware. The idea is to use an :after pseudo element and a child element to create the ratios. In the below example I’ve separated the padding-top property into individually scoped :after pseudo elements. The ratios I’m using are the more common video types; 4:3, 16:9, and the epic 2.39:1.

Check out this Pen!

The Hidden Image

I’m actually using this method on the Notre Dame Magazine website. Unfortunately this is the modern-day equivalent of the spacer gif. The idea is that the image size with a max-width or width property with a percent-based value would scale the parent element in a proportionate manner.

Check out this Pen!

You can also use this method to add some additional CSS styling to an image that can’t be added directly to an img tag.

Final Thoughts

As far as solutions I’m aware of, I think the Two Elements and a :pseudo is the way to go for most cases. However, I can see and have had situations where the Hidden Image method makes the most sense. If you go the image route make sure it is working semantically and not just used for sizing the element. In the case with the Notre Dame Magazine website, the img tag has a title attribute describing the image in the background.

Keep in mind that these ratios don’t need to be something that exist outside of media queries. Let the content dictate the layout and use of ratios.

2012 was an incredible year. It kicked off with an intense, ground-up revamp of the University of Notre Dame homepage. This site caused an avalanche of humbling accolades¹. Following the launch of the Notre Dame homepage, focus shifted to numerous other projects, including the College of Science, the Provost’s Office, and the School of Architecture. All great projects to further many of the standards set with the main university site. The year’s end brought a wonderful and challenging project—the redesign of the Notre Dame Magazine website, which launched this past Friday.

The Notre Dame Magazine website is a bit of a dream project for me. Content is priority. Mobile traffic is high. What really helped—the folks at the magazine recognized these things. They wanted a website that could supersede the print edition.

Design Choices

I had a clear personal goal with this project. The magazine’s content had to provide a distraction-free and pleasant reading experience. In particular, the content of this website had to look incredible on a Retina iPad. This meant finding some great fonts to use, and The League of Moveable Type did not disappoint. The primary fonts of the site were Chunk, for the headlines, and Sorts Mill Goudy, for the body copy. Additionally PTSans, by Paratype, was used as a sans-serif alternate font for buttons, navigation, and other places as needed.

Once I had my typefaces gathered, layout work started. Good responsive layout work starts at mobile. Mobile is raw content presentation. No frills, just text. Any floats attributed to an image are cut away. The image takes up the width of the screen, on its own line. As the layout expands on to larger screens the image positions take on more requirements.

I find left-aligned images to be distracting to the content on a webpage. To limit how a left-aligned image cuts into the content, the image width maxes out at around one-sixth to one-fifth the width of the content. Right-aligned images are awesome—these images breakout of the implied constraints of the content, quite beautifully. Finally our inline images maintain that full-width of the content that started off on the smaller, mobile screens.

Navigation

One aspect of this site became apparent early on, the content makes pages long. From the start of the mobile layout, I wanted an accessible button to aid in navigating the page. In the top right, a touchable red button stays with you from the top of the page to the bottom. Upon interaction the button produces a few some essential pieces. A button to return to the page top², the first few menu items with a link to the rest of the menu, and finally a search box.

Once the layout had the required space needed, the menu was brought to left of the content and the search bar nested in the site’s header. Like the mobile layout’s navigation button, the menu stays with you the length of the page. However, a problem came about on the articles. The menu broke my main rule for this site, no distractions. So a hybrid of the mobile navigation and the main menu was created specifically for news pages³.

Final bits

I am very pleased with the results of this project. This is the first SASS site launched by the web team, an experience I hope to talk about soon⁴. The reactions so far have been quite positive, though we’re still in the midst of post-launch clean-up.

The slides from my HighEdWeb presentation are now up on Speaker Deck for your viewing pleasure.