I got to talk to Paulina Hetman this week! Paulina is a heck of a creative coder, using her skills as an illustrator and all-around web developer to make ideas come to life. And she doesn’t keep all those ideas to herself, she spends time educating other budding developers both professionally and by building courses and things like her incredibly clever quizzes (as Pens!).
Notion is an amazing collaborative tool that not only helps organize your company’s information but helps with project management as well. We know that all too well here at CodePen, as we use Notion for countless business tasks. Learn more and get started for free at notion.com/codepen. Take your first step toward an organized, happier team, today.
Sometimes when creating inset borders, we want to set them at different distances from the edge of the element. There are several ways to do this in CSS, which can all be applicable depending on the situation you find yourself in.
Let's look at the different ways to create inset borders with CSS.
This week I got to speak with Chris Nager! I’ve known Chris quite a while. I remember being inspired by his hand-drawn SVG plus symbol and subsequent guide to <path> commands, which inspired my own shortly after I was properly obsessed with SVG. We talk about all sorts of things like accessibility, how far CSS has come, and some of the amazing stuff that has shipped recently in Safari Technical Preview. Check out Chris’ Twitter, personal site, and classic great project Give ‘n’ Go, a CodePen/Dribbble crossover website.
One of the hottest and admittedly controversial CSS frameworks to land on the front-end scene in recent years is Tailwind CSS, and this Tailwind CSS tutorial for beginners will try to get you up to speed with what it’s all about. I’ll cover the basics, along with why you might want to use a tool like Tailwind CSS to build your web pages, and how Tailwind changes your whole view of HTML and CSS.
GiveWP quietly released its new plugin, Donation Form Block for Stripe, in the WordPress directory last week. It is a standalone block that allows users to accept donations almost instantly. No complicated setup. Just install, activate, connect to Stripe, and play.
I named the GiveWP plugin my favorite of 2019. The team behind the donation plugin has consistently produced top-tier plugins and extensions, and I have long been of fan of the company’s work. It did not take me long to install and activate its latest plugin.
Donation Form Block for Stripe is essentially a lite version of GiveWP. The primary product is far more powerful and has an entire ecosystem of extensions built around it. In general, it is geared more toward charities, non-profits, and other fundraising efforts where users might need more flexibility, reporting, and integration with third-party systems. It can be overkill for someone who merely needs a simple donation form.
The one-off donation form block is better-suited for those “buy me a coffee” scenarios than well-organized fundraisers. I am glad to see GiveWP tackling this side of the donation arena.
Inserting the block is as easy as adding any other. However, before using it, users should connect their Stripe account, and the plugin provides a handy button for doing so in the block sidebar:
Connecting to Stripe.
The Stripe connection persists, so it only needs to be configured once. From that point, everything is relatively straightforward. Plug in a few details and publish.
In a couple of minutes, I had created and published a fictional fundraiser for cleaning a local basketball court.
Full donation form on the front end.
As much as I love the idea of this block, I was not entirely happy with the user experience. However, keeping in mind that this is version 1.0.x, it has a ton of potential.
GiveWP’s donation form managed to break nearly every one of my block-related cardinal sins while still managing to be an exceptional product.
Users must add an image, custom text, and donation field text via the block options sidebar. This means there is no Rich Text input, so users cannot even add simple bold and italic styles. It also feels unintuitive working from the sidebar instead of modifying the fields directly from the content canvas.
Text editing in the sidebar instead of the block in the content canvas.
A more ideal approach would have used the “inner blocks” feature to put Heading, Paragraph, and Image/Cover blocks — locked in place — into the main donation form. It could have done the same with the buttons and other form elements via custom blocks.
Ultimately, most of the problems are related to control over the design. One of the worst things block plugins can do is overrule everything the theme styles on the front end.
Do not get me wrong; blocks should ensure quality control over their own output. Their functionality should be unencumbered, and their layout should work well regardless of the theme.
However, this donation block takes its duties a step too far, using JavaScript to inject CSS into the page and doubling up on the specificity with !important. Even if a theme wanted to integrate with the block, it is next to impossible to style the donation form elements. Is there really any reason that the inputs are required to have 2px, solid, rounded borders?
And, why are my theme and user-registered colors not even available for the single color option provided?
Theme colors not selectable.
That is what frustrates me the most — not just with this block. WordPress has built this standardized system that allows communication between the platform, plugins, themes, and end-users. It lets developers build output that should always be customizable. By no means does it cover every Aspect of design. However, the foundational components are in place. Colors and font sizes have been around for over three years. Extended typography and border controls are available now.
There is no way to make a wide or full-width form. The block does not support alignments, and even when wrapping a Group block, the plugin limits it to a maximum width of 650 pixels.
Some of these problems are similar to the issues I was writing about nearly two years ago with the release of GiveWP 2.7. I would have liked to have seen them addressed on an entirely new plugin release from the outset.
Despite my complaints, the plugin does the one thing it must do correctly, at least as good as anyone and better than most. It makes accepting donations as simple as inserting a block into a page, customizing a handful of fields, and hitting the publish button. If the dev team never added another enhancement, that would be all most of its users need.
One of the ways to help get a grasp of CSS specificity is thinking terms of “what beats what” or how strong the specificity is. Manuel Matuzovic has a helpful interactive step-by-step demo. You keep clicking the “Add selector” button, and the CSS shown (and applied to the page) changes with ever-increasingly-strong selectors applied to the body that change the background-color. At the end, it veers into not-really-selectors trickery, like using @keyframes to override things.
More specificity practice
If you enjoyed the trickery at the end, check out Francisco Dias’ A Specificity Battle!, an article we published a few years back that does a back-and-forth styling battle with nineteen steps “selecting” the same element to re-style it. CSS is cray sometimes.
Maintaining the same form styles and appearance across all of your forms has never been easier with Forminator’s Global Appearance Presets.
The look and style of a form you create with our free plugin, Forminator, can be replicated and used for all of your forms. Even change existing forms to your new style and appearance with a click of a button!
This article shows you how it’s done. We’ll be covering how to…
Using a form to your specification across multiple platforms is excellent for branding, saves you time, and helps manage your form creation as simple as possible.
Let’s get to it!
Update the Default Preset
Forminator starts from scratch with its Default preset. Before we dive into making new presets, here’s a look at how you can change the default settings.
The whole process begins in Settings and Appearance Presets. You’ll see at the top of the page an area called Preset.
This Preset dropdown is what shows up first.
The preset design that pops up is Forminator’s Default Preset.
This is the blank slate of style for your form.
Underneath this, jazz things up for the default design. You have your choice of any Color, Hundreds of Fonts, Form Container, and even Custom CSS.
Check out all of the configurations options in our documentation and below…
There are a TON of configuration options.
When you have it edited according to your configuration, hit Update – and that’s it! We’ll talk about how to apply it to all of your forms and more coming up in this article.
Create a New Preset
Let’s say you want to create a new preset and leave the default one alone. Or, you decide to change the default configuration and make a new configuration. Either way – it’s simple to do!
We’ll head back to the banner on the top of the Settings and Appearance Presets web page. From there, it’s just a matter of clicking on the plus sign for a New Preset.
New Preset is a click away!
You’ll first give the form a Preset Name.
This window will appear after hitting New Preset.
Additionally, you can import the style from an existing form that you created by clicking the Import Style From Form dropdown. It’s up to you.
All of my current forms are displayed.
We’ll create a new preset for this example and name it Preset One. Once named, you’ll hit Create Preset.
Name the preset anything you’d like!
After that, you’ll see the new preset in the dropdown.
All of your presets will be shown here.
And that’s all it takes. If needed, you can access it at any time to edit.
All of your presets will appear in the dropdown. You can create unlimited amounts of presets as you want!
Apply Your Preset to Multiple Forms in Bulk
There are several ways to apply a preset to multiple forms – either in bulk or individually. All of this is done from Forminator’s dashboard under Forms.
Let’s say you want to apply a preset to ALL of your forms. That can be done in just a few clicks. Simply click the checkbox to the left of the dropdown, and click Apply Appearance Preset.
This updates all of the forms at once.
After choosing your bulk action, you’ll select which preset you’d like to apply. Select the one you’ll use from the dropdown, click Apply Preset – and you’re done.
All the presets created will show in the dropdown.
Additionally, you can check only certain forms to apply the appearance preset. The choice is yours!
Add Preset to Individual Form
You can use the method I just touched on with bulk by checking the box to the form you want to change. However, there’s another option.
Each form has a Gear icon. When clicked, a dropdown appears of various functions (e.g. preview, duplicate, etc.). One of those options is Apply Preset.
All of your forms will have the gear icon.
Just like with bulk presets, you’ll choose which preset form you’d like to apply. The preset will then be applied to that individual form.
Looks and Style at Peak Per-FORM-ance
As you can see, it’s as easy as ever to apply Forminator’s Global Appearance Presets to all or individual forms. It makes branding and form creation much more manageable than starting from scratch with each new form you create.
This keeps the style of your form and looks consistent throughout, no matter where you’re using them.
If you haven’t yet, be sure to start using our Forminator plugin to implement this useful feature and check out the documentation if you need help. Forminator is free to use, with over 200k active installs and a solid 5-star review.
I grabbed Adam intending to chat about all sorts of CSS stuff and his work at Google and on VisBug. But then we chatted pretty much the entire time about color and what’s coming there to the web platform.
WordPress.com is the fastest way to spin up a WordPress site. You’ll be able to build any sort of site around it to power your business or hobby. How do you make the most of it? Subscribe to their brand spankin’ new YouTube channel to learn more about using your site and what fellow customers are doing with theirs.
A while back, I wrote an article on 3d interactive CSS buttons. Using a similar technique, I decided to design some 3d interactive (and flippable) CSS user cards. These also work great for lots of different things - for example, a bank card UI, a playing card UI, or just a team's page. The demo can be seen below!
Now imagine you don’t always want all the transform values to be applied, so some are optional. You might think of CSS optional custom property values:
But surprisingly using optional custom property values like this does not work as intended. If the --transform variable is not defined the whole property will not be applied. I’ve got a little “trick” to fix this and it looks like this:
Notice the difference? There is a fallback defined in there that is set to an empty value: (, )
That’s the trick, and it’s very useful! Here’s what the specification has to say:
In an exception to the usual comma elision rules, which require commas to be omitted when they’re not separating values, a bare comma, with nothing following it, must be treated as valid in var(), indicating an empty fallback value.
This is somewhat spiritually related to the The CSS Custom Property Toggle Trick that takes advantage of a custom property having the value of an empty space.
Demo
Like I said, this is useful and works for any multi-value CSS property. The following demo shows it using text-shadow, background, and filter in addition to the transform example we just discussed.
Some properties that accept multiple values, like text-shadow, require special treatment because they only work with a comma delimiter. In those cases, when the CSS custom property is defined, you (as the code author) know it is only to be used in a situation where a value is already defined where the custom property is used. Then a comma should be inserted directly in the custom property before the first value, like this:
--text-shadow: ,0 0 5px black;
This, of course, inhibits the ability to use this variable in places where it’s the only value of some property. That can be solved, though, by creating “layers” of variables for abstraction purposes, i.e. the custom property is pointing to lower level custom properties.
Beware of Sass compiler
While exploring this trick, uncovered a bug in the Sass compiler that strips away the empty value (,) fallback, which goes against the spec. I’ve reported the bug and hope it will be fixed up soon.
As a temporary workaround, a fallback that causes no rendering can be used, such as:
CSS transitions give us the ability to smoothly transition from one set of styles to another. Without them, your hover, click and transform effects can look janky and sudden.
To illustrate a CSS transition, below are two emojis. Click on them to see the difference:
Louis Hoebregts (aka Mamboleoo) has been creating wonderfully creative Pens on CodePen for many years. His early work, as we learn on this episode, was inspired by the CSS trickery of Lea Verou! He rotates his tools between HTML and CSS, SVG, and canvas, but tends to have an Aspect of motion and the unexpected. Some of the most popular Pens have an Aspect of education to them as well. Here’s a list of Louis’ Pens he chose to talk about, covering some of his history here, each of which is symbolic of a personal era and often unlocking new professional doors:
WooCommerce can do it all as far as adding eCommerce functionality to a WordPress site. One off product sales, for sure, including shipping and inventory management and all that. But it can also sell digital products. It can also sell memberships and subscriptions. Put on your what if hat. What if your business sold memberships? What could you offer? It’s always worth thinking about.
Paper documents were the original metaphor for the web. […]
The page you’re reading this on still mimics paper. We still call it a page or an HTML document. It follows the same typographic rules and conventions – black text on white backgrounds and a top-to-bottom / left-to-right heirarchical structure.
Over in the ShopTalk Discord, the idea of CSS custom properties named --ink and --paper came up the other day as abstractions for color and background-color and I kinda like it. There’s something more clear about the meanings of those terms to me.
But Maggie gets into some of the downsides of the paper-based metaphors, pointing out Ted Nelson’s critiques. This is interesting:
We treat the page as the smallest unit of linkable information, instead of the sentence or paragraph.
Will the main metaphor of the web as paper change in time? I’d say it’s highly likely. The interactivity and behavior we expect on the web today is a million miles different than we expected in the past and that’s going to keep happening. These updates accelerate the change. Perhaps someday the metaphors will have shifted to “alternate neighborhood,” “second brain,” or “dedicated assistant.”
CSS overrides can change the default look of almost anything:
You can use CSS to override what a checkbox or radio button looks like, but if you don’t, the checkbox will look like a default checkbox on your operating system and some would say that’s best for accessibility and usability.
You can use CSS to override what a select menu looks like, but if you don’t, the select will look like a default select menu on your operating system and some would say that’s best for accessibility and usability.
You can override what anchor links look like, but some would say they should be blue with underlines because that is the default and it’s best for accessibility and usability.
You can override what scrollbars look like, but if you don’t, the scrollbars will look (and behave) the way default scrollbars do on your operating system, and some would say that’s best for accessibility and usability.
In my experience, everyone has a different line. Nearly everybody styles their buttons. Nearly everybody styles their links, but some might only customize the hue of blue and leave the underline, drawing the line at more elaborate changes. It’s fairly popular to style form elements like checkboxes, radio buttons, and selects, but some people draw the line before that.
Some people draw a line saying you should never change a default cursor, some push that line back to make the cursor into a pointer for created interactive elements, some push that line so far they are OK with custom images as cursors. Some people draw the line with scrollbars saying they should never be customized, while some people implement elaborate designs.
CSS is a language for changing the design of websites. Every ruleset you write likely changes the defaults of something. The lines are relatively fuzzy, but I’d say there is nothing in CSS that should be outright banned from use — it’s more about the styling choices you make. So when you do choose to style something, it remains usable and accessible. Heck, background-color can be terribly abused making for inaccessible and unusable areas of a site, but nobody raises pitchforks over that.
Ahmad Shadeed nails it again with “Defensive CSS.” The idea is that you should write CSS to be ready for issues caused by dynamic content.
More items than you thought would be there? No problem, the area can expand or scroll. Title too long? No problem, it either wraps or truncates, and won’t bump into anything weird because margins or gaps are set up. Image come over in an unexpected size? No worries, the layout is designed to make sure the dedicated area is filled with image and will handle the sizing/cropping accordingly.
There is no such thing as being a good CSS developer and not coding defensively. This is what being a CSS developer is, especially when you factor in progressive enhancement concepts and cross-browser/device unknowns.
One thing people can do to make their websites better is to remember that you are not representative of all your users. Our life experiences and how we interact with the web are not indicative of how everyone interacts with the web.
We must care about accessibility.
Some users rely on assistive technology to navigate web pages.
We must care about multi-language support.
Layouts that make sense to me, as a native English speaker (a left-to-right language) don’t necessarily make sense in Arabic (a right-to-left language) and can’t simply be swapped from a content perspective.
We must care about common/familiar UX paradigms.
What may be obvious to you may not be obvious to other users.
Take the time to research your key user markets and understand how these users expect your website or product to function. Don’t forget accessibility. Don’t forget internationalization. And don’t forget that you are not the representation of all users.
Do you need to add custom styling to the first and last items of your WordPress navigation menu?
You could simply add a custom CSS class to the first and last menu items, but if the menu is rearranged, then those items will no longer be first and last.
In this article, we’ll show you how to add a .first and .last class that will style the first and last menu items even if the menu items are reordered.
Why Style the First and Last Navigation Items Differently?
In a past custom design project, we needed to add some custom styling to the navigation menu items of a WordPress website. This design in particular required different styling for the first menu item and the last menu item.
Now we could easily edit the menu and add a custom CSS class to the first and last menu item. But because we were delivering the project to a client, our solution had to work even if they rearranged the order of the menus.
In this tutorial, we’ll show you two ways to style the first and last items of your navigation menu. You can choose your preferred method from the list below:
This creates .first and .last CSS classes for your first and last navigation menu items respectively. You can use those classes to style the menu items.
For this tutorial, we’ll add the following basic CSS formatting to our theme’s style.css stylesheet to simply bold the first and last menu items:
.first a {font-weight: bold;}
.last a {font-weight: bold;}
Here you can see screenshots before and after we added the code to our demo site.
Method 2: Styling First and Last Items Using CSS Selectors
A second way to style the first and last menu items differently is to use CSS selectors. This method is simpler, but it may not work with some older browsers, such as Internet Explorer.
Note that you will need to replace ‘yourmenuid’ with the actual ID of the navigation menu. The selectors ‘first-child’ and ‘last-child’ select an element if it is the first and last child of its parent, which is the navigation menu.
For example, we used this code to bold the first and last navigation menu items on our demo site:
ul#primary-menu-list > li:first-child a {
font-weight: bold;
}
ul#primary-menu-list > li:last-child a {
font-weight: bold;
}
We hope this tutorial helped you learn how to add the .first and .last class to WordPress navigation menus.
You get an extra-round-y appearance in Safari, which at one time matched the macOS look for search inputs, but not really anymore. I don’t hate the look, except…
Safari totally ignores the font-size you set on it, so careful about that. Unless you smash off the round-y look with -webkit-appearance: none—then you can, so probably 92% of all websites do this.
You get a little × icon inside the input (when it has a value) that clears it out. This is probably the best reason to use it, and mercifiully you get to keep it even after resetting the appearance.
You get the satisfaction of knowing that you’re using the semantically correct input type for the job, assuming you are building a thing that actually searches something.
You get past search terms with autocomplete. Browsers store those past search terms and offer a menu for autocompleting them. I’m trying to make this a list of things that are unique to search inputs, and I can prove this happens on non-search inputs. But hey, it does make the most sense on search inputs.
You get the pleasure of adding a role to the parent form (i.e. <form role="search">) because that helps assistive technology announce it as a search form.
You get to remember to add a proper <label> to the input. Just using a magnifying glass icon or just a placeholder alone won’t cut it, even though that’s what a lot of designs call for visually.
You get a super weird incremental attribute that sends a debounced search event to the DOM element itself. I guess that is useful for live search UX. But it’s non-standard and not in Firefox so probably don’t count on it (via Christian Shaefer).
