Tag: Want

Exactly What You Want

What is one thing people can do to make their website better?

Exactly what you want to build!

Ask yourself:

  • What drew you to development in the beginning?
  • Is there an experimental API that you’ve been wanting to try out?
  • What could you spend all night hacking away at, just for the fun of it?

Your personal site is a statement of who you are and what you want to do. If you showcase your favorite type of work, you’ll get more requests for similar projects or jobs — feeding back into a virtuous cycle of doing more of what you love.

Like stage performances, you can tell when love and excitement went into creating a website. One of my favorite examples is Cassie Evans’ website. She added so many fun flourishes (including an adorable SVG self-portrait). The joy baked into her work has (at least partially) led to her current role, bestowing animation superpowers at GreenSock!

So, go forth, and create a trailing mouse cursor. Or a confetti component! A real-time drawing pad, or some hardware to show the current state of your coffee machine. Really, anything that gets you excited to build!



So, You Want to Build an @mention Autocomplete Feature?

We’re all familiar with the concept of autocompletion, right? You type something into a search box and it tries to guess what you’re looking for as you type, displaying suggestions, often below the cursor. While we’re used to autocomplete on eCommerce sites that redirect to search or product pages, an underrated usage is when used as a secondary search pattern to augment the typing experience.

In modern web applications, there’s no reason a composition box has to be a dull, plain text area, or limit itself to rich text formatting. Social and productivity apps like Twitter, Slack, Notion, Google Docs, and Asana have popularized the “@mention” pattern, allowing you to reference other users as you type. You can mention another person, a channel, a file, or some other queryable object using triggers, such as the @ or # characters. This opens a panel with suggestions, letting you complete your message with the right reference.

A Twitter-like compose box with a @mention feature on user names.

The text box acts as a search input, and the suggestions panel acts as a typing assistant, allowing users to reference the right resource without leaving their keyboard. When implemented correctly, everything is only a few keystroke away, including when users misspell something.

Along with powering a composition box, this pattern drives consistency in user-generated content. Hashtags are a good example: users are empowered to create semi-structured data in a free-form context, which then helps categorize content without needing to post-process it. Once users have mentioned other people in a document, referenced resources, or added several hashtags, you get a graph of connections across all the resources available on your app, making it a lot simpler to recommend related content and understand how users think.

The basics of building @mentions

Beyond letting users find what they want, a great @mention autocomplete feature should be as fluid as possible. The goal is to create a seamless typing experience where the pattern behaves as an assistant that learns as you type and helps you out, but knows when to get out of your way. You can keep typing, ignoring the suggestions and letting them go away, or you can leverage them to complete your message without friction.

On Twitter, which popularized the pattern with mentions and hashtags, the panel closes as soon as the word being typed is no longer considered a token, to avoid bugging users who want out. Twitter user handles don’t support spaces, so it closes the panel immediately after a space.

Twitter dismisses the @mention panel when hitting Space.

Slack works a bit differently, allowing spaces to let you search full names. It uses different heuristics to determine what signals that users want out.

Slack allows spaces to let users search in full names.

When selecting a suggestion, Twitter closes the panel, replaces the token, and adds a space so the user can keep typing seamlessly. This kind of attention to detail might seem insignificant in isolation, but when they add up, they give a sense of fluidity that empowers users to embrace the pattern instead of fighting it.

Twitter adds a space on select to let users keep on typing.

When you start adding mentions in a composition box like this, they become part of your text, but should also retain full interactivity to let users edit them.

On Twitter, for example, you can “focus” a mention by either clicking on it or navigating the text box with the Left and Right arrow keys. Twitter detects it and reopens the panel with the mentions as the search query. It ensures who is notified when the tweet is sent, and allows you to edit the mention in case of mistake.

Twitter lets you inspect and edit mentions.

One way to build such experiences with minimal effort is using the open-source Autocomplete library. Autocomplete is designed to integrate best with Algolia, but works with any source, static or remote. It lets you build multi-source dynamic and accessible autocomplete experiences, and works great for @mention features.

Mixing different types of suggestions

Having a symbol per result type works well when you have a few, distinct types, such as “@” for people, and “#” for hashtags. As soon as you have more types with blurrier limits, chances are good that users are unable to remember them all. Isolating them could make the experience more cumbersome.

Instead, assigning more than a single type per symbol with federated search (multi-source) helps discover all possible types without having to “learn” too many patterns.

