Tag: someone

What should someone learn about CSS if they last boned up during CSS3?

“CSS3” was a massive success for CSS. A whole bunch of stuff dropped essentially at once that was all very terrific to get our hands on in CSS. Gradients, animation/transition, border-radius, box-shadow, transformwoot! And better, the banner name CSS3 (and the spiritual umbrella “HTML5”) took off and the industry was just saturated in learning material about it all. Just look at all the “CSS3”-dubbed material that’s been published around here at CSS-Tricks over the years.

No doubt loads of people boned up on these technologies during that time. I also think there is no doubt there are lots of people that haven’t learned much CSS since then.

So what would we tell them?

Some other folks have speculated similarly. Scott Vandehey in “Modern CSS in a Nutshell” wrote about his friend who hasn’t kept up with CSS since about 2015 and doesn’t really know what to learn. I’ll attempt to paraphrase Scott’s list and what’s changed since the days of CSS3.

Preprocessors are still widely used since the day of CSS3, but the reasons to use them have dwindled, so maybe don’t even bother. This includes more newfangled approaches like polyfilling future features. This also includes Autoprefixer. CSS-in-JS is common, but only on projects where the entire workflow is already in JavaScript. You’ll know when you’re on a relevant project and can learn the syntax then if you need to. You should learn Custom Properties, Flexbox, and Grid for sure.

Sounds about right to me. But allow me to make my own list of post-CSS3 goodies that expands upon that list a smidge.

What’s new since CSS3?

And by “CSS3” let’s say 2015 or so.


.card {   display: grid;   grid-template-columns:     150px 1fr;   gap: 1rem; } .card .nav {   display: flex;   gap: 0.5rem; }

Layout

You really gotta learn Flexbox and Grid if you haven’t — they are really cornerstones of CSS development these days. Even more so than any feature we got in CSS3.

Grid is extra powerful when you factor in subgrid and masonry, neither of which is reliable cross-browser yet but probably will be before too long.

