Tags: css

808

sparkline

Monday, April 23rd, 2018

page-transitions-travelapp

A demo of page transition animations by Sarah—she’s written about how she did it. I really like it as an example of progressive enhancement: you can navigate around the site just fine, but with JavaScript you get the smooth transitions as a bonus.

All of this reminds me of Jake’s proposal for navigation transitions in the browser. I honestly think this would solve 80% of the use-cases for single page apps.

Animating Progress - Snook.ca

Jonathan goes down the rabbit hole of trying to animate a progress element.

Sunday, April 22nd, 2018

Inside CSS | Clearleft

If you’ve ever wondered what it would be like to be a fly on the wall at a CSS Working Group meeting, Richard has the inside scoop.

The consensus building is vital. Representatives from all the major browsers were in the room, collaborating closely by proposing ideas and sharing implementations. But most fundamentally they were agreeing together what should go in the specifications, because what goes in the specs is what gets built and ends up in the hands of users.

Friday, April 20th, 2018

:focus-visible and backwards compatibility

Patrick is thinking through a way to implement :focus-visible that’s forwards and backwards compatible.

Wednesday, April 18th, 2018

Best Practices With CSS Grid Layout — Smashing Magazine

A great set of answers from Rachel to frequently asked questions about CSS grid. She addresses the evergreen question of when to use flexbox and when to use grid:

I tend to use Flexbox for components where I want the natural size of items to strongly control their layout, essentially pushing the other items around.

A sign that perhaps Flexbox isn’t the layout method I should choose is when I start adding percentage widths to flex items and setting flex-grow to 0. The reason to add percentage widths to flex items is often because I’m trying to line them up in two dimensions (lining things up in two dimensions is exactly what Grid is for).

Sunday, April 15th, 2018

Keep Pixelated Images Pixelated as They Scale | CSS-Tricks

This is a potentially useful bit of CSS that I had no idea existed.

Thursday, April 12th, 2018

Notes on `lang` by Taylor Hunt on CodePen

A really deep dive into the lang attribute, and the :lang() pseudo-class (hitherto unknown to me). This is all proving really useful for a little side project I’m working on.

Tuesday, April 10th, 2018

Think like it’s 1995; code like it’s 2035 - Grayscale

This is such a great write-up of the workshop I did in Hong Kong!

Jeremy, it was a pleasure to work with you and you are always welcome here in Hong Kong!

If you fancy having this one-day workshop at your company, get in touch.

Friday, April 6th, 2018

Starability - Accessible rating system demo

Accessible star ratings (progressively enhanced from radio buttons) with lots of animation options. The code is on Github.

Understandable excitement

An Event Apart Seattle just wrapped. It was a three-day special edition and it was really rather good. Lots of the speakers (myself included) were unveiling brand new talks, so there was a real frisson of excitement.

It was interesting to see repeating, overlapping themes. From a purely technical perspective, three technologies that were front and centre were:

  • CSS grid,
  • variable fonts, and
  • service workers.

From listening to other attendees, the overwhelming message received was “These technologies are here—they’ve arrived.” Now, depending on your mindset, that understanding can be expressed as “Oh shit! These technologies are here!” or “Yay! Finally! These technologies are here!”

My reaction is very firmly the latter. That in itself is an interesting data-point, because (as discussed in my talk) my reaction towards new technological advances isn’t always one of excitement—quite often it’s one of apprehension, even fear.

I’ve been trying to self-analyse to figure out which kinds of technologies trigger which kind of reaction. I don’t have any firm answers yet, but it’s interesting to note that the three technologies mentioned above (CSS grid, variable fonts, and service workers) are all additions to the core languages of the web—the materials we use to build the web. Frameworks, libraries, build tools, and other such technologies are more like tools than materials. I tend to get less excited about advances in those areas. Sometimes advances in those areas not only fail to trigger excitement, they make me feel overwhelmed and worried about falling behind.

Since figuring out this split between materials and tools, it has helped me come to terms with my gut emotional reaction to the latest technological advances on the web. I think it’s okay that I don’t get excited about everything. And given the choice, I think maybe it’s healthier to be more excited about advances in the materials—HTML, CSS, and JavaScript APIs—than advances in tooling …although, it is, of course, perfectly possible to get equally excited about both (that’s just not something I seem to be able to do).

