Post pobrano z: Pizza Hut: Unlimited
Outdoor
Pizza Hut
Ice cream and soft drinks are unlimited in Pizza Hut Restaurants. So we created an outdoor poster to highlight the never-ending nature of the offering.
Advertising Agency:TBWA\MCR, Manchester, United Kingdom
Art Director:Jason Chadwick
Copywriter:Sam Rutter
Creative Director:Gary Fawcett, Lisa Nichols
Digital Artist:Phill Buckland
Post pobrano z: American Red Cross: Give Blood to Give Time
Film
American Red Cross
1 in 3 people in the U.S. are diagnosed with cancer. With this disease affecting so many people across the country, cancer patients use nearly 25% of the nation’s blood supply—more than patients fighting any other disease—but only 3% of Americans donate blood in a given year. For the first time, American Red Cross and the American Cancer Society are partnering in a powerful new campaign to explain the critical role blood donations play in a cancer patient’s journey.
Advertising Agency:BBDO, New York, USA
Chief Creative Officer:David Lubars, Greg Hahn
BBDO Worldwide:David Lubars
BBDO New York:Greg Hahn
Creative Director:Roberto Danino, Carolyn Davis, Matthew Page
Art Director:Carolyn Davis
Copywriter:Matthew Page
Head Of Integrated Production:David Rolfe
VP Executive producer:Sofia Handler
Planning:Alex Britt
Svp Account Director:Valerie Sena
Account Director:Jimmy McNamara
Account Executive:Darcy McGuire
Production Company:Caviar
Director:Benjamin Mege
Director Of Photography:John Londono
Producer:Malcom Wax
Head Of Production:Casey Wooden
Editing:The Work
Editor:Anne Perri
Post:Mpc
Sound:HoneyMix
Music:Q Department
Post pobrano z: SAS: What is truly Scandinavian
Film
Sas
Advertising Agency:Co+, Copenhagen, Denmark
Post pobrano z: Why JavaScript is Eating HTML
Web development is always changing. One trend in particular has become very popular lately, and it fundamentally goes against the conventional wisdom about how a web page should be made. It is exciting for some but frustrating for others, and the reasons for both are difficult to explain.
A web page is traditionally made up of three separate parts with separate responsibilities: HTML code defines the structure and meaning of the content on a page, CSS code defines its appearance, and JavaScript code defines its behavior. On teams with dedicated designers, HTML/CSS developers and JavaScript developers, this separation of concerns aligns nicely with job roles: Designers determine the visuals and user interactions on a page, HTML and CSS developers reproduce those visuals in a web browser, and JavaScript developers add the user interaction to tie it all together and “make it work.” People can work on one piece without getting involved with all three.
In recent years, JavaScript developers have realized that by defining a page’s structure in JavaScript instead of in HTML (using frameworks such as React), they can simplify the development and maintenance of user interaction code that is otherwise much more complex to build. Of course, when you tell someone that the HTML they wrote needs to be chopped up and mixed in with JavaScript they don’t know anything about, they can (understandably) become frustrated and start asking what the heck we’re getting out of this.
As a JavaScript developer on a cross-functional team, I get this question occasionally and I often have trouble answering it. All of the materials I’ve found on this topic are written for an audience that is already familiar with JavaScript — which is not terribly useful to those who focus on HTML and CSS. But this HTML-in-JS pattern (or something else that provides the same benefits) will likely be around for a while, so I think it’s an important thing that everyone involved in web development should understand.
This article will include code examples for those interested, but my goal is to explain this concept in a way that can be understood without them.
To broaden the audience of this article as much as possible, I want to give a quick background on the types of code involved in creating a web page and their traditional roles. If you have experience with these, you can skip ahead.
HTML (HyperText Markup Language) code defines the structure and meaning of the content on a page. For example, this article’s HTML contains the text you’re reading right now, the fact that it is in a paragraph, and the fact that it comes after a heading and before a CodePen.
Let’s say we want to build a simple shopping list app. We might start with some HTML like this:
We can save this code in a file, open it in a web browser, and the browser will display the rendered result. As you can see, the HTML code in this example represents a section of a page that contains a heading reading “Shopping List (2 items),” a text input box, a button reading “Add Item,” and a list with two items reading “Eggs” and “Butter.” In a traditional website, a user would navigate to an address in their web browser, then the browser would request this HTML from a server, load it and display it. If there are already items in the list, the server could deliver HTML with the items already in place, like they are in this example.
Try to type something in the input box and click the “Add Item” button. You’ll notice nothing happens. The button isn’t connected to any code that can change the HTML, and the HTML can’t change itself. We’ll get to that in a moment.
CSS (Cascading Style Sheets) code defines the appearance of a page. For example, this article’s CSS contains the font, spacing, and color of the text you’re reading.
You may have noticed that our shopping list example looks very plain. There is no way for HTML to specify things like spacing, font sizes, and colors. This is where CSS (Cascading Style Sheets) comes in. On the same page as the HTML above, we could add CSS code to style things up a bit:
As you can see, this CSS changed the font sizes and weights and gave the section a nice background color (designers, please don’t @ me; I know this is still ugly). A developer can write style rules like these and they will be applied consistently to any HTML structure: if we add more <section>, <button> or <ul> elements to this page, they will have the same font changes applied.
The button still doesn’t do anything, though: that’s where JavaScript comes in.
JavaScript code defines the behavior of interactive or dynamic elements on a page. For example, the embedded CodePen examples in this article are powered by JavaScript.
Without JavaScript, to make the Add Item button in our example work would require us to use special HTML to make it submit data back to the server (<form action="...">, if you’re curious). Then the browser would discard the entire page and reload an updated version of the entire HTML file. If this shopping list was part of a larger page, anything else the user was doing would be lost. Scrolled down? You’re back at the top. Watching a video? It starts over. This is how all web applications worked for a long time: any time a user interacted with a webpage, it was as if they closed their web browser and opened it again. That’s not a big deal for this simple example, but for a large complex page which could take a while to load, it’s not efficient for either the browser or the server.
If we want anything to change on a webpage without reloading the entire page, we need JavaScript (not to be confused with Java, which is an entirely different language… don’t get me started). Let’s try adding some:
Now when we type some text in the box and click the “Add Item” button, our new item is added to the list and the item count at the top is updated! In a real app, we would also add some code to send the new item to the server in the background so that it will still show up the next time we load the page.
Separating JavaScript from the HTML and CSS makes sense in this simple example. Traditionally, even more complicated interactions would be added this way: HTML is loaded and displayed, and JavaScript runs afterwards to add things to it and change it. As things get more complex, however, we start needing to keep better track of things in our JavaScript.
If we were to keep building this shopping list app, next we’d probably add buttons for editing or removing items from the list. Let’s say we write the JavaScript for a button that removes an item, but we forget to add the code that updates the item total at the top of the page. Suddenly we have a bug: after a user removes an item, the total on the page won’t match the list! Once we notice the bug, we fix it by adding that same totalText.innerHTML line from our “Add Item” code to the “Remove Item” code. Now we have the same code duplicated in more than one place. Later on, let’s say we want to change that code so that instead of “(2 items)” at the top of the page it reads “Items: 2.” We’ll have to make sure we update it in all three places: in the HTML, in the JavaScript for the “Add Item” button, and in the JavaScript for the “Remove Item” button. If we don’t, we’ll have another bug where that text abruptly changes after a user interaction.
In this simple example, we can already see how quickly these things can get messy. There are ways to organize our JavaScript to make this kind of problem easier to deal with, but as things continue to get more complex, we’ll need to keep restructuring and rewriting things to keep up. As long as HTML and JavaScript are kept separate, a lot of effort can be required to make sure everything is kept in sync between them. That’s one of the reasons why new JavaScript frameworks, like React, have gained traction: they are designed to show the relationships between things like HTML and JavaScript. To understand how that works, we first need to understand just a teeny bit of computer science.
The key concept to understand here involves the distinction between two common programming styles. (There are other programming styles, of course, but we’re only dealing with two of them here.) Most programming languages lend themselves to one or the other of these, and some can be used in both ways. It’s important to grasp both in order to understand the main benefit of HTML-in-JS from a JavaScript developer’s perspective.
.selected class to it; and when the user de-selects it, remove the .selected class from it..selected class if the user has selected it.Forget about JavaScript for a moment. Here’s an important fact: HTML on its own is a declarative language. In an HTML file, you can declare something like:
<section>
<h1>Hello</h1>
<p>My name is Mike.</p>
</section>When a web browser reads this HTML, it will figure out these imperative steps for you and execute them:
As a web developer, the details of how a browser does these things is irrelevant; all that matters is that it does them. This is a perfect example of the difference between these two kinds of programming. In short, HTML is a declarative abstraction wrapped around a web browser’s imperative display engine. It takes care of the „how” so you only have to worry about the „what.” You can enjoy life writing declarative HTML because the fine people at Mozilla or Google or Apple wrote the imperative code for you when they built your web browser.
We’ve already looked at a simple example of imperative JavaScript in the shopping list example above, and I mentioned how the complexity of an app’s features has ripple effects on the effort required to implement them and the potential for bugs in that implementation. Now let’s look at a slightly more complex feature and see how it can be simplified by using a declarative approach.
Imagine a webpage that contains the following:
Here’s an implementation of this in plain HTML, CSS and imperative JavaScript:
There isn’t much CSS code here because I’m using the wonderful PatternFly design system, which provides most of the CSS for my example. I imported their CSS file in the CodePen settings.
In order to implement this feature with imperative JavaScript, we need to give the browser several granular instructions. This is the English-language equivalent to the code in my example above:
.selected CSS class to it..selected class from it..selected class to them..selected class from them.Wow. That’s a lot, right? Well, we better remember to write code for each and every one of those things. If we forget or screw up any of those instructions, we will end up with a bug where the totals don’t match the checkboxes, or a button is enabled that doesn’t do anything when you click it, or a row ends up with the wrong color, or something else we didn’t think of and won’t find out about until a user complains.
The big problem here is that there is no single source of truth for the state of our app, which in this case is “which checkboxes are checked?” The checkboxes know whether or not they are checked, of course, but, the row styles also have to know, the summary text has to know, and each button has to know. Five copies of this information are stored separately all around the HTML, and when it changes in any of those places the JavaScript developer needs to catch that and write imperative code to keep the others in sync.
This is still only a simple example of one small component of a page. If that sounds like a headache, imagine how complex and fragile an application becomes when you need to write the whole thing this way. For many complex modern web applications, it’s not a scalable solution.
Tools, like React, allow us to use JavaScript in a declarative way. Just as HTML is a declarative abstraction wrapped around the web browser’s display instructions, React is a declarative abstraction wrapped around JavaScript.
Remember how HTML let us focus on the structure of a page and not the details of how the browser displays that structure? Well, when we use React, we can focus on the structure again by defining it based on data stored in a single place. When that source of truth changes, React will update the structure of the page for us automatically. It will take care of the imperative steps behind the scenes, just like the web browser does for HTML. (Although React is used as an example here, this concept is not unique to React and is used by other frameworks, such as Vue.)
Let’s go back to our list of checkboxes from the example above. In this case, the truth we care about is simple: which checkboxes are checked? The other details on the page (e.g. what the summary says, the color of the rows, whether or not the buttons are enabled) are effects derived from that same truth. So, why should they need to have their own copy of this information? They should just use the single source of truth for reference, and everything on the page should „just know” which checkboxes are checked and conduct themselves accordingly. You might say that the row elements, summary text, and buttons should all be able to automatically react to a checkbox being checked or unchecked. (See what I did there?)
In order to implement this page with React, we can replace the list with a few simple declarations of facts:
checkboxValues that represents which boxes are checked.
checkboxValues = [false, false, true, false]checkboxValues, there is a row element which:
.selected if the value is true, and{x} of {y} selected” where {x} is the number of true values in checkboxValues and {y} is the total number of values in checkboxValues.checkboxValues.checkboxValues.checkboxValues.checkboxValues to true.checkboxValues to false.You’ll notice that the last three items are still imperative instructions („When this happens, do that”), but that’s the only imperative code we need to write. It’s three lines of code, and they all update the single source of truth. The rest of those bullets are declarations („there is a…”) which are now built right into the definition of the page’s structure. In order to do this, we write our elements in a special JavaScript syntax provided by React called JSX, which resembles HTML but can contain JavaScript logic. That gives us the ability to mix logic like „if” and „for each” with the HTML structure, so the structure can be different depending on the contents of checkboxValues at any given time.
Here’s the same shopping list example as above, this time implemented with React:
JSX is definitely weird. When I first encountered it, it just felt wrong. My initial reaction was, “What the heck is this? HTML doesn’t belong in JavaScript!” I wasn’t alone. That said, it’s not HTML, but rather JavaScript dressed up to look like HTML. It is also quite powerful.
Remember that list of 20 imperative instructions above? Now we have three. For the price of defining our HTML inside our JavaScript, the rest of them come for free. React just does them for us whenever checkboxValues changes.
With this code, it is now impossible for the summary to not match the checkboxes, or for the color of a row to be wrong, or for a button to be enabled when it should be disabled. There is an entire category of bugs which are now impossible for us to have in our app: sources of truth being out of sync. Everything flows down from the single source of truth, and we developers can write less code and sleep better at night. Well, JavaScript developers can, at least…
As web applications become more complex, maintaining the classic separation of concerns between HTML and JavaScript comes at an increasingly painful cost. HTML was originally designed for static documents, and in order to add more complex interactive functionality to those documents, imperative JavaScript has to keep track of more things and become more confusing and fragile.
The ability to use a single source of truth is the most important benefit of this pattern, but the trade-off gives us other benefits, too. Defining elements of our page as JavaScript code means that we can turn chunks of it into reusable components, preventing us from copying and pasting the same HTML in multiple places. If we need to change a component, we can make that change in one place and it will update everywhere in our application (or in many applications, if we’re publishing reusable components to other teams).
We can take these simple components and compose them together like LEGO bricks, creating more complex and useful components, without making them too confusing to work with. And if we’re using components built by others, we can easily update them when they release improvements or fix bugs without having to rewrite our code.
All of those benefits do come at a cost. There are good reasons people value keeping HTML and JavaScript separate, and to get these other benefits, we need to combine them into one. As I mentioned before, moving away from simple HTML files complicates the workflow of someone who didn’t need to worry about JavaScript before. It may mean that someone who previously could make changes to an application on their own must now learn additional complex skills to maintain that autonomy.
There can also be technical downsides. For example, some tools like linters and parsers expect regular HTML, and some third-party imperative JavaScript plugins can become harder to work with. Also, JavaScript isn’t the best-designed language; it’s just what we happen to have in our web browsers. Newer tools and features are making it better, but it still has some pitfalls you need to learn about before you can be productive with it.
Another potential problem is that when the semantic structure of a page is broken up into abstract components, it can become easy for developers to stop thinking about what actual HTML elements are being generated at the end. Specific HTML tags like <section> and <aside> have specific semantic meanings that are lost when using generic tags like <div> and <span>, even if they look the same visually on a page. This is especially important for accessibility. For example, these choices will impact how screen reader software behaves for visually impaired users. It might not be the most exciting part, but JavaScript developers should always remember that semantic HTML is the most important part of a web page.
It’s become a trend for developers to reach for frameworks on every single project. Some people are of the mindset that separating HTML and JavaScript is obsolete, but this isn’t true. For a simple static website that doesn’t need much user interaction, it’s not worth the trouble. The more enthusiastic React fans might disagree with me here, but if all your JavaScript is doing is creating a non-interactive webpage, you shouldn’t be using JavaScript. JavaScript doesn’t load as fast as regular HTML, so if you’re not getting a significant developer experience or code reliability improvement, it’s doing more harm than good.
You also don’t have to build your entire website in React! Or Vue! Or Whatever! A lot of people don’t know this because all the tutorials out there show how to use React for the whole thing. If you only have one little complex widget on an otherwise simple website, you can use React for that one component. You don’t always need to worry about webpack or Redux or Gatsby or any of the other crap people will tell you are “best practices” for your React app.
For a sufficiently complex application, declarative programming is absolutely worth the trouble. It is a game changer that has empowered developers the world over to build amazing, robust and reliable software with confidence and without having to sweat the small stuff. Is React in particular the best possible solution to these problems? No. Will it just be replaced by the next thing? Eventually. But declarative programming is not going anywhere, and the next thing will probably just do it better.
I’m not touching that one.
The post Why JavaScript is Eating HTML appeared first on CSS-Tricks.
Post pobrano z: The Unseen Performance Costs of Modern CSS-in-JS Libraries
This article is full of a bunch of data from Aggelos Arvanitakis. But lemme just focus on his final bit of advice:
Investigate whether a zero-runtime CSS-in-JS library can work for your project. Sometimes we tend to prefer writing CSS in JS for the DX (developer experience) it offers, without a need to have access to an extended JS API. If you app doesn’t need support for theming and doesn’t make heavy and complex use of the
cssprop, then a zero-runtime CSS-in-JS library might be a good candidate.
„Zero-runtime” meaning you author your styles in a CSS-in-JS syntax, but what is produced is .css files like any other CSS preprocessor would produce. This shifts the tool into a totally different category. It’s a developer tool only, rather than a tool where the user of the website pays the price of using it.
The flagship zero-runtime CSS-in-JS library is Linaria. I think the syntax looks really nice.
import { css } from 'linaria';
import fonts from './fonts';
const header = css`
text-transform: uppercase;
font-family: ${fonts.heading};
`;
<h1 className={header}>Hello world</h1>;I’m also a fan of the just do scoping for me ability that CSS modules brings, which can be done zero-runtime style.
Direct Link to Article — Permalink
The post The Unseen Performance Costs of Modern CSS-in-JS Libraries appeared first on CSS-Tricks.
Post pobrano z: While You Weren’t Looking, CSS Gradients Got Better
One thing that caught my eye on the list of features for Lea Verou’s conic-gradient() polyfill was the last item:
Supports double position syntax (two positions for the same color stop, as a shortcut for two consecutive color stops with the same color)
Surprisingly, I recently discovered most people aren’t even aware that double position for gradient stops is something that actually exists in the spec, so I decided to write about it.
According to the spec:
Specifying two locations makes it easier to create solid-color „stripes” in a gradient, without having to repeat the color twice.
I completely agree, this was the first thing I thought of when I became aware of this feature.
Let’s say we want to get the following result: a gradient with a bunch of equal width vertical stripes (which I picked up from an earlier post by Chris):
The hex values are: #5461c8, #c724b1, #e4002b, #ff6900, #f6be00, #97d700, #00ab84 and #00a3e0.
Let’s first see how we’d CSS this without using double stop positions!
We have eight stripes, which makes each of them one-eighth of the gradient width. One eighth of 100% is 12.5%, so we go from one to the next at multiples of this value.
This means our linear-gradient() looks as follows:
linear-gradient(90deg,
#5461c8 12.5% /* 1*12.5% */,
#c724b1 0, #c724b1 25% /* 2*12.5% */,
#e4002b 0, #e4002b 37.5% /* 3*12.5% */,
#ff6900 0, #ff6900 50% /* 4*12.5% */,
#f6be00 0, #f6be00 62.5% /* 5*12.5% */,
#97d700 0, #97d700 75% /* 6*12.5% */,
#00ab84 0, #00ab84 87.5% /* 7*12.5% */,
#00a3e0 0)Note that we don’t need to repeat stop position % values because, whenever a stop position is smaller than a previous one, we automatically have a sharp transition. That’s why it’s always safe to use 0 (which is always going to be smaller than any positive value) and have #c724b1 25%, #e4002b 0 instead of #c724b1 25%, #e4002b 25%, for example. This is something that can make our life easier in the future if, for example, we decide we want to add two more stripes and make the stop positions multiples of 10%.
Not too bad, especially compared to what gradient generators normally spit out. But if we decide one of those stripes in the middle doesn’t quite fit in with the others, then changing it to something else means updating in two places.
Again, not too bad and nothing we can’t get around with a little bit of help from a preprocessor:
$c: #5461c8 #c724b1 #e4002b #ff6900 #f6be00 #97d700 #00ab84 #00a3e0;
@function get-stops($c-list) {
$s-list: ();
$n: length($c-list);
$u: 100%/$n;
@for $i from 1 to $n {
$s-list: $s-list,
nth($c-list, $i) $i*$u,
nth($c-list, $i + 1) 0
}
@return $s-list
}
.strip {
background: linear-gradient(90deg, get-stops($c)))
}This generates the exact CSS gradient we saw a bit earlier and now we don’t have to modify anything in two places anymore.
See the Pen by thebabydino (@thebabydino) on CodePen.
However, even if a preprocessor can save us from typing the same thing twice, it doesn’t eliminate repetition from the generated code.
And we may not always want to use a preprocessor. Leaving aside the fact that some people are stubborn or have an irrational fear or hate towards preprocessors, it sometimes feels a bit silly to use a loop.
For example, when we barely have anything to loop over! Let’s say we want to get a much simpler background pattern, such as a diagonal hashes one, which I’d imagine is a much more common use case than an over-the-top rainbow one that’s probably not a good fit on most websites anyway.
This requires using repeating-linear-gradient() and this means a bit of repetition, even if we don’t have the same long list of hex values as we did before:
repeating-linear-gradient(-45deg,
#ccc /* can't skip this, repeating gradient won't work */,
#ccc 2px,
transparent 0,
transparent 9px /* can't skip this either, tells where gradient repetition starts */)Here, we cannot ditch the first and last stops because those are precisely what indicate how the gradient repeats within the rectangle defined by the background-size.
If you want to understand why it’s better to use repeating-linear-gradient() instead of a plain old linear-gradient() combined with the proper background-size in order to create such hashes, check out this other article I wrote a while ago.
This is precisely where such feature comes to the rescue — it allows us to avoid repetition in the final CSS code.
For the rainbow stripes case, our CSS becomes:
linear-gradient(90deg,
#5461c8 12.5%,
#c724b1 0 25%,
#e4002b 0 37.5%,
#ff6900 0 50%,
#f6be00 0 62.5%,
#97d700 0 75%,
#00ab84 0 87.5%,
#00a3e0 0)And to recreate the hashes, we only need:
repeating-linear-gradient(-45deg,
#ccc 0 2px,
transparent 0 9px)See the Pen by thebabydino (@thebabydino) on CodePen.
What about support? Well, glad you asked! It actually happens to be pretty good! It works in Safari, Chromium browsers (which now includes Edge as well!) and Firefox. Pre-Chromium Edge and maybe some mobile browsers could still hold you back, but if you don’t have to worry about providing support for every browser under the sun or it’s fine to provide a fallback, go ahead and start using this!
The post While You Weren’t Looking, CSS Gradients Got Better appeared first on CSS-Tricks.
Post pobrano z: While You Weren’t Looking, CSS Gradients Got Better
One thing that caught my eye on the list of features for Lea Verou’s conic-gradient() polyfill was the last item:
Supports double position syntax (two positions for the same color stop, as a shortcut for two consecutive color stops with the same color)
Surprisingly, I recently discovered most people aren’t even aware that double position for gradient stops is something that actually exists in the spec, so I decided to write about it.
According to the spec:
Specifying two locations makes it easier to create solid-color „stripes” in a gradient, without having to repeat the color twice.
I completely agree, this was the first thing I thought of when I became aware of this feature.
Let’s say we want to get the following result: a gradient with a bunch of equal width vertical stripes (which I picked up from an earlier post by Chris):
The hex values are: #5461c8, #c724b1, #e4002b, #ff6900, #f6be00, #97d700, #00ab84 and #00a3e0.
Let’s first see how we’d CSS this without using double stop positions!
We have eight stripes, which makes each of them one-eighth of the gradient width. One eighth of 100% is 12.5%, so we go from one to the next at multiples of this value.
This means our linear-gradient() looks as follows:
linear-gradient(90deg,
#5461c8 12.5% /* 1*12.5% */,
#c724b1 0, #c724b1 25% /* 2*12.5% */,
#e4002b 0, #e4002b 37.5% /* 3*12.5% */,
#ff6900 0, #ff6900 50% /* 4*12.5% */,
#f6be00 0, #f6be00 62.5% /* 5*12.5% */,
#97d700 0, #97d700 75% /* 6*12.5% */,
#00ab84 0, #00ab84 87.5% /* 7*12.5% */,
#00a3e0 0)Note that we don’t need to repeat stop position % values because, whenever a stop position is smaller than a previous one, we automatically have a sharp transition. That’s why it’s always safe to use 0 (which is always going to be smaller than any positive value) and have #c724b1 25%, #e4002b 0 instead of #c724b1 25%, #e4002b 25%, for example. This is something that can make our life easier in the future if, for example, we decide we want to add two more stripes and make the stop positions multiples of 10%.
Not too bad, especially compared to what gradient generators normally spit out. But if we decide one of those stripes in the middle doesn’t quite fit in with the others, then changing it to something else means updating in two places.
Again, not too bad and nothing we can’t get around with a little bit of help from a preprocessor:
$c: #5461c8 #c724b1 #e4002b #ff6900 #f6be00 #97d700 #00ab84 #00a3e0;
@function get-stops($c-list) {
$s-list: ();
$n: length($c-list);
$u: 100%/$n;
@for $i from 1 to $n {
$s-list: $s-list,
nth($c-list, $i) $i*$u,
nth($c-list, $i + 1) 0
}
@return $s-list
}
.strip {
background: linear-gradient(90deg, get-stops($c)))
}This generates the exact CSS gradient we saw a bit earlier and now we don’t have to modify anything in two places anymore.
See the Pen by thebabydino (@thebabydino) on CodePen.
However, even if a preprocessor can save us from typing the same thing twice, it doesn’t eliminate repetition from the generated code.
And we may not always want to use a preprocessor. Leaving aside the fact that some people are stubborn or have an irrational fear or hate towards preprocessors, it sometimes feels a bit silly to use a loop.
For example, when we barely have anything to loop over! Let’s say we want to get a much simpler background pattern, such as a diagonal hashes one, which I’d imagine is a much more common use case than an over-the-top rainbow one that’s probably not a good fit on most websites anyway.
This requires using repeating-linear-gradient() and this means a bit of repetition, even if we don’t have the same long list of hex values as we did before:
repeating-linear-gradient(-45deg,
#ccc /* can't skip this, repeating gradient won't work */,
#ccc 2px,
transparent 0,
transparent 9px /* can't skip this either, tells where gradient repetition starts */)Here, we cannot ditch the first and last stops because those are precisely what indicate how the gradient repeats within the rectangle defined by the background-size.
If you want to understand why it’s better to use repeating-linear-gradient() instead of a plain old linear-gradient() combined with the proper background-size in order to create such hashes, check out this other article I wrote a while ago.
This is precisely where such feature comes to the rescue — it allows us to avoid repetition in the final CSS code.
For the rainbow stripes case, our CSS becomes:
linear-gradient(90deg,
#5461c8 12.5%,
#c724b1 0 25%,
#e4002b 0 37.5%,
#ff6900 0 50%,
#f6be00 0 62.5%,
#97d700 0 75%,
#00ab84 0 87.5%,
#00a3e0 0)And to recreate the hashes, we only need:
repeating-linear-gradient(-45deg,
#ccc 0 2px,
transparent 0 9px)See the Pen by thebabydino (@thebabydino) on CodePen.
What about support? Well, glad you asked! It actually happens to be pretty good! It works in Safari, Chromium browsers (which now includes Edge as well!) and Firefox. Pre-Chromium Edge and maybe some mobile browsers could still hold you back, but if you don’t have to worry about providing support for every browser under the sun or it’s fine to provide a fallback, go ahead and start using this!
The post While You Weren’t Looking, CSS Gradients Got Better appeared first on CSS-Tricks.
Post pobrano z: A Complete Guide to Links and Buttons
There is a lot to know about links and buttons in HTML. There is markup implementation and related attributes, styling best practices, things to avoid, and the even-more-nuanced cousins of the link: buttons and button-like inputs.
Let’s take a look at the whole world of links and buttons, and all the considerations at the HTML, CSS, JavaScript, design, and accessibility layers that come with them. There are plenty of pitfalls and bad practices to avoid along the way. By covering it, we’ll have a complete good UX implementation of both elements.
Quick guidelines on when to use each:
<a href="/somewhere">link</a>)<button type="button">button</button>)<input type="submit" value="Submit">)Links are one of the most basic, yet deeply fundamental and foundational building blocks of the web. Click a link, and you move to another page or are moved to another place within the same page.
<a href="https://css-tricks.com">CSS-Tricks</a>That’s a link to a „fully qualified” or „absolute” URL.
You can link „relatively” as well:
<!-- Useful in navigation, but be careful in content that may travel elsewhere (e.g. RSS) -->
<a href="/pages/about.html">About</a>That can be useful, for example, in development where the domain name is likely to be different than the production site, but you still want to be able to click links. Relative URLs are most useful for things like navigation, but be careful of using them within content — like blog posts — where that content may be read off-site, like in an app or RSS feed.
Links can also be „hash links” or „jump links” by starting with a #:
<a href="#section-2">Section Two</a>
<!-- will jump to... -->
<section id="section-2"></section>Clicking that link will „jump” (scroll) to the first element in the DOM with an ID that matches, like the section element above.
💥 Little trick: Using a hash link (e.g. #0) in development can be useful so you can click the link without being sent back to the top of the page like a click on a # link does. But careful, links that don’t link anywhere should never make it to production.
💥 Little trick: Jump-links can sometimes benefit from smooth scrolling to help people understand that the page is moving from one place to another.
It’s a fairly common UI/UX thing to see a „Back to top” link on sites, particularly where important navigational controls are at the top but there is quite a bit of content to scroll (or otherwise navigate) through. To create a jump link, link to the ID of an element that is at the top of the page where it makes sense to send focus back to.
<a href="#top-of-page">Back to Top</a>Jump links are sometimes also used to link to other anchor (<a>) elements that have no href attribute. Those are called „placeholder” links:
<a id="section-2"></a>
<h3>Section 2</h3>There are accessibility considerations of these, but overall they are acceptable.
A link without an href attribute is the only practical way to disable a link. Why disable a link? Perhaps it’s a link that only becomes active after logging in or signing up.
a:not[href] {
/* style a "disabled" link */
}When a link has no href, it has no role, no focusability, and no keyboard events. This is intentional. You could think of it like a <span>.
You can use the target attribute for that, but it is strongly discouraged.
<a href="https://css-tricks.com" target="_blank" rel="noopener noreferrer">
CSS-Tricks
</a>The bit that makes it work is target="_blank", but note the extra rel attribute and values there which make it safer and faster.
Making links open in new tabs is a major UX discussion. We have a whole article about when to use it here. Summarized:
Don’t use it:
Do use it:
The download attribute on a link will instruct the browser to download the linked file rather than opening it within the current page/tab. It’s a nice UX touch.
<a href="/files/file.pdf" download>Download PDF</a>rel attributeThis attribute is for the relationship of the link to the target.
The rel attribute is also commonly used on the <link> element (which is not used for creating hyperlinks, but for things like including CSS and preloading). We’re not including rel values for the <link> element here, just anchor links.
Here are some basic examples:
<a href="/page/3" rel="next">Next</a>
<a href="/page/1" rel="prev">Previous</a>
<a href="http://creativecommons.org/licenses/by/2.0/" rel="license">cc by 2.0</a>
<a href="/topics/" rel="directory">All Topics</a>rel="alternate": Alternate version of the document.rel="author": Author of the document.rel="help": A resource for help with the document.rel="license": License and legal information.rel="manifest": Web App Manifest document.rel="next": Next document in the series.rel="prev": Previous document in the series.rel="search": A document meant to perform a search in the current document.There are also some rel attributes specifically to inform search engines:
rel="sponsored": Mark links that are advertisements or paid placements (commonly called paid links) as sponsored.rel="ugc": For not-particularly-trusted user-generated content, like comments and forum posts.rel="nofollow": Tell the search engine to ignore this and not associate this site with where this links to.And also some rel attributes that are most security-focused:
rel="noopener": Prevent a new tab from using the JavaScript window.opener feature, which could potentially access the page containing the link (your site) to perform malicious things, like stealing information or sharing infected code. Using this with target="_blank" is often a good idea.rel="noreferrer": Prevent other sites or tracking services (e.g. Google Analytics) from identifying your page as the source of clicked link.You can use multiple space-separated values if you need to (e.g. rel="noopener noreferrer")
And finally, some rel attributes come from the microformats standard, like:
rel="directory": Indicates that the destination of the hyperlink is a directory listing containing an entry for the current page.rel="tag": Indicates that the destination of that hyperlink is an author-designated „tag” (or keyword/subject) for the current page.rel="payment": Indicates that the destination of that hyperlink provides a way to show or give support for the current page.rel="help": States that the resource linked to is a help file or FAQ for the current document.The default role of a link is link, so you do not need to do:
<a role="link" href="/">Link</a>You’d only need that if you were faking a link, which would be a weird/rare thing to ever need to do, and you’d have to use some JavaScript in addition to this to make it actually follow the link.
<span class="link" tabindex="0" role="link" data-href="/">
Fake accessible link created using a span
</span>Just looking above you can see how much extra work faking a link is, and that is before you consider that is breaks right-clicking, doesn’t allow opening in a new tab, doesn’t work with Windows High Contrast Mode and other reader modes and assistive technology. Pretty bad!
A useful ARIA role to indicate the current page, like:
<a href="/" aria-current="page">Home</a>
<a href="/contact">Contact</a>
<a href="/about">About/a></a>title attribute?Probably not. Save this for giving an iframe a short, descriptive title.
<a title="I don't need to be here" href="/">
List of Concerts
</a>title provides a hover-triggered UI popup showing the text you wrote. You can’t style it, and it’s not really that accessible.
Hover-triggered is the key phrase here. It’s unusable on any touch-only device. If a link needs more contextual information, provide that in actual content around the link, or use descriptive text the link itself (as opposed to something like „Click Here”).
If a link only has an icon inside it, like:
<a href="/">😃</a>
<a href="/">
<svg> ... </svg>
</a>That isn’t enough contextual information about the link, particularly for accessibility reasons, but potentially for anybody. Links with text are almost always more clear. If you absolutely can’t use text, you can use a pattern like:
<a href="/">
<!-- Hide the icon from assistive technology -->
<svg aria-hidden="true" focusable="false"> ... </svg>
<!-- Acts as a label that is hidden from view -->
<span class="visually-hidden">Useful link text</span>
</a>visually-hidden is a class used to visually hide the label text with CSS:
.visually-hidden {
border: 0;
clip: rect(0 0 0 0);
height: 1px;
margin: -1px;
overflow: hidden;
padding: 0;
position: absolute;
white-space: nowrap;
width: 1px;
}Unlike aria-label, visually hidden text can be translated and will hold up better in specialized browsing modes.
Images can be links if you wrap them in a link. There is no need to use the alt text to say the image is a link, as assistive technology will do that already.
<a href="/buy/puppies/now">
<img src="puppy.jpg" alt="A happy puppy.">
</a>You can link a whole area of content, like:
<a href="/article/">
<div class="card">
<h2>Card</h2>
<img src="..." alt="...">
<p>Content</p>
</div>
</a>But it’s slightly weird, so consider the UX of it if you ever do it. For example, it can be harder to select the text, and the entire element needs styling to create clear focus and hover states.
Take this example, where the entire element is wrapped in a link, but there are no hover and focus states applied to it.
If you need a link within that card element, well, you can’t nest links. You could get a little tricky if you needed ot, like using a pseudo-element on the link which is absolutely positioned to cover the whole area.
Additionally, this approach can make really long and potentially confusing announcements for screen readers. Even though links around chunks of content is technically possible, it’s best to avoid doing this if you can.
Here’s the default look of a link:
It’s likely you’ll be changing the style of your links, and also likely you’ll use CSS to do it. I could make all my links red in CSS by doing:
a {
color: red;
}Sometimes selecting and styling all links on a page is a bit heavy-handed, as links in navigation might be treated entirely differently than links within text. You can always scope selectors to target links within particular areas like:
/* Navigation links */
nav a { }
/* Links in an article */
article a { }
/* Links contained in an element with a "text" class */
.text a { }Or select the link directly to style.
.link {
/* For styling <a class="link" href="/"> */
}
a[aria-current="page"] {
/* You'll need to apply this attribute yourself, but it's a great pattern to use for active navigation. */
}Links are focusable elements. In other words, they can be selected using the Tab key on a keyboard. Links are perhaps the most common element where you’ll very consciously design the different states, including a :focus state.
:hover: For styling when a mouse pointer is over the link.:visited: For styling when the link has been followed, as best as the browser can remember. It has limited styling ability due to security.:link: For styling when a link has not been visited.:active: For styling when the link is pressed (e.g. the mouse button is down or the element is being tapped on a touch screen).:focus: Very important! Links should always have a focus style. If you choose to remove the default blue outline that most browsers apply, also use this selector to re-apply a visually obvious focus style.These are chainable like any pseudo-class, so you could do something like this if it is useful for your design/UX.
/* Style focus and hover states in a single ruleset */
a:focus:hover { }Perhaps some of the confusion between links and buttons is stuff like this:
That certainly looks like a button! Everyone would call that a button. Even a design system would likely call that a button and perhaps have a class like .button { }. But! A thing you can click that says „Learn More” is very much a link, not a button. That’s completely fine, it’s just yet another reminder to use the semantically and functionally correct element.
Since we often style links with a distinct color, it’s important to use a color with sufficient color contrast for accessibility. There is a wide variety of visual impairments (see the tool WhoCanUse for simulating color combinations with different impairments) and high contrast helps nearly all of them.
Perhaps you set a blue color for links:
While that might look OK to you, it’s better to use tools for testing to ensure the color has a strong enough ratio according to researched guidelines. Here, I’ll look at Chrome DevTools and it will tell me this color is not compliant in that it doesn’t have enough contrast with the background color behind it.
Color contrast is a big consideration with links, not just because they are often colored in a unique color that needs to be checked, but because they have all those different states (hover, focus, active, visited) which also might have different colors. Compound that with the fact that text can be selected and you’ve got a lot of places to consider contrast. Here’s an article about all that.
We can get clever in CSS with attribute selectors and figure out what kind of resource a link is pointing to, assuming the href value has useful stuff in it.
/* Style all links that include .pdf at the end */
a[href$=".pdf"]::after {
content: " (PDF)";
}
/* Style links that point to Google */
a[href*="google.com"] {
color: purple;
}CSS has an „at-rule” for declaring styles that only take effect on printed media (e.g. printing out a web page). You can include them in any CSS like this:
@media print {
/* For links in content, visually display the link */
article a::after {
content: " (" attr(href) ")";
}
}If you needed to take all the styling off a link (or really any other element for that matter), CSS provides a way to remove all the styles using the all property.
.special-area a {
all: unset;
all: revert;
/* Start from scratch */
color: purple;
}You can also remove individual styles with keywords. (Again, this isn’t really unique to links, but is generically useful):
a {
/* Grab color from nearest parent that sets it */
color: inherit;
/* Wipe out style (turn black) */
color: initial;
/* Change back to User Agent style (blue) */
color: revert;
}Say you wanted to stop the clicking of a link from doing what it normally does: go to that link or jump around the page. In JavaScript, you can usepreventDefault to prevent jumping around.
const jumpLinks = document.querySelectorAll("a[href^='#']");
jumpLinks.forEach(link => {
link.addEventListener('click', event => {
event.preventDefault();
// Do something else instead, like handle the navigation behavior yourself
});
});This kind of thing is at the core of how „Single Page Apps” (SPAs) work. They intercept the clicks so browsers don’t take over and handle the navigation.
SPAs see where you are trying to go (within your own site), load the data they need, replace what they need to on the page, and update the URL. It’s an awful lot of work to replicate what the browser does for free, but you get the ability to do things like animate between pages.
Another JavaScript concern with links is that, when a link to another page is clicked, the page is left and another page loads. That can be problematic for something like a page that contains a form the user is filling out but hasn’t completed. If they click the link and leave the page, they lose their work! Your only opportunity to prevent the user from leaving is by using the beforeunload event.
window.addEventListener("beforeunload", function(event) {
// Remind user to save their work or whatever.
});A link that has had its default behavior removed won’t announce the new destination. This means a person using assistive technology may not know where they wound up. You’ll have to do things like update the page’s title and move focus back up to the top of the document.
In a JavaScript framework, like React, you might sometimes see links created from something like a <Link /> component rather than a native <a> element. The custom component probably creates a native <a> element, but with extra functionality, like enabling the JavaScript router to work, and adding attributes like aria-current="page" as needed, which is a good thing!
Ultimately, a link is a link. A JavaScript framework might offer or encourage some level of abstraction, but you’re always free to use regular links.
We covered some accessibility in the sections above (it’s all related!), but here are some more things to think about.
role="link") so there’s no need to explicitly set it.<a href="google.com">google.com</a>)alt text anyway, but doubly so when the image is wrapped in a link with otherwise no text.Some assistive technology can create lists of interactive elements on the page. Imagine a group of four article cards that all have a „Read More”, the list of interactive elements will be like:
Not very useful. You could make use of that .visually-hidden class we covered to make the links more like:
<a href="/article">
Read More
<span class="visually-hidden">
of the article "Dancing with Rabbits".
<span>
</a>Now each link is unique and clear. If the design can support it, do it without the visually hidden class to remove the ambiguity for everyone.
Buttons are for triggering actions. When do you use the <button> element? A good rule is to use a button when there is “no meaningful href.” Here’s another way to think of that: if clicking it doesn’t do anything without JavaScript, it should be a <button>.
A <button> that is within a <form>, by default, will submit that form. But aside from that, button elements don’t have any default behavior, and you’ll be wiring up that interactivity with JavaScript.
<button>Buy Now</button>Buttons inside of a <form> do something by default: they submit the form! They can also reset it, like their input counterparts. The type attributes matter:
<form action="/" method="POST">
<input type="text" name="name" id="name">
<button>Submit</button>
<!-- If you want to be more explicit... -->
<button type="submit">Submit</button>
<!-- ...or clear the form inputs back to their initial values -->
<button type="reset">Reset</button>
<!-- This prevents a `submit` action from firing which may be useful sometimes inside a form -->
<button type="button">Non-submitting button</button>
</form>Speaking of forms, buttons have some neat tricks up their sleeve where they can override attributes of the <form> itself.
<form action="/" method="get">
<!-- override the action -->
<button formaction="/elsewhere/" type="submit">Submit to elsewhere</button>
<!-- override encytype -->
<button formenctype="multipart/form-data" type="submit"></button>
<!-- override method -->
<button formmethod="post" type="submit"></button>
<!-- do not validate fields -->
<button formnovalidate type="submit"></button>
<!-- override target e.g. open in new tab -->
<button formtarget="_blank" type="submit"></button>
</form>Since buttons are focusable elements, we can automatically focus on them when the page loads using the autofocus attribute:
<div class="modal">
<h2>Save document?</h2>
<button>Cancel</button>
<button autofocus>OK</button>
</div>Perhaps you’d do that inside of a modal dialog where one of the actions is a default action and it helps the UX (e.g. you can press Enter to dismiss the modal). Autofocusing after a user action is perhaps the only good practice here, moving a user’s focus without their permission, as the autofocus attribute is capable of, can be a problem for screen reader and screen magnifier users.
Note thatautofocus may not work if the element is within an <iframe sandbox> for security reasons.
To prevent a button from being interactive, there is a disabled attribute you can use:
<button disabled>Pay Now</button>
<p class="error-message">Correct the form above to submit payment.</p>Note that we’ve included descriptive text alongside the disabled button. It can be very frustrating to find a disabled button and not know why it’s disabled. A better way to do this could be to let someone submit the form, and then explain why it didn’t work in the validation feedback messaging.
Regardless, you could style a disabled button this way:
/* Might be good styles for ANY disabled element! */
button[disabled] {
opacity: 0.5;
pointer-events: none;
} We’ll cover other states and styling later in this guide.
A submit button and a submit input (<input type="submit">) are identical in functionality, but different in the sense that an input is unable to contain child elements while a button can.
<button>
<svg aria-hidden="true" focusable="false">
<path d="..." />
</svg>
<span class="callout">Big</span>
Sale!
</button>
<button type="button">
<span role="img" aria-label="Fox">
🦊
</span>
Button
</button>Note the focusable="false" attribute on the SVG element above. In that case, since the icon is decorative, this will help assistive technology only announce the button’s label.
Buttons are generally styled to look very button-like. They should look pressable. If you’re looking for inspiration on fancy button styles, you’d do well looking at the CodePen Topic on Buttons.
How buttons look by default varies by browser and platform.
border: 0; to those same buttons as above, and we have different styles entirely.While there is some UX truth to leaving the defaults of form elements alone so that they match that browser/platform’s style and you get some affordance for free, designers typically don’t like default styles, particularly ones that differ across browsers.
Removing all the styles from a button is easier than you think. You’d think, as a form control, appearance: none; would help, but don’t count on that. Actually all: revert; is a better bet to wipe the slate clean.
You can see how a variety of properties are involved
And that’s not all of them. Here’s a consolidated chunk of what Normalize does to buttons.
button {
font-family: inherit; /* For all browsers */
font-size: 100%; /* For all browsers */
line-height: 1.15; /* For all browsers */
margin: 0; /* Firefox and Safari have margin */
overflow: visible; /* Edge hides overflow */
text-transform: none; /* Firefox inherits text-transform */
-webkit-appearance: button; /* Safari otherwise prevents some styles */
}
button::-moz-focus-inner {
border-style: none;
padding: 0;
}
button:-moz-focusring {
outline: 1px dotted ButtonText;
}.button classIn addition to using reset or baseline CSS, you may want to have a class for buttons that gives you a strong foundation for styling and works across both links and buttons.
.button {
border: 0;
border-radius: 0.25rem;
background: #1E88E5;
color: white;
font-family: -system-ui, sans-serif;
font-size: 1rem;
line-height: 1.2;
white-space: nowrap;
text-decoration: none;
padding: 0.25rem 0.5rem;
margin: 0.25rem;
cursor: pointer;
}Check out this Pen to see why all these properties are needed to make sure it works correctly across elements.
Just as with links, you’ll want to style the states of buttons.
button:hover { }
button:focus { }
button:active { }
button:visited { } /* Maybe less so */You may also want to use ARIA attributes for styling, which is a neat way to encourage using them correctly:
button[aria-pressed="true"] { }
button[aria-pressed="false"] { }There are always exceptions. For example, a website in which you need a button-triggered action within a sentence:
<p>You may open your <button>user settings</button> to change this.</p>We’ve used a button instead of an anchor tag in the above code, as this hypothetical website opens user settings in a modal dialog rather than linking to another page. In this situation, you may want to style the button as if it looks like a link.
This is probably rare enough that you would probably make a class (e.g. .link-looking-button) that incorporates the reset styles from above and otherwise matches what you do for anchor links.
Remember earlier when we talked about the possibility of wrapping entire elements in links? If you have a button within another element, but you want that entire outer element to be clickable/tappable as if it’s the button, that’s a „breakout” button. You can use an absolutely-positioned pseudo-element on the button to expand the clickable area to the whole region. Fancy!
Even without JavaScript, button elements can be triggered by the Space and Enter keys on a keyboard. That’s part of what makes them such appealing and useful elements: they are discoverable, focusable, and interactive with assistive technology in a predictable way.
Perhaps any <button> in that situation should be inserted into the DOM by JavaScript. A tall order! Food for thought. 🤔
Say a button does something pretty darn important, like submitting a payment. It would be pretty scary if it was programmed such that clicking the button multiple times submitted multiple payment requests. It is situations like this where you would attach a click handler to a button that only runs once. To make that clear to the user, we’ll disable the button on click as well.
document.querySelector("button").addEventListener('click', function(event) {
event.currentTarget.setAttribute("disabled", true);
}, {
once: true
});Then you would intentionally un-disable the button and reattach the handler when necessary.
JavaScript can be executed by activating a button through code on the button itself:
<button onclick="console.log('clicked');">
Log it.
</button>
<button onmousedown="">
</button>
<button onmouseup="">
</button>That practice went from being standard practice to being a faux pas (not abstracting JavaScript functionality away from HTML) to, eh, you need it when you need it. One advantage is that if you’re injecting this HTML into the DOM, you don’t need to bind/re-bind JavaScript event handlers to it because it already has one.
It’s common in any JavaScript framework to make a component for handling buttons, as buttons typically have lots of variations. Those variations can be turned into an API of sorts. For example, in React:
const Button = ({ className, children }) => {
const [activated, setActivated] = React.useState(false);
return (
<button
className={`button ${className}`}
aria-pressed={activated ? "true" : "false")
onClick={() => setActivated(!activated)}
>
{children}
</button>
);
};In that example, the <Button /> component ensures the button will have a button class and handles a toggle-like active class.
The biggest accessibility consideration with buttons is actually using buttons. Don’t try to replicate a button with a <div> or a <span>, which is, unfortunately, more common than you might think. It’s very likely that will cause problems. (Did you deal with focusability? Did you deal with keyboard events? Great. There’s still probably more stuff you’re forgetting.)
Like all focusable elements, browsers apply a default focus style, which is usually a blue outline.
While it’s arguable that you should leave that alone as it’s a very clear and obvious style for people that benefit from focus styles, it’s also not out of the question to change it.
What you should not do is button:focus { outline: 0; } to remove it. If you ever remove a focus style like that, put it back at the same time.
button:focus {
outline: 0; /* Removes the default blue ring */
/* Now, let's create our own focus style */
border-radius: 3px;
box-shadow: 0 0 0 2px red;
}
The fact that a button may become focused when clicked and apply that style at the same time is offputting to some. There is a trick (that has limited, but increasing, browser support) on removing focus styles from clicks and not keyboard events:
:focus:not(:focus-visible) {
outline: 0;
}Buttons already have the role they need (role="button"). But there are some other ARIA attributes that are related to buttons:
aria-pressed: Turns a button into a toggle, between aria-pressed="true" and aria-pressed="false". More on button toggles, which can also be done with role="switch" and aria-checked="true".aria-expanded: If the button controls the open/closed state of another element (like a dropdown menu), you apply this attribute to indicate that like aria-expanded="true".aria-label: Overrides the text within the button. This is useful for labeling buttons that otherwise don’t have text, but you’re still probably better off using a visually-hidden class so it can be translated.aria-labelledby: Points to an element that will act as the label for the button.For that last one:
<button aria-labelledby="buttonText">
Time is running out!
<span id="buttonText">Add to Cart</span>
</button>Deque has a deeper dive blog post into button accessibility that includes much about ARIA.
If a button opens a dialog, your job is to move the focus inside and trap it there. When closing the dialog, you need to return focus back to that button so the user is back exactly where they started. This makes the experience of using a modal the same for someone who relies on assistive technology as for someone who doesn’t.
Focus management isn’t just for dialogs, either. If clicking a button runs a calculation and changes a value on the page, there is no context change there, meaning focus should remain on the button. If the button does something like „move to next page,” the focus should be moved to the start of that next page.
Don’t make buttons too small. That goes for links and any sort of interactive control. People with any sort of reduced dexterity will benefit.
The classic Apple guideline for the minimum size for a touch target (button) is 44x44pt.
Here’s some guidelines from other companies. Fitt’s Law tells us smaller targets have greater error rates. Google even takes button sizes into consideration when evaluating the SEO of a site.
In addition to ample size, don’t place buttons too close each other, whether they’re stacked vertically or together on the same line. Give them some margin because people experiencing motor control issues run the risk of clicking the wrong one.
Buttons work by being clicked/touched, pressing the Enter key, or pressing the Space key (when focused). Even if you add role="button" to a link or div, you won’t get the spacebar functionality, so at the risk of beating a dead horse, use <button> in those cases.
The post A Complete Guide to Links and Buttons appeared first on CSS-Tricks.
Post pobrano z: A Complete Guide to Links and Buttons
There is a lot to know about links and buttons in HTML. There is markup implementation and related attributes, styling best practices, things to avoid, and the even-more-nuanced cousins of the link: buttons and button-like inputs.
Let’s take a look at the whole world of links and buttons, and all the considerations at the HTML, CSS, JavaScript, design, and accessibility layers that come with them. There are plenty of pitfalls and bad practices to avoid along the way. By covering it, we’ll have a complete good UX implementation of both elements.
Quick guidelines on when to use each:
<a href="/somewhere">link</a>)<button type="button">button</button>)<input type="submit" value="Submit">)Links are one of the most basic, yet deeply fundamental and foundational building blocks of the web. Click a link, and you move to another page or are moved to another place within the same page.
<a href="https://css-tricks.com">CSS-Tricks</a>That’s a link to a „fully qualified” or „absolute” URL.
You can link „relatively” as well:
<!-- Useful in navigation, but be careful in content that may travel elsewhere (e.g. RSS) -->
<a href="/pages/about.html">About</a>That can be useful, for example, in development where the domain name is likely to be different than the production site, but you still want to be able to click links. Relative URLs are most useful for things like navigation, but be careful of using them within content — like blog posts — where that content may be read off-site, like in an app or RSS feed.
Links can also be „hash links” or „jump links” by starting with a #:
<a href="#section-2">Section Two</a>
<!-- will jump to... -->
<section id="section-2"></section>Clicking that link will „jump” (scroll) to the first element in the DOM with an ID that matches, like the section element above.
💥 Little trick: Using a hash link (e.g. #0) in development can be useful so you can click the link without being sent back to the top of the page like a click on a # link does. But careful, links that don’t link anywhere should never make it to production.
💥 Little trick: Jump-links can sometimes benefit from smooth scrolling to help people understand that the page is moving from one place to another.
It’s a fairly common UI/UX thing to see a „Back to top” link on sites, particularly where important navigational controls are at the top but there is quite a bit of content to scroll (or otherwise navigate) through. To create a jump link, link to the ID of an element that is at the top of the page where it makes sense to send focus back to.
<a href="#top-of-page">Back to Top</a>Jump links are sometimes also used to link to other anchor (<a>) elements that have no href attribute. Those are called „placeholder” links:
<a id="section-2"></a>
<h3>Section 2</h3>There are accessibility considerations of these, but overall they are acceptable.
A link without an href attribute is the only practical way to disable a link. Why disable a link? Perhaps it’s a link that only becomes active after logging in or signing up.
a:not[href] {
/* style a "disabled" link */
}When a link has no href, it has no role, no focusability, and no keyboard events. This is intentional. You could think of it like a <span>.
You can use the target attribute for that, but it is strongly discouraged.
<a href="https://css-tricks.com" target="_blank" rel="noopener noreferrer">
CSS-Tricks
</a>The bit that makes it work is target="_blank", but note the extra rel attribute and values there which make it safer and faster.
Making links open in new tabs is a major UX discussion. We have a whole article about when to use it here. Summarized:
Don’t use it:
Do use it:
The download attribute on a link will instruct the browser to download the linked file rather than opening it within the current page/tab. It’s a nice UX touch.
<a href="/files/file.pdf" download>Download PDF</a>rel attributeThis attribute is for the relationship of the link to the target.
The rel attribute is also commonly used on the <link> element (which is not used for creating hyperlinks, but for things like including CSS and preloading). We’re not including rel values for the <link> element here, just anchor links.
Here are some basic examples:
<a href="/page/3" rel="next">Next</a>
<a href="/page/1" rel="prev">Previous</a>
<a href="http://creativecommons.org/licenses/by/2.0/" rel="license">cc by 2.0</a>
<a href="/topics/" rel="directory">All Topics</a>rel="alternate": Alternate version of the document.rel="author": Author of the document.rel="help": A resource for help with the document.rel="license": License and legal information.rel="manifest": Web App Manifest document.rel="next": Next document in the series.rel="prev": Previous document in the series.rel="search": A document meant to perform a search in the current document.There are also some rel attributes specifically to inform search engines:
rel="sponsored": Mark links that are advertisements or paid placements (commonly called paid links) as sponsored.rel="ugc": For not-particularly-trusted user-generated content, like comments and forum posts.rel="nofollow": Tell the search engine to ignore this and not associate this site with where this links to.And also some rel attributes that are most security-focused:
rel="noopener": Prevent a new tab from using the JavaScript window.opener feature, which could potentially access the page containing the link (your site) to perform malicious things, like stealing information or sharing infected code. Using this with target="_blank" is often a good idea.rel="noreferrer": Prevent other sites or tracking services (e.g. Google Analytics) from identifying your page as the source of clicked link.You can use multiple space-separated values if you need to (e.g. rel="noopener noreferrer")
And finally, some rel attributes come from the microformats standard, like:
rel="directory": Indicates that the destination of the hyperlink is a directory listing containing an entry for the current page.rel="tag": Indicates that the destination of that hyperlink is an author-designated „tag” (or keyword/subject) for the current page.rel="payment": Indicates that the destination of that hyperlink provides a way to show or give support for the current page.rel="help": States that the resource linked to is a help file or FAQ for the current document.The default role of a link is link, so you do not need to do:
<a role="link" href="/">Link</a>You’d only need that if you were faking a link, which would be a weird/rare thing to ever need to do, and you’d have to use some JavaScript in addition to this to make it actually follow the link.
<span class="link" tabindex="0" role="link" data-href="/">
Fake accessible link created using a span
</span>Just looking above you can see how much extra work faking a link is, and that is before you consider that is breaks right-clicking, doesn’t allow opening in a new tab, doesn’t work with Windows High Contrast Mode and other reader modes and assistive technology. Pretty bad!
A useful ARIA role to indicate the current page, like:
<a href="/" aria-current="page">Home</a>
<a href="/contact">Contact</a>
<a href="/about">About/a></a>title attribute?Probably not. Save this for giving an iframe a short, descriptive title.
<a title="I don't need to be here" href="/">
List of Concerts
</a>title provides a hover-triggered UI popup showing the text you wrote. You can’t style it, and it’s not really that accessible.
Hover-triggered is the key phrase here. It’s unusable on any touch-only device. If a link needs more contextual information, provide that in actual content around the link, or use descriptive text the link itself (as opposed to something like „Click Here”).
If a link only has an icon inside it, like:
<a href="/">😃</a>
<a href="/">
<svg> ... </svg>
</a>That isn’t enough contextual information about the link, particularly for accessibility reasons, but potentially for anybody. Links with text are almost always more clear. If you absolutely can’t use text, you can use a pattern like:
<a href="/">
<!-- Hide the icon from assistive technology -->
<svg aria-hidden="true" focusable="false"> ... </svg>
<!-- Acts as a label that is hidden from view -->
<span class="visually-hidden">Useful link text</span>
</a>visually-hidden is a class used to visually hide the label text with CSS:
.visually-hidden {
border: 0;
clip: rect(0 0 0 0);
height: 1px;
margin: -1px;
overflow: hidden;
padding: 0;
position: absolute;
white-space: nowrap;
width: 1px;
}Unlike aria-label, visually hidden text can be translated and will hold up better in specialized browsing modes.
Images can be links if you wrap them in a link. There is no need to use the alt text to say the image is a link, as assistive technology will do that already.
<a href="/buy/puppies/now">
<img src="puppy.jpg" alt="A happy puppy.">
</a>You can link a whole area of content, like:
<a href="/article/">
<div class="card">
<h2>Card</h2>
<img src="..." alt="...">
<p>Content</p>
</div>
</a>But it’s slightly weird, so consider the UX of it if you ever do it. For example, it can be harder to select the text, and the entire element needs styling to create clear focus and hover states.
Take this example, where the entire element is wrapped in a link, but there are no hover and focus states applied to it.
If you need a link within that card element, well, you can’t nest links. You could get a little tricky if you needed ot, like using a pseudo-element on the link which is absolutely positioned to cover the whole area.
Additionally, this approach can make really long and potentially confusing announcements for screen readers. Even though links around chunks of content is technically possible, it’s best to avoid doing this if you can.
Here’s the default look of a link:
It’s likely you’ll be changing the style of your links, and also likely you’ll use CSS to do it. I could make all my links red in CSS by doing:
a {
color: red;
}Sometimes selecting and styling all links on a page is a bit heavy-handed, as links in navigation might be treated entirely differently than links within text. You can always scope selectors to target links within particular areas like:
/* Navigation links */
nav a { }
/* Links in an article */
article a { }
/* Links contained in an element with a "text" class */
.text a { }Or select the link directly to style.
.link {
/* For styling <a class="link" href="/"> */
}
a[aria-current="page"] {
/* You'll need to apply this attribute yourself, but it's a great pattern to use for active navigation. */
}Links are focusable elements. In other words, they can be selected using the Tab key on a keyboard. Links are perhaps the most common element where you’ll very consciously design the different states, including a :focus state.
:hover: For styling when a mouse pointer is over the link.:visited: For styling when the link has been followed, as best as the browser can remember. It has limited styling ability due to security.:link: For styling when a link has not been visited.:active: For styling when the link is pressed (e.g. the mouse button is down or the element is being tapped on a touch screen).:focus: Very important! Links should always have a focus style. If you choose to remove the default blue outline that most browsers apply, also use this selector to re-apply a visually obvious focus style.These are chainable like any pseudo-class, so you could do something like this if it is useful for your design/UX.
/* Style focus and hover states in a single ruleset */
a:focus:hover { }Perhaps some of the confusion between links and buttons is stuff like this:
That certainly looks like a button! Everyone would call that a button. Even a design system would likely call that a button and perhaps have a class like .button { }. But! A thing you can click that says „Learn More” is very much a link, not a button. That’s completely fine, it’s just yet another reminder to use the semantically and functionally correct element.
Since we often style links with a distinct color, it’s important to use a color with sufficient color contrast for accessibility. There is a wide variety of visual impairments (see the tool WhoCanUse for simulating color combinations with different impairments) and high contrast helps nearly all of them.
Perhaps you set a blue color for links:
While that might look OK to you, it’s better to use tools for testing to ensure the color has a strong enough ratio according to researched guidelines. Here, I’ll look at Chrome DevTools and it will tell me this color is not compliant in that it doesn’t have enough contrast with the background color behind it.
Color contrast is a big consideration with links, not just because they are often colored in a unique color that needs to be checked, but because they have all those different states (hover, focus, active, visited) which also might have different colors. Compound that with the fact that text can be selected and you’ve got a lot of places to consider contrast. Here’s an article about all that.
We can get clever in CSS with attribute selectors and figure out what kind of resource a link is pointing to, assuming the href value has useful stuff in it.
/* Style all links that include .pdf at the end */
a[href$=".pdf"]::after {
content: " (PDF)";
}
/* Style links that point to Google */
a[href*="google.com"] {
color: purple;
}CSS has an „at-rule” for declaring styles that only take effect on printed media (e.g. printing out a web page). You can include them in any CSS like this:
@media print {
/* For links in content, visually display the link */
article a::after {
content: " (" attr(href) ")";
}
}If you needed to take all the styling off a link (or really any other element for that matter), CSS provides a way to remove all the styles using the all property.
.special-area a {
all: unset;
all: revert;
/* Start from scratch */
color: purple;
}You can also remove individual styles with keywords. (Again, this isn’t really unique to links, but is generically useful):
a {
/* Grab color from nearest parent that sets it */
color: inherit;
/* Wipe out style (turn black) */
color: initial;
/* Change back to User Agent style (blue) */
color: revert;
}Say you wanted to stop the clicking of a link from doing what it normally does: go to that link or jump around the page. In JavaScript, you can usepreventDefault to prevent jumping around.
const jumpLinks = document.querySelectorAll("a[href^='#']");
jumpLinks.forEach(link => {
link.addEventListener('click', event => {
event.preventDefault();
// Do something else instead, like handle the navigation behavior yourself
});
});This kind of thing is at the core of how „Single Page Apps” (SPAs) work. They intercept the clicks so browsers don’t take over and handle the navigation.
SPAs see where you are trying to go (within your own site), load the data they need, replace what they need to on the page, and update the URL. It’s an awful lot of work to replicate what the browser does for free, but you get the ability to do things like animate between pages.
Another JavaScript concern with links is that, when a link to another page is clicked, the page is left and another page loads. That can be problematic for something like a page that contains a form the user is filling out but hasn’t completed. If they click the link and leave the page, they lose their work! Your only opportunity to prevent the user from leaving is by using the beforeunload event.
window.addEventListener("beforeunload", function(event) {
// Remind user to save their work or whatever.
});A link that has had its default behavior removed won’t announce the new destination. This means a person using assistive technology may not know where they wound up. You’ll have to do things like update the page’s title and move focus back up to the top of the document.
In a JavaScript framework, like React, you might sometimes see links created from something like a <Link /> component rather than a native <a> element. The custom component probably creates a native <a> element, but with extra functionality, like enabling the JavaScript router to work, and adding attributes like aria-current="page" as needed, which is a good thing!
Ultimately, a link is a link. A JavaScript framework might offer or encourage some level of abstraction, but you’re always free to use regular links.
We covered some accessibility in the sections above (it’s all related!), but here are some more things to think about.
role="link") so there’s no need to explicitly set it.<a href="google.com">google.com</a>)alt text anyway, but doubly so when the image is wrapped in a link with otherwise no text.Some assistive technology can create lists of interactive elements on the page. Imagine a group of four article cards that all have a „Read More”, the list of interactive elements will be like:
Not very useful. You could make use of that .visually-hidden class we covered to make the links more like:
<a href="/article">
Read More
<span class="visually-hidden">
of the article "Dancing with Rabbits".
<span>
</a>Now each link is unique and clear. If the design can support it, do it without the visually hidden class to remove the ambiguity for everyone.
Buttons are for triggering actions. When do you use the <button> element? A good rule is to use a button when there is “no meaningful href.” Here’s another way to think of that: if clicking it doesn’t do anything without JavaScript, it should be a <button>.
A <button> that is within a <form>, by default, will submit that form. But aside from that, button elements don’t have any default behavior, and you’ll be wiring up that interactivity with JavaScript.
<button>Buy Now</button>Buttons inside of a <form> do something by default: they submit the form! They can also reset it, like their input counterparts. The type attributes matter:
<form action="/" method="POST">
<input type="text" name="name" id="name">
<button>Submit</button>
<!-- If you want to be more explicit... -->
<button type="submit">Submit</button>
<!-- ...or clear the form inputs back to their initial values -->
<button type="reset">Reset</button>
<!-- This prevents a `submit` action from firing which may be useful sometimes inside a form -->
<button type="button">Non-submitting button</button>
</form>Speaking of forms, buttons have some neat tricks up their sleeve where they can override attributes of the <form> itself.
<form action="/" method="get">
<!-- override the action -->
<button formaction="/elsewhere/" type="submit">Submit to elsewhere</button>
<!-- override encytype -->
<button formenctype="multipart/form-data" type="submit"></button>
<!-- override method -->
<button formmethod="post" type="submit"></button>
<!-- do not validate fields -->
<button formnovalidate type="submit"></button>
<!-- override target e.g. open in new tab -->
<button formtarget="_blank" type="submit"></button>
</form>Since buttons are focusable elements, we can automatically focus on them when the page loads using the autofocus attribute:
<div class="modal">
<h2>Save document?</h2>
<button>Cancel</button>
<button autofocus>OK</button>
</div>Perhaps you’d do that inside of a modal dialog where one of the actions is a default action and it helps the UX (e.g. you can press Enter to dismiss the modal). Autofocusing after a user action is perhaps the only good practice here, moving a user’s focus without their permission, as the autofocus attribute is capable of, can be a problem for screen reader and screen magnifier users.
Note thatautofocus may not work if the element is within an <iframe sandbox> for security reasons.
To prevent a button from being interactive, there is a disabled attribute you can use:
<button disabled>Pay Now</button>
<p class="error-message">Correct the form above to submit payment.</p>Note that we’ve included descriptive text alongside the disabled button. It can be very frustrating to find a disabled button and not know why it’s disabled. A better way to do this could be to let someone submit the form, and then explain why it didn’t work in the validation feedback messaging.
Regardless, you could style a disabled button this way:
/* Might be good styles for ANY disabled element! */
button[disabled] {
opacity: 0.5;
pointer-events: none;
} We’ll cover other states and styling later in this guide.
A submit button and a submit input (<input type="submit">) are identical in functionality, but different in the sense that an input is unable to contain child elements while a button can.
<button>
<svg aria-hidden="true" focusable="false">
<path d="..." />
</svg>
<span class="callout">Big</span>
Sale!
</button>
<button type="button">
<span role="img" aria-label="Fox">
🦊
</span>
Button
</button>Note the focusable="false" attribute on the SVG element above. In that case, since the icon is decorative, this will help assistive technology only announce the button’s label.
Buttons are generally styled to look very button-like. They should look pressable. If you’re looking for inspiration on fancy button styles, you’d do well looking at the CodePen Topic on Buttons.
How buttons look by default varies by browser and platform.
border: 0; to those same buttons as above, and we have different styles entirely.While there is some UX truth to leaving the defaults of form elements alone so that they match that browser/platform’s style and you get some affordance for free, designers typically don’t like default styles, particularly ones that differ across browsers.
Removing all the styles from a button is easier than you think. You’d think, as a form control, appearance: none; would help, but don’t count on that. Actually all: revert; is a better bet to wipe the slate clean.
You can see how a variety of properties are involved
And that’s not all of them. Here’s a consolidated chunk of what Normalize does to buttons.
button {
font-family: inherit; /* For all browsers */
font-size: 100%; /* For all browsers */
line-height: 1.15; /* For all browsers */
margin: 0; /* Firefox and Safari have margin */
overflow: visible; /* Edge hides overflow */
text-transform: none; /* Firefox inherits text-transform */
-webkit-appearance: button; /* Safari otherwise prevents some styles */
}
button::-moz-focus-inner {
border-style: none;
padding: 0;
}
button:-moz-focusring {
outline: 1px dotted ButtonText;
}.button classIn addition to using reset or baseline CSS, you may want to have a class for buttons that gives you a strong foundation for styling and works across both links and buttons.
.button {
border: 0;
border-radius: 0.25rem;
background: #1E88E5;
color: white;
font-family: -system-ui, sans-serif;
font-size: 1rem;
line-height: 1.2;
white-space: nowrap;
text-decoration: none;
padding: 0.25rem 0.5rem;
margin: 0.25rem;
cursor: pointer;
}Check out this Pen to see why all these properties are needed to make sure it works correctly across elements.
Just as with links, you’ll want to style the states of buttons.
button:hover { }
button:focus { }
button:active { }
button:visited { } /* Maybe less so */You may also want to use ARIA attributes for styling, which is a neat way to encourage using them correctly:
button[aria-pressed="true"] { }
button[aria-pressed="false"] { }There are always exceptions. For example, a website in which you need a button-triggered action within a sentence:
<p>You may open your <button>user settings</button> to change this.</p>We’ve used a button instead of an anchor tag in the above code, as this hypothetical website opens user settings in a modal dialog rather than linking to another page. In this situation, you may want to style the button as if it looks like a link.
This is probably rare enough that you would probably make a class (e.g. .link-looking-button) that incorporates the reset styles from above and otherwise matches what you do for anchor links.
Remember earlier when we talked about the possibility of wrapping entire elements in links? If you have a button within another element, but you want that entire outer element to be clickable/tappable as if it’s the button, that’s a „breakout” button. You can use an absolutely-positioned pseudo-element on the button to expand the clickable area to the whole region. Fancy!
Even without JavaScript, button elements can be triggered by the Space and Enter keys on a keyboard. That’s part of what makes them such appealing and useful elements: they are discoverable, focusable, and interactive with assistive technology in a predictable way.
Perhaps any <button> in that situation should be inserted into the DOM by JavaScript. A tall order! Food for thought. 🤔
Say a button does something pretty darn important, like submitting a payment. It would be pretty scary if it was programmed such that clicking the button multiple times submitted multiple payment requests. It is situations like this where you would attach a click handler to a button that only runs once. To make that clear to the user, we’ll disable the button on click as well.
document.querySelector("button").addEventListener('click', function(event) {
event.currentTarget.setAttribute("disabled", true);
}, {
once: true
});Then you would intentionally un-disable the button and reattach the handler when necessary.
JavaScript can be executed by activating a button through code on the button itself:
<button onclick="console.log('clicked');">
Log it.
</button>
<button onmousedown="">
</button>
<button onmouseup="">
</button>That practice went from being standard practice to being a faux pas (not abstracting JavaScript functionality away from HTML) to, eh, you need it when you need it. One advantage is that if you’re injecting this HTML into the DOM, you don’t need to bind/re-bind JavaScript event handlers to it because it already has one.
It’s common in any JavaScript framework to make a component for handling buttons, as buttons typically have lots of variations. Those variations can be turned into an API of sorts. For example, in React:
const Button = ({ className, children }) => {
const [activated, setActivated] = React.useState(false);
return (
<button
className={`button ${className}`}
aria-pressed={activated ? "true" : "false")
onClick={() => setActivated(!activated)}
>
{children}
</button>
);
};In that example, the <Button /> component ensures the button will have a button class and handles a toggle-like active class.
The biggest accessibility consideration with buttons is actually using buttons. Don’t try to replicate a button with a <div> or a <span>, which is, unfortunately, more common than you might think. It’s very likely that will cause problems. (Did you deal with focusability? Did you deal with keyboard events? Great. There’s still probably more stuff you’re forgetting.)
Like all focusable elements, browsers apply a default focus style, which is usually a blue outline.
While it’s arguable that you should leave that alone as it’s a very clear and obvious style for people that benefit from focus styles, it’s also not out of the question to change it.
What you should not do is button:focus { outline: 0; } to remove it. If you ever remove a focus style like that, put it back at the same time.
button:focus {
outline: 0; /* Removes the default blue ring */
/* Now, let's create our own focus style */
border-radius: 3px;
box-shadow: 0 0 0 2px red;
}The fact that a button may become focused when clicked and apply that style at the same time is offputting to some. There is a trick (that has limited, but increasing, browser support) on removing focus styles from clicks and not keyboard events:
:focus:not(:focus-visible) {
outline: 0;
}Buttons already have the role they need (role="button"). But there are some other ARIA attributes that are related to buttons:
aria-pressed: Turns a button into a toggle, between aria-pressed="true" and aria-pressed="false". More on button toggles, which can also be done with role="switch" and aria-checked="true".aria-expanded: If the button controls the open/closed state of another element (like a dropdown menu), you apply this attribute to indicate that like aria-expanded="true".aria-label: Overrides the text within the button. This is useful for labeling buttons that otherwise don’t have text, but you’re still probably better off using a visually-hidden class so it can be translated.aria-labelledby: Points to an element that will act as the label for the button.For that last one:
<button aria-labelledby="buttonText">
Time is running out!
<span id="buttonText">Add to Cart</span>
</button>Deque has a deeper dive blog post into button accessibility that includes much about ARIA.
If a button opens a dialog, your job is to move the focus inside and trap it there. When closing the dialog, you need to return focus back to that button so the user is back exactly where they started. This makes the experience of using a modal the same for someone who relies on assistive technology as for someone who doesn’t.
Focus management isn’t just for dialogs, either. If clicking a button runs a calculation and changes a value on the page, there is no context change there, meaning focus should remain on the button. If the button does something like „move to next page,” the focus should be moved to the start of that next page.
Don’t make buttons too small. That goes for links and any sort of interactive control. People with any sort of reduced dexterity will benefit.
The classic Apple guideline for the minimum size for a touch target (button) is 44x44pt.
Here’s some guidelines from other companies. Fitt’s Law tells us smaller targets have greater error rates. Google even takes button sizes into consideration when evaluating the SEO of a site.
In addition to ample size, don’t place buttons too close each other, whether they’re stacked vertically or together on the same line. Give them some margin because people experiencing motor control issues run the risk of clicking the wrong one.
Buttons work by being clicked/touched, pressing the Enter key, or pressing the Space key (when focused). Even if you add role="button" to a link or div, you won’t get the spacebar functionality, so at the risk of beating a dead horse, use <button> in those cases.
The post A Complete Guide to Links and Buttons appeared first on CSS-Tricks.
Post pobrano z: How to Remove a Background in Photoshop
If you want to learn how to remove a background in Photoshop or how to make a background transparent in Photoshop, in this tutorial I will show you the most universal method for achieving this goal. I’ll teach you how to isolate the object, and how to keep its edges smooth in the process.
Follow along with us over on our Envato Tuts+ YouTube channel:
You can use any photo for this tutorial, but if you want to follow my steps directly, download this image:
First, we need to tell Photoshop where the object ends and the background starts. There are many selection tools available, but if you want to be precise, it’s best to use the Pen Tool (P). Try to imagine the selection outline. Zoom in and click somewhere on this imaginary outline.
Find another place to click—this time click and hold. A line will appear between the two points. If you move your cursor now, you’ll have a chance to control the shape of the curve. Try to make it fit the imaginary selection outline.
Remember not to drag too far—the handle you’re dragging should land on the outline. The curvier the area, the closer you should place your points. Don’t be afraid to Undo and try again if you placed a point too far away.
Once you’ve gone around the whole object, simply click the first point to close the outline.
Sometimes, objects have an inner outline as well. Select it the same way.
Press Control-Enter to turn the path into a selection.
You could remove the background now, but we can do one more thing to make the effect more convincing. Press Control-Alt-R to refine the edge of the selection. Change the View Mode to On Black, and check Smart Radius.
Experiment with the Radius and Adjust Edge settings to make the edge of selection smoother and more natural. If the background was blurry, the object should have slightly blurry edges as well.
When you’re done, set the Output to Layer Mask and press OK.
The background has disappeared! But sometimes, only after removing the background do you notice a flaw in the selection. It’s not a problem at all—just click the Layer Mask to select it and then paint carefully with black and white. Black will remove the area, and white will bring it back. You can also use various shades of gray to create a semi-transparent effect.
Additionally, you can use this technique to bring back the shadow that belongs to the object, not the background. This will make the isolated object look more complete.
If you’re happy with the selection, right-click the Layer Mask and select Apply Layer Mask. The background will be permanently removed.
If you ever wanted to know how to change the background color in Photoshop, now you’re able to do it—use the Paint Bucket Tool (G) on a layer below, or place a photo, or fill it with a pattern.
Now you know how to remove a background in Photoshop!
Do you want to learn more about creating photo effects, or maybe even Photoshop actions? Try these tutorials as well:
