Post pobrano z: Learning Gutenberg: A Primer with create-guten-block

Welcome back! We’ve just taken a look at what Gutenberg is and how it operates from the admin side. Gutenberg is certainly going to have a massive impact on the WordPress world. If you are just arriving here and have no idea what we’re talking about, I recommend at least skimming Part 1 to make sure you have the appropriate background.

Let’s create a custom block with a bit of help from a wonderful tool called create-guten-block. Onward!

Blocks live in plugins

To create a Gutenberg block, you create a WordPress plugin. Anything that affects *content*, like a Gutenberg block certain will, needs to be a plugin so that it remains active even as you change themes. Something that is very theme-specific or just affects how your site looks can be part of the theme files or functions.php file in your theme. Read more about this distinction in our article about WordPress Functionality Plugins.

That said, the blocks in themes issue is a hot topic. The WordPress Theme Review Team is discussing whether or not to allow blocks in themes at all as part of themes. A post, “Getting Ready for Gutenberg”, on the Theme Review Team’s Make page posed this question, and was met with strong opinions from both sides. The general consensus, however, is that blocks are plugin territory.

WordPress.org is comprised of various teams, each with their own homepage at make.wordpress.org/team-name, channel in the WordPress Slack, and a weekly meeting. If you are interested in getting involved in WordPress or curious about how it operates, I highly recommend browsing through a list of the teams here, joining a Slack channel, and popping into a weekly meeting to see how it all happens.

In the far future, it’s possible that themes will consist of *just a stylesheet*, while all custom functionality and content structure come from blocks in plugins. I’m paraphrasing the words of Tammie Lister, Gutenberg’s design lead, on this episode of Shoptalk Show. Very much worth a listen!

Taking a setup shortcut… for now

What’s kept me from diving head first into modern JavaScript is the dang configuration. The transpiling, the bundling, the code splitting, the tree shaking… yeesh, I’m busy! I love learning new things, but there’s a limit to my patience and, apparently, configuring a build process for a small test project is my limit.

It’s this sentiment that led to the development of a tool called create-react-app, zero-configuration build setup for, you guessed it, creating React apps. It’s brilliant. Assuming you have a functioning node and npm installation, you can run a single command and you have a project ready for you to start coding in React. The transpiling, bundling, and tree shaking is set up for you.

But wait… can we use create-react-app for Gutenberg blocks? No, but the aforementioned create-guten-block, developed and beautifully documented by Ahmad Awais, does pretty much the same thing for us! That’s what we’ll be using for our block.

create-guten-block is not the only block generating tool at our disposal! You can scaffold a block using WP-CLI, but I have chosen not to because the default setup is for ES5 (for now) and does not give us what we need for our journey into modern JavaScript. That being said, I found it helpful to dig through the ES5 implementation of a block as a way to reinforce the core concepts, so maybe give it a go after you finish here!

Yes, this is a shortcut. We are choosing to avoid understanding the core concepts of a technology by using a tool. We’ll have to learn these concepts someday. But for now, I’m totally fine bypassing this configuration step. My philosophy about using tools such as this: use them, but do so with the understanding that it *probably* won’t save you time or effort in the long run.

It’s worth noting that, like create-react-app, create-guten-block allows you to npm eject your configuration. This means exposing all of the settings the tool has created for us and making them available for customization. Note, however, that this is irreversible; if you eject and then make a mistake, you’re on your own to fix it! Like I said, you’ll have to learn it someday 🙂

Step 1: Install create-guten-block

We will first install create-guten-block globally, like so:

npm install -g create-guten-block

In theory this should work no problem, but that’s not realistic. create-guten-block requires a minimum of Node version 8 and npm 5.3, so if you haven’t updated either of them for a while, that’s one possible error (and here’s one possible solution).

I always start by pasting my console error into a search engine and removing line numbers and file names to keep my query general. In the interest of improving this tutorial, however, I am curious to hear about what went wrong so feel free to post your issue in the comments as well.

Step 2: Create that guten-block

It’s time! Let’s do it! You know what? I’m not going to tell you how because Ahmad’s documentation is so good and there’s no sense in replicating it.

Go here and follow Ahmad’s instructions to create that guten-block in your command line.

Step 3: Activate the plugin

Go to your Plugins screen, activate your new block plugin — it should be called something like test-block — CGB Gutenberg Block Plugin where „test-block” is what you named your block when creating it.

Step 4: That’s it! Let’s use our custom block!

So easy! Now, go to the editor view of a post or page, locate your block, and insert it.

Although I named my block “test”, searching “test” in the block selector yielded the wrong result as you can see in the gif above. The default name of the block is instead “CGB Block” — we will change this very soon!

Text editor setup (optional)

I’ve found it very helpful to have a specific text editor setup for developing blocks. I use Visual Studio Code for my text editor, but I’m sure you can figure out something similar with whatever editor is your preference.

Here are the key ingredients:

1. Easy access to the command line to keep an eye on build errors (there will be build errors)
2. A copy of the Gutenberg source from GitHub for code reference (download or clone it here)
3. Easy access to both your plugin’s directory and Gutenberg’s source directory from #2

In VS Code, I accomplish this using the following features:

1. The integrated terminal — open with Command + ~ on Mac, or from the menu bar with View > Integrated Terminal
2. A Workspace containing folders for both your plugin and Gutenberg’s source from GitHub. You can doing this by opening your plugin directory in VS Code, then choosing File > Add Folder to Workspace and selecting the Gutenberg directory you downloaded from the GitHub repo. You can then save the Workspace for easy access with File > Save Workspace As (I called mine “Blocks” in the image above).

This part is optional, and you don’t have to use VS Code. The important thing is having ready access to the command line, your plugin’s source, and the Gutenberg plugin’s source for reference. You can totally reference the source on GitHub if you like, but I enjoy having the files in the same environment for side-by-side comparison and easy searching with Find In Folder.

We are using Gutenberg from the plugin repository for the actual functionality, but that instance only includes the compiled files. We want to reference the source files, so we need to use the codebase directly from GitHub. If you’d like to access updates before they are released in the plugin, you can clone the repository. It would be totally possible to build and work from the GitHub version, but for simplicity’s sake, we are using the plugin version in this tutorial.

Once you are ready to go, make sure you are cd’d into your block’s plugin folder and run npm start. You should see a satisfying message indicating the process has started:

I’m using Wes Bos’s theme for Cobalt 2 in VS Code as well as the same theme for ZSH in my Terminal and iTerm. This makes absolutely no difference in how the technology works, but it does make a difference, on a personal level, to customize your workspace and make it feel like your own (or Wes Bos’, in my case).

What’s what

Now that we are in code mode, let’s take a look at the files we’ll be working with. I’ll borrow this from the create-guten-block Readme for reference:

└── test-block
  ├── plugin.php
  ├── package.json
  ├── README.md
  |
  ├── dist
  |  ├── blocks.build.js
  |  ├── blocks.editor.build.css
  |  └── blocks.style.build.css
  |
  └── src
     ├── block
     |  ├── block.js
     |  ├── editor.scss
     |  └── style.scss
     |
     ├── blocks.js
     ├── common.scss
     └── init.php

For the purposes of this tutorial, we are only concerned with what is inside the src directory. We will not touch anything in dist (those are compiled files), plugin.php, or any stragglers such as package.json, package-lock.json, or.eslintignore.

plugin.php officially alerts WordPress of our plugin’s existence. It requires src/init.php, which is where we’ll write any PHP we need for our block(s). In general, we won’t write anything in plugin.php — out of the box, the only code it contains are the comments to register our plugin.

Let’s drill into src:

└── src
   ├── block
   |  ├── block.js
   |  ├── editor.scss
   |  └── style.scss
   |
   ├── blocks.js
   ├── common.scss
   └── init.php

The block directory contains files for single, individual block. This includes:

• block/block.js — All the JavaScript for the individual block.
• block/editor.scss — Sass partial for styles specific to the editor view,
• block/style.scss — Sass partial for styles specific to the front-end view, i.e. what you see when you view your page/post.

Now, open up src/blocks.js:

I think of src/blocks.js as a table of contents for blocks, similar to the role of an index.scss or main.scss in a Sass project structure. If we wanted to include two blocks in our plugin — let’s say this was a suite of custom blocks — we could, in theory, duplicate the block directory, rename it, and add something like this to src/blocks.js:

import 'new-block/block.js';>

Then, whatever create-guten-block has prepared for us behind the scenes would know to include our new block’s block.js in the main script file compiled into dist (now is a good time to take a peek into dist, if you haven’t already).

Not too bad so far, right? We still haven’t really gotten to any JavaScript…

A challenge!

Okay, now it’s time for a challenge! Open up src/block/block.js and take a couple of minutes to read through the author, Ahmad’s, excellent comments.

Then, see if you can figure out how to^*:

1. Change the name of your block, that is, the one that shows in the block selector
2. Change the icon of your block (❤ Dashicons)
3. Change the text that displays on the front end i.e. when you “View Post”
4. Change the text that displays on the back end i.e. editor view
5. Give the front end view a border radius of 30px
6. Give the editor view a gradient background
7. Make the text in first paragraph tag editable

^* You should be able to work through (almost!) all of these in about 10 minutes. 😉

---

How was that?

What problems did you run into? Did you get tired of reloading the editor? Did you see the “This block appears to have been modified externally” message more often than you’d like? I sure did, but such is life with new technology — there’s a lot to be desired in the developer experience, but this isn’t a priority for the team at present and will come in the later stages of Gutenberg’s planned development.

Most importantly, did you get #7?

If you did, then you should be writing this tutorial! That one was a gotcha. I hope you felt at least a little confused and curious because that’s how we learn! We’ll get to that in Part 3.

