Author: Chris Coyier

Posted on

I Saw Two Mega Menus Today…

Category Image 052

One was the footer of an (older) U.S. Government website:

The other was the navigation for AWS services from the AWS Console:

A four column layout with a long list of white links in each column against a dark blue background.
It’s weird how much they use the word “Amazon” and “AWS” when you’re literally logged into AWS.

Both of them have that vibe of: holy crap we have a lot of stuff, I guess we’ll just make a massive grid of links to it all.

The difference is the AWS Console one has a search bar at the top of it. Its primary function is finding things in that menu (but it does search the wider site as well):

Showing a full-width search box with a dark blue background and the AWS logo pinned to the top of the screen, followed by search results for the term s3 and a list of filters to the left of it against a darker blue background.
They also have a “favorites” UI for saving the ones you use the most.

The “search a list of things already on the page” idea reminds me of that classic jQuery contains selector. Please allow me:

The post I Saw Two Mega Menus Today… appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Posted on

Styling Web Components

Category Image 052

Nolan Lawson has a little emoji-picker-element that is awfully handy and incredibly easy to use. But considering you’d probably be using it within your own app, it should be style-able so it can incorporated nicely anywhere. How to allow that styling isn’t exactly obvious:

What wasn’t obvious to me, though, was how to allow users to style it. What if they wanted a different background color? What if they wanted the emoji to be bigger? What if they wanted a different font for the input field?

Nolan list four possibilities (I’ll rename them a bit in a way that helps me understand them).

  1. CSS Custom Properties: Style things like background: var(--background, white);. Custom properties penetrate the Shadow DOM, so you’re essentially adding styling hooks.
  2. Pre-built variations: You can add a class attribute to the custom elements, which are easy to access within CSS inside the Shadow DOM thanks to the pseudo selectors, like :host(.dark) { background: black; }.
  3. Shadow parts: You add attributes to things you want to be style-able, like <span part="foo">, then CSS from the outside can reach in like custom-component::part(foo) { }.
  4. User forced: Despite the nothing in/nothing out vibe of the Shadow DOM, you can always reach the element.shadowRoot and inject a <style>, so there is always a way to get styles in.

It’s probably worth a mention that the DOM you slot into place is style-able from “outside” CSS as it were.

This is such a funky problem. I like the Shadow DOM because it’s the closest thing we have on the web platform to scoped styles which are definitely a good idea. But I don’t love any of those styling solutions. They all seem to force me into thinking about what kind of styling API I want to offer and document it, while not encouraging any particular consistency across components.

To me, the DOM already is a styling API. I like the scoped protection, but there should be an easy way to reach in there and style things if I want to. Seems like there should be a very simple CSS-only way to reach inside and still use the cascade and such. Maybe the dash-separated custom-element name is enough? my-custom-elemement li { }. Or maybe it’s more explicit, like @shadow my-custom-element li { }. I just think it should be easier. Constructable Stylesheets don’t seem like a step toward make it easier, either.

Last time I was thinking about styling web components, I was just trying to figure out how to it works in the first place, not considering how to expose styling options to consumers of the component.

Does this actually come up as a problem in day-to-day work? Sure does.

I don’t see any particularly good options in that thread (yet) for the styling approach. If I was Dave, I’d be tempted to just do nothing. Offer minimal styling, and if people wanna style it, they can do it however they want from their copy of the component. Or they can “force” the styles in, meaning you have complete freedom.

The post Styling Web Components appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Posted on

#300: Exploring Custom Profiles

Category Image 052

You’ve got two options for customzing your profile on CodePen, and endless possibility:

  • Open to everyone: Apply Custom CSS (which can be a link to a Pen on CodePen)
  • PRO only: Apply a Pen-as-Header-Background

In this video, Chris & Stephen look at a bunch of awesome profiles on CodePen, and find that many users (especially the coolest profiles) do both. Here’s the shuffle machine we used in the video to randomize cool profiles:

The post #300: Exploring Custom Profiles appeared first on CodePen Blog.

Posted on

The Holy Grail Layout with CSS Grid

Category Image 052

A reader wrote in asking specifically how to build this layout in CSS Flexbox:

My answer: That’s not really a layout for CSS Flexbox. You could pull it off if you had to, but you’d need some kind of conceit, like grouping the nav and article together in a parent element (if not more grouping). CSS Grid was born to describe this kind of layout and it will be far easier to work with, not to mention that the browser support for both is largely the same these days.

What do you mean by “Holy Grail”?

See, kids, layout on the web used to be so janky that the incredible simple diagram above was relatively difficult to pull off, particularly if you needed the “columns” there to match heights. I know, ridiculous, but that was the deal. We used super weird hacks to get it done (like huge negative margins paired with positive padding), which evolved over time to cleaner tricks (like background images that mimicked columns). Techniques that did manage to pull it off referred to it as the holy grail. (Just for extra clarity, usually, holy grail meant a three-column layout with content in the middle, but the main point was equal height columns).

CSS is much more robust now, so we can use it without resorting to hacks to do reasonable things, like accomplish this basic layout.

Here it is in CSS Grid

This grid is set up both with grid-template-columns and grid-template-rows. This way we can be really specific about where we want these major site sections to fall.

I slipped in some extra stuff

  • I had another question come my way the other day about doing 1px lines between grid areas. The trick there is as simple as the parent having a background color and using gap: 1px;, so I’ve done that in the demo above.
  • It’s likely that small screens move down to a single-column layout. I’ve done that at a media query above. Sometimes I use display: block; on the parent, turning off the grid, but here I’ve left grid on and reset the columns and rows. This way, we still get the gap, and we can shuffle things around if needed.
  • Another recent question I was asked about is the subtle “body border” effect you can see in the demo above. I did it about as simple as possible, with a smidge of padding between the body and the grid wrapper. I originally did it between the body and the HTML element, but for full-page grids, I think it’s smarter to use a wrapper div than use the body for the grid. That way, third-party things that inject stuff into the body won’t cause layout weirdness.

The post The Holy Grail Layout with CSS Grid appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Posted on

On Auto-Generated Atomic CSS

Featured Imgs 23

Robin Weser’s “The Shorthand-Longhand Problem in Atomic CSS” in an interesting journey through a tricky problem. The point is that when you take on the job of converting something HTML and CSS-like into actual HTML and CSS, there are edge cases that you’ll have to program yourself out of, if you even can at all. In this case, Fela (which we just mentioned), turns CSS into “atomic” classes, but when you mix together shorthand and longhand, the resulting classes, mixed with the cascade, can cause mistakes.

I think this whole idea of CSS-in-JS that produces Atomic CSS is pretty interesting, so let’s take a quick step back and look at that.

Atomic CSS means one class = one job

Like this:

.mb-8 {
  margin-bottom: 2rem;
}

Now imagine, like, thousands of those that are available to use and can do just about anything CSS can do.

Why would you do that?

Here’s some reasons:

  • If you go all-in on that idea, it means that you’ll ship less CSS because there are no property/value pairs that are repeated, and there are are no made-up-for-authoring-reasons class names. I would guess an all-atomic stylesheet (trimmed for usage, which we’ll get to) is a quarter the size of a hand-authored stylesheet, or smaller. Shipping less CSS is significant because CSS is a blocking resource.
  • You get to avoid naming things.
  • You get some degree of design consistency “for free” if you limit the available classes.
  • Some people just prefer it and say it makes them faster.

How do you get Atomic CSS?

There is nothing stopping you from just doing it yourself. That’s what GitHub did with Primer and Facebook did in FB5 (not that you should do what mega corporations do!). They decided on a bunch of utility styles and shipped it (to themselves, largely) as a package.

Perhaps the originator of the whole idea was Tachyons, which is a just a big ol’ opinionated pile of classes you can grab as use as-is.

But for the most part…

Tailwind is the big player.

Tailwind has a bunch of nice defaults, but it does some very smart things beyond being a collection of atomic styles:

  • It’s configurable. You tell it what you want all those classes to do.
  • It encourages you to “purge” the unused classes. You really need to get this part right, as you aren’t really getting the benefit of Atomic CSS if you don’t.
  • It’s got a UI library so you can get moving right away.

Wait weren’t we talking about automatically-generated Atomic CSS?

Oh right.

It’s worth mentioning that Yahoo was also an early player here. Their big idea is that you’d essentially use functions as class names (e.g. class="P(20px)") and that would be processed into a class (both in the HTML and CSS) during a build step. I’m not sure how popular that got really, but you can see how it’s not terribly dissimilar to Tailwind.

These days, you don’t have to write Atomic CSS to get Atomic CSS. From Robin’s article:

It allows us to write our styles in a familiar “monolithic” way, but get Atomic CSS out. This increases reusability and decreases the final CSS bundle size. Each property-value pair is only rendered once, namely on its first occurence. From there on, every time we use that specific pair again, we can reuse the same class name from a cache. Some libraries that do that are:

• Fela
• Styletron
• React Native Web
• Otion
• StyleSheet

In my honest opinion, I think that this is the only reasonable way to actually use Atomic CSS as it does not impact the developer experience when writing styles. I would not recommend to write Atomic CSS by hand.

I think that’s neat. I’ve tried writing Atomic CSS directly a number of times and I just don’t like it. Who knows why. I’ve learned lots of new things in my life, and this one just doesn’t click with me. But I definitely like the idea of computers doing whatever they have to do to boost web performance in production. If a build step turns my authored CSS into Atomic CSS… hey that’s cool. There are five libraries above that do it, so the concept certainly has legs.

It makes sense that the approaches are based on CSS-in-JS, as they absolutely need to process both the markup and the CSS — so that’s the context that makes the most sense.

What do y’all think?

The post On Auto-Generated Atomic CSS appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Posted on

Fixing Smooth Scrolling with Find-on-Page

Category Image 052

Back when we released the v17 design (we’re on v18 now) of this site. I added html { scroll-behavior: smooth; } to the CSS. Right away, I got comments like this (just one example):

… when you control+f or command+f and search on CSS-Tricks, it’ll scroll very slowly instead of snapping to the result, which makes finding information and keywords on CSS-Tricks much slower. As someone who uses this shortcut frequently, this is a usability issue for me.

Not terribly long after, I just removed it. I didn’t feel that strongly about it, and the fact that you have almost zero control over it, made me just can the idea.

I see it come up as a “CSS tip” a lot, so I chimed in with my experience:

After mentioning that, Christian Schaefer chimed in with a great idea:

Love that!

Christian blogged it:

Smooth scrolling is consequently applied to everything. Always. Even when cycling through the browser’s page search results. At least that’s the case for Chromium. So for the page search it would be desirable for the browser to make an exception to that rule and to deactivate smooth scrolling. Until the Chromium team fixes it, here is a trick how to solve the problem on your own with a little bit of extra CSS and HTML.

I’m not sure if Chrome (or any other browser) would consider that a bug or not. I doubt it’s specced since find-on-page isn’t really a web technology feature. But anyway, I much prefer find-on-page without it. 

html:focus-within {
  scroll-behavior: smooth;
}

It mostly works. The bummer part about it is situations like this…

<a href="#link-down-the-page">Jump down</a>

...

<h2 id="link-down-the-page">Header</h2>

That will jump the page down. With scroll-behavior: smooth; in place, that’s kinda nice. But <h2> is typically not a “focusable” element. So, with the trick above, there is now no focus within <html> anymore, and the smooth scrolling is lost. If you want to preserve that, you’d have to do:

<h2 tabindex="-1" id="link-down-the-page">Header</h2>

The post Fixing Smooth Scrolling with Find-on-Page appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Posted on

CSS Snapshot 2020

Featured Imgs 23

I think it’s great that the CSS Working Group does these. It’s like planting a flag in the ground saying this is what CSS looks like at this specific point in time. They do specifically say it’s not for us CSS authors though…

This document collects together into one definition all the specs that together form the current state of Cascading Style Sheets (CSS) as of 2020. The primary audience is CSS implementers, not CSS authors, as this definition includes modules by specification stability, not Web browser adoption rate.

Remember “CSS3”? That was the closest thing we had to a “snapshot” that was designed for CSS authors (and learners). Because CSS3 was so wildly successful, we saw a short round of enthusiasm for CSS4, me included. There is zero marketing panache on that snapshot page, which is exactly what CSS4 would need to succeed. Remember, HTML5 and friends (including CSS3) even had fancy logos!

If someone were to say to me “Chris, when CSS3 came around, I boned up on all that, but I haven’t kept up with CSS since, what should I learn?” I’d say “That’s a damn fine question, developer that has a normal healthy relationship with technology.” But honestly, I might struggle to answer cohesively.

I’d say: Uhm, CSS grid for sure. Custom properties. Clipping and Offset paths I suppose. prefers-reduced-motion. I dunno. There are probably like 100 things, but there is no great single reference point to see them all together.

