Coding CSS for Context
Dave Rupert recently tweeted asking a question that I see quite often:
Code language: CSS
.some-context .thing { /* special rules and overrides */ }
Does that go in thing.css or some-context.css?
Then, Harry Roberts discussed this concept further in his article of CSS Code Smells Revisited.
Harry uses a practical example of
.thingbeing a.button. (Well, actually, a.btnbut whatever. And yes, I just “well, actuallied” myself. It’s preemptive mansplaining.)You’ll have the standard button that appears throughout your application. And then you have this variation in modal dialogs.
Instinctively, we start writing
.modal .button. Hence, Dave’s question of where to put this particular bit of code. It’s interesting to note that the results of Dave’s survey indicated that a slim majority of people prefer that this bit of code live in with the modal CSS and not with the button CSS.Harry indicated that it should live with the button CSS. And I agree with him. We’re styling a button! It should be in with the buttons.
[…]
One thing you have to worry about is components becoming too complex. Yes, the modal has a button. It could also have inputs and headings and all sorts of things. Over my career, I’ve noticed useful boundaries and tend not to create components with deep hierarchies.
Identifying The Thing
Going back to our thing that we’re trying to style: the button. Yes, right now, we’re styling a button in a modal dialog. Is this the only place that this exists? Right now, quite possibly. Will it always be the only place it exists? If your project is constantly in flux, then not likely.
Here’s what’s important:
- We want to identify that this is a variation on our button.
- We want to indicate the purpose of this button style.
- We want to avoid tying the code to a particular context that could change.
Going with
.button--modal, for example, now identifies it as a variation. But fails on the other two points: It indicates its context and doesn’t say what it’s trying to do other than be in a particular place on the page.So, why is the button in the modal different than regular buttons? (If you’re the designer, ask yourself this. If you’re not the designer, ask them this.) You might get something like, “It needs to be green to draw attention to the fact that it’s a primary action.” Or maybe something like, “the button is smaller because we don’t have as much room.”
This helps you come up with a name like
.button--primaryor.button--compact.Either of those names satisfy the three points I mentioned above.
- It identifies itself as a variation using the BEM double hyphen.
- It indicates its purpose through the variation name.
- It hasn’t tied itself to a specific context.
That last point, to me, is the most important. As a designer, I might end up using these styles on a new page that hasn’t been thought up yet. I might want to use a primary button style on a form that isn’t in a modal dialog. I might want to use a compact button in a sidebar where I don’t have a lot of room.
And as Harry also mentioned, by keeping all our button styles in one place, we have the ability to see patterns emerge across an entire project.
Three months down the line, do we suddenly find ourselves with 30 button styles and need to reduce the complexity of our UI? That can be harder to do if button styles are strewn throughout the codebase, hidden within other contexts.
Full Width Containers in Limited Width Parents
Code language: CSS
.full-width {
width: 100vw;
position: relative;
left: 50%;
right: 50%;
margin-left: -50vw;
margin-right: -50vw;
}
The idea here is: push the container to the exact middle of the browser window with
left: 50%;, then pull it back to the left edge with negative-50vwmargin.
Mozilla Hacks title hover animation
I just noticed the delightful little animation on the Mozilla Hacks site title. It’s triggered by hovering over the title with a pointer, or if you’re on mobile, long pressing it to focus it seems to be the equivalent.
The end of the clearfix hack?
A new value of the display property has landed in Chrome Canary and Firefox Nightlies. In the Editor’s Draft of the CSS Display Module Level 3, display: flow-root is defined as:
“The element generates a block container box, and lays out its contents using flow layout. It always establishes a new block formatting context for its contents.”
The key use of this comes when you have a box with a floated element inside it, and the floated element is taller than the other content inside the box. Default behaviour is that the box will not clear the float, and anything that comes afterwards will also wrap the floated item.
The typical way we have solved this issue is to use a clearfix hack. The hack inserts some generated content, sets it to display; table or display: block and then clears it. This then ensures that the box becomes self-clearing, in our example the border will display after the floated item, and any following content will not rise up to wrap the float.
Enter display: flow-root
Using display: flow-root on an element will perform this clearing for us. Instead of needing to apply the clearfix hack we can use the CSS display property on the container with a value of flow-root.
Code language: CSS
.container {
display: flow-root;
}
The border then clears the float and following content displays after our contained floated element.
[…]
There is some discussion about the name of the value on an issue posted to the CSS Working Group GitHub. If you want to see interoperable support for this feature soon, then I’d suggest you pop over to the Edge UserVoice site and give it a vote.
WebSlides: Create Beautiful HTML Presentations
WebSlides makes HTML presentations easy.
Just the essentials and using lovely CSS.[…]
Each parent
<section>in the #webslides element is an individual slide.Code is clean and scalable. It uses intuitive markup with popular naming conventions. There’s no need to overuse classes or nesting. Making an HTML presentation has never been so rewarding.
Safari bug with gradients that fade to "transparent"
Say you have a gradient in CSS that goes from red to transparent. Easy, right? Like this:
Code language: CSS
.element {
background: linear-gradient(
to bottom,
red,
transparent
);
}
There is a pretty big gotcha here, though.
In Chrome (also Android), Firefox, and Edge, you’d be all good.
But in Safari (also iOS), you’d not be good.
The problem, the best I understand it, is that transparent is being interpreted (and interpolated) as “transparent black”.
To fix it, you have to set the color as a fully transparent version of that exact color. Like:
Code language: CSS
.element {
background: linear-gradient(
to bottom,
red,
rgba(255, 0, 0, 0)
)
}
[…]
Sass can help out, if you are using that:
Code language: Sass
.element {
background: linear-gradient(
to bottom,
#eb8fa9,
rgba(#eb8fa9, 0);
)
}
The limits of @supports
@supports may be very useful, but it can only tell you so much, especially in the case of browsers that will return true, technically supporting the feature, but having a buggy implementation. This is a case where we can often assume too much about a browser based on a reductive test that isn’t guaranteed to tell us what we think it does. PPK explains:
If a mobile browser doesn’t support
background-attachment: fixedin practice, what happens when you do this?
Code language: CSS
@supports(background-attachment: fixed) {
// CSS
}
Does it return false because the mobile browser doesn’t support it? Or does it return true because its desktop version supports it? With my
background-attachmenttest data in hand I could now answer this question.All mobile browsers return true for both
fixedandlocal. Only 3 out of 23 browsers speak the truth here. See the test case and the inevitable table for more details.[…]
What’s clear from these tests is that
@supportsis only useful when you’re detecting entire CSS modules such as flexbox. So the check below makes sense.
Code language: CSS
@supports (display: flex) {
// flexbox layout
}
@supports not(display: flex) {
// float layout
}
This example is likely safe. If a browser decides to support flexbox,
display: flexis the first item on the agenda, so detecting it makes perfect sense. (It’s theoretically possible, though, that a browser fakesdisplay: flexsupport in order to end up on the right side of some support detects. But as far as I know this is not the case today.)On the other hand, if a browser has flaky support for, I don’t know,
justify-content, a more precise check like this may or may not work, depending on how the CSS parser is written:
Code language: CSS
@supports (justify-content: space-around) {
// may or may not fire correctly in case
// of a browser bug
}
So this example is unsafe. Don’t use
@supportsfor such detailed compatibility questions.
Vertical viewport units are unreliable on mobile
When I was first styling Resilient Web Design, I made heavy use of
vhunits. The vertical spacing between elements—headings, paragraphs, images—was all proportional to the overall viewport height. It looked great!Then I tested it on real devices.
Here’s the problem: when a page loads up in a mobile browser—like, say, Chrome on an Android device—the URL bar is at the top of the screen. The height of that piece of the browser interface isn’t taken into account for the viewport height. That makes sense: the viewport height is the amount of screen real estate available for the content. The content doesn’t extend into the URL bar, therefore the height of the URL bar shouldn’t be part of the viewport height.
But then if you start scrolling down, the URL bar scrolls away off the top of the screen. So now it’s behaving as though it is part of the content rather than part of the browser interface. At this point, the value of the viewport height changes: now it’s the previous value plus the height of the URL bar that was previously there but which has now disappeared.
[…]
In my initial implementation of Resilient Web Design, the one where I was styling almost everything with
vh, the site was unusable. Every time you started scrolling, things would jump around. I had to go back to the drawing board and remove almost all instances ofvhfrom the styles.