Now that we have our bearings, let’s dig deeper into this notion of a block.

Skeleton of a block

Here is block.js with the comments stripped out — what we might call the skeleton of a static block:

// Stripped down version of src/block/block.js

// PART 1: Import dependencies
import './style.scss';
import './editor.scss';

// PART 2: Setup references to external functions
const { __ } = wp.i18n;
const { registerBlockType } = wp.blocks;

// PART 3: Register the block!
registerBlockType( 'cgb/block-test', {
  
  // Part 3.1: Block settings
  title: __( 'test - CGB Block' ),
  icon: 'shield',
  category: 'common',
  keywords: [
    __( 'test — CGB Block' ),
    __( 'CGB Example' ),
    __( 'create-guten-block' ),
  ],
  
  // PART 3.2: Markup in editor
  edit: function( props ) {
    return (
      <div>You’ll see this in the editor</div>
    );
  },
  
  // PART 3.3: Markup saved to database
  save: function( props ) {
    return (
      <div>This is saved to the database and returned with the_content();</div>
    );
  },
} );

Let’s do a side-by-side comparison with another static block, the “Separator” block from the default blocks included in Gutenberg. That file is is located in gutenberg/blocks/library/separator/index.js. If you have the folder open in either VS Code or Sublime, you can use the shortcut Command + Option + 2 on a Mac, or View > Split Editor to get the files side-by-side.

If you are following the text editor setup outlined previously, you should have something like this:

In this image, I copy/pasted the above stripped-down version of the block into an empty file to compare it without the comments. That’s optional!

What similarities do you notice? What differences? Open up a few of the other block directories inside gutenberg-master/library/, and take a peek into their files, comparing them to our block skeleton. Spend a few minutes reading the code and see if you can spot some patterns.

Here are a few patterns I noticed:

1. There are curly braces in variable declarations and function arguments all over the place.
2. Markup appears inside of return statements and often contains made-up tag names (you might recognize these as React components).
3. All blocks seem to have a settings object containing entires for title, icon , category, etc. In the library blocks, they appear in an export const settings = ... object, whereas in our plugin block, they are part of an argument for registerBlockType.
4. All blocks have functions for edit and save as part of the settings object.
   • The syntax for the functions is slightly different than our block’s editand save functions:
     • edit( { className } ) { ... } in separator/index.js
     • edit: function(props) { ... } in our block.js
   • The library blocks appear to reference attributes and instead of props