On Slack, suggestions are mixed and differentiated with visual cues (such as different icons and badges). Still, the results look similar to how you experience them in the rest of the app. For example, people suggestions show the users’ avatar, display name, and status. This helps users feel more confident about who or what they mention.

On Slack, the “@” symbol searches for people, groups, and apps.

On Notion, suggestions are grouped by type. Unlike a typical search experience which favors per-result relevance, this approach favors consistency: until you refine the query, you always get dates first, then people, then links. This helps users build muscle memory as they use the tool, by setting expectations regarding where things are.

On Notion, the “@” symbol searches for dates, people, and links.

Grouping by type is achievable either by querying multiple sources at once, or using grouping mechanisms such as Autocomplete’s Reshape API, that transform results after retrieving them.

Another cool Notion pattern is the dynamic placeholder, or predictive suggestion, that they inject based on the active suggestion. By default, the placeholder helps users take action by hinting about what they can do. Then, as they browse, the placeholder updates, letting users know what to expect if they select a suggestion.

When users start typing, suggestions update in the panel, but the placeholder also adapts by pre-filling the input.
Users can apply a suggestion with Enter or Tab.

Peeking into Notion’s code, you can see how they leverage CSS Custom Properties to do this: every time you move through suggestions, they set the CSS variable --pseudoAfter--content on the input’s parent element with JavaScript. This CSS variable is then used with the content property on a ::before pseudo-element. Nifty!

When drawing results from multiple sources, it can become harder to control the number of results. That’s because each source might return the number of requested suggestions, or less, when it doesn’t have enough matches. This can result in a “jumpy” UI, where the number of results fluctuate as the user types.

You can mitigate this either with a fixed height panel containing a scrollbar, or by using combine and limit mechanisms like Autocomplete’s Reshape API.

There are always four results. The number of suggestions varies depending on the number of recent searches.

Thinking outside the search results

When you work on search and discovery every day like I do, you start seeing it everywhere. It’s fantastic how creative you can get with the @mention pattern when you go beyond how it is typically implemented.

If you’re using Slack, you might be used to looking for emojis by typing “:” then refining by name. While it doesn’t look like search or mentions, it uses the same exact mechanisms: you open a suggestions panel with a special character, search for the right item, and “apply” it on select.

On Slack, the “:” symbol searches for emojis.

This is even more striking on Notion, where the panel doesn’t look like search results at all.

Notion uses the “:” sign to let users search for emojis.

What’s interesting here is how versatile the pattern can be when changing simple things like item templates and styling results differently. It integrates even better in a composition box and creates a fluid experience that users recognize across all the apps they use.

A Slack-like compose box with a custom emoji autocomplete

Going beyond type completion

Mentions are the most common use case when using dynamic suggestions in a composition box, but you can go a lot further. While mentions help you “complete” a sentence and enhance the typing experience, a composition box can also be a conversational interface between the user and the app.

On Notion, typing the special character “/” gives you access to inserting actions. You still get to refine suggestions by typing further, but instead of filling the input, selecting a result creates a brand new block of a given type.

On Notion, the “/” symbol lets you create a brand new block of a given type.

This pattern, commonly known as “shortcuts” or “slash commands” was popularized in game chats and has become a standard in general purpose chat applications like Slack and Discord.

On Slack, the “/” symbol lets you type shortcuts to trigger custom actions
such as starting a Zoom call, leaving a channel, posting a GIF, etc.

Shortcuts are interesting because it lets users perform common tasks in one place, without having to look for the feature. For example, it’s common to do impromptu Zoom meetings with remote coworkers, and usually requires sending a Zoom link over Slack. But having to open Zoom, copy the link, then paste it into Slack is cumbersome. The “/zoom” shortcut removes those hurdles by centralizing common tasks in a single interface.

A Slack-like compose box with a command palette.

While features like slash commands used to be dedicated to power users, they’re now emerging in more and more apps and targeting all kinds of users.

Ultimately, augmenting the typing experience isn’t about unlocking “power features” but about uncovering content, as well as reducing friction and the cognitive load: instead of teaching users about the complexity of your system ahead of time, you’re bringing the right information at the right time, where and when users need it.

The post So, You Want to Build an @mention Autocomplete Feature? appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.


, , , ,

You want enabling CSS selectors, not disabling ones

I think this is good advice from Silvestar Bistrović:

An enabling selector is what I call a selector that does a job without disabling the particular rule.

The classic example is applying margin to everything, only to have to remove it from the final element because it adds space in a place you don’t want.

.card {   margin-bottom: 1rem; }  /* Wait but not on the last one!! */ .parent-of-cards :last-child {   margin-bottom: 0; }

You might also do…

/* "Disabling" rule */ .card:last-child {   margin-bottom: 0; }

But that’s maybe not as contextual as selecting from the parent.

Another variation is:

.card:not(:last-of-child) {   margin-bottom: 1rem; }

That’s what Silvestar refers to as “enabling” because you’re only ever applying this rule — not applying it and then removing it with another selector later. I agree that’s harder to understand and error-prone.

Yet another example is a scoped version of Lobotomized Owls:

/* Only space them out if they stack */ .card + .card {   margin-top: 1rem; }

I think gap is where this is all headed in the long term. Put the onus on the parent, not the child, and keep it an enabling selector:

.parent-of-cards {   display: grid;   gap: 1rem; }

Direct Link to ArticlePermalink

The post You want enabling CSS selectors, not disabling ones appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.


, , , ,

So you want to self-publish books and courses on programming

John Resig and I recently self-published our book on GraphQL. There are tons of how-tos for self-publishing a book, or even online classes, but very little in the way of why you would want to, or whether it’s even worth your while. I’m going to share my experience and revenue numbers with you in this post, as well as those from others who have self-published material. I’ll go specifically into the pros and cons of self-publishing books and courses in tech.


This is probably what you’re most curious about, right? When I originally started working on our book, I sent a book proposal to publishers. But by the time John and I joined forces, we were both set on self-publishing. He had written two popular JavaScript books and a blog post about traditional publishing for programming books, which includes:

  • Programmers aren’t that into reading books! Programming books, by and large, are poor sellers. They rarely sell more than 4,000 copies.
  • He made $ 7,500 on his first 4,000 copies, where his royalty rate started at 10% for print sales and 20% for digital copies.

On the topic of traditional publishing revenue, Randall Kanna says: “Nothing comes from a tech book. Just the credibility.” A book can make significantly more, but it’s rare. Martin Kleppmann’s book on machine learning was O’Reilly’s second most popular seller in 2019, and he made $ 478,000 in the first three years (with 108,000 copies sold, a 10% royalty on print sales, and a 25% royalty on digital sales).

The Pragmatic Bookshelf is the outlying publisher when it comes to royalties: it gives authors 50% of gross profit. In their first 10 years operating, 42% of their authors made more than $ 50,000, and 12% made more than $ 100,000.

That said, self-publishing has much higher royalty rates:

  • Amazon: 70% (for e-books; 60% minus printing cost for printed books)
  • Leanpub: 80%
  • Gumroad: 96.5% ($ 10 monthly membership fee)
  • Your own website: 97%

This gives authors the potential to make more money. Discover Meteor was probably the most successful self-published programming book of its time, with around $ 500,000 in sales (9,000 copies) between 2013 (when they launched) and 2018 (when they made it available for free). The authors Sacha Grief and Tom Coleman put a lot of effort into marketing it (described in their Gumroad case study), and it became the recommended learning resource in the Meteor community. The current best-selling book is Adam Wathan and Steve Schoger’s Refactoring UI, which I believe passed $ 2 million in 2020! 🤑 Their success was also largely due to their ability to market the book, in addition to addressing a significant need for a broad audience (practical user interface design for front-end developers).

That’s books. Looking at publishing video courses, there are a few options:

Like self-published books, self-published courses have a lot of potential. Level Up Tutorials, Kent C. Dodds, and Wes Bos don’t share revenue numbers for their courses, but I’m assuming they have made considerable sums. Wes, for example, has sold his courses to over 140,000 people at the time of writing!

Those are the outliers, of course. The majority of resources out there make significantly less. Take, for example, the self-published books in the GraphQL space that we were entering:

Title (Author) Sales Price Estimated Revenue
Production Ready GraphQL (Marc-André Giroux) 3,000 (this is a guess) $ 49–$ 79 $ 147,000–$ 237,000
The Road to GraphQL (Robin Wieruch) 2,250 $ 30–$ 80 $ 67,500–$ 180,000
The GraphQL Guide (John Resig and Loren Sands-Ramshaw) 1,000 $ 30–$ 279 $ 78,000 in sales; $ 68,000 in sponsorships
Advanced GraphQL with Apollo & React (Mandi Wise) 200 $ 30–$ 45 $ 10,000+
Fullstack GraphQL (Julian Mayorga) 100 $ 39 $ 3,000

