When WordPress saves Gutenberg blocks to the database, it smashes them together as a string of markup. When you query that via the REST-API or WPGraphQL? You get this big ugly blob of HTML:

The screenshot above isn’t that bad, but what happens when you have a 2,000 word blog post with images, block quotes and Twitter embeds? When working on a headless frontend, how are you going to create a layout to match your client’s design, when you’re stuck with a big string of HTML?

Maybe reach for regular expressions to pluck out the data? Try using CSS to drill down and style HTML tags? You could totally YOLO that blob of HTML right into a component with dangerouslySetInnerHTML…

…but the reality is, losing control over the decision making process for handling data makes for a poor developer experience.

There’s already a standard way to work with APIs that have structured data. To quote the MDN:

JavaScript Object Notation (JSON) is a standard text-based format for representing structured data based on JavaScript object syntax. It is commonly used for transmitting data in web applications (e.g., sending some data from the server to the client, so it can be displayed on a web page, or vice versa).

After reading that definition, you might be asking, “If JSON is a standard way to transmit structured data, why isn’t WordPress doing this with Gutenberg blocks?”

That’s the million dollar question.

WPGraphQL Gutenberg to the Rescue

You’re in luck because the WPGraphQL Gutenberg plugin from Peter Pristas converts Gutenberg blocks to JSON!

Using WPGraphQL, you can query for blocksJSON on a page or post and receive a big ugly blob of JSON instead!

Thanks to both the JSON.parse() and .map() methods, you can convert the JSON response from WPGraphQL into an array of objects, and then .map() over it (kind of like the WordPress Loop). This is standard practice when working with JSON in JavaScript.

The following code snippet parses the JSON response, starts a loop, plucks out the ‘core/paragraph’ block, then passes in the data as props:

Thanks to the structure JSON provides, you now have full control over content coming from Gutenberg. Now that’s a good developer experience!

The post Quick Tip: Gutenberg Blocks as JSON appeared first on WebDevStudios.

Most of the the time we do it like this:

View the code on Gist.

It works. However, it’s difficult to maintain this code, and most of the time, the HTML markup we need to use is much more complex than the example above. As more updates and changes occur in the markup, we find it increasingly difficult to work with this code.

Enter wp.template

If you are familiar with Underscore.js or {{ mustache }}, wp.template is an underscore-based JavaScript templating helper shipped with WordPress.

So, how do we use it?

Create and render your HTML markup template

View the code on Gist.

Just with this, we can immediately see how easy it is to maintain our HTML markup.

Notes

1. It is important that the HTML markup template is wrapped with <script type=“text/html” id=“tmpl-[TEMPLATE-NAME]”></script>.
2. The id needs to be prefixed with tmpl-.
3. data is the variable passed to the template from the JavaScript. You’ll see this shortly.
4. JavaScript logic goes inside <# #>.
5. <# _.forEach() #> is an Underscore function. See Underscore.js.
6. Use {{ }} for escaping output.
7. Use {{{ }}} for unescaped output. Using {{ }} with data containing markup will convert the tags to HTML entities. So for example, if the data is <img src=""/> and we indeed want to render the image, we need to use {{{ }}}.

Load wp-util

The code for wp.template is inside wp-util, so we need to make sure that wp-util.js is loaded.

You can do this by adding wp-util as a dependency of your JavaScript. Like this:
wp_enqueue_script( 'custom_js', plugins_url( 'js/custom.js', __FILE__ ), [ 'jquery', 'wp-util' ] );

The JavaScript

View the code on Gist.

A few more notes…

1. We omit tmpl- in wp.template( 'display-posts' ).
2. The data we pass to display_posts_template() is the data variable we use in our template.

Conclusion

While we used <# _.forEach() #> in our example, it is a good idea to minimize the JavaScript logic in your template. The goal is to separate the “view” and “logic.”

For example, you can approach our example like this:

JavaScript

View the code on Gist.

Template

View the code on Gist.

wp.template is a good tool to create clean and maintainable code. Another advantage of using this technique is you don’t need to modify your JavaScript when you modify your HTML template. As a developer, it means no re-compiling / bundling / minifying / purging of JavaScript cache is needed.

What do you think? Will these tips help you with a better, cleaner way to render HTML with JavaScript? Leave us a comment below. Need a team to offer up solutions like this for your website project? Contact us today.