5. All blocks in the library contain an index.js. Some contain a block.js or other files that appear to contain a definition for a class extending a Component, e.g. class LatestPostsBlock extends Component { ....

What did you find? Feel free to contribute in the comments (but don’t stop reading here!).

A somewhat brief and relevant tangent

You probably noticed a statement importing @wordpress/i18n in every index.js and block.js file in the library, as well as a reference to wp.i18n in our plugin’s block.js. i18n stands for internationalization just like a11y stands for accessibility. Internationalization refers to the practice of developing your application to be easily translated to other languages. Since we want to prepare all static text in our blocks for translation, we assign wp.i18n to an alias of __for brevity, very much like we use the $ as an alias for good ‘ol jQuery. Read more about i18n for WordPress here

It’s also worth mentioning where that wp in wp.i18n is coming from and why it’s referenced as @wordpress/i18n in the Gutenberg source. wp is a global object — global meaning a variable available everywhere — containing all of WordPress’ publicly available JavaScript API methods. To demonstrate this, open up the console while on a page within the WordPress admin. Type wp and hit Enter. You should see something like this:

So, anytime we reference something within that wp object, all we are doing is accessing some functionality the WordPress JavaScript API provides us. @wordpress/i18n in the Gutenberg source is doing the same thing, but its importing the functions from an npm module rather than the global object. The functions in the wp global have been intentionally exposed to the public API by the WordPress core developers for use in themes and plugins.

If you are anything like my internal critic, you might be thinking, “Whatever, Lara, I don’t care about those details. Just tell me how to make a cool block with all the JavaScript already!” To which I would reply:

There are so many moving parts and new concepts in this environment that, I’ve found, the more code I take for granted, the more frustrating and time-consuming the process becomes. Approach every line of code with curiosity! If you don’t know what it does, do a Find in Folder in the Gutenberg source and see if you can find a trail to follow. For me, at least, this has been a much more enjoyable way to approach unfamiliar code than trying to build something haphazardly with copy and paste.

And with that, let’s wrap up Part 2!

Homework

What? Homework? Heck yes, there is homework! In Part 3, Andy 🍉 will dive into modern JavaScript goodies: React, JSX, and ES6 syntax. Although our series is written for those relatively new to JavaScript, it is helpful to learn the code and the concepts from many different angles and resources.

In an effort to introduce some concepts early on, here is an outline for some “Homework” prior to Part 3:

1. Spend some time (1-2 hours) on a React tutorial, or until you can explain in your own words:

• The render method in React
• JSX and that those made-up tag names map to JavaScript functions
• Why React uses className instead of class

Recommended resources:

• I really liked Learning React.js by Eve Porcello on Lynda.com. Lynda is a paid service, but you can watch for free with a library card in some cities (Los Angeles, for sure).
• I also recommend this article series, Learning React with create-react-app by Brandon Richey
• There are many, many options on Youtube!
• I’ve been working my way through Brian Holt’s Complete Intro to React course on Frontend Masters (paid) and it’s very good.
• I can’t go without mentioning Wes Bos’s React for Beginners course(paid) — I haven’t done it myself, but I’ve heard only great things, and he keeps it up to date!

I’d also recommend reading React State from the Ground Up here on CSS-Tricks, by Kingsley Silas, because it specifically dives into state in React. If you are brand new to React, this will be a lot to digest, but I think it’s worth getting it into your brain ASAP even if it doesn’t make sense quite yet.

---

2. Understand ES6 Destructuring and find a few examples of it in both the Gutenberg source and our plugin (that won’t be hard).

Recommended resources:

• Blog post: A Dead Simple Intro to Destructuring Objects by Wes Bos
• Video: Destructuring: What, Why and How on Fun Fun Function (these are A+ — watch this one about arrow functions while you’re at it)

---

3. Be comfortable with conditional or ternary operators.

In a sentence, ternary operators are shorthand for if...else statements. You’ll see these all over the Gutenberg source — find some simple examples that provide a fallback for a string’s value, as well as more robust uses like in blocks/library/paragraph/index.js, for example.

Recommended resources:

• The MDN article is very good.
• Also look into the not not operator — here is a Stack Overflow post about it.
• Not to get too far down this rabbit hole, but if you are extra ambitious, do some research about type coercion in JavaScript. This article on FreeCodeCamp and this chapter from You Don’t Know JS by Kyle Simpson are solid starting points.

---

Okay! Thank you so much for reading, and see you in Part 3 for React, JSX, and other goodies.

Comments

Was there any part of this tutorial that didn’t make sense? Did you get lost anywhere? We’d love to keep making this better, so please let us know if any part of this was hard to follow or if any information is incorrect or out of date.

Thank you, again, and good luck!

---

The post Learning Gutenberg: A Primer with create-guten-block appeared first on CSS-Tricks.

Post pobrano z: ​Build live comments with sentiment analysis using Nest.js

(This is a sponsored post.)

Interestingly, one of the most important areas of a blog post is the comment section. This plays an important role in the success of a post or an article, as it allows proper interaction and participation from readers. This makes it inevitable for every platform with a direct comments system to handle it in realtime.

In this post, we’ll build an application with a live comment feature. This will happen in realtime as we will tap into the infrastructure made available by Pusher Channels. We will also use the sentiment analysis to measure whether comments are positive or negative, and display this information on an admin panel.

Direct Link to Article — Permalink

The post ​Build live comments with sentiment analysis using Nest.js appeared first on CSS-Tricks.

Post pobrano z: The backdrop-filter CSS property

I had never heard of the backdrop-filter property until yesterday, but after a couple of hours messing around with it I’m positive that it’s nothing more than magic. This is because it adds filters (like changing the hue, contrast or blur) of the background of an element without changing the text or other elements inside.

Take this example where I’ve replicated the iOS notification style: see how the background of each of these boxes are blurred but the text isn’t?

That’s only a single line of CSS to create that faded background effect, just like this:

.notification {
  backdrop-filter: blur(3px);
}

Now it’s worth noting that browser support for this CSS property isn’t particularly well supported just yet (see below). But we’ve been trying to do this sort of filtering stuff for a really long time and so it’s great to see that progress is being made here. Chris wrote about the “frosted-glass” technique in 2014 and way back then you had to use a bunch of weird hacks and extra images to replicate the effect. Now we can write a lot less code to get the same effect!

We also get to pick from a lot more filters than just that frosted glass style. The following demo showcases all of the backdrop-filter values and how they change the background:

Each of these boxes are just separate divs where I’ve applied a different backdrop-filter to each. And that’s it! I sort of can’t believe how simple this is, actually.

Of course you can chain them together like so:

.element {
  backdrop-filter: blur(5px) contrast(.8);
} 

And this could make all sorts of elaborate and complex designs, especially if you start combining them together with animations.

But wait, why do we even need this property? Well, after reading up a little it seems that the go-to default example is a modal of some description. That’s what Guillermo Esteves was experimenting with back in 2015:

See the Pen PwRPZa by Guillermo Esteves (@gesteves) on CodePen.

I reckon we can do something much weirder and more beautiful if we put our minds to it.

A note about browser support

The backdrop-filter property is not well supported at the time of this writing. And even in Safari where it is supported, you’ll still need to prefix it. There’s no support for Firefox at all. But, really, do websites need to look exactly the same in every browser?

Further reading

• backdrop-filter on MDN
• Building iOS-like transparency effects in CSS with backdrop-filter

The post The backdrop-filter CSS property appeared first on CSS-Tricks.

Post pobrano z: A Strategy Guide To CSS Custom Properties

CSS preprocessor variables and CSS custom properties (often referred to as „CSS variables”) can do some of the same things, but are not the same.

Practical advice from Mike Riethmuller:

If it is alright to use static variables inside components, when should we use custom properties? Converting existing preprocessor variables to custom properties usually makes little sense. After all, the reason for custom properties is completely different. Custom properties make sense when we have CSS properties that change relative to a condition in the DOM — especially a dynamic condition such as :focus, :hover, media queries or with JavaScript.

Direct Link to Article — Permalink

The post A Strategy Guide To CSS Custom Properties appeared first on CSS-Tricks.

Post pobrano z: designsystems.com

The team at Figma has created a new resource for “learning, creating and evangelizing design systems” called Design Systems that already has a good collection of interviews and articles by some folks thinking about these things.

I particularly liked Jeroen Ransijn’s post on how to convince your company it’s ready for a design system, where he writes:

Building a design system is not about reaching a single point in time. It’s an ongoing process of learning, building, evangelizing and driving adoption in your organization.

Design systems are a popular topic. Ethan Marcotte recently looked at instances where patterns get weird, Lucan Lemonnier shared a process for creating a consistent design system in Sketch, and Brad Frost debunked the perception that design systems are rigid. Seems like Figma’s new site will be a nice curated repository of this ongoing discussion.

Direct Link to Article — Permalink

The post designsystems.com appeared first on CSS-Tricks.

Post pobrano z: Five of My Favorite Features of Jetpack

Jetpack is an official WordPress plugin directly from Automattic. It’s an interesting plugin in that it doesn’t just do *one thing* — it does a whole slew of things that enhance what your WordPress site can do. *Any* WordPress site, that is, and often with extremely little effort. Those easy win features Jesse Friedman calls light switch features, meaning you literally flip a switch in Jetpack’s settings and start benefitting. I love that.

There are dozens of features in Jetpack, and I personally make use of most of them and see the benefit in all of them. Allow me to share with you five of my favorites and how they are actively used right here on this site. It’s actually a bit hard to pick, so perhaps I’ll do this again sometime!

1) Related Posts