Another split I’ve noticed is between technologies that directly benefit users, and technologies that directly benefit developers. I think there was a bit of a meta-thread running through the talks at An Event Apart about CSS grid, variable fonts, and service workers: all of those advances allow us developers to accomplish more with less. They’re good for performance, in other words. I get much more nervous about CSS frameworks and JavaScript libraries that allow us to accomplish more, but require the user to download the framework or library first. It feels different when something is baked into browsers—support for CSS features, or JavaScript APIs. Then it feels like much more of a win-win situation for users and developers. If anything, the onus is on developers to take the time and do the work and get to grips with these browser-native technologies. I’m okay with that.

Anyway, all of this helps me understand my feelings at the end of An Event Apart Seattle. I’m fired up and eager to make something with CSS grid, variable fonts, and—of course—service workers.

Thursday, April 5th, 2018

Dear Developer, The Web Isn’t About You | sonniesedge.co.uk

This is absolutely brilliant!

Forgive my excitement, but this transcript of Charlie’s talk is so, so good—an equal mix of history and practical advice. Once you’ve read it, share it. I want everyone to have the pleasure of reading this inspiring piece!

It is this flirty declarative nature makes HTML so incredibly robust. Just look at this video. It shows me pulling chunks out of the Amazon homepage as I browse it, while the page continues to run.

Let’s just stop and think about that, because we take it for granted. I’m pulling chunks of code out of a running computer application, AND IT IS STILL WORKING.

Just how… INCREDIBLE is that? Can you imagine pulling random chunks of code out of the memory of your iPhone or Windows laptop, and still expecting it to work? Of course not! But with HTML, it’s a given.

Tuesday, April 3rd, 2018

How display: contents; Works

A really deep dive into display: contents from Ire.

The Way of the Web | Jeremy Keith | Hooked On Code

Here are Torre’s notes on my talk at An Event Apart Seattle. (She’s been liveblogging all the talks.)

LukeW | An Event Apart: The Way of the Web

Here are Luke’s notes from the talk I just gave at An Event Apart in Seattle.

Everything You Know About Web Design Just Changed by Jen Simmons

Alright! It’s time for the final talk of the day at An Event Apart Seattle (Special Edition). Jen is wrapping up a CSStastic afternoon with her talk Everything You Know About Web Design Just Changed. These are my notes…

Ready for another hour of layout in CSS? Well, Jen will be showing no code in this talk. She’s actually nervous about this particular talk. Is she really planning to say “Everything about web design just changed”? That sounds so clickbaity! But she really believes we’re at an inflection point. This may be the sixth such point in the history of the web. One of those points where everything changes and we swap out our techniques.

For the last few years, we’ve been saying that everything changed when mobile came along. But actually, the real fight has been going on for longer than that. It’s the battle between wanting art and dealing with how the web works.

There’s a seminal book called Creating Killer Websites by David Siegel from 1996. In it, he describes the first time he saw the same site in two different browsers. His reaction was panic. The web gave control to the user. David Siegel wanted more control. And that’s how we got spacer gifs and tables for layout.

What are the five major changes in the history of web design?

  1. Simple HTML. There was only one kind of layout: flow layout. There’s no CSS, but the browser is still thinking of everything has having a box. Text takes up as much space as it needs. Images take up as much space as their size. This is flow. There wasn’t much you could do until tables came along. They were created for tabular content but abused for layouts. The “We need art!” crowd used what was available to them at the time. Lots of slicing and dicing.
  2. Flash. It was hard to get HTML tables to work in multiple browsers. Flash seemed like an amazing chance to start over. And we could do things that were previously only possible in CD-ROMs. As a designer, you take an element and place it where you want to go on the stage (the UI tradition that goes all the way back to Xerox PARC). We made some crazy sites, explored a lot of possibilities, and got a lot of control. But the downside was the lack of accessibility. We went back to getting to grips with the web as its own medium. Jeffrey’s book, Designing With Web Standards, was a rallying cry to allow HTML to return to doing what it was meant to.
  3. Fluid Layouts. This was a return to the way the web always behaved—content takes up as much room as it needs to. But this time there’s a certain amount of control over how things are laid out. Still, we pretended that nobody has screens smaller than 640 pixels or bigger than 1024 pixels. We still live with the idea of fluid columns today.
  4. Fixed-Width Layouts. The “We need art!” crowd wanted more control than fluid layouts offered. We pretended that everyone’s screen was at least 640 pixels, or later 800 pixels, or later 1024 pixels.
  5. Responsive Web Design. Unveiled by Ethan at An Event Apart Seattle in 2011: flexible grid; flexible images; media queries. It’s a return to fluid layouts, but the addition of media queries gives us more control. The idea of fluid image was a bit radical. Up until that point, we thought of images as always being their intrinsic size. But something Ethan said that day was “It’s not just about layout.” And it’s true. For the last eight years, it’s been about more than layout. You set out to redesign your website and end up redesigning your whole business. Responsive web design is, frankly, what the web is now.

