I’ve been enjoying these little “You want…” style posts. Post titles like that are a little more… forceful for my normal taste, but I like the spirit of sharing a best practice that perhaps isn’t well-known-enough.
Why? In the former, the minimum width of the grid column is min-content, which can be awkwardly wider than you want it to be (see: grid blowouts). In the latter, you’ve reduced the minimum to 10px (not zero, so it doesn’t disappear on you and lead to more confusion).
While it’s slightly unfortunate this is necessary, doing it leads to more predictable behavior and prevents headaches.
A friend of mine recently asked me to teach her to code. She was an absolute beginner, having no idea what coding really involves. I decided to start where I started: HTML and CSS. Using CodePen, we started forking Pens and altering them. Soon, a learning path started to unravel.
The aim of this article is not to teach basic CSS to those who already know it but rather to highlight the things that inspired a newcomer and hopefully inspire you to pass on some knowledge to others if the opportunity arises. It felt good to help someone out and, in turn, I learned some really valuable lessons that have changed the way I think about my code. Win win!
So, here we go: five lessons I learned from teaching someone CSS.
Lesson 1: Don’t start from scratch
When I starting coding for the web 12 years ago, I began with layout — positioning with floats, margins, padding and position declarations. It might seem outdated these days, but still, this is where I went right away with my new coding buddy.
It didn’t go that well.
As you might guess, starting with something like, “Here is how to position an empty box in the middle of the screen,” was a mistake. How uninspiring! And even though I was impressed with my own ability to demonstrate how Flexbox can position an element in the center of the screen (more on that later), I was immediately faced with lots of additional, non-positional questions.
Within minutes, my friend was hooked! There was no boring positioning to worry about, just a clear example of how a few simple lines of code can change something so familiar into something entirely different.
Then it kicked in that you can change the color of anything! We loaded up a couple of well known sites in the browser and changed the colors of some text and backgrounds with DevTools, all in a couple of minutes. Mission accomplished! My friend was hooked.
Lesson learned: Don’t worry about trying to build something from scratch. Have a play with what’s already out there!
Lesson 2: Comments
This isn’t where I had planned to go with my planned class, but the question of why some parts of CSS start with /* and end with */ came up, so we went with it.
This one really had me thinking about my own work. I really do not comment my code enough. Watching a new coder comment everything (and I mean everything) reminded me just how helpful comments are, not only for yourself, but also to a wider team, or even future you. (Sarah Drasner has a great talk on this topic).
Lesson learned: Comment more.
Lesson 3: Positioning
We started with some basic HTML, and honestly, I saw my friend’s eyes glazing over almost immediately. It just looks so dull when you can’t see it doing anything right away (unlike editing pre-written CSS). However, we stuck with it, and got results.
Take my word for it, don’t start by positioning empty <div> elements with 1-pixel borders around them. You’ll lose your audience very quickly. Put a picture of a dog in there — or baby Yoda or a pizza — just as long as it’s anything other than an empty element.
We then turned to Flexbox. We actually found CSS Grid a bit too much at the start. We looked briefly at CSS Grid, but when reading lots of articles about it, it’s clear that many assume the reader already has familiarity with CSS, Flexbox in particular. My friend decided to start with Flexbox.
An admission on my part: I am so used to using UI frameworks (especially Bootstrap) that I very rarely position anything in Flexbox by writing the CSS myself. I know how it works and (most of) the declarations, but I still very rarely write it out myself, even in situations where it would be relatively easy. Teaching made me think about my reliance on UI frameworks as a whole. Yes, they are undoubtedly amazing and save us tons of time on projects, but I recalled using Bootstrap on a recent project that was essentially two pages and probably didn’t need it!
Lesson learned: If the project is something small with a minimal number of elements to position, then consider ditching the framework and code from scratch! The end result will be lightweight, fast, and way more satisfying!
Lesson 4: Typography
I love typography. I’ve been lucky enough to work with great designers over the past few years and that has really helped me dial in on the nuances of type. It’s amazing how changes to things like line-height and letter-spacing can really help lift a design from average to amazing. This was something I was keen to impress upon my eager new student. Well, I needn’t have bothered, as the only thing of interest (initially) was changing the fonts and then, crucially for me, the sheer number of fonts available for us to use. The choices are almost limitless and the services and foundries offering web fonts have exploded in the past few years to a point where anything is possible, at speed with little impact on load times.
But here is the thing about designers (and front-end developers like myself): we can be a bit narrow-minded in our font choices. Designs tend to stick to the same fonts from the same services (Roboto and Open Sans anyone?) because we know they are easy to implement and that they work. Exploring fonts with someone new to the trade forced me to look beyond the old staples and try a few new things. I’m now looking for new pairings that work together and dialing in on how they work on screen and impact the whole look and feel of a design. In short, teaching someone else about type has improved my own journey with type, which was probably stuck in something like 2017.
Lesson learned: Keep up to date with type.
Lesson 5. :hover makes everything fun
Things were going OK up to this point, but as you can probably imagine, things were still pretty static. Without really planning, we stumbling into adding a hover effect on on an element and it was an instant hook, just like it was changing colors for the first time!
Hovers add interaction and easily impress, which makes them great for a newcomer to play around with. Scaling objects, changing a box from square to round, hiding content — these are the types of thing that can all be done so easily that hovers are an ideal way for a new coder to get instant results. And here’s the thing: “‘playing” around like this opens other doors. “What if I just do this?” is something many us rarely get to ask ourselves in our day-to-day jobs. With defined designs to work from, there is often little chance to play and equally less chance to experiment.
So, here is the final lesson: Make time to play. Just by being asked, “How do you make this thing do that?” has forced me to learn new things, see what’s new in CSS, and see what I can take back into my day-to-day work. Experimenting (or better yet, playing) has made me a better designer, and I’ll be doing more.
Lesson learned: Make time to play.
If my time teaching CSS to a newbie has taught me anything, it’s that I rarely write code from scratch anymore. Code snippets and autocomplete save me hours, but it’s those same conveniences that let me forget about some really basic stuff. Stuff I should know. By teaching someone else, even if just for 15 minutes now and then, my coding has generally improved and my eyes are open to new ideas and techniques that I may not have otherwise considered.
And as for my friend? Well, she was so taken by CSS in our short time together that she is now doing an online course that includes HTML, which doesn’t seem so dull now that she knows what it is capable of doing!
On the Microsoft Edge team, we’re committed to an open web and helping to drive innovation forward, which is why we’ve kicked off a new initiative in collaboration with Google, Mozilla, Samsung Internet, Igalia and — most importantly — the web community, called The Web We Want.
The Web We Want is an open initiative for web developers and designers (or anyone who builds things for the web) to tell browser vendors what we should focus on building or fixing. The overarching question we’re asking is this: If you had a magic wand and could change anything about the web platform, what would it be? What are problems you’ve encountered with the web that you need to hack around or what tools need to be improved or built to help you do your job better? What’s something you think you should be able to do natively but can’t? These are just a few questions to get you thinking about submissions to the initiative.
Some of the submissions we’ve had so far span from specific feature requests to broader problems with the web platform:
This is just a snapshot of the feedback we’re getting. The whole list is available for you to browse.
Why should I submit to the Web We Want?
This is an opportunity to make your voice heard and help us determine where the future of the web platform is headed. Once you’ve submitted your problem or feature, we’ll determine if your want is something that browser vendors can tackle directly or if it’s something that needs more scoping and is suited for Web Standards discussions.
This is an opportunity for all of us to take a step back and reassess where the future of the web is heading and figure out where the gaps are that make building for the web difficult today.
How can I participate?
There are a few different ways you can participate and there are a few different components to the Web We Want. First, think about what you think browser vendors should go fix and submit your ideas at webwewant.fyi. And that could be all that you want to do, which is great! We want any and all feedback about the platform and we have folks from different browsers constantly watching what’s being submitted.
There’s a second, optional aspect to the Web We Want, which is a great way to get involved in the web community and dip your toes in the public speaking pool. We’ve been running the Web We Want as a community-focused panel session at conferences around the world.
If you submit and are attending one of the events we’ll be at, your submission could be picked to be presented in a 3-5 minute lightning pitch to a panel of judges during the session, like an episode of Shark Tank but for tech. The live sessions we run are a way to get feedback and opinions from industry experts like Rachel Andrew, Jen Simmons, Miriam Suzanne, and Marcy Sutton.
Even if you’re not attending one of the events in person, you can still participate! We want to be mindful that not everyone can attend conferences so if you your submission is selected and you indicate you’re not attending an event,you’ll have an opportunity to record your lightning talk ahead of time and we’ll include it in the live session.
The live session culminates with the judges deliberating and deciding on the most pressing “want” pitched during the session. We also have a community voting aspect that allows the event audience to rank what they think is the most pressing thing for browser vendors (or standards bodies) to work on. Even if you’re not attending an event, you can still vote for your favorite “wants” on the website as well as by sharing them on social media.
So far we’ve run sessions at An Event Apart DC, Smashing Conf, and View Source, and the community participation and panel discussion of wants has been fantastic. If you run a meetup or a conference and are interested in facilitating this session, reach out to Stephanie Stimac or Aaron Gustafson.
The Web We Want
We’re at a point in the web platform where browser vendors and standards bodies are eager to know what it is web developers and designers need in the platform. We need to know where to invest resources. Hop over to the Web We Want and let us know what you think the web platform needs so that we can shape the future of the web together.
In this week’s week roundup of browser news, a trick for loading images conditionally using the picture element, your chance to tell bowser vendors about the web you want, and the styles applied to inline SVG elements are, well, not scoped only to that SVG.
Let’s turn to the headlines…
Preventing image loads with the picture element
You can use the <picture> element to prevent an image from loading if a specific media query matches the user’s environment (e.g., if the viewport width is larger or smaller than a certain length value). [Try out the demo:
The Web We Want (webwewant.fyi) is a new collaboration between browser vendors that aims to collect feedback from web developers about the current state of the web. You can submit a feature request on the website (“What do you want?””) and get a chance to present it at an event (An Event Apart, Smashing Conference, etc.).
Firefox supports a non-standard Boolean parameter for the location.reload method that can be used to hard-reload the page (bypassing the browser’s HTTP cache) [via Wilson Page]
If you use inline <svg> elements that itself have inline CSS code (in <style> elements), be aware that those styles are not scoped to the SVG element but global, so they affect other SVG elements as well [via Sara Soueidan]
XSS Auditor, a Chrome feature that detects cross-site scripting vulnerabilities, has been deemed ineffective and will be removed from Chrome in a future version. You may still want to set the HTTP X-Xss-Protection: 1; mode=block header for legacy browsers [via Scott Helme]
Read more news in my new, weekly Sunday issue. Visit webplatform.news for more information.
Styling row and column gaps. I’ve also heard requested styling grid cells directly, rather than needing to place an element there and style that element.
Multiple gap values. I wanted this just the other week, and I was told to use an empty column or row instead of a gap. The size of that column can be controlled, and things are placed accordingly to treat it like a gap. Sort of OK, except that isn’t particularly friendly to implicit grids.
Autoflow patterns. This is clever. Check out Michelle’s use case and proposal.
calc() with the fr unit. This is a mindbender. I can see wanting to do something like calc(1fr - 100px), but then isn’t the leftover space 100px short and 1fr recalcuated to fill that space? Seems infinite loopy.
Aspect ratio grid cells. I suspect, if we get this, it’ll be a generic aspect ratio solution that will work on any element, including elements placed onto a grid.
Subgrid is also starting to be hotly requested, and I can see why. While building the last page layout I did using grid, I found myself strongly wishing I could share the overall page grid lines within sub-elements.
Rachel Andrew talked about its status about six months ago in CSS Grid Level 2: Here Comes Subgrid. I’m not sure where it’s at now, but I don’t think any browser is supporting it quite yet. (I’m not even sure if the spec is technically done.)
Brad put a point on the desire here:
Container queries and subgrid would make my design system work so much easier.
Define a grid and throw some components in there, then watch them snap into place to the parent grid and look great no matter what the container dimensions are.
If we combine subgrid with grid-template-areas within the cards (read my last post if you don’t know about Grid Areas, it’ll blow your mind), complex responsive card-based layouts become trivial.
The prospect of a subgrid on both axes gives us a way to sort of accomplish relative grid positioning, at least for semantically grouped items, like I wished I had above! Group your stuff in a container, position your container on the grid, make that container a subgrid on both axes, and declare your tracks relative to the subgrid element’s grid position!
Between Flexbox, Grid, display: contents, and subgrids, we will finally have everything we need to write very slim, clean, semantic markup with basically no fluff or purely structural elements. It will be a huge boon for accessibility, SEO, and just developers trying to understand your markup!
This is why I’ve come to the same conclusion other grid experts (like Rachel) already have: subgrids are a major component of grid layout, and should be a part of any grid layout implementation when it emerges from developer-preview status. If that means delaying the emergence of grids, I think it’s worth it.