I’ll work on putting a list together. I don’t think I’ll have the gumption to call it CSS4, but at least I’ll be able to answer that question. Feel free to suggest ideas in the comments.

The post CSS Snapshot 2020 appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Posted on

Centering in CSS

Category Image 052


Adam Argyle has a post over on web.dev digging into this. He starts with the assumption that you need to do vertical centering and horizontal centering. It’s that vertical centering that has traditionally been a bit trickier for folks, particularly when the height of the content is unknown.

We have a complete guide to centering that covers a wide variety of situations like a decision tree.

Adam details five(!) methods for handling it, even getting into centering unknown vertical and horizontal dimensions, plus a handful of other restraints like language direction and multiple elements. I guess all the silly jokes about the difficulty of centering things in CSS need to be updated. Maybe they should poke fun about how many great ways there are to center things in CSS.

Adam does a great job listing out the pros and cons of all the techniques, and demonstrating them clearly. There is also a video. He picks “the gentle flex” as the winning approach:

.gentle-flex {
  display: flex;
  flex-direction: column;
  align-items: center;
  justify-content: center;
  gap: 1ch;
}

You can always find it in my stylesheets because it’s useful for both macro and micro layouts. It’s an all-around reliable solution with results that match my expectations. Also, because I’m an intrinsic sizing junkie, I tend to graduate into this solution. True, it’s a lot to type out, but the benefits it provides outweighs the extra code.

Remember that when you’re “centering in CSS” it’s not always within these extreme situations. Let’s look at another situation, just for fun. Say you need to horizontally center some inline-*¹ elements… text-align: center; gets you there as a one-liner:

But what if you need to center the parent of those items? You’d think you could do a classic margin: 0 auto; thing, and you can, but it’s likely the parent is block-level and thus either full-width or has a fixed width. Say instead you want it to be as wide as the content it contains. You could make the parent inline-*, but then you need another parent in which to set the text-align on to get it centered.

Stefan Judis talked about this recently. The trick is to leave the element block-level, but use width: fit-content;

The ol’ gentle flex could have probably gotten involved here too, but we’d need an additional parent again. Always something to think about.

  1. What I mean by inline-* is: inline, inline-block, inline-flex, inline-grid, or inline-table. Did I miss any?

Direct Link to Article — Permalink

The post Centering in CSS appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Posted on

A font-display setting for slow connections

Featured Imgs 25

Me, I really dislike FOUT. I like that it’s an option, because not displaying text quickly on the web is no good. I know font-display: swap; is popular because it’s good for performance, but that FOUT stuff pains me. Matt Hobbs:

If there’s one thing I’d like readers to take away from this post it’s that font-display: swap is a very good option for users with a fast internet connection. But its infinite swap period could be frustrating for users on very slow and unstable connections. If you have users viewing your site under these conditions (I’m pretty certain you will at some point in time), then it may be worth considering font-display: fallback or even font-display: optional.

Seeeee, I told ya. I like how font-display: optional; totally stops FOUT. The font is either applied super fast, or isn’t used at all (but still downloaded async). Chances are, on the next page load, the font is loaded and cached and will be used.

Note this is about slow connections, not necessarily connections where the user would prefer as little data usage as possible. If that’s the case, check out some of the recent posts we linked up in Responsible, Conditional Loading.

And boy howdy, the Web Performance Calendar this year was just loaded in great articles.

Direct Link to Article — Permalink

The post A font-display setting for slow connections appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Posted on

A Calendar in Three Lines of CSS

Category Image 052

This article has no byline and is on a website that is even more weirdly specific than this one is, but I appreciate the trick here. A seven-column grid makes for a calendar layout pretty quick. You can let the days (grid items) fall onto it naturally, except kick the first day over to the correct first column with grid-column-start.

Thoughts:

  • I’d go with an <ol> rather than a <ul> just because it seems like days are definitely ordered.
  • The days as-a-list don’t really bother me since maybe that makes semantic sense to the content of the calendar (assuming it has some)
  • But… seeing the titles of the days-of-the-week as the first items in the same list feels weird. Almost like that should be a separate list or something.
  • Or maybe it should all just be a <table> since it’s sort of tabular data (it stands to reason you might want to cross-reference and look at all Thursdays or whatever).

Anyway, the placement trickery is fun.

Here’s another (similar) approach from our collection of CSS Grid starter templates.

Direct Link to Article — Permalink

The post A Calendar in Three Lines of CSS appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Posted on