So, yes, the potential is big. But it’s not a guarantee.

Self-publishing pros and cons

Pros Cons
Potential for more revenue. You get to set the price, sell different packages, and receive a larger cut. It’s much harder. A publisher does a ton of things for you: editing, gathering feedback from technical reviewers, the build toolchain, translating, an online store, getting it on Amazon and other bookstores, customer service, tracking errata, etc. Doing all of these things yourself takes a lot of time, especially if you also decide to build a Gatsby site to display the text online. 😜
Flexibility. You get to decide what goes into the book as well as how it’s formatted and sold. No built-in marketing or distribution. The success of your own book completely depends on your ability to market it. This is hard, as you can read in swyx’s notes on the topic. Books published traditionally usually sell more copies.
Updates. You have the email addresses of your readers, and can send them updated versions of the book. No print edition. While you can print on demand with some services, like Kindle Direct Publishing, most people don’t put in that effort.

These pros and cons are for books. If you’re wondering about a breakdown of pros and cons specifically for self-published courses, they’re very similar because they face the same opportunities and challenges.

Should I create a book or course?

This is the big question. And while I wish I could give you a definitive answer one way or the other, it’s always going to be the same answer we love to give in tech: it depends.

Why would you want to self-publish a book or course? Here are some reasons:

  • Income: It’s nice to put something out there and have it generate an income as long as it’s available.
  • Positive impact: Creating a digital asset has high potential leverage. For example, if something takes you X amount of resources to create, and you distribute it to a thousand people who each gain Y amount of utility from learning with it, you’ve produced 1000 * Y utility in the world, which can be much larger than X. For more on this, I recommend Kleppmann’s post on the topic.
  • Reputation: Having written a book can help you get a job, gain clients, or simply elevate your reputation. Eve Porcello says publishing boosted her credibility—and as an added benefit, many readers hire her to teach workshops.
  • Knowledge: If you’re like me, you’ll find that you learn much more about the topic you’re writing about than you knew when you started. I know I certainly did—I finally read the GraphQL spec, learned Vue and Android, ran into and solved a ton of bugs, and went through countless blog posts and conference talks. 😄
  • Enjoyment: Some people enjoy the creative process. I liked learning, building example applications, and writing. In other words, there’s a level of self-fulfillment you can get from the work.

Those are the reasons why you might want to self-publish material. But whether you should actually do it depends on:

  • Your writing ability: You absolutely need to be good at explaining complex concepts in simple terms that are easy for anyone to grasp. That’s a seriously high bar, especially if there’s existing good content on the topic.
  • Your willingness to market: You need to be willing to get the word out, because no one will do it for you (at least at first). That takes some guts. I know there are many of people out there who have a tough time promoting themselves and their work.
  • What it’s worth to you: You’ve seen a lot of the benefits that self-publishing content can offer, but are they worth it to you? Do impact, knowledge, and reputation motivate you? Maybe none of that matters and you’re simply looking for a labor of love. Whatever your motivation is, it’s important. Without it, you could lose steam and wind up with an unfinished project.
  • The opportunity cost: What else would you do with your time and energy if you didn’t self-publish? Is that thing more valuable to you? Is there anything you’d regret missing out on because of this?

For me, while writing a book had an opportunity cost of lower income (compared to doing more consulting work), I’ve made a positive impact, increased my knowledge on a subject I care about, gained reputation, and enjoyed the process. And it also feels great when someone goes out of their way to tell me they’re “blown away” and appreciate reading my book. 😃🤗✨

Thanks to Chris Coyier, Geoff Graham, Sacha Greif, Robin Wieruch, Mandi Wise, Sebastian Grebe, Julian Mayorga, and Rachel Lake for providing input for this article.

The post So you want to self-publish books and courses on programming appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.


, , , ,

You want margin-inline-start

David Bushell in ”Changing CSS for Good“:

I’m dropping “left“ and “right“ from my lexicon. The new CSS normal is all about Logical Properties and Values […] It can be as easy as replacing left/right with inline start/end. Top/bottom with block start/end. Normal inline flow, Flexbox, and Grid layouts reverse themselves automatically.

I figured it made sense as a “You want…” style post. Geoff has been documenting these properties nicely in the Almanac.

The post You want margin-inline-start appeared first on CSS-Tricks.

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



Want to Write a Hover Effect With Inline CSS? Use CSS Variables.

The other day I was working on a blog where each post has a custom color attached to it for a little dose of personality. The author gets to pick that color in the CMS when they’re writing the post. Just a super-light layer of art direction.

To make that color show up on the front end, I wrote the value right into an inline style attribute on the <article> element. My templates happened to be in Liquid, but this would look similar in other templating languages:

{% for post in posts %} <article style="background: {{post.custom_color}}">   <h1>{{post.title}}</h1>   {{content}} </article> {% endfor %}

No problem there. But then I thought, “Wouldn’t it be nice if the custom color only showed up when when hovering over the article card?” But you can’t write hover styles in a style attribute, right?

My first idea was to leave the style attribute in place and write CSS like this:

article {   background: lightgray !important; } article:hover {   /* Doesn't work! */   background: inherit; }

I can override the inline style by using !important, but there’s no way to undo that on hover.

Eventually, I decided I could use a style attribute to get the color value from the CMS, but instead of applying it right away, store it as a CSS variable:

<article style="--custom_color: {{post.custom_color}}">   <h1>{{post.title}}</h1>   {{content}} </article>

Then, that variable can be used to define the hover style in regular CSS:

article {   background: lightgray; } article:hover {   /* Works! */   background: var(--custom_color); }

Now that the color value is saved as a CSS variable, there are all kinds of other things we can do with it. For instance, we could make all links in the post appear in the custom color:

article a {   color: var(--custom_color); }

And because the variable is scoped to the <article> element, it won’t affect anything else on the page. We can even display multiple posts on the same page where each one renders in its own custom color.

Browser support for CSS variables is pretty deep, with the exception of Internet Explorer. Anyway, just a neat little trick that might come in handy if you find yourself working with light art direction in a CMS, as well as a reminder of just how awesome CSS variables can be.

The post Want to Write a Hover Effect With Inline CSS? Use CSS Variables. appeared first on CSS-Tricks.

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


, , , , ,

You want…

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.

Got an idea along these lines? You should blog it! Here or elsewhere.

The post You want… appeared first on CSS-Tricks.

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



You want minmax(10px, 1fr) not 1fr

There are a lot of grids on the web like this:

.grid {   display: grid;   grid-template-columns: repeat(3, 1fr); }

My message is that what they really should be is:

.grid {   display: grid;   grid-template-columns: repeat(3, minmax(10px, 1fr)); }

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.

That’s it. That’s my whole message.

(Blog post format kiped from Kilian’s “You want overflow: auto, not overflow: scroll” which is also true.)

The post You want minmax(10px, 1fr) not 1fr appeared first on CSS-Tricks.

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



Want to get better at code? Teach someone CSS.

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.

“So how do you change the colors?”

“Can it change shape when hovered over?”

“What fonts can you use on the web?”

I thought we were weeks away from all that.

So, my plans of teaching the 12-column grid went out the window and we pulled up Chris’ named color chart alongside a couple of forked Pens and started playing around. First off, we changed the colors of Cassidy Williams Netflix/Netlify logo. Wow! Instant hit.

<a class="container" href="https://netlify.com" target="_blank">    <div class="logo">     <div class="uno"></div>     <div class="dos"></div>     <div class="tres"></div>   </div>   <div class="name">Prettier</div> </a>

Then a few simple tweaks to the CSS:

body {   background: #F9F2DB;   color: #092935;   font-size: 50px; } 
 a {   color: #092935; } 
 .logo .uno, .dos, .tres {   background: #C61561; }  .logo .dos {   box-shadow: 0 0 20px #F9F2DB; }  .logo::before {   background: #F9F2DB; } 
 .name {   letter-spacing: 8px; }

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).

And here is the thing: until then, I thought I was commenting pretty diligently. However, watching someone else do it made me realize how many times I look at a piece of code (particularly JavaScript) and wish I had put a line or two in there to remind myself what I was doing. A ten-second task might have saved me five (or perhaps even more) minutes down the road. That adds up and is now something I am working on.

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!

The post Want to get better at code? Teach someone CSS. appeared first on CSS-Tricks.

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


, , , , ,

Building the Web We Want

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 AndrewJen SimmonsMiriam 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. 

The post Building the Web We Want appeared first on CSS-Tricks.