But let’s talk about layout. What’s next? Intrinsic Web Design.

Why a new name? Why bother? Well, it was helpful to debate fluid vs. fixed, or table-based layouts: having words really helps. Over the past few years, Jen has needed a term for “responsive web design +”.

Responsive web design has flexible images. Intrinsic web design has flexible images …or fixed images. Whichever you want.

Responsive web design has a fluid columns. Intrinsic web design has fluid columns and rows.

Responsive web design uses media queries. Intrinsic web design doesn’t necessarily need them.

The name comes from words that have been floating in the ether. In Rachel’s talk, the words “sizing” and “intrinsic” came up a lot. This is about the nature of the web.

Let’s look at images specifically. Before responsive web design, images overflow their container if they are bigger than the container. Fluid images (as used in responsive web design) shrink and grow depending on the size of their container. You can also make images fluid in a vertical direction. If we make the image fluid vertically and horizontally, the image looks distorted. But now if we use object-fit: cover we can specify how we want the image to react.

Fixed or fluid? With grid layout, you can mix fixed and fluid. You can make a layout fluid until it hits a minimum size, at which point it stays fixed.

There are four stages of squishiness:

  1. fixed
  2. fr units (fluid)
  3. minmax()(fluid until fixed)
  4. auto (a return to flow)

That’s a powerful set of tools that may take us years to explore.

We can do truly two-dimensional layouts: rows and columns. Every one of those four stages of squishiness works for rows as well as columns. This means we can create intentional white space. Jen made a video about this and got the response that this was always possible, but it’s different now: it’s more intentional. You can set heights and widths.

We can have nested contexts now:

  1. Flow
  2. Flexbox (formatting context)
  3. Grid (formatting context)
  4. Multicolumn (formatting context)

Floats never created a new formatting context, which is why used clearfix. Now we don’t need hacks. You can mix and match, choosing the best layout tool for the job at hand. You can have a grid layout that has flexbox items within it. The Firefox dev tools allow you to inspect each layout type separately. You can use the nightly build to get the latest tools.

Then we’ve got ways to contract and expand content. We have more options now. For a while, we’ve had the option to squish and grow (e.g. with fluid images). Another is wrapping and reflowing (like we can do with text). Another option now is to add and remove whitespace. Maybe the content size doesn’t need to change; the whitespace shrinks and grows instead. An even more radical option now is to have things slide behind one another and overlap deliberately.

Sometimes you don’t even need to use media queries (meaning we’ve effectively got container queries). But we can still use media queries, as needed, to tweak the details.

So intrinsic web design is:

  1. Fluid and fixed
  2. Stages of squishiness
  3. Truly two-dimensional layouts
  4. Nested contexts
  5. Expand and contract content
  6. Media queries, as needed

We have a whole new sandbox that we can play in. You can find examples at labs.jensimmons.com.

See also:

Monday, April 2nd, 2018

Fit For Purpose: Making Sense of the New CSS by Eric Meyer

Time for even more CSS goodness at An Event Apart Seattle (Special Edition). Eric’s talk is called Fit For Purpose: Making Sense of the New CSS. Here are my notes…

Eric isn’t going to dive quite as deeply as Rachel, but he is going to share some patterns he has used.

Feature queries

First up: feature queries! Or @supports, if you prefer. You can ask a browser “do you support this feature?” If you haven’t used feature queries, you might be wondering why you have to say the property and the value. Well, think about it. If you asked a browser “do you support display?”, it’s not very useful. So you have to say “do you support display: grid?”

Here’s a nice pattern from Lea Verou for detecting support for custom properties:

@supports (--css: variables)

Here’s a gotcha:

@supports (clip-path: polygon())

That won’t work because polygon() is invalid. This will work:

@supports (clip-path: polygon(0 0))

So to use feature queries, you need to understand valid values for properties.

You can chain feature queries together, or just pick the least-supported thing you’re testing for and test just for that.

Here’s a pattern Eric used when he only wanted to make text sideways, but only if grid is supported:

@supports (display: grid) {
    ...
    @supports (writing-mode: sideways-lr) {
        ...
    }
}

That’s functionally equivalent to:

@supports (display: grid) {
    ...
}
@supports (display:grid) and (writing-mode: sideways-lr) {
    ...
}

Choose whichever pattern makes sense to you. More to the point, choose the pattern that makes sense to your future self when you revisit your code.

Feature queries need to work together with media queries. Sometimes there are effects that you only want to apply on larger viewports. Do you put your feature queries inside your media queries? Or do you put your media queries inside your feature queries?

  • MOSS: Media Outside Support Statements
  • MISO: Media Inside Supports Object

Use MOSS when you have more media switches than support blocks. Use MISO when you only have a few breakpoints but lots of feature queries.

That’s one idea that Eric has. It’ll be interesting to see how this develops.

And remember, CSS is still CSS. Sometimes you don’t need a feature query at all. You could just use hanging-punctuation without testing for it. Browsers that don’t understand it will just ignore it. CSS has implicit feature queries built in. You don’t have to put your grid layout in a feature query, but you might want to put grid-specific margins and widths inside a feature query for display: grid.

Feature queries really help us get from now to the future.

Flexbox

Let’s move on to flexbox. Flexbox is great for things in a line.

On the An Event Apart site, the profile pictures have social media icons lined up at the bottom. Sometimes there are just a few. Sometimes there are a lot more. This is using flexbox. Why? Because it’s cool. Also, because it’s flexbox, you can create rules about how the icons should behave if one of the icons is taller than the others. (It’s gotten to the point that Eric has forgotten that vertically-centring things in CSS is supposed to be hard. The jokes aren’t funny any more.) Also, what if there’s no photo? Using flexbox, you can say “if there’s no photo, change the direction of the icons to be vertical.” Once again, it’s all about writing less CSS.

Also, note that the profile picture is being floated. That’s the right tool for the job. It feels almost transgressive to use float for exactly the purpose for which it was intended.

On the An Event Apart site, the header is currently using absolute positioning to pull the navigation from the bottom of the page source to the top of the viewport. But now you get overlap at some screen sizes. Flexbox would make it much more robust. (Eric uses the flexbox inspector in Firefox Nightly to demonstrate.)

With flexbox, what works horizontally works vertically. Flexbox allows you to align things, as long as you’re aligning in one direction. Flexbox makes things springy. Everything’s related and pushing against each other in a way that makes sense for this medium. It’s intuitive, even though it takes a bit of getting used to …because we’ve picked up some bad habits. To quote Yoda, “You must unlearn what you have learned.” A lot of the barrier is getting over what we’ve internalised. Eric envies the people starting out now. They get to start fresh. It’s like when people who never had to table layouts see code from that time period: it (quite rightly) doesn’t make any sense. That’s what it’s going to be like when people starting out today see the float-based layouts from Bootstrap and the like.

Grid

That’s going to happen with grid too. We must unlearn what we have learned from twenty years of floats and positioning. What makes it worth is:

  1. Flexbox and grid are pretty easy to get used to, and
  2. It’s amazing what you can do!

Eric quotes from an article called How We adopted CSS Grid at Scale:

…we agreed to use CSS Grid at the layout level and Flexbox at the component level (arranging child items of components). Although there’s some overlap and in some cases both could be used interchangeably, abiding by this rule helped us avoid any confusion in gray areas.

Don’t be afraid to set these kind of arbitrary limits that aren’t technological, but are necessary for the team to work well together.

Eric hacked his Wordpress admin interface to use grid instead of floats for an activity component (a list of dates and titles). He initially turned each list item into a separate grid. The overall list didn’t look right. What Eric really needed was a subgrid capability, so that the mini grids (the list items) would relate to one another within the larger grid (the list). But subgrid doesn’t exist yet.

In this case, there’s a way to fake it using display: contents. Eric made the list a grid and used display: contents on the list items. It’s as though you’re saying that the contents of the li are really the contents of the ul. That works in this particular case.

The feature queries for that looked like:

@supports (display: grid) {
    ...
    @supports (display: contents) {
        ...
    }
}

Eric is also using the grid “ASCII art” (named areas) technique on his personal site. This works independent of source order. For that reason, make sure your source order makes sense.

Using media queries, Eric defines entirely different layouts simply by using different ASCII art. He’s switching templates.

For a proposed redesign of the An Event Apart site, Eric used CSS grid as a prototyping tool. He took a PDF, sliced it up, exported JPGs, and then used grid to lay out those images in a flexible grid. Rapid prototyping! The Firefox grid inspector really helps here. In less than an hour, he had a working layout. He could test whether the layout was sensible and robust. Then he swapped out the sliced images for real content. That took maybe another hour (mostly because it was faster to re-type the text than try to copy and paste from a PDF). CSS makes it that damn easy now!

So even if you’re not going to put things like grid into production, they can still be enormously useful as design tools (and you’re getting to grips with this new stuff).

See also:

Graduating to Grid by Rachel Andrew

It’s time for a gridtastic afternoon at An Event Apart Seattle (Special Edition). Kicking it off is Rachel with her talk Graduating to Grid. Here are my notes…

When Rachel spoke at An Event Apart last year, grid layout was still on the horizon. Then in March 2017, Chrome, Safari, and Firefox all shipped within weeks of one another. Then at An Event Apart Seattle last year, Edge announced that they were shipping too. So within a very short time, CSS grid got really good browser support.

What’s it like being in the middle of a launch of a big new CSS feature? Very quickly, we had 90% browser support. Suddenly it wasn’t just Jen and Rachel talking about grid—everyone was talking about grid. It involved a lot of email. Alas, Rachel couldn’t answer all those questions (she has a job, after all) but she did start collecting those questions. She found that people were excited, confused, and scared. So much to learn!

Rachel put out a survey and asked “How do you feel when a new CSS feature is announced?” Responses included “Oh, no!” and “Tired.” Some of us in the audience can, no doubt, identify with that.

People started emailing Rachel asking for her blessing. Were they doing the right thing? But Rachel can’t tell you what to do. She’s not in your situation. But she can help you develop the skills to make those decisions yourself. She can offer you confidence. She wants everyone to be the amazing CSS layout person on their team. That’s what this talk is for.

First of all, you need to understand CSS. There’s no shortcut here. But that doesn’t mean you need to learn every single property and value by heart. That’s not what CSS is about. That’s like learning phrases in a foreign language—knowing the words for “coffee” or “beer” doesn’t help you grok the language. It’s the same for CSS. There are some core ideas that help CSS layout make sense. You probably have an understanding of them already, but maybe you don’t have the right words for them.

At the heart of this is the first word in the language we’re talking about: cascading. You need to understand the (much-maligned) cascade. And you can’t talk about the cascade without encountering specificity. The MDN page on the cascade and specificity is a good explanation.

Then there’s dimensions. In any language with a horizontal writing mode, the inline dimension runs left to right or right to left, and the block dimension runs down the page from top to bottom. In vertical writing mode, it’s different.

In grid, we talk about the inline axis as rows, and the block axis as columns.

Sizing matters. It has become obvious that no one understands how big anything is. We’re living in a world where you don’t control the size of things.

In older float-based systems, everything is given a percentage. As long as our percentages don’t exceed 100%, everything’s okay. And we’ve got wrappers to keep things within rows. We end up with something that looks like a grid. It involves us doing a lot of calculating. You can do this with flexbox too, but it’s much the same—figuring out percentages. These past layout methods create the appearance of a grid by lining things up.

With the new layout, we don’t have to do the calculations. We need to understand CSS intrinsic sizing and extrinsic sizing (say that ten times fast).

With a regular div, you’ve got a block-level element. The box will stretch as far as it will go, to the viewport width by default. You can specify an intrinsic size by saying, say, width: 500px. That makes 500 pixels wide in the inline direction.

However the content of the box has a size. The maximum size of a string of text is how much space it would take up if it never wrapped. The minimum size is the space it would take up if everything wrapped. Now in CSS we can say width: min-content or width: max-content.

Let’s say our div was in a container that had a width of 20em. The max-content of the contents of the div (which is more than 20 ems) is wider than the width of the div and so the content overflows.

In flexbox, let’s say we’ve got a flex container with four items and we’ve declared that each one should take up max-content. Each item takes up as much space as it needs. Each one uses max-content as its starting point, and then width is removed to make all four items fit in the container. flex: 1 1 auto will distribute space according to the content. flex: 1 1 0 will distribute the space equally (you’re effectively saying that the max-content is zero).

It’s similar with grid layout but with slight differences. Flexbox is starting from max-content and taking space away. Grid is starting from min-content and adding space.

Those content keywords aren’t well supported outside grid layout. They’re safe to use for track sizing.

grid-template-columns: repeat(4, min-content);

That will make everything squished down.

grid-template-columns: repeat(4, max-content);

That one will probably cause an overflow.

grid-template-columns: repeat(4, fit-content(15ch));

That one will make 15 characters an upper limit!

You can make a grid layout using fr units and grid-gap. No need for figuring out percentages. You can use percentages if you like though. You can use percentages for gaps, for example.

Remember, you don’t have to stick with a twelve column grid. Slack started with that because it was what they were used to. Then they realised they didn’t have to.

Imagine a media object pattern, where you don’t want the image to ever be bigger than 300 pixels.

grid-template-columns: fit-content(300px) 1fr

As Rachel creates more layouts with grid, she finds she’s using less and less CSS, which is great. The browser is doing the work. That matches the reality of the situation where you don’t know the size of your content in advance—long titles, and so on.

This is not exciting. But it will let you do exciting things. Learning about sizing is the CSS equivalent of eating your vegetables or getting enough sleep.

“Why is all of this so complicated?”, is something Rachel hears a lot. It’s like all software. People want all the features, and they also want it to be easy to use.

More capability and flexibility means more to learn. But it’s worth remembering that you don’t have to learn everything at once. Once you switch your mindset to the grid way of thinking (where you define things on the layout) it gets easier. It’s all just lines.

If you name your grid lines, e.g. “content-start” and “content-end”, you automatically get a named area called “content.”

It works the other way around too. If you create an area called “content”, you automatically get lines named “content-start” and “content-end”.

You don’t have to use any of that. You have real choice for the first time.

A lot of the assumptions we’ve had in the past about what isn’t possible don’t hold up any more. You can now ask, “what’s the best way to do this?” instead of asking “which patterns does our framework give us?”

Well, that’s fine, you might be thinking, for shiny new things. But what if you’re building things that have an old codebase? Rachel asked “How old is the oldest CSS in your project?” in her survey. People have code that’s over ten years old. But old CSS in your codebase doesn’t mean you can’t use new CSS. You can design components or a section of a page using a new technique. This is where understanding CSS comes in really useful—the cascade, especially.

Rachel shows an example of a page made with Bootstrap. She drops a grid component into that layout. It works fine. Nothing explodes. They coexist side by side.

You can create systems with new layout. You’ve got a lot of choice. You can start to make decisions about which layout method works best for different situation. Other layout methods still exist. Don’t try to recreate floats within grid—just use floats. It’s like when we moved from tables for layout, some people went too far and stopped using tables for tabular data. If you need content to flow around an element, float that element. Likewise, if you’re doing layout in just one dimension, you don’t have to use grid; use flexbox.

Off-the-shelf frameworks are designed to solve generic problems. We end up solving problems we don’t have. Do you want your project to inherit the CSS problems of the rest of the world? Solving your specific problems only will result in lighter, easier to understand code.

You don’t need to lean on somebody else’s framework to get reusable code for your project and your team.

What about working with less capable browsers? (these may not always be old browsers). Let’s go back to 2006 and Yahoo’s graded browser support matrix. It was updated quarterly. It was useful. A lot of discussion around browser support was happening with a lack of understanding on one side (bosses, clients) meeting a lack of confidence on the other (developers). Yahoo’s browser support matrix gave us ammunition. If it was okay for Yahoo to say that it was okay for certain browsers to not receive certain features, then that argument was easier to make.

A lot of the discussion now is about older Internet Explorer—IE11 comes up a lot. If IE10 and 11 are your oldest supported versions, you can use the ms- prefixed grid layout.

Some people are using devices that aren’t updating to new browsers. UC browser for Android is used a lot. It’s very popular in India (35% usage). Many browsers without grid support are mobile browsers, popular in areas where data is expensive.

People want a magical grid polyfill that will make grid work in non-supporting browsers. Please stop asking for that! Why, oh, why would you send more JavaScript to less-capable devices!

You can use feature queries to ask if a browser supports a feature before using it. The great thing about doing this is that you are future-proofing: as browsers get support for features, your code works automatically.

You can create complex layouts for browsers that support them with a few lines of CSS. Being able to do new cool stuff is great. Saving developer time is great. But making the web available to everyone …that’s exciting!

To wrap up, Rachel recounts some of the other responses to her survey. People said they were “Excited!”

See also:

Friday, March 30th, 2018

Ampersand: Interview with Mandy Michael – Clear(left) Thinking – Medium

I’m soooo excited that Mandy is speaking at Ampersand here in Brighton in June!

Be there or be square.

Animated SVG Radial Progress Bars - daverupert.com

Using a single path SVG, a smidge of CSS, and ~6 lines of JavaScript.

In this days of monolithic frameworks, I really like seeing modest but powerful patterns like this—small pieces that we can loosely join.

Focusing on Focus Styles | CSS-Tricks

A deep dive into the :focus pseudo-class and why it’s important.