“Yes or No?”

Category Image 052

Sara Soueidan digs into this HTML/UX situation. “Yes” or “no” is a boolean situation. A checkbox represents this: it’s either on or off (uh, mostly). But is a checkbox always the best UX? It depends, of course:

Use radio buttons if you expect the answer to be equally distributed. If I expect the answer to be heavily biased to one answer I prefer the checkbox. That way the user either makes an explicit statement or just acknowledges the expected answer.

If you want a concrete, deliberate, explicit answer and don’t want a default selection, use radio buttons. A checkbox has an implicit default state. And the user might be biased to the default option. So having the requirement for an explicit “No” is the determinig factor.

So you’ve got the checkbox approach:

<label>
  <input type="checkbox">
  Yes?
</label>

Which is nice and compact but you can’t make it “required” (easily) because it’s always in a valid state.

So if you need to force a choice, radio buttons (with no default) are easier:

<label>
  <input type="radio" name="choice-radio">
  Yes
</label>
<label>
  <input type="radio" name="choice-radio">
  No
</label>

I mean, we might as well consider another a range input too, which can function as a toggle if you max it out at 1:

<label class="screen-reader-only" for="choice">Yes or No?</label>
<span aria-hidden="true">No</span>
<input type="range" max="1" id="choice" name="choice">
<span aria-hidden="true">Yes</span>

Lolz.

And I suppose a <select> could force a user choice too, right? 

<label>
  Yes or no?
  <select>
    <option value="">---</option>
    <option value="">Yes</option>
    <option value="">No</option>
  </select>
</label>

I weirdly don’t hate that only because selects are so compact and styleable.

If you really wanna stop and make someone think, though, make them type it, right?

<label>
  Type "yes" or "no"
  <input type="text" pattern="[Yy]es|[Nn]o">
</label>

Ha.

The post “Yes or No?” appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Posted on

What Makes CSS Hard To Master

Featured Imgs 23

Tim Severien:

I feel we, the community, have to acknowledge that CSS is easy to get started with and hard to master. Let’s reflect on the language and find out what makes it hard.

Tim’s reasons CSS is hard (in my own words):

  • You can look at a matching Ruleset, and still not have the whole styling story. There might be multiple matching rulesets in disparate places, including in places that only apply conditionally, like within @media queries.
  • Even if you think you’ve got a complete handle on the styling information in the CSS, you still may not, because styling is DOM-dependent. You need information from both places to know how something will be styled.
  • You have no control over the device, browser, version, resolution, input mode, etc., all of which can be CSS concerns.
  • Making changes to CSS can be scary because it’s hard to understand everywhere it applies.

I’m not sure people making sweeping generalizations about CSS either being too hard or too easy is helpful for anyone. It’s much more interesting to look at what can be straightforward about CSS and what can be tricky, like Tim has done here.

Direct Link to Article — Permalink

The post What Makes CSS Hard To Master appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Posted on

MDN on GitHub

Featured Imgs 25

Looks like all the content of MDN is on GitHub now. That’s pretty rad. That’s been the public plan for a while. Chris Mills:

We will be using GitHub’s contribution tools and features, essentially moving MDN from a Wiki model to a pull request (PR) model. This is so much better for contribution, allowing for intelligent linting, mass edits, and inclusion of MDN docs in whatever workflows you want to add it to (you can edit MDN source files directly in your favorite code editor).

Looks like that transition is happening basically today, and it’s a whole new back-end and front-end architecture.

Say you wanted to update the article for :focus-within. There will be a button on that page that takes you to the file in the repo (rather than the wiki editing page), and you can edit it from the GitHub UI (or however you like to do Git, but that seems like right-on-GitHub will be where the bulk of editing happens). Saving the changed document will automatically become a Pull Request, and presumably, there is a team in place to approve those.

We think that your changes should be live on the site in 48 hours as a worst case scenario.

Big claps from me here, I think this is a smart move. I can’t speak to the tech, but the content model is smart. I’d maybe like to see the content in Markdown with less specialized classes and such, but I suspect that kind of thing can evolve over time and this is already a behemoth of an update to ship all at once.

In August 2020, the entire MDN (writers) team was laid off, so it looks like the play here is to open up the creation and editing of these technical docs to the world of developers. Will it work? It super didn’t work for the “Web Platform Docs” (remember those?). But MDN has way more existing content, mindshare, and momentum. I suspect it will work great for the maintenance of existing docs, decently for new docs on whatever is hot ‘n’ fresh, but less so for anything old and “boring”.