html {   --bgColor: #70f1d9;      --font-size-base:      clamp(1.833rem, 2vw + 1rem, 3rem);   --font-size-lrg:     clamp(1.375rem, 2vw + 1rem, 2.25rem); }  html.dark {   --bgColor: #2d283e; } 

CSS Custom Properties

Custom properties are also a big deal for several reasons. They can be your home for design tokens on your project, making a project easier to maintain and keep consistent. Color theming is a big use case, like dark mode.

You can go so far as designing entire sites using mostly custom properties. And along those lines, you can’t ignore Tailwind these days. The approach of styling an entire site with classes in HTML strikes the right chord with a lot of people (and the wrong chord with a lot of people, so no worries if it doesn’t jive with you).

@media    (prefers-reduced-motion: reduce) {   * {     animation-duration: 0.001s !important;   } }  @media    (prefers-color-scheme: dark) {   :root {     --bg: #222;   } } 

Preference Queries

Preference queries are generally @media queries like we’ve been using to respond to different browsers sizes for year, but now include ways to detect specific user preferences at the OS level. Two examples are prefers-reduced-motion and prefers-color-scheme. These allow us to build interfaces that more closely respect a user’s ideal experience. Read Una’s post.

.block {   background:      hsl(0 33% 53% / 0.5);    background:     rgb(255 0 0);    background:     /* can display colors         no other format can */     color(display-p3 0.9176 0.2003 0.1386)    background:     lab(52.2345% 40.1645 59.9971 / .5);}    background:     hwb(194 0% 0% / .5); }

Color Changes

The color syntax is moving to functions that accept alpha (transparency) without having the change the function name. For example, if you wanted pure blue in the CSS3 days, you might do rgb(0, 0, 255). Today, however, you can do it no-comma style (both work): rgb(0 0 255), and then add alpha without using a different function: rgb(0 0 255 / 0.5). Same exact situation for hsl(). Just a small nicety, and how future color functions will only work.

Speaking of future color syntaxes:

body {  font-family: 'Recursive', sans-serif;  font-weight: 950;  font-variation-settings: 'MONO' 1, 'CASL' 1; }

Variable Fonts

Web fonts became a big thing in CSS3. Now there are variable fonts. You might as well know they exist. They both unlock some cool design possibilities and can sometimes be good for performance (like no longer needing to load different font files for bold and italic versions of the same font, for example). There is a such thing as color fonts too, but I’d say they haven’t seen much popularity on the web, despite the support.

.cut-out {   clip-path: polygon(25% 0%, 75% 0%, 100% 50%, 75% 100%, 25% 100%, 0% 50%); }
.mask {   mask: url(mask.png) right bottom / 100px repeat-y; }
.move-me {   offset-path: path('M 5 5 m -4, 0 a 4,4 0 1,0 8,0 a 4,4 0 1,0 -8,0');   animation: move 3s linear infinite; }  @keyframes move {   100% {      offset-distance: 100%;   } }

Paths

SVG has also exploded since CSS3. You can straight up crop any element into shapes via clip-path, bringing SVG-like qualities to CSS. Not only that, but you can animate elements along paths, float elements along paths, and even update the paths of SVG elements.

These all feel kind of spirtually connected to me:

  • clip-path — allows us to literally crop elements into shapes.
  • masks — similar to clipping, but a mask can have other qualities like being based on the alpha channel of the mask.
  • offset-path — provides a path that an element can be placed on, generally for the purpose of animating it along that path.
  • shape-outside — provides a path on a floated element that other elements wrap around.
  • d — an SVG’s d attribute on a <path> can be updated via CSS.

.disable {   filter:      blur(1px)     grayscale(1); }  .site-header {   backdrop-filter:      blur(10px); }  .styled-quote {   mix-blend-mode:      exclusion; } 

CSS Filters

There is a lot of image manipulation (not to mention other DOM elements) that is possible these days directly in CSS. There is quite literally filter, but its got friends and they all have different uses.

These all feel kind of spirtually connected to me:

  • filter — all sorts of useful Photoshop-like effects like brightness, contrast, grayscale, sautration, etc. Blurring is a really unique power.
  • background-blend-mode — again, evocative of Photoshop in how you can blend layers. Multiply the layers to darken and combine. Overlay to mix the background and color. Lighten and darken are classic effects that have real utility in web design, and you never know when a more esoteric lighting effect will create a cool look.
  • backdrop-filter — the same abilities you have with filter, but they only apply to the background and not the entire element. Blurring just the background is a particularly useful effect.
  • mix-blend-mode — the same abilities you have with background-blend-mode, but for the entire element rather than bring limited to backgrounds.

import "https://unpkg.com/extra.css/confetti.js";
body {   background: paint(extra-confetti);   height: 100vh;   margin: 0; }

Houdini

Houdini is really a collection of technologies that are all essentially based around extending CSS with JavaScript, or at least at the intersection of CSS and JavaScript.

  • Paint API — returns an image that is built from <canvas> APIs and can be controlled through custom properties.
  • Properties & Values API / Typed OM — gives types to values (e.g. 10px) that would have otherwise been strings.
  • Layout API — create your own display properties.
  • Animation API

Combined, these make for some really awesome demos, though browser support is scattered. Part of the magic of Houdini is that it ships as Worklets that are pretty easy to import and use, so it has the potential to modularize powerful functionality while making it trivially easy to use.

my-component {   --bg: lightgreen; }  :host(.dark) {    background: black;  }  my-component:part(foo) {   border-bottom: 2px solid black; }

Shadow DOM

The Shadow DOM comes up a bit if you’ve played with <svg> and the <use> element. The “cloned” element that comes through has a shadow DOM that has limitations on how you can select “through” it. Then, when you get into <web-components>, it’s the same ball of wax.

If you find yourself needing to style web components, know there are essentially four options from the “outside.” And you might be interested in knowing about native CSS modules and constructible stylesheets.

The CSS Working Group

It’s notable that the CSS working group has its own way of drawing lines in the sand year-to-year, noting where certain specs are at a given point in time:

These are pretty dense though. Sure, they’re great references and document things where we can see what’s changed since CSS3. But no way I’d send a casual front-end developer to these to choose what to learn.

Yeah — but what’s coming?

I’d say probably don’t worry about it. 😉

The point of this is catching up to useful things to know now since the CSS3 era. But if you’re curious about what the future of CSS holds in store…

  • Container queries will be a huge deal. You’ll be able to make styling choices based on the size of a container element rather than the browser size alone. And it’s polyfillable today.
  • Container units will be useful for sizing things based on the size of a container element.
  • Independant transforms, e.g. scale: 1.2;, will feel more logical to use than always having to use transform.
  • Nesting is a feature that all CSS preprocessor have had forever and that developers clearly like using, particularly for media queries. It’s likely we’ll get it in native CSS soon.
  • Scoping will be a way to tell a block of CSS to only apply to a certain area (the same way CSS-in-JS libraries do), and helps with the tricky concept of proximity.
  • Cascade layers open up an entirely new concept of what styles “win” on elements. Styles on higher layers will beat styles on lower layers, regardless of specificity.
  • Viewport units will greatly improve with the introduction of “relative” viewport lengths. The super useful ones will be dvh and dvw, as they factor in the actual usable space in a browser window, preventing terrible issues like the browser UI overlapping a site’s UI.

Bramus Van Damme has a pretty good article covering these things and more in his “CSS in 2022” roundup. It looks like 2022 should be a real banner year for CSS. Perhaps more of a banner year than the CSS3 of 2015.


What should someone learn about CSS if they last boned up during CSS3? originally published on CSS-Tricks. You should get the newsletter and become a supporter.

CSS-Tricks

, , , , , , , ,

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.

Conclusion

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.

CSS-Tricks

, , , , ,
[Top]

What makes someone a good front-end developer?

We recently covered this exact same thing, but from the perspective of a bunch of developers.

Chris Ferdinandi weighs in:

The least important skills for a front-end developer to have are technical ones.

The nuances of JavaScript. How to use a particular library, framework, or build tool. How the cascade in CSS works. Semantic HTML. Fizz-buzz.

Chris takes that a little farther than I would. I do think that with an understanding of HTML, CSS, and JavaScript, the deeper the better, and that it is an ingredient in making a good front-end developer. But I also agree it’s much more than that. In fact, with solid foundational skills and really good soft skills (e.g. you’re great at facilitating a brainstorming meeting), you could and should get a job before they even look at your language skills.

Direct Link to ArticlePermalink

The post What makes someone a good front-end developer? appeared first on CSS-Tricks.

CSS-Tricks

, , , ,
[Top]