Tags: display

14

sparkline

Saturday, May 12th, 2018

Segmented type appreciation corner

Marcin built this lovely little in-browser tool to demonstrate how segmented type displays work at different sizes.

Tuesday, April 3rd, 2018

How display: contents; Works

A really deep dive into display: contents from Ire.

Wednesday, March 21st, 2018

90 Minutes | Type Supply

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!”

Sunday, August 20th, 2017

If you really dislike FOUT, `font-display: optional` might be your jam | CSS-Tricks

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.

Monday, July 3rd, 2017

Fixing fieldsets — That Emil is Emil Björklund

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: contents is 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?

Saturday, April 15th, 2017

The invisible parts of CSS · MadebyMike

This is a really clear explanation of how CSS works.

Tuesday, September 6th, 2016

`font-display` for the Masses | CSS-Tricks

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 with fallback or optional when using font-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. */
}

Thursday, February 11th, 2016

Vanishing boxes with display contents

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.

Wednesday, July 30th, 2014

Full-width pinned layouts with flexbox

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.

Friday, June 1st, 2012

FixMyStreet

Not only is FixMyStreet responsive, it’s using the “display: table-caption” trick I documented for adjustable “content first/navigation second” source order.

Tuesday, May 8th, 2012

In Flux | Trent Walton

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.

Thursday, April 26th, 2012

Resizable Displays | Fluid Interfaces

See now, this is why liquid layouts are the way to go.

Wednesday, April 25th, 2012

What’s the Deal With Display: Inline-Block? | Design Shack

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.

Tuesday, August 16th, 2011

Re-tabulate

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.

Luke Wroblewski — Designing Mobile Web Experiences » UIE Brain Sparks on Huffduffer