The post A Better, Cleaner Way to Render HTML with JavaScript appeared first on WebDevStudios.

This guide aims to provide direction and help you discover the right paths for learning web development.

The Circle of Knowledge

Before we begin, let’s discuss briefly what I like to call the Circle of Knowledge (aka, the generalized way in which I like to think about knowledge acquisition). Consider the following image:

For the purpose of this article, let’s assume you are interested in learning to build your first website. In the Circle of Knowledge, the outer edge broadly establishes the topic of Web Development. The inner circles define your level of familiarity with the general topic’s more specific subtopics. These interior circles divide your understanding of the larger topic into three sections: topics you know (or think you know), topics you have heard about, and topics you are unaware even exist.

Initially, the innermost circle is probably pretty small, because you’re just starting to dig into what you need to learn in order to understand web development. Maybe you know how to turn on a computer; you understand that something called a browser lets you access the internet (which you know some people also call the web); you can search for topics of interest, and parse the search results to determine which of those accurately represent the answers to your questions.

It may not seem like much, but this is a great starting point. You already have something in common with the vast majority of computer programmers in the world: if we don’t know something, we look it up.

Your First Search

Imagine you search for the phrase “how to build a website” and encounter the following results:

You just populated the middle segment of your Circle of Knowledge. Although you may not understand what they mean, terms like domain, hosting, Wix and eCommerce are now on your radar. Next, you click the link labeled How to Create a Website: Step-by-Step Guide for Beginners (2018) and are greeted with an additional set of terms: WordPress, content management system, HTML, CSS, Drupal, and so on.

Prior to each click, all of these terms occupied your outermost circle (topics you were unaware even existed), but through the process of research, one-by-one you are now moving them to the middle circle: topics you have heard about. This is excellent progress!

The process of learning anything—web development, baking, running for Congress—can be broken down into these steps. Beginning with just a single search, you will learn a whole new set of terms, notice patterns (domain and hosting came up multiple times in our initial search), and start piecing together the puzzle. The goal for your Circle of Knowledge is to grow the inner circle—the things you know—as much as possible. To do that, first you need to expand the middle segment by discovering new concepts, then selecting those on which to focus your efforts.

“That’s great, but where do I go from here?”

I’ll give you a head start: 100% of all websites are composed of HyperText Markup Language, more easily recognized by its initialism: HTML. This language defines the structure of a website’s content and indicates to your browser the differences between headings, sections, paragraphs, images, bulleted lists, numbered lists, and so on. Well-structured HTML is readable both by browsers and devices that assist web users with impaired vision. It’s the foundation of the internet. It’s also the most important language you can learn to write well at the beginning of your web development career.

Of course, websites are powered by more than just well-structured content. Some are beautifully designed. Some have extremely dynamic interactions, and others work like native computer applications. On occasion, you find a site that does it all.

While learning about HTML, you may find yourself asking some new questions:

• “How can I make this look better?”
• “Do I really need to create this navigation menu in every file?”
• “Can I save information that I enter into a form?”
• “Is my markup accessible?”

Once again, search is your friend; and by leveraging your research skills, you will learn new information. You will perhaps discover that CSS is responsible for the way a website looks. Languages like PHP let you to create reusable templates to split up distinct pieces of content such as navigation. Database languages such as MySQL allow you to save form data. And writing semantic markup goes a long way toward making your content accessible.

The Fork in the Road

You will begin to see new learning paths as you continue to acquire more knowledge; and where there are paths, there are choices. Whether you care more about how a website looks and how users interact with it, or how a website saves and makes available its data, is going to inform your decision to pursue specified knowledge in those areas. We define a website’s look and collection of user interfaces as its “frontend,” and its data structures and application logic as its “backend.”

My friend and colleague, Justin Foell, previously published an article that asked whether you should first learn JavaScript or PHP. An alternate question might be, “Should I start by learning to build user interfaces or systems?” That is the primary difference between frontend and backend development.

Frontend Development

The frontend of a site comprises the publicly-visible content that regular visitors will see. As you’ve learned, HTML provides the structure for that content, but the responsibility for the visual appearance of that content belongs to Cascading Style Sheets, or CSS. Additionally, some behavior of your site that responds to user input, such as triggering a slideshow or using keyboard commands to trigger different settings, is written in a language called JavaScript. Developing a mastery of HTML, CSS, and JavaScript is essential to becoming a frontend web engineer.

Frontend Development: templates, presentation styles, animations, handling user interactions.

Resources

One of my favorite book series for an introduction to frontend development is Web Design with HTML, CSS, JavaScript, and jQuery Set, written by Jon Duckett. These books are a wonderful introduction to each of the three primary frontend languages, and they’re beautiful. too.

For CSS development, CSS Tricks has a great beginner’s guide for learning HTML and CSS. Once you have exhausted their collection of those articles, they have loads more about more general frontend development.

A Book Apart regularly publishes books about a variety of topics from renowned experts in the field. You might be interested in their Front-end Fundamentals series. Then shortly after, check out both the series on Responsive Design and Front-end Next Steps.

Smashing Magazine is another great general resource for frontend development. Smashing publishes loads of articles, tutorials, and books for free, and also offers memberships that provide deep discounts to that content. They also host several live events throughout the year.

Backend Development

The backend (sometimes called “server-side”) of a site typically consists of:

1. a mechanism for storing data in a persistent fashion
2. a collection of files that a web server understands

Data can be stored in files, but it’s more likely that you will be using a database instead. The open-source content management system WordPress uses a combination of MySQL (database language) and PHP (otherwise known as Pre-HyperText PHP, a server-side language) to dynamically generate HTML content.

Backend: databases, server-side languages, application logic, application programming interfaces.

If you’re interested in learning how to make a website dynamic, then we recommend you consider learning PHP immediately after you learn HTML.

PHP began as a templating language. As such, you can create HTML templates that use PHP to pull in your dynamic data. This makes it incredibly versatile for building your site’s structure, as you can separate reusable content like navigation menus into separate files. Thus, if that part of your site changes, it can be easily updated everywhere that part is used.

Of course, the true power of PHP is in application development. Because it’s a backend language, most of your PHP code won’t be outputting templates. Instead, it will be used to connect to data sources like a database or application programming interface to retrieve, manipulate, and update that data. Once you learn how to use PHP for templating, introducing a database to the mix and learning how to write queries is the next logical path.

Resources

There are, in my view, two definitive resources for learning PHP. First, PHP has a glorious online manual that will be your go-to resource any time you have questions. Second, PHP The Right Way is an online book that covers everything from templating to servers and deployment, so you can focus on an area of the language that’s right for your skill level.

Of course, in looking for other resources while researching this article, I just found out that Jon Duckett is publishing a new book about server-side development with PHP and MySQL. I don’t own this, but knowing how great the frontend series books are, I’m pre-ordering this today!

In my view, good online MySQL resources are a bit harder to come by, but sites like Lynda.com and Laracasts have some solid instructional videos, if you’re willing to pay for a subscription.

Still with me?

Good! That fork in the road is important, because your initial question, “How do I build a website?” will lead you down many paths. Some will be fulfilling, and some you’ll find are better left unexplored. They are left there for you to discover.

Earlier, I suggested that computer programming contains far more subtopics than any single person could possibly hope to learn. As a part of choosing your own path, you must continually ask yourself whether the information you are learning is necessary in helping you reach your personal goals. Only you can know that for sure.

Continuing Down a Path

Once you spend enough time learning front or backend development basics, you can no longer say you’ve heard of their languages. Instead, you can confidently say that you are proficient with them. Congratulations! You successfully moved one or more topics into the innermost section of your Circle of Knowledge: “topics you know.”

However, learning doesn’t stop because you are proficient. During the course of learning frontend development, you may discover other topics: CSS preprocessors like Sass or LESS, templating engines like Twig or Blade, or JavaScript frameworks like React, Vue, or Angular. Or, while learning backend development, you will hear about dependency management via Composer, unit testing with PHPUnit, or development practices like SOLID. In either path, you might find websites discussing version control, content management applications, responsive design, intrinsic web design, or a concept called “test driven development.”

Summing Up

Regardless of your path, bringing knowledge into your inner circle leads to new information, questions, and ways of thinking about a topic. At that point, it’s up to you to evaluate your own proficiency, level of interests, and next areas of focus. There are no right or wrong paths. Thankfully, there are some folks out there who have published suggested routes.