This seems like such a simple little feature, but it’s anything but. Something has to analyze all the content on your site and figure out what is most related to the current content. That kind of thing can be incredibly database intensive and bring even powerful hosting to its knees. WP Engine, by all accounts a powerful and WordPress-tuned host, bans many of them outright:

Almost all “Related Posts” plugins suffer from the same fundamental problems regarding MySQL, indexing, and search. These problems make the plugins themselves extremely database intensive.

Their top recommendation? Jetpack Related Posts.

Jetpack handles this by offloading the work off your servers and onto theirs. Your site has no additional load for this super useful feature. I find it does a great job.

2) Markdown

I wrote once: You Should Probably Blog in Markdown.

I’m quite serious about that. I’ve been involved with far too many sites where old content was mired with old crufty HTML or otherwise formatted in a way that held them back, and cleaning up that content was an impractically large job. You avoid that situation entirely if you create your content in Markdown (and stick to Markdown syntax).

Things like <span style="font-weight: bold; font-family: Georgia; color: red;"> around seemingly random sentences. <div class="content-wrap-wrap"> wrapping every single blog post because it was just “what you did”. Images force-floated to the right because that made sense three designs ago. Headers with class names on them that don’t even exist anymore. Tables of data spit into content with all the whitespace stripped out and weird alignment attributes you barely recognize. An about page that was pasted in from Microsoft Word.

Content like this will not and cannot last.

With Jetpack, you flip on Markdown support and you’re good!

Almost more importantly, it feels like the Markdown option you can trust. There are other plugins out there that add Markdown support, and that’s great, but they leave open questions. How long is the plugin going to be supported? What variety of Markdown did they pick? Is that variety going to continue to be supported? Does it work in comments? These kind of questions make me nervous.

Choosing Jetpack feels safe because it’s the official Markdown choice of WordPress, in a plugin we can be sure will be updated forever.

It’ll be interesting to see what Markdown + Gutenberg is like!

3) Social Sharing

This is a multi-pronged feature.

One, it can easily add sharing buttons to your posts. This isn’t a particularly difficult thing to do for any developer worth their salt, but having it abstracted away in a plugin is nice.

Two, it can share your posts directly to social sites like Twitter and Facebook. That’s a much harder thing to write from scratch. It’s a thing I used a paid third-party service for years. It was a pleasant surprise when I discovered Jetpack’s ability to do this.

The „official” buttons can be nice as they have the most integrated functionality with the services themselves, but I dig that the other options are like „Responsible Social Sharing Links” in that they have the least possible performance overhead.