Seems a little risky to fire all the writers before you find out if it works, so that speaks to the product direction. Things are changing and paying a content creation team directly just ain’t a part of whatever the new direction is.

The post MDN on GitHub appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Posted on

Projects in Collections (and Collections in Collections!)

Featured Imgs 23

For a long time on CodePen, Collections essentially meant “A Collection of Pens”, even though there is more on CodePen than just Pens. There are Projects too, which we’ve given a good amount of love to recently. Now you can add Projects to Collections just as naturally as you can a Pen.

Notice there is a Collection in that Collection too. 🤯. Hey why not right? It’s kind of like nested folders and might unlock some organizational possibilities for you.

Note that privacy works the same way across the board. If you put a private thing in a public Collection, only you will see the private stuff (you’ll see a message about it). If the Collection is private, it reveals the private things inside of it to whoever can see the private Collection.

This has been a satisfying thing to roll out and watch because we’ve seen y’all just using it naturally with no prompting (or confusion, or bugs, as best we can tell!)

The post Projects in Collections (and Collections in Collections!) appeared first on CodePen Blog.

Posted on

Under-Engineered Responsive Tables

Category Image 052

I first blogged about responsive data tables in 2011. When responsive web design was first becoming a thing, there were little hurdles like data tables that had to be jumped. The nature of <table> elements are that they have something a minimum width depending on the content they contain and that can easily exceed the width of a small screen device.

This image I made then still covers the issue pretty well:

Except… maybe they don’t equally suck. If that image on the left were scrollable, then maybe that’s actually… not so bad. In fact, that’s what I’ve done right here on CSS-Tricks recently. I think it’s the safest way of handling responsive tables when you have no idea what content the table contains. That’s the case here, where I need to set up base table styles that apply to any blog post which may contain a table.

The crux of the idea of a scrollable table is to wrap it in a <div> that has overflow: auto; on it. That way the <table> inside is free to exceed the width of the parent, but it won’t “blow out the width” and instead triggers a scrollbar. This isn’t quite enough though, so here’s Adrian Roselli with the real scoop. The wrapping <div> needs to be focusable and labelled, so:

<div role="region" aria-labelledby="Caption01" tabindex="0">
  <table>
    <caption id="Caption01">Appropriate caption</caption>
    <!-- ...  -->
  </table>
</div>

Then apply the scrolling and focus styles, in the condition you’ve done everything else right:

[role="region"][aria-labelledby][tabindex] {
  overflow: auto;
}

[role="region"][aria-labelledby][tabindex]:focus {
  outline: .1em solid rgba(0,0,0,.1);
}

If you’re going to further engineer responsive tables, there are all sorts of options. One of the classics is to display: block a lot of the elements, meaning that all the data in a row (<tr>) ends up as a chunk of stacked content together that stands less of a chance of breaking the parent element’s width. You can get all the data labels properly with pseudo-elements. But, this only makes sense when individual rows of content make perfect sense alone. That’s not the case with every table. A table’s purpose might be cross-referencing data, and in that case, you’ve ruined that with this approach. So again, there are nice approaches for responsive tables when you know exactly the content and purpose of the table. But the best responsive solution when you don’t know is to just make sure they are swipeable.

Direct Link to Article — Permalink

The post Under-Engineered Responsive Tables appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Posted on

What’s Missing from CSS?

Featured Imgs 23

The survey results from the State of CSS aren’t out yet, but they made this landing page that randomly shows you what one person wrote to answer that question. Just clicking the reload button a bunch, I get the sense that the top answers are:

  • Container Queries
  • Parent Selectors
  • Nesting
  • Something extremely odd that doesn’t really make sense and makes me wonder about people

Direct Link to Article — Permalink

The post What’s Missing from CSS? appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Posted on

Thinking Outside the Box with CSS Grid

Featured Imgs 23

Great tutorial from Alex Trost (based on some demos, like this one, from Andy Barefoot) showcasing how, while CSS grid has straight grid lines across and down, you can place items across grid lines creating a staggered effect that looks pretty rad. Grid-like, but it appears to align to diagonal lines rather than horizontal and vertical lines because of the staggering. And you still get all the flexibility of grid!

Direct Link to Article — Permalink

The post Thinking Outside the Box with CSS Grid appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.