Search the Community

I was asked if we could make a button with cut corners, and it seemed like a fun challenge, and this is my solution! It involves a lot of custom properties and the setup is a little complex, but the custom properties make it easy to make changes down the line!

Custom properties are amazing, but sometimes you go to overwrite one and it doesn't work as you'd expect it to. It happens for a good reason, even though it feels like it should work! So in this video, I look at what the problem is, why it happens, and how to get around it.

Styling responsive navigation menus for end users is hardly ever an easy process. Frontend developers have to consider certain parameters — like device breakpoints and accessibility — to create a pleasant navigation experience. It can get more challenging in frontend frameworks like React, where CSS-in-JS tends to get tricky. In this post, you will learn how to create a responsive navbar with CSS and React Hooks. You can fiddle with the source code and view the live project here. Creating the project Understanding the navigation layout Styling the navbar component Responsiveness with media queries Toggling the navbar view with useState Prerequisites To follow along with this tutorial, you’ll need: Basic understanding of React and React Hooks Some CSS knowledge — particularly Flexbox Now, let’s set up a new React application! Creating the project To bootstrap a new React project in CodeSandbox, open a new browser tab and type in react.new. This will create a starter React application: // App.js import "./styles.css"; export default function App() { return ( <div className="App"> <h1>Hello CodeSandbox</h1> <h2>Start editing to see some magic happen!</h2> </div> ); } Currently, the default stylesheet for your app is located at the root, in styles.css. Let’s edit this file to give our own feel to the page layout: // styles.css @import url("https://fonts.googleapis.com/css2?family=Karla:wght@200;400&display=swap"); * { box-sizing: border-box; margin: 0; padding: 0; } body { font-family: "Karla", -apple-system, BlinkMacSystemFont, "Segoe UI", "Roboto", "Oxygen", "Ubuntu", "Cantarell", "Fira Sans", "Droid Sans", "Helvetica Neue", sans-serif; -webkit-font-smoothing: antialiased; -moz-osx-font-smoothing: grayscale; } .container { max-width: 90%; margin-right: auto; margin-left: auto; padding: 1rem; } article h1 { margin: 1rem 0; } The rules above sets Karla as the primary font of the document and includes a container class for padding and aligning content on the page. With that done, let’s write some markup in App.js to display content: // App.js import Navbar from "./components/Navbar"; import "./styles.css"; function App() { return ( <div> <Navbar /> <div className="container"> <article> <h1>What is Lorem Ipsum? </h1> Lorem Ipsum is simply dummy text of the printing and typesetting industry... </article> </div> </div> ); } export default App; Notice the Navbar component import on the second line. I’ve created the Navbar.js file through CodeSandbox’s sidebar in the following file path: src/components/Navbar.js. The content of this file, so far, is the component’s default export statement, allowing you to import it into App.js: // Navbar.js export default function Navbar() { return ( <nav>Navigation</nav> ) } Understanding the navigation layout Our goal is to create a responsive navbar that initially displays the nav menu — ul element — in a horizontal layout. On reaching a mobile viewport, the menu repositions under the navbar and spans the remaining height and width of the screen. This layout will be achieved through a conflation of both Flexbox and CSS positioning rules. Write the markup from the subsequent code block into Navbar.js: // Navbar.js export default function Navbar() { return ( <nav className="navigation"> <a href="/" className="brand-name"> MacroSoft </a> <button className="hamburger"> {/* icon from heroicons.com */} <svg xmlns="http://www.w3.org/2000/svg" className="h-5 w-5" viewBox="0 0 20 20" fill="white" > <path fillRule="evenodd" d="M3 5a1 1 0 011-1h12a1 1 0 110 2H4a1 1 0 01-1-1zM3 10a1 1 0 011-1h12a1 1 0 110 2H4a1 1 0 01-1-1zM9 15a1 1 0 011-1h6a1 1 0 110 2h-6a1 1 0 01-1-1z" clipRule="evenodd" /> </svg> </button> <div className="navigation-menu"> <ul> <li> <a href="/home">Home</a> </li> <li> <a href="/about">About</a> </li> <li> <a href="/contact">Contact</a> </li> </ul> </div> </nav> ); } The markup above includes the brand-name, hamburger icon, and the navigation-menu, which are the three elements of our navbar. Now let’s proceed to style this component. Styling the navbar component Create the stylesheet for the navbar component in the following file path: src/styles/navbar.css And import it into Navbar.js: // Navbar.js import "../styles/navbar.css" export default function Navbar() { return( {/* navbar markup */} ) } We’ll begin with the navigation class: // navbar.css .navigation { height: 60px; width: 100%; display: flex; align-items: center; position: relative; padding: 0.5rem 0rem; background-color: #fff; color: black; box-shadow: 0 2px 2px 2px rgba(9, 9, 9, 0.23); } In here, we’ve set the navbar’s width to 100% so that it spans the full width of the device. By making this element a flex container and assigning a specific height property to it, Flexbox lets us use the align-items property to center the flex items vertically. Also, setting position to relative on this element ensures that the position value of any child element is determined relative to it. You’ll see this in effect momentarily. Let’s style brand-name and navigation-menu: // navbar.css .brand-name { text-decoration: none; color: black; font-size: 1.3rem; margin-left: 1rem; } .navigation-menu { margin-left: auto; } The major rule in the code block above is margin-left: auto rule applied to navigation-menu. This pushes the menu to the far right by taking up the available space to the left of it. Now we can style child elements of navigation-menu: // navbar.css .navigation-menu ul { display: flex; padding: 0; } .navigation-menu li { // removes default disc bullet for li tags and applies margin to left & right side list-style-type: none; margin: 0 1rem; } .navigation-menu li a { // increases the surface area of the anchor tag to span more than just the anchor text text-decoration: none; display: block; width: 100%; } display: flex on the ul element turns it into a flex container. The child li elements are then arranged in a row, which is the default value of the flex-direction property. The other rules serve to make the navigation links look better. Let’s go on to style the menu icon with the hamburger class: // navbar.css .hamburger { // removes default border on button element border: 0; height: 40px; width: 40px; padding: 0.5rem; border-radius: 50%; background-color: #283b8b; cursor: pointer; transition: background-color 0.2s ease-in-out; // positions the icon to the right and center aligns it vertically position: absolute; top: 50%; right: 25px; transform: translateY(-50%); display: none; } .hamburger:hover { background-color: #2642af; } Here, we’ve used CSS positioning to position the menu icon on the right side of the navbar. Remember the parent nav element has position set to relative. Therefore, with the position property of the icon set to absolute, we can center the icon vertically along the borders of the parent element using the top and transform properties. Read more on CSS positioning if you’re curious how this works. Since we want the menu icon to stay hidden until a mobile viewport is reached, let’s set its display property to none and proceed to style the mobile layout with CSS media queries. Responsiveness with media queries Media queries are a CSS feature that lets you specify how your content layout will respond to different conditions — such as a change in viewport width. Queries are written using the @media rule, followed by the target media type and the breakpoint at which to apply the styles: @media screen and (max-width: 768px) { // rules go here } Here, max-width: 768px ensures the styles are implemented only when the device width is at 768px or lower. Let’s now display the hamburger icon: // navbar.css @media screen and (max-width: 768px) { .hamburger { display: block; } } And hide the ul element in navigation-menu: // navbar.css @media screen and (max-width: 768px) { .navigation-menu ul { display: none; } } Your mobile layout should look like this so far: Generally, a navbar has two possible views: expanded and hidden. You can implement this into your application by having separate classes control these two navbar views. We’ll start by styling the expanded version of the menu. Subsequently, you will see how to toggle between these two views with Hooks: // navbar.css @media screen and (max-width: 768px) { .navigation-menu ul { // navigation menu is positioned to start 60px from the top of the document (which is directly below the navbar) position: absolute; top: 60px; left: 0; // stacks the li tags vertically flex-direction: column; // makes menu span full height and width width: 100%; height: calc(100vh - 77px); background-color: white; border-top: 1px solid black; } .navigation-menu li { // centers link text and strips off margin text-align: center; margin: 0; } .navigation-menu li a { color: black; // increases the surface area of the anchor tag to span the full width of the menu width: 100%; padding: 1.5rem 0; } .navigation-menu li:hover { background-color: #eee; } } Above, we’ve positioned the navbar 60px from the top of the document — directly below the navbar. To determine the height of this element, I’ve made use of the CSS calc function, and I’ll explain why. Ideally, we want the menu to span the full height of the document by using the viewport height unit vh. But because viewport units take all elements on the page into consideration, the 60px navbar contributes to the overall height of the page, causing the navigation menu to take its extra viewport units from the bottom of the screen, thereby producing a vertical scrollbar. The calc function helps us counter this by allowing us to perform calculations when specifying CSS property values. Therefore, subtracting 60px from 100vh produces the accurate height for the navigation menu. The preceding styles should result in the layout below (the yellow area marks the end of the document): However, because we want another class to control the display of the navigation menu, we’ll set its display to none: // navbar.css @media screen and (max-width: 768px) { .navigation-menu ul { /* previous styles */ dipslay: none; } } And create an expanded class, attached to navigation-menu, that sets the display property back to block: // navbar.css @media screen and (max-width: 768px) { .navigation-menu.expanded ul { display: block; } } At this stage, you can only observe the two states of the navbar by manually editing the markup in Navbar.js to include the expanded class. Unless your user is a devtools expert, you wouldn’t want to stop developing at this point. Let’s use the menu icon to toggle between the different navbar views using React’s useState Hook. Toggling the navbar view with useState In order to monitor the current state of the navigation menu, we’ll introduce state into the Navbar component. Create an isNavExpanded state and give it an initial value of false as such: // Navbar.js import { useState } from "react; import "../styles/navbar.css"; export default function Navbar(){ const [isNavExpanded, setIsNavExpanded] = useState(false) return ( <nav className="navigation"> <a href="/" className="brand-name"> MacroSoft </a> <button className="hamburger" > {/* hamburger svg code... */} </button> {/* nav menu code... */} </nav> ) } Now let’s use the onClick event handler on the button element to toggle the isNavExpanded state: // Navbar.js import { useState } from "react; import "../styles/navbar.css"; export default function Navbar(){ const [isNavExpanded, setIsNavExpanded] = useState(false) return ( <nav className="navigation"> <a href="/" className="brand-name"> MacroSoft </a> <button className="hamburger" onClick={() => { setIsNavExpanded(!isNavExpanded); }} > {/* hamburger svg code... */} </button> {/* nav menu code... */} </nav> ) } Here, we’ve called an anonymous arrow function within the onClick event handler. This function uses the updater function setIsNavExpanded to reverse the current value of the isNavExpanded state. This means isNavExpanded will toggle between true and false whenever the icon is clicked. You can now use the JavaScript ternary operator to conditionally pick the appropriate class name for the navigation menu based off isNavExpanded‘s value: // Navbar.js import { useState } from "react" import "../styles/navbar.css" export default function Navbar() { const [isNavExpanded, setIsNavExpanded] = useState(false) return ( <nav className="navigation"> <a href="/" className="brand-name"> MacroSoft </a> <button className="hamburger" onClick={() => { setIsNavExpanded(!isNavExpanded) }} > {/* hamburger svg code... */} </button> <div className={ isNavExpanded ? "navigation-menu expanded" : "navigation-menu" } > <ul> <li> <a href="/home">Home</a> </li> <li> <a href="/about">About</a> </li> <li> <a href="/contact">Contact</a> </li> </ul> </div> </nav> ); } And that’s a wrap! Now you should have a fully functional, responsive navbar. Conclusion Navigation menus serve an important role in the overall experience of your web application. It’s usually the first component your user comes in contact with when trying to figure out your app. Therefore, it’ll serve you well to make it as organized and accessible as possible because it boosts user experience and even SEO performance. The post Create a responsive navbar with React and CSS appeared first on LogRocket Blog.

Introducing Color Tokens — bringing Color Variables to your development projects Now, with Color Tokens, we’re bringing that same effortless consistency to your development projects.

Bootstrap is an open source CSS framework that takes a mobile-first approach for responsive site development. It focuses on simplifying the entire development process to reduce time spent writing plain CSS. Developers can take advantage of Boostrap’s many classes to access templates for buttons, typography, forms, images, and icons. Simply put, Bootstrap simplifies and removes much of the tedium from web development. Although Bootstrap is still the unrivaled king in the web development space, several alternatives have sprung up in recent years. Some of these newer frameworks are favored by developers who prioritize flexibility and speed. In this article, we’ll take a closer look at two popular Boostrap alternatives: Bulma and Tailwind CSS. We’ll consider how these two frameworks stack up, and how each attempts to address some of Bootstrap’s shortcomings. We’ll also discuss what developers find most compelling about each of these frameworks, and what types of projects might be best suited for Bulma or Tailwind. Bulma Bulma is a free, open source CSS framework built primarily with Sass and a Flexbox system. It offers modular columns for easy development and comes with an awesome predefined color palette to provide an ample number of design options. These colors can be used with Bulma’s rich classes for rapid UI development. Bulma is constantly updated with new features, keeping it relevant for the latest development trends. Refer to Bulma’s documentation to learn more about this framework. Bulma vs. Bootstrap: Pros Bulma provides a bit more flexibility for customization compared to Bootstrap. in addition, its modular structure provides more control over individual projects. Unlike Bootstrap, Bulma permits users to import only the modules required for desired features, omitting any that aren’t necessary. Bulma vs. Bootstrap: Cons Unlike Bootstrap, Bulma is CSS only. It doesn’t include inbuilt JavaScript or jQuery. Adding a basic feature in Bulma that requires the use of JavaScript or jQuery, such as a toggle, necessitates writing a custom script. Tailwind CSS Tailwind is an increasingly popular free, utility-first framework for user interface development. From its 2017 initial release as a side project, it rapidly gained popularity becoming the most widely used utility-first CSS framework for rapid development. Tailwind may be used to create highly customized, elegant user interfaces without writing custom CSS. This framework is well documented with new additions made each year. Tailwind CSS vs. Bootstrap: Pros Tailwind has a relatively small file size (about 27kb) compared to that of Bootstrap (close to 300kb). Additionally, the overall file size of a Tailwind project can be reduced even further using purgeCSS. This tool reduces file size by inspecting the file and removing any unused CSS classes. Smaller file size is advantageous as it generally translates to faster page load speed. Tailwind CSS vs. Bootstrap: Cons Although Tailwind alone does not contain predefined components, the Tailwind UI contains ready to use components built primarily with Tailwind. These components can be used for both simple HTML projects as well as in more complex React or Vue applications. Bulma vs. Tailwind CSS Other than the fact that both Bulma and Tailwind are open source CSS frameworks for easy web interface development, there aren’t many similarities between the two. They both aim to simplify UI development, but each takes a fundamentally different approach toward addressing this issue. Tailwind allows the developer to make significant decisions on how the interface should look. Meanwhile, Bulma makes most of those decisions for the developer, offering inbuilt modules to enable quick development. Tailwind CSS is a utility-first framework that does not provide pre-built components or UI kits. Instead, developers are provided with the necessary tools to build out all components and layouts from scratch. Bulma, on the other hand, comes with prefabricated components like other traditional CSS frameworks, including Bootstrap and MUI (formerly Material UI). Another way to think about this is that Bulma provides a ready to use template, while Tailwind provides all the tools needed for a developer to build their own template. What developers love about Bulma Developers who have a Bootstrap background generally find Bulma relatively easy to pick up as both follow a similar methodology. Both Bootstrap and Bulma function like rapid interface development UI kits. Bulma is also a great option for developers who have limited experience building user interfaces. With Bulma, it’s possible to get a UI up and running with just a couple of classes. This is something that’s not easily achieved with Tailwind. Building out even the most basic interface in Tailwind necessitates a detailed, careful study of the framework’s different classes. Bulma also offers a high level of flexibility, allowing for ease of customization on the part of the developer. This is in contrast to similar frameworks, like Bootstrap, that make customization fairly complex. This complexity is why most Bootstrap developers use the framework’s default template, and most Boostrap sites have a very similar look. What developers love about Tailwind CSS Most developers will agree that the ability to build out a UI without any constraint cannot be overemphasized. Unlike Bootstrap or Bulma, Tailwind does not impose design decisions on developers. This means that all UI components may be built from scratch. Another benefit is that, despite the complexity of Tailwind’s markup file layout, developers still find it relatively easy to debug and track styling errors. Scanning the Tailwind markup file and making any necessary changes made to reflect the developer’s intent is a straightforward process. Tailwind is ideal for projects with an already defined interface, layout, or design aesthetic. Developers can make important decisions about how each component should look with minimal constraints. Conclusion The Bulma vs. Tailwind debate is similar to the infamous React vs. Vue.js dust up. There is no obvious, clear winner. If you’re looking for a utility-first framework that permits building custom components from scratch, then you may wish to consider Tailwind. If you need to build a UI quickly and are looking for predefined components and interfaces, then you may wish to consider Bulma as your go-to framework. The post Bulma vs. Tailwind CSS: Which is the better Bootstrap alternative? appeared first on LogRocket Blog.

If you wish to make Web development a career or it is merely your hobby it can be overwhelming to decide where to begin. You can certainly… Continue reading on Medium »

CSS is short for “Cascading Style Sheets”. But what exactly is this cascade, and how does it work? Let this talk enlighten you.

Color is one of the first things you learn to apply as a web developer when learning CSS, but once you learn the basics, how often do you revisit it? With advanced techniques, applying colors with CSS can provide more functionality and depth to projects. In this post, we’ll explore all the common and more advanced ways of applying colors with CSS including some of the exciting methods that will hopefully be widely adopted within CSS soon. Basic color syntax in CSS We can’t talk about applying colors in CSS without covering the basics that everyone starts their journey in CSS with: keywords and HEX. Keywords Often the first way new developers learn to apply colors with CSS is using the predefined list of color keywords in CSS. These are a series of words that equate to color that apply to elements: .SomeElement { color: blue; background-color: black; } There’s a fair amount of predefined words you can use. If you’re interested in seeing them, you can check out this section on the MDN page on color. HEX values At a certain point in your CSS journey, it’s natural for a developer to outgrow the predefined words available in CSS and need something more powerful. Often, the next step on the CSS color journey is understanding hexadecimal values, also known as HEX values. HEX values are great because they are supported by every major browser and offer more flexibility and customizability than what’s offered by the standalone keywords. However, the one major downside to HEX values is that they are not easily readable or understandable. For example, could you guess what color #ff8c00 is? That’s right, it’s a bright orange color… Other than being difficult to understand, they can also be hard to work with. Without using a color picker or a guide of some sort, making HEX values darker or lighter is difficult without fully comprehending how the HEX numerical system works. And, even if you do have those aids, it’s not as simple or intuitive as just adjusting a single parameter. Here are some other examples of colors in HEX: .SomeElement { color: #ffffff; /* White */ background-color:#ff8c00; /* Orange-y color from before */ } Understanding RGB and HSL Now that we’ve covered the basics of defining color on the web, let’s take a look at two more advanced but more flexible and useable alternatives: RGB and HSL. RGB Red, green, and blue, or RGB, gives us access to the same colors as HEX but in a much more readable and user-friendly format. We define the color by using an rgb() function in CSS, which we will see in a moment when we look at some examples. By using the three parameters passed to the function, we can create colors; however, note that the colors are additive, meaning the more red, green, and blue we add, the lighter the overall color will be. If we set all three values as high as they go (to 255), then we will end up with white; if we set all three to 0, then we get black: background-color: rgb(255,255,255); /* White */ Working with RGB is a lot more logical than HEX while still providing the same colorspace to work within. Here are some examples showing HEX followed by the same RGB value to illustrate this: /* Dark Red */ #a60000; rgb(166,0,0); /* Light Blue */ #046cdb rgb(4, 108, 219); Although it may not be immediately clear what the RGB yields, it’s a lot more readable than HEX. RGB is a lot better than HEX when it comes to making small changes to a color. For example, if you wanted to add more red to a HEX color, would you know what to change and what to change it to? But, with RGB, you can just increment the red value by one or two to achieve this. HSL Although RGB is nice and a step in the right direction from HEX, it still has its pitfalls when it comes to the question, “Can you make this 30% darker for me?” Taking one of the RGB values from above, try to make one of those colors 30 percent darker without an aid. While you’ll probably do it faster than you would with HEX, it’s still far from ideal because RGB values don’t directly map to the lightness of the value. To make the color darker, you would need to experiment with all three values to achieve the desired outcome. But, this is where the wonderful hue, saturation, and lightness (HSL) comes in. As a developer, HSL is a dream because it provides a more logical method for handling colors and manipulating them because it uses parameters to adjust the color properties. However, there is a bit of a steeper learning curve when using HSL because, unlike RGB where we deal with colors we already know (red, blue, and green), HSL requires us to learn some color science like the hue and saturation of colors. Let’s now take a look at defining colors in HSL with its three main parameters to get a better understanding of how this color scheme works. The hue parameter represents the position on the color wheel, ranging from 0 to 360deg The saturation parameter represents how saturated a color is, ranging from 0 to 100% The lightness parameter represents how light a color is, ranging from 0 to 100% Note that if you set the lightness to 0, regardless of the other parameters, you get black, and if you set it to 100%, you get white. Below is a diagram that shows the HSL color space and how you can manipulate it using the three parameters outlined above. Here are the same colors that we defined previously with HEX and RGB, but now with their corresponding HSL values: /* Dark Red */ #a60000; rgb(166,0,0); hsl(0°, 100%, 33%); /* Light Blue */ #046cdb rgb(4, 108, 219); hsl(211°, 96%, 44%); Once you understand the color science behind HSL and can manipulate its three properties, using HSL becomes a lot more flexible than RGB. With HSL you can easily change the lightness of the color without online tools assistance. For example, imagine you have a button on a form that has a disabled state. With HSL, you can make the disabled state darker by simply decreasing the lightness parameter to achieve the effect. On the other hand, with RGB, you would need to either need to experiment with the values or use an online tool to help, neither being an efficient process. Using the alpha channel with HSL and RGB A final note to mention in regards to HSL and RGB is that you can now pass an optional fourth parameter to control the alpha channel; in layman’s terms, we’re controlling the transparency of the color. Here are some examples using that: hsl(211° 96% 44% / .5); /* 50% opacity */ hsl(0° 100% 33% / .25); /* 25% opacity */ rgb(166 0 0 / 0.7); /* 70% opacity */ rgb(4 108 219 / 0.3); /* 30% opacity */ The keen-eyed among you may also notice something different about the above syntax: that’s right, no commas. Thanks to CSS Color Module Level 4, you can now use spaces to separate values and pass an optional fourth parameter preceded with a / to control the alpha channel. Using advanced color spaces With the most common methods of defining colors in CSS covered, let’s take a look at some of the more experimental ways of defining color that is quite possibly the future of defining color in CSS. These are currently considered experimental because of their limited browser support at the time of writing this post. HWB Hue, whiteness, and blackness (HWB) is similar to HSL. The hue parameter can be set anywhere from 0 to 360deg, but, unlike HSL, we can control the saturation and the lightness by controlling the amount of white or black added into the original hue we selected. Try mixing HWB colors through the CodePen below. Note that HWB can only be seen in the Safari browser or the Firefox Developer browser: See the Pen HWB Color Playground by Coner Murphy (@conermurphy) on CodePen. But, why use HWB instead of something like HSL, which arguably provides more granular controls because it allows you to adjust the saturation of the color? Well, the reason HWB was designed was to be more intuitive for humans to use and faster to compute than other methods. With HWB, if you want a lighter color, add white; if you want a darker color, add black. It doesn’t get simpler than that. Here are our examples from before but with HWB added: /* Dark Red */ #a60000; rgb(166 0 0); hsl(0 100% 33%); hwb(0 0% 35%); /* Light Blue */ #046cdb rgb(4 108 219); hsl(211 96% 44%); hwb(211 2% 14%); LAB Both LAB and LCH (which we’ll come to in a moment), are defined as device-independent colors, meaning that no matter where you apply the color coordinates, you get the same color output. If you took a LAB value and applied it across different mediums, from a website, to digital art, to something physically printed, the color would remain the same. This uniformity is one of the key benefits of the LAB and LCH color spaces. To use LAB, there are three parameters you need to pass in: L, A, and B. The lightness (L) parameter, similar to others discussed in this article, accepts a percentage between 0 and 100 with 0% as black and 100% as white. However, different from the other methods we’ve covered, LAB uses the a-axis (A) and b-axis (B) parameters to define color. The a parameter represents how far along the a-axis in the LAB colorspace you want to go between green and red. Similarly, the b parameter represents how far along the b-axis in the LAB colorspace you want to go between blue and yellow. Conceptually, LAB is one of the harder color spaces to grasp since it moves through space rather than linear numbers. So, here is a visual representation of the colorspace to show how the values work together to create a color. Also, here is another pen to show the LAB colorspace in use, but can only be seen in a Safari browser. See the Pen LAB Color Playground by Coner Murphy (@conermurphy) on CodePen. Here are our examples from before but with LAB added: /* Dark Red */ #a60000; rgb(166 0 0); hsl(0 100% 33%); hwb(0 0% 35%); lab(34% 58 48); /* Light Blue */ #046cdb rgb(4 108 219); hsl(211 96% 44%); hwb(211 2% 14%); lab(46% 17 -63); If you are using Safari, you can view the LAB color rendered in the CodePen below. See the Pen CSS Colour Values by Coner Murphy (@conermurphy) on CodePen. LCH The final colorspace and method for defining color in CSS we will look at is lightness, chroma, and hue (LCH). Once again, similar to the other color functions that use a lightness value, the lightness parameter accepts a percentage between 0 and 100, with 0% as black and 100% as white. However, LCH introduces chroma, which indicates the amount of color we want to use; conceptually it is similar to saturation in HSL, but chroma is theoretically limitless. Before getting too excited, however, while chroma is theoretically limitless, there is, unfortunately, a limit on the colors our browsers and monitors can display. So, beyond a certain point (around 230), the value you choose is unlikely to make any noticeable difference to the user. And finally, as with HSL, the hue can be expressed from 0 to 360 with the value selected driven from the position on the color wheel. Why do we need advanced color spaces? At this point, you may be rightfully asking why do we need color spaces in CSS like LAB and LCH; what’s wrong with HSL? With the introduction of LAB and LCH, developers can now access the entire spectrum of colors humans can perceive, while HSL (or the others) cannot. The flipside to this however is the issues with syntax and support. The syntax for LAB and LCH are less intuitive and currently have very little browser support (Safari only), so you need to give a fallback value in another more widely supported method for the time being. But, once the syntax has more support in other browsers, both LAB and LCH are powerful options for specifying colors in CSS. As with LAB, LCH is also another tricky color space to grasp, so here is another diagram showing the LCH color space and how the parameters influence the color we get. Using the alpha channel in HWB, LAB, and LCH Finally, as with the other color function in CSS, hwb(), lab(), and lch() can take a fourth optional parameter to control the alpha channel: hwb(0 0% 35% / .5); lab(34% 58 48 / .24); lch(34% 75 39 / .9); Here are our examples from before but with LCH added: /* Dark Red */ #a60000; rgb(166 0 0); hsl(0 100% 33%); hwb(0 0% 35%); lab(34% 58 48); lch(34% 75 39); /* Light Blue */ #046cdb rgb(4 108 219); hsl(211 96% 44%); hwb(211 2% 14%); lab(46% 17 -63); lch(46% 65 285); If you are using Safari, you can view the LCH color rendered in the CodePen below. See the Pen CSS Colour Values by Coner Murphy (@conermurphy) on CodePen. Browser support The four methods for defining colors we looked at first (keywords, HEX, RGB, and HSL) are all widely supported across the major browsers, so you don’t need to worry about using them and wondering if they will work or not. But, the methods for defining colors we looked at in the latter half of the article (HWB, LAB, and LCH) are still in the early days of support, so if you use them, define a fallback value in one of the four mentioned above to be safe. If you’re curious to check out the browser support for the individual methods below are the links to each page on caniuse: HEX RGB HSL HWB LAB LCH Conclusion So, that’s it! In this article, we covered every way you can set colors in CSS including some of the new and exciting methods yet to become widely supported in CSS as well as why and how to use each method for your next project. I hope you found this article on setting colors in CSS helpful. If you did, please consider following me over on Twitter, where I post helpful and actionable tips and content on the JavaScript ecosystem and web development as a whole. Or if Twitter isn’t your thing, visit my blog for more of my content. The post An advanced guide to setting colors in CSS appeared first on LogRocket Blog.

Front-end development is fascinating, not only because you can create magical experiences and it is very tangible to see the results of your work, but also because of the vast number of options available for building UIs. Regularly we face the decision to pick from fantastic JavaScript frameworks and CSS or visual design frameworks, which grew up so complex that they have their own learning curve.

Class prefixes/modifiers Wait, what's that sm: bit in the atomic classname example above? That's a new naming convention you'll see which controls at which breakpoints the style is applied. Unprefixed (e.g. ipsBorder_top). Applies to all devices, desktop and smaller. md: (e.g. md:ipsBorder_top). Applies to tablets and smaller. sm: (e.g. sm:ipsBorder_top). Applies to phones only. sm and md prefixes take priority over the desktop classname. This means you provide the desktop classname but can override it for tablets and/or phones by also adding an md: or sm: classname. For example, ipsPadding_top:double sm:ipsPadding_top:half applies double top padding on desktop, but only half top padding on phones. You'll also see modifiers on some classes (as in the example above), for example ipsPadding:half. ipsPadding is saying 'apply padding to all sides', and the ':half' modifier makes it a smaller amount.

"Pull" class To better display content areas on mobile, a class named ipsResponsive_pull has been added which 'pulls' a box on the left and right sides on small devices. It's intended to be used on boxes (normally with the ipsBox class) that you want to take up the whole screen width on mobile, allowing better usage of the available screen space.

Borders We've also added a class family to add light grey 1px borders to elements - used commonly as dividers between some parts of the page. ipsBorder - apply border to all sides ipsBorder:none - remove border from all sides ipsBorder_vertical - apply border to top and bottom ipsBorder_horizontal - apply border to left and right ipsBorder_top, ipsBorder_bottom, ipsBorder_left, ipsBorder_right - apply border to a particular side These classes have md and sm prefixed versions too, to control borders shown on each device size. This is particularly useful if you apply a border to a flex child which is in a row on desktop but a column on desktop, for example - you will be able to easily control which side the border appears on once collapsed.

Gaps Another new family of classes is ipsGap. These classes are used when you want spacing between elements. In the past, you'd have to use :last-child or :first-child to exclude an element, or loop over the elements in the template to leave off a class. If elements wrapped to a new line, putting spacing between the lines was tricky too. ipsGap solves this by applying even spacing between elements, then applying a negative margin on the whole container to bring it back to the starting position. The classname is followed by a modifier, which is a number from our spacing scale, e.g. 1 is 4px spacing, 2 is 8px spacing and so on. ipsGap:1 (1-5 available) - applies both horizontal and vertical spacing around each element in the container ipsGap_row:1 (1-5 available, as well as 0 to remove) - applies vertical spacing on each element in the container Notice ipsGap_row also supports the :0 modifier. This allows you to have horizontal-only spacing - simply apply ipsGap:1 ipsGap_row:0. Be aware that using both ipsMargin (or custom styles that apply a margin) and ipsGap on the same element can cause issues. You may want add a wrapper element to handle your margin in this situation.