It allows you to customize the mesasge, and does smart stuff like includes the Featured Image as image attached to the social post.

4) Comment Improvements

I’m a little uncomfortable using a third-party comment system on my sites. I like control. Comments are content and I like making sure those are in my own database. Yet, I think users have a little higher expectations of comment thread UX than they used to. Having to manually type in your name and email and all that feels kinda old school in a not-so-great way.

Fortunately, Jetpack can replace your comment form with a modernized version:

Now users can log in with their social accounts, making leaving a comment a much easier flow. Not to mention the fact that it’s all the less work you have to do styling the comment form.

Notice the „Notify me of new comments via email” checkbox there too. Guess what powers that? Jetpack. That’s a nice feature for people who are leaving question-style comments on your site. They very likely want to be notified of about the conversations happening in comments as it evolves.

5) Security

I’ve been deep into the world of web development for many years. The more I know, the more I can see that I don’t know. We all have to focus on certain things to get done what we need to on our own journeys. I fully admit I know very little about server-side web security. I’d rather leave that exertise to others, or ideally, software that I trust.

Here’s some fun statistics from here on CSS-Tricks:

It’s nice to know my site is being protected that way from malicious logins. Spam, an even more direct problem, is also taken care of by Akismet, the spam-blocking plugin that my Jetpack subscription covers.

Should anything happen to the site, I know it’s backed up off my server by VaultPress, which is also part of my Jetpack subscription.

See how much it does!?

---

Again, this is just a handful of the features of Jetpack. There are so many niceties tucked into it I consider it a no-brainer plugin. Probably the first and most important plugin you’ll install on any self-hosted WordPress site.

The post Five of My Favorite Features of Jetpack appeared first on CSS-Tricks.

Post pobrano z: VS Code Can Do That?

Clever microsite from Burke Holland and Sarah Drasner that highlights some of VS Code’s coolest features. All fifteen of them are pretty darn cool. Here’s a few other compelling features I’ve seen people use/love:

• There is a terminal right in there, so you don’t need a separate app.
• The GitLens add-on, which shows you who last updated any line of code in your codebase, and when.
• Vim nerds aren’t left out.
• Live Share is coming soon.
• Solis looks like a pretty cool add-on for live previews.
• Type checking

Personally, I’m still on Sublime. I gave VS Code the college try last year but failed. I can’t even remember why now, which means it’s probably about time to try again. If it was slowness, maybe it was because I was using too many add-ons.

Direct Link to Article — Permalink

The post VS Code Can Do That? appeared first on CSS-Tricks.

Post pobrano z: Overriding Default Button Styles

There are a variety of „buttons” in HTML. You’ve got:

<button>Button</button>
<input type="button" value="Button">

Plus, for better or worse, people like having links that are styled to match the look of other true buttons on the site

<a href="#0" class="button">Button</a>

One challenge is getting all those elements to look and layout exactly the same. We’ll cover that a few ways.

Another challenge is getting people to use them correctly

This is a bit surprising to me — but I hear it often enough to worry about it — is that more and more developers are using <div>s for buttons. As in, they just reach for whatever generic, styling-free HTML is handy and build it up as needed. Andy Bell explains why a real button is better:

So, <button> elements are a pain in the butt to style right? That doesn’t mean you should attach your JavaScript events to a <div> or an <a href="#"> though. You see, when you use a <button>, you get keyboard events for free. You’re also helping screen reader users out because it’ll announce the element correctly.

And here’s Andy again helping you out with a chunk of CSS that’ll get you a cleanly styled button:

See the Pen Button Pal — some basic button styles by Andy Bell (@hankchizljaw) on CodePen.

It’s that styling that just might be the mental roadblock

It’s a bit understandable. Buttons are weird! They have a good amount of default styling (that come from the „User Agent Stylesheet”) that varies from browser to browser and means you have work to do to get them exactly how you want.

See all the weirdness there?

• Without any styling, the button is kinda little and has that native border/border-radius/box-shadow thing going on.
• Just by setting the font-size, we lose all those defaults, but it’s got a new default look, one with a border and square corners, a gradient background, and no box-shadow. This is essentially -webkit-appearance: button;.
• Buttons have their own font-family, so don’t inherit from the cascade unless you tell it to.

Here’s Chrome’s user agent stylesheet for buttons:

Firefox behaves a bit differently. See in the video above how setting border: 0; removed the border in Chrome, but also the background? Not the case in Firefox:

I only point this out to say, I get it, buttons are truly weird things in browsers. Factor in a dozen other browsers, mobile, and the idea that we want to style all those different elements to look exactly the same (see the opening of the article), and I have a modicum of empathy for people wanting to avoid this.

Never hurts to consult Normalize

Normalize does a good amount:

/**
 * 1. Change the font styles in all browsers.
 * 2. Remove the margin in Firefox and Safari.
 */

button,
input,
optgroup,
select,
textarea {
  font-family: inherit; /* 1 */
  font-size: 100%; /* 1 */
  line-height: 1.15; /* 1 */
  margin: 0; /* 2 */
}

/**
 * Show the overflow in IE.
 * 1. Show the overflow in Edge.
 */

button,
input { /* 1 */
  overflow: visible;
}

/**
 * Remove the inheritance of text transform in Edge, Firefox, and IE.
 * 1. Remove the inheritance of text transform in Firefox.
 */

button,
select { /* 1 */
  text-transform: none;
}

/**
 * Correct the inability to style clickable types in iOS and Safari.
 */

button,
[type="button"],
[type="reset"],
[type="submit"] {
  -webkit-appearance: button;
}

I was a tiny bit surprised to see WTF, Forms? not cover buttons, only because of how much weirdness there is. But the form elements that project whips into shape are even more notoriously difficult!

A Style-Testing Kinda Thingy

I feel like the answer to this is basically a big ol’ block of CSS. That’s what Andy provided, and you could very likely come to one on your own by just being a little heavier handed than the usual of setting style rules with your buttons.

Still, I felt compelled to make a little tester machine thingy so you can toggle styles on and off and see how they all go together in whatever browser you happen to be in:

See the Pen Consistent button styles by Chris Coyier (@chriscoyier) on CodePen.

A11y

The biggest point here is to use the correct native elements, as you get a bunch of functionality and accessibility for free. But you might as well get the styling right, too!

While we’re talking buttons, I’m gonna use the same quote I used in our When To Use The Button Element post from MDN:

Warning: Be careful when marking up links with the button role. Buttons are expected to be triggered using the Space key, while links are expected to be triggered through the Enter key. In other words, when links are used to behave like buttons, adding role="button" alone is not sufficient. It will also be necessary to add a key event handler that listens for the Space key in order to be consistent with native buttons.

You don’t need role="button" on <button> because they are already buttons, but if you’re going to make any other element button-like, you have more work to do to mimic the functionality.

Plus, don’t forget about :hover and :focus styles! Once you’ve wrangled in the styles for the default state, this shouldn’t be so hard, but you definitely need them!

button:hover,
button:focus {
    background: #0053ba;
}

button:focus {
    outline: 1px solid #fff;
    outline-offset: -4px;
}

button:active {
    transform: scale(0.99);
}

The post Overriding Default Button Styles appeared first on CSS-Tricks.

Post pobrano z: Grid Level 2 and Subgrid

I find the concept of subgrid a little hard to wrap my mind around.

I do understand the idea that we want to use nested semantic markup as we like and have elements participate in one grid so we don’t have to flatten our markup just for layout reasons. But that is largely handled by display: contents;.

Rachel Andrew explains it in a way that finally clicked for me:

I have an item spanning three column tracks of the grid, it is also a Grid Container with three column tracks – however these do not line up with the tracks of the parent…

If the nested grid columns were to be defined as a subgrid, we would use the subgrid value of grid-template-columns on that child element. The child would then use the three column tracks that it spanned, and its children would lay out on those tracks.

It’s not that the parent disappears, it’s that it shares grid lines with the parent so that getting internal elements to line up with everything else happens naturally.

Direct Link to Article — Permalink

The post Grid Level 2 and Subgrid appeared first on CSS-Tricks.

Post pobrano z: Decorating lines of text with box-decoration-break

An institution’s motto, an artist’s intro, a company’s tagline, a community’s principle, a service’s greeting… all of them have one thing in common: they’re one brief paragraph displayed on a website’s home page — or at least the about page!

It’s rare that just one word or one line of text welcomes you to a website. So, let’s look at some interesting ways we could style the lines of a paragraph.

To see how things currently are, let’s try giving borders to all the lines of some text in an inline span and see how it looks:

<p><span>Hummingbirds are birds from...</span></p>

span {
  border: 2px solid;
}

See the Pen Broken inline box. by Preethi (@rpsthecoder) on CodePen.

The edges appear broken, which they technically are, as the inline box has been fragmented into multiple lines. But we can fix those broken edges with box-decoration-break!

The box-decoration-break property in CSS can decorate the edges of fragments of a broken inline box (as well as of a page, column, and region boxes).

Its value, clone, does that with the same design that appears in the box’s unbroken edges, and its default value, slice, does not copy the decorations at the edges, keeping the break very visible like you saw in the demo above.

Let’s try it:

span {
  border: 2px solid;
  box-decoration-break: clone;
}

See the Pen Broken inline box w/ box-decoration-break. by Preethi (@rpsthecoder) on CodePen.

The property affects not only the border but also the shadow, spacing, and background of the broken edges.

Let’s play with the background first. While writing the post on knockout text, I was working with the background-clip property and wanted to see if the design held up for multiple lines of text. It didn’t.

The background gradient I applied was not replicated in every line, and after clipping it, only the first one was left with a background. That is, unless box-decoration-break: clone is added:

<p><span>Singapore:<br>Lion City</span></p>

span {
  background-image: linear-gradient(135deg, yellow, violet);
  background-clip: text;
  color: transparent;
  padding: .5em;
  box-decoration-break: clone;
}

See the Pen Gradient multi-line text w/box-decoration-break. by Preethi (@rpsthecoder) on CodePen.

The background-clip property with the text value clips a background to the shape of its foreground text. Since we used box-decoration-break, the gradient background is shown and clipped uniformly across all the lines of the text.

Going back to the border, let’s see how its shape and shadow can be copied across the broken edges, along with padding:

<img src="tree.png">
<p><span>Supertrees are tree-like structures...</span></p>
<img src="tree.png">
<p><span>Supertrees are tree-like structures...</span></p>

span {
  background: rgb(230,157,231);
  border-radius: 50% 0%;
  box-shadow: 0 0 6px rgb(41,185,82), 0 0 3px beige inset;
  padding: .5em 1.3em;
  box-decoration-break: clone;
}

p:nth-of-type(2) span {
  background-clip: content-box;
}

See the Pen Inline border shape & shadow w/box-decoration-break. by Preethi (@rpsthecoder) on CodePen.

In the second paragraph of the demo, the background is cropped until the content box (background-clip: content-box). As you can see, the crop happens in the broken edges as well, because of box-decoration-break: clone.

Another way we can style borders is with images. You might see a gradient border around the lines of text below, covering the broken edges, if the browser you’re now using supports border-image and the application of box-decoration-break over its result.

<p><span>The Malaysia–Singapore Second Link...</span></p>

span {
  border: 2px solid;
  border-image: linear-gradient(45deg, #eeb075, #2d4944) 1;
  background: #eef6f3;
  padding: .5em 1.3em;
  box-decoration-break: clone;
}

See the Pen Inline border image w/ box-decoration-break. by Preethi (@rpsthecoder) on CodePen.

An additional behavior we can tap into for decorating individual lines is of outline’s. In supported browsers, box-decoration-break can add an outline to every line of the text, including the broken edges, which is useful for creating bicolored dashed borders.

<p><span>Cloud Forest replicates...</span></p>

span {
  outline: 2px dashed rgb(216,255,248);
  box-shadow: 0 0 0 2px rgb(39,144,198);
  background: #fffede;
  padding: .5em 1.3em;
  animation: 1s animateBorder ease infinite;
  box-decoration-break: clone;
}

@keyframes animateBorder{
  to{
    outline-color: rgb(39,144,198);
    box-shadow: 0 0 0 2px rgb(216,255,248);
  }
}

See the Pen Inline outline w/ box-decoration-break. by Preethi (@rpsthecoder) on CodePen.

As observed in the demo, box-decoration-break withstands animation.

Besides borders and backgrounds, box-decoration-break can also manage shapes applied over elements. There is not much use for it in inline boxes, and is maybe better used in a column or page box, although the application is not yet widely supported in browsers.

But to show an example of what that does, let’s try applying the clip-path property to the span.

The property clip-path itself is only fully supported by Firefox, so only in it you might see an expected outcome. But following are two images: the results of applying a circular clip path over the span, without and with box-decoration-break.

span {
  clip-path: circle(50% at 202.1165px 69.5px);
  ...
}

span {
  clip-path: circle(50% at 202.1165px 69.5px);
  box-decoration-break: clone;
  ...
}

You’ll notice in the first image that the 50% radius value is derived from the width of the inline box (the longest line) where box-decoration-break is not used.

The second image shows how box-decoration-break: clone redefines the computed value for 50% by basing them on the widths of the individual lines while keeping the center same as before.

And here’s how the inset function of clip-path (an inset rectangle) applied over the span clips it without and with box-decoration-break:

span {
  clip-path: inset(0);
  ...
}

span {
  clip-path: inset(0);
  box-decoration-break: clone;
  ...
}

Without box-decoration-break, only a portion of the first line that matches the length of the shortest is visible, and with box-decoration-break: clone, the first line is fully visible while the rest of the box is clipped.

So, maybe if you ever want to show only the first line and hide the rest, this can come in handy. But, as I mentioned before, this application is more suitable for other types of boxes than ones that are inline. Either way, I wanted to show you how it works.

Browser Support

As we’ve seen here, box-decoraton-break can be super useful and opens up a lot of possibilities, like creating neat text effects. The property enjoys a lot support with the -webkit prefix, but is still in Working Draft at the time of this writing and lacks any support in Internet Explorer and Edge. Here’s where you can vote for Edge support.

Wrapping Up

The box-decoration-break: clone copies any border, spatial, and background designs applied on a fragmented inline box’s unbroken edges to its broken ones. This creates an even design across all the lines of the text, decorating them uniformly and can be super useful for all those blurbs of text that we commonly use on websites.

The post Decorating lines of text with box-decoration-break appeared first on CSS-Tricks.