One such example is Kamran Ahmed’s “Developer Roadmap – 2018”, published on GitHub. Kamran offers recommended paths for both frontend and backend development. His paths are rich with information, but can seem overwhelming, if it’s the absolute first thing you look into. We recommend you start with the basics described above and revisit Kamran’s articles once you feel ready to learn more. Also, take note of new terms or information that come up during the process of learning. The frequency at which you see those terms will inform which topics to dig into next.

Be sure to check in with yourself regularly and evaluate whether or not you are learning topics that you enjoy. If so, great! You have discovered topics rich with new information that are right within your areas of interest. If not, that’s okay, too. There are some aspects of the field that are less thrilling but still important to know to attain long-term success. Sometimes, a topic is simply not for you. Depending how far along you are on your path, you may discover the path itself isn’t the right one. Evaluating your interest in the information you are learning goes a long way toward guiding your path.

Good luck!

The post Paths to Learning Web Development appeared first on WebDevStudios.

Since then, WebDevStudios has kept that promise. When we ship a website to a client, it passes all sorts of accessibility tests, as well as HTML and CSS validation. When a potential client asks us to provide examples of accessible websites that we have built, it’s easy to oblige. More often than not, that leads to a sale.

While impressing clients and acquiring a new project are good reasons to build an accessible website, the reality is that over 285 million people worldwide have visual impairments… which is almost the population of the United States! Thinking about accessibility is just the right thing to do.

Four Basic Principles

Make no mistake, accessibility is hard. So where should you start? To keep from getting overwhelmed, take a cue from Foundation by Zurb and follow four basic principles:

1) Structure your document properly

Modern web browsers can do a lot of the heavy lifting… if you write semantic HTML.

1. Use <button> instead of making <a>, <div> and <spans> look like buttons.
2. Use headings <h1> – <h6> to help provide both structure and context to screen readers.
3. Steer clear of “enhanced” form field plugins. Ask yourself, “Is it really worth having a pretty dropdown, when it is completely unusable by 285 million people?”
4. Use WAI-ARIA to help provide additional semantics to describe role, state, and properties.
5. Read more about “How Writing Semantic HTML Can Help Accessibility” by Jeffrey de Wit.

2) <label> everything

For 285 million people, a screen reader is the only way to “view” a website. When it’s read back to them… does your website makes sense?

1. Make sure form fields have a <label>. It is OK to hide labels with CSS: <label class="sr-only">
2. Using <fieldset> and <legend> to group related form elements.
3. Provide descriptive alt attributes on images: <img alt="A hen Mallard landing on a pond"> vs <img alt="mallard_duck-1.jpg">
4. Read more about “Labeling Controls” from w3.org.

3) Don’t rely on purely visual cues

If a page is being read to a user by a screen reader, it may not be obvious what the user is supposed to do next.

1. Make sure call to actions have labels that can be read by a screen reader.
2. Do call to actions meet a minimum contrast ratio? Meaning, can this person actually see/read it? Make sure the contrast ratio (on everything from text to buttons) is at least 1:4.5 for normal text and 3:1 for headings.

4) Make everything usable on a keyboard, mouse, and touch screen

1. Make sure you can use the tab, spacebar, and arrow keys to navigate a web page.
2. Give users the option to skip around a page.
3. Complex components such as sliders or modals should be tested with arrow and esc keys.

Tools Can Help

These accessibility testing tools can help, by pointing out areas of your web page that need work.

• Tenon.io – Will check your website against Section 508 and WCAG 2.0, and provide recommended fixes.
• WAVE – Similarly, WAVE can test your website against accessibility standards and even display contrast issues.
• Total Validator – Available for Windows and MacOS, this tool can test entire websites against a wide range of validation tests.

Conclusion

By thinking about and ultimately acting on these principles during the entire life cycle of a project, from scoping to design, development, and QA, not only will you be making your website usable by those with disabilities, you will be doing the right thing. This will come with many other benefits including: long-term maintainable code, SEO juice, and that feeling deep down when you do something nice for someone else. In my book, it doesn’t get more successful than that.

Further Reading

• MDN – Learning accessibility
• WebAIM – Training, assistance, certification, and testing
• WordPress Accessibility Code Standards – The WordPress A11y Team
• Accessibility APIs – A key to web accessibility

The post How Thinking About Accessibility Can Lead to Success appeared first on WebDevStudios.

A majority of a site’s visitors will be able to use their sight to help them understand what things are and what they might do. For them, it’s largely irrelevant that the thing that looks like a button isn’t built with a <button> element. As long as it functions in a way that matches their goals and expectations, they will be happy (maybe even delighted if it does exceptionally well).

But what if you couldn’t see the page for yourself and you need assistive technology to help you? Suddenly, all the inherent semantic information that HTML elements carry becomes infinitely more relevant.

This post will describe three examples where semantics matter and how they may influence a user’s experience on the website.

Anchors, and buttons, and spans, oh my.

It’s entirely possible to add a span or a div to a page, slap some CSS and JS on it, and call it a button. Maybe you’d do it because it’s “easier” to make it look like the design that way. Or, maybe you have a different reason for doing this. However, you’d only be doing yourself a disservice by reinventing the wheel and making a bunch of extra work for yourself.

You see, it may look like a button. It may even act like a button when you click it. What it most likely won’t do is get added to the page’s list of focusable elements. This means that people navigating your site with a keyboard will never be able to reach it, let alone interact with it.

And, I can almost guarantee that it won’t identify as a button either. This is an important detail to those that use assistive technologies to tell them what something is. If I don’t even know it’s a button, then how can I be expected to know that I can interact with it?

Both of these shortcomings can be fixed to some extent, but why would you? The browser will take care of all of these things for you when you use the appropriate element, and it will do that much better than you can emulate them. As a bonus, you’ll be supporting older browsers without even trying!

In addition, both the anchor and button element have a number of additional attributes that are simply not valid to use with a div or a span – attributes with which you can give more information, or with which you can instruct the browser how to handle it.

For example, if I were to add the download attribute to a link, I can basically tell your browser to download the file I’m linking to instead of trying to open it. I can also add more information about the page I’m linking to through attributes like rel or hreflang.

Or, you can use the disabled attribute on a button element, which will allow you to easily disable it completely. A button that is disabled this way cannot get focus anymore, nor can it be activated anymore. For all intents and purposes, it does not exist anymore. Simply removing this state attribute will completely restore the button’s function again.

The subtle difference between anchors and buttons

A more common occurrence is anchor tags acting like buttons. While this isn’t necessarily as bad, you’d still be using an element whose primary function is relating documents (or sections of the same document) together to do something it wasn’t meant to do.

So how can you easily recognize when to use an anchor and when to use a button? If you are using a valid href attribute to link to a different page, or to a different section on the same page, then go right ahead and use an <a> tag.

Otherwise, every time you find yourself writing a toggle that is along the lines of one of the following, you may want to consider using a <button> instead:

<a href="#" id="click-this">Click Me, I do stuff</a>

<a href="javascript:toggleStuff();">No, click me. I do stuff too!</a>

Always remember, someone using a screen reader doesn’t really care what the thing looks like. All they will know is what their screen reader tells them about the thing, and that will come down to two simple words that carry a lot of implied meaning: “link” or “button.”

Headings, more than just text size

The headings (<h1>–<h6>) in your document provide for more than simply a way to increase the size of the text. It’s true that, visually, headings will stand out in most cases and do their job that way.

But remember, not everyone will be able to see your page. Headings have the added benefit of making an outline of your document available. They allow you to give a good overview of what the page is going to be about. Additionally, most screen readers allow their users to jump through the page from heading to heading. In this specific situation, your heading is now without any context and needs to convey what the section is going to be about by itself. And so, those sentences that are marked up with different heading levels become meaningless fractures.

For a good illustration of how navigating a page with headings works, have a look at this video:

Form elements

Forms, too, benefit from being structured semantically. Just like spans that were turned into buttons, your users will also stop liking you if you do not use form fields appropriately.

And like anchors and buttons, each form element (and especially more complicated ones, such as select boxes) come with inherent functionality based on the browser’s implementation. To stay on the select box example, this element lets you select an option with the arrow keys but will also allow you to select an option through typing. That is to say, typing “united s” in a list of countries will select “United States of America” for you. Screen readers will also read out every option as you navigate through the list with the arrow keys.

With all this in mind, it’s all the more heartbreaking to see form widgets that are aimed to replace these native elements for something that looks nicer or that has more functionality and do a poor job at it. It is really easy to forget about all the other things that these elements do for your users. And at the same time, it can be really complicated to get it to work well, too.

To illustrate, I’ve prepared a video straight from the demo page for one of these libraries that “enhances” form elements (it is irrelevant which one it is, really). It demonstrates how a regular select box element works in Chrome with NVDA running. As you’d expect, it reads out the options properly. The “enhanced” version, on the other hand, continuously reads out “blank,” at least until I try and filter the list by typing some letters, because then it starts repeating what I’ve typed instead.

But my feature needs some control that doesn’t even exist!

By now I can hear you think: “That’s great and all, but my needs surpass what native elements can provide.”

Awesome! By all means, use whatever elements you think are appropriate for your cool feature. But, don’t forget that you’re now responsible for making it accessible, too.

So, make sure you have a clear vision of the following:

• What goal does it have and how does it do that better than other options?
• How should it operate with a mouse?
• How should it operate with a keyboard?
• How does it manage focus states (which is especially important for more complicated widgets, like calendars, for example)?
• What kind of feedback should it give the user?
• And finally, what does it actually do when a user decides to use it?

And then make sure to read into WAI-ARIA, because this is exactly what a use-case WAI-ARIA is for.

Further Reading

• Wikipedia article: Principle of least astonishment
• WAI-ARIA overview on w3.org
• Name, Role, Value: Understanding WCAG success criterion 4.1.2

The post Accessibility of Semantics: How Writing Semantic HTML Can Help Accessibility appeared first on WebDevStudios.

“Please, no matter how we advance technologically, please don’t abandon the book. There is nothing in our material world more beautiful than the book.” –Patti Smith

There are many great pathways to glean new information out there, whether it be on the web or in a class. Your mileage may vary depending on your learning style or the topic at hand. With the tech industry, evolution often occurs at a faster rate than print media can keep up.

Still, sometimes a good ol’ print version of what you need comes along that earns its place on your bookshelf. Maybe it got there after you heard it mentioned for the tenth time. Maybe it is the book you always find yourself lending out to someone when they want to dip their feet in to a new niche (regardless of the evolution of name-your-favourite-framework-here.js). Maybe it is the book that someone leant to you at a crucial step of your learning. There are brilliant books for front-end developers out there–and they are definitely worth looking over.

A single book won’t be able to provide you with the breadth of information necessary, especially with today’s multi-dimensional coding ecosystems. Often, books cite wonderfully curated online resources so you are able to use their foundation as a jumping off point for knowledge expansion.

The WordPress-specific

WebDevStudios is abundant with people who know more than a few things about WordPress–with a stack of books to their credit, no less! One book from this list is Professional WordPress: Design and Development, which starts from a top-level view on WordPress then digs down into all the nitty-gritty. Sure, I’m biased, but this is a wonderful additional to any WordPress developer’s bookshelf.

The Process

For those who want to know more about the principles of intuitive navigation and information design, Don’t Make Me Think: A Common Sense Approach to Web Usability, by Steve Krug, is an excellent straight-forward resource for both beginners and the more-seasoned on how people connect with interfaces. This is a good resource for management, designers, and developers alike.

The Visual

Are you more visually inclined? Jon Duckett’s books on HTML/CSS and JavaScript/jQuery may be a good fit. They each include code examples and there is a general assumption of little-to-no previous programming experience that make these a good beginner’s starting point and reference.

The Varied

Smashing Magazine offers many great resources and one compilation is Smashing Book 5: Real-Life Responsive Web Design. While responsive design is a default these days, this gathers techniques and strategies on everything from workflow to SVGs to debugging. (There is a level of assumed knowledge and experience in many chapters.)

The Non-Code Code Books

• Code: The Hidden Language of Computer Hardware and Software: Starting with Morse Code and working its way linearly through telegraphs, barcodes and I/O devices, this isn’t going to teach you how to better implement code but you will likely have a new respect for the history behind the work you’re doing (Published in 2000, so don’t expect discussion of technologies beyond)
• Quiet: The Power of Introverts in a World That Can’t Stop Talking: Okay, this one has truly nothing to do specifically with code. This book explores the dominant values of business culture and how the leadership potential of introverts is often overlooked.

What are some other must-reads that you have on your bookshelf?

The post Helpful Books for Front-End Developers appeared first on WebDevStudios.