Technology doesn’t have to be terrible. Here’s an absolutely wonderful use of an e-ink display:
I made as much use of vanilla HTML and CSS as possible. I used a small amount of JavaScript but no framework or other libraries.
Those HTML web components I made for date inputs are very simple. All they do is slightly extend the behaviour of the existing input elements.
This would be the ideal use-case for the is attribute:
<input is="input-date-future" type="date">
Alas, Apple have gone on record to say that they will never ship support for customized built-in elements.
So instead we have to make HTML web components by wrapping existing elements in new custom elements:
<input-date-future>
<input type="date">
<input-date-future>
The end result is the same. Mostly.
Because there’s now an additional element in the DOM, there could be unexpected styling implications. Like, suppose the original element was direct child of a flex or grid container. Now that will no longer be true.
So something I’ve started doing with HTML web components like these is adding something like this inside the connectedCallback method:
connectedCallback() {
this.style.display = 'contents';
…
}
This tells the browser that, as far as styling is concerned, there’s nothing to see here. Move along.
Or you could (and probably should) do it in your stylesheet instead:
input-date-future {
display: contents;
}
Just to be clear, you should only use display: contents if your HTML web component is augmenting what’s within it. If you add any behaviours or styling to the custom element itself, then don’t add this style declaration.
It’s a bit of a hack to work around the lack of universal support for the is attribute, but it’ll do.
It’s said that the best way to learn about something is to teach it. I certainly found that to be true when I was writing the web.dev course on responsive design.
I felt fairly confident about some of the topics, but I felt somewhat out of my depth when it came to some of the newer modern additions to browsers. The last few modules in particular were unexplored areas for me, with topics like screen configurations and media features. I learned a lot about those topics by writing about them.
Best of all, I got to put my new-found knowledge to use! Here’s how…
The Session is a progressive web app. If you add it to the home screen of your mobile device, then when you launch the site by tapping on its icon, it behaves just like a native app.
In the web app manifest file for The Session, the display-mode property is set to “standalone.” That means it will launch without any browser chrome: no address bar and no back button. It’s up to me to provide the functionality that the browser usually takes care of.
So I added a back button in the navigation interface. It only appears on small screens.
Do you see the assumption I made?
I figured that the back button was most necessary in the situation where the site had been added to the home screen. That only happens on mobile devices, right?
Nope. If you’re using Chrome or Edge on a desktop device, you will be actively encourged to “install” The Session. If you do that, then just as on mobile, the site will behave like a standalone native app and launch without any browser chrome.
So desktop users who install the progressive web app don’t get any back button (because in my CSS I declare that the back button in the interface should only appear on small screens).
I was alerted to this issue on The Session:
It downloaded for me but there’s a bug, Jeremy - there doesn’t seem to be a way to go back.
Luckily, this happened as I was writing the module on media features. I knew exactly how to solve this problem because now I knew about the existence of the display-mode media feature. It allows you to write media queries that match the possible values of display-mode in a web app manifest:
.goback {
display: none;
}
@media (display-mode: standalone) {
.goback {
display: inline;
}
}
Now the back button shows up if you “install” The Session, regardless of whether that’s on mobile or desktop.
Previously I made the mistake of inferring whether or not to show the back button based on screen size. But the display-mode media feature allowed me to test the actual condition I cared about: is this user navigating in standalone mode?
If I hadn’t been writing about media features, I don’t think I would’ve been able to solve the problem. It’s a really good feeling when you’ve just learned something new, and then you immediately find exactly the right use case for it!
An experimental image font made using the University of Plymouth’s unique letterpress workshop.
Grungy!
The font is intended for display purposes only, and not is suitable for body text.
This broke my brain.
The challenge: in the fewest resources possible, render meaningful text.
- How small can a font really go?
- How many bytes of memory would you need (to store it and run it?)
- How much code would it take to express it?
Lets see just how far we can take this!
Marcin built this lovely little in-browser tool to demonstrate how segmented type displays work at different sizes.
A really deep dive into display: contents from Ire.
Tal Leming’s thoroughly delightful (and obsessive) account of designing the 90 Minutes typeface for U.S. Soccer.
FIFA has strict regulations that govern the size and stroke weight of numbers and letters used on official match uniforms. This made me unbelievably paranoid. I had a nightmare that one of the national teams would be set for kickoff of an important match and the referee would suddenly blow the whistle and say, “Hey, hey, hey! The bottom stroke of that 2 is 1 mm too light. The United States must forfeit this match!”
Everyone’s been talking about font-display: swap as a way of taking the pain out of loading web fonts, but here Chris looks at font-display: optional and font-display: fallback as well.
This is an excellent proposal from Emil. If we can apply display: contents to fieldsets, then we would finally have a way of undoing the byzantine browser styles that have hindered adoption of this element. This proposal also ensures backwards compatibility so there’d be no breakage of older sites:
The legacy appearance of fieldsets probably needs to be preserved for compatibility reasons. But
display: contentsis not supported in any old browsers, and is most likely used on exactly zero sites using the legacy look of fieldsets.
Whaddya say, browser makers?
This is a really clear explanation of how CSS works.
The font-display property is landing in browsers, and this is a great introduction to using it:
If you don’t know which option to use, then go with
swap. Not only does it provide an optimal balance between custom fonts and accessibility of content, it provides the same font loading behavior that we’ve relied on JavaScript for. If you have fonts on the page that you’d like to have load, but could ultimately do without, consider going withfallbackoroptionalwhen usingfont-display.
Until it’s more widely supported, you can continue to use a JavaScript solution, but even then you can feature detect first:
if ("fontDisplay" in document.body.style === false) {
/* JavaScript font loading logic goes here. */
}
I’ve seen the exact problem that Rachel describes here—flexbox only applied to direct children, meaning the markup would have to be adjusted. display: contents looks like a nifty solution.
Zoe uses one little case study to contrast two different CSS techniques: display-table and flexbox. Flexbox definitely comes out on top when it comes to true source-order independence.
Not only is FixMyStreet responsive, it’s using the “display: table-caption” trick I documented for adjustable “content first/navigation second” source order.
Trent offers some excellent advice for dealing with the effects of the iPad’s retina display on your websites. That advice is: don’t panic.
See now, this is why liquid layouts are the way to go.
When I linked to the Toast framework the other day, I mentioned that I was intrigued by its use of inline-block for layout. Here’s a more detailed analysis of how display: inline-block works, along with some caveats.
Right after I wrote about combining flexbox with responsive design—to switch the display of content and navigation based on browser size—I received an email from Raphaël Goetter. He pointed out a really elegant solution to the same use-case that makes use of display:table.
Let’s take the same markup as before:
<body>
<div role="main">
<p>This is the main content.</p>
</div>
<nav role="navigation">
<p>This is the navigation.</p>
<ol>
<li><a href="#">foo</a></li>
<li><a href="#">bar</a></li>
<li><a href="#">baz</a></li>
</ol>
</nav>
</body>
The source order reflects the order I want on small-screen devices (feature phones, smart phones, etc.). Once the viewport allows it, I’d like to put that navigation at the top. I can do this by wrapping some display declarations in a media query:
@media screen and (min-width: 30em) {
body {
display: table;
caption-side: top;
}
[role="navigation"] {
display: table-caption;
}
}
That’s it. It works much like box-orient:vertical with box-direction:reverse but because this is good ol’ CSS 2.1, it’s very well supported.
We can solve the other issue too: making those list items display horizontally on larger screens:
[role="navigation"] ol {
display: table-row;
}
[role="navigation"] ol li {
display: table-cell;
}
Once again, I’ve put a gist up on Github (get me! I’m like a proper computer nerd).
Update: And Remy has put it on JSbin so you can see it in action (resize the live preview pane).
So there you go: we’ve at least two different mechanisms in CSS to re-order the display of content and navigation in response to screen real-estate. The default is content first, navigation second—a pattern that Luke talked about in this interview with Jared:
Yeah, one of the design principles that I’ll be talking on the tour about, for mobile, is content first, navigation second; which is just really putting something up right away that somebody can engage with, and saving the pivoting and the navigating for later.
There’s, basically, UI patterns that you can use to make that happen. I’m still surprised at how many, both mobile websites and applications, the first thing they give you is a menu of choices, instead of content.
Don’t get me wrong, the menu’s important, and you can get to it, but it’s actually the content that the immediacy of mobile, and the fact that you’re probably on a slower network, and in some cases you’re even paying for your data transfers, right? Giving you a list of choices as your first time experience tends not to work so well.