CSS Variables & calc We're now making use of CSS variables (also known as CSS custom properties). Check out this MDN article if you aren't familiar with them. This enables us to define some values in one place but use them throughout the product - and it allows you to change the value in one place if you wish to do so for your theme. Most of our CSS variables are defined at the top of global.css in the CSS framework, but you'll also see some other local variables defined in other places. Variables are simply used by wrapping the name in the var() function, e.g. var(--positive-light). You'll see some variables named --sp-1 and so on. This is our new 4px spacing scale. In 4.5 and going forward, when we style elements we'll generally be using one of these values for widths, heights, borders, spacing etc. to keep everything consistent. You should do the same for elements you create. We're also making use of calc(). This is another CSS function that allows math operations to be done. Instead of having to hardcode numbers for positions, sizes etc., we can now use calc() to do it for us based on some other values (often CSS variables). CSS Variables for theme settings We are deprecating the usage of the {theme} and {hextorgb} tags for color-type theme setting keys (but not for non-color settings or when you need to pass a specific hex code in). Instead, color-type theme settings will automatically have a CSS variable created for them, named --theme-setting_key, where setting_key is the key of the setting as defined in the AdminCP. The variable will be a triplet representing the color, for example 255, 255, 255. Therefore, this value can be used with both the rgb and rgba CSS color functions. Here's an example. If in the past you'd wanted to use the area_background theme setting in your CSS, you'd do background: {theme="area_background"}. Or if you want some opacity, you'd do background: {hextorgb="area_background" opacity="0.2"}. In 4.5, the correct way of using these will be: background: rgb( var(--theme-area_background) ) and background: rgba( var(--theme-area_background), 0.2 ) respectively. We're doing this now because it will open up some exciting functionality in future. To be clear, any existing usage of {theme} and {hextorgb} will continue to work fine in 4.5, but we encourage you to move over to the CSS variable approach.