Instant Web Site Tools

Scott O’Hara recently published “Inclusively Hidden,” a nice walkthrough of the different ways to hide things on the web. Nothing is ever cut and dry when it comes to the web! What complicates this is that hidden begs the question: hidden for whom? Different answers to that have different solutions:

• Hidden for everyone? display: none; or visibility: hidden; or the hidden attribute. (But watch out for that hidden attribute, says Monica Dinculescu.)
• Hidden visually, but present for assistive tech? A .screen-reader-only class with a smattering of properties to do the job correctly.
• Hidden for assistive tech, but not visually? The aria-hidden="true" attribute/value.

It’s worth grokking all this because it’s is a perfect example of why HTML and CSS is not some easy bolt-on skill for front-end web development. This is critical stuff that isn’t done as correctly as it should be.

If you like video, I did one called “Hiding Things with CSS” that goes over a lot of this.

As I write this, I’m freshly back from Smashing Conf in San Francisco. Sara Soueidan had a wonderful talk that covered some “hiding things” situations that are even less intuitive than what we might be accustomed to seeing.

One thing she covered was the inert attribute and how it can be used to skip interactive elements from keyboard tabbing. It can even be used on a parent element, nullifying everything inside it. I understood that part, but not entirely why it’s useful since it seems like you might as well use display: none; if an element is hidden and the elements inside aren’t meant to be in focus. But I’m sure it’s my lack of understanding, so I’m looking forward to Sara’s video to come out so I can re-watch it. It had to do with maintaining a non-awkward tabbing order.

Another thing Sara covered is that some folks who use assistive technology also tend to explore touch screens with haptics, moving about the page with their fingers looking for interactive elements. If you, say, replace a native …

I’ve said before one quick and powerful thing you can learn as a front-end developer just getting starting with JavaScript is changing classes.

const button = document.querySelector(".my-button");
const element = document.querySelector(".content");

button.addEventListener("click", function() {
  element.classList.toggle("sparkles");
});

We could use that skill to build some tabs, right? Right.

We got this.

Say we have this changing classes ability in our skillset now and we need to build a tabbed interface. If we just add a little more code that deals with click handlers, we could probably wire up some simple tabs, like this:

See the Pen
XQpqZV by Chris Coyier (@chriscoyier)
on CodePen.

Totally functional tabs. I might pat myself on the back a little here. See how I used those anchor links to create jump links between the link and the tabbed section? That’s mighty semantic, don’t you think? The tabs are accessible with a keyboard, have focus styles, and can be activated with the Return key.

Did we win? Case closed? Perfect tabs?

Nothing is ever so easy, is it?

One issue here is that we didn’t do anything special with keyboard handling, which tabbed interfaces may require. Heydon Pickering wrote about this:

Unlike a same-page link, a tab does not move the user to the associated section/panel of content. It just reveals the content visually. This is advantageous to sighted users (including sighted screen reader users) who wish to flit between different sections without having to wade back up the page each time they want to choose a new one.

This comes with an unfortunate side effect: If the user wishes to move to a section by keyboard and interact with its internal content, they have to step through any tabs to the right of the current tab, which are in focus order.

Turns out there is a whole checklist of other behavioral things tabs interfaces can and should be doing. In Heydon’s explanation, the Tab key actually acts as a way to jump from the tab itself to the content related to …

PWA (Progressive Web Apps) have been with us for some time now. Yet, each time I try explaining it to clients, the same question pops up: “Will my users be able to install the app using app stores?” The answer has traditionally been no, but this changed with Chrome 72 which shipped a new feature called TWA (Trusted Web Activities).

Trusted Web Activities are a new way to integrate your web-app content such as your PWA with yourAndroid app using a protocol based on Custom Tabs.

In this article, I will use Netguru’s existing PWA (Wordguru) and explain step-by-step what needs to be done to make the application available and ready to be installed straight from the Google Play app store.

Some of the things we cover here may sound silly to any Android Developers out there, but this article is written from the perspective of a front-end developer, particularly one who has never used Android Studio or created an Android Application. Also, please do note that a lot of what we’re covering here is still extremely experimental since it’s limited to Chrome 72.

Step 1: Set up a Trusted Web Activity

Setting up a TWA doesn’t require you to write any Java code, but you will need to have Android Studio. If you’ve developed iOS or Mac software before, this is a lot like Xcode in that it provides a nice development environment designed to streamline Android development. So, grab that and meet me back here.

Create a new TWA project in Android Studio

Did you get Android Studio? Well, I can’t actually hear or see you, so I’ll assume you did. Go ahead and crack it open, then click on “Start a new Android Studio project.” From there, let’s choose the “Add No Activity” option, which allows us to configure the project.

The configuration is fairly straightforward, but it’s always good to know what is what:

• Name The name of the application (but I bet you knew that).
• Package name: An identifier for Android

There is already an env() function in CSS, but it kinda came out of nowhere as an Apple thing for dealing with “The Notch” but it has made it’s way to be a draft spec. The point will be for UAs or authors to declare variables that cannot be changed. Global const for CSS, sorta.

That spec doesn’t seem to suggest how we’ll actually set those env() values just yet. If you want them now, the easiest way to fake them would be using regular ol’ CSS custom properties and simply not change them.

But if you want that env() syntax though, there is a PostCSS plugin for emulating it. The way the plugin handles them is through a JavaScript file that declares them.

postcssCustomProperties({
  importFrom: 'path/to/file.js' /* module.exports = {
    environmentVariables: {
      '--branding-padding': '20px',
      '--branding-small': '600px'
    }
  } */
});

Having them start life as JavaScript is interesting, as it means we could perhaps have a single place to set variables that are accessible both to JavaScript and CSS.

That’s what Harry Nicholls covers more in his article, “Why you should use CSS env()” like some gotchas when dealing with units and such. But if you really needed a single source for unchangeable variables in both CSS and JavaScript, then I’d say this is a good way to go — and could potentially be ripped out once support for env() formally arrives.

The post Faking env() to Use it Now appeared first on CSS-Tricks.

from CSS-Tricks https://css-tricks.com/faking-env-to-use-it-now/…

Hey CSS-Tricksters! Bryan Hughes was kind enough to take a concept from an existing post he published on converting to TypeScript and take it a few couple steps further in this post to elaborate on creating reusable base classes. While this post doesn’t require reading the other one, it’s certainly worth checking it out because it covers the difficult task of rewriting a codebase and writing unit tests to help the process.

Johnny-Five is an IoT and robotics library for Node.js. Johnny-Five makes it easy to interact with hardware by taking a similar approach that jQuery took to the web a decade ago: it normalizes the differences between various hardware platforms. Also like jQuery, Johnny-Five provides higher-level abstractions that make it easier to work with the platform.

Johnny-Five supports a wide array of platforms via IO Plugins, from the Arduino family, to the Tessel, to the Raspberry Pi, and many more. Each IO Plugin implements a standardized interface for interacting with lower-level hardware peripherals. Raspi IO, which I first created five years ago, is the IO plugin that implements support for the Raspberry Pi.

Any time there are multiple implementations that conform to one thing, there is a chance to share code. IO Plugins are no exception, however, we have not shared any code between IO Plugins to date. We recently decided, as a group, that we wanted to change this. The timing was fortuitous since I was planning on rewriting Raspi IO in TypeScript anyways, so I agreed to take on this task.

The goals of a base class

For those who many not be familiar with using class-based inheritance to enable code sharing, let’s do a quick walk-through of what I mean when I say “creating a base class to reuse code.”

A base class provides structure and common code that other classes can extend. Let’s take a look at a simplified TypeScript example base class that we will extend later:

abstract class Automobile {
  private _speed: number = 0;
  private _direction: number = 0;
  

(This is a sponsored post.)

An Event Apart Boston is almost here! We’re talking, like, less than a month away. If you’ve been holding off from registering, this might be your last chance because time and seating are both limited. Besides, we’re talking about three days of pure knowledge-dropping by an impressive lineup of speakers on a wide range of topics. Seriously, just look at the full schedule and prepare to be get stoked for a great time.

But, if a couple of weeks until show time is a little too tight for your liking, that’s where An Event Apart has you totally covered because there’s another one taking place in Washington D.C. this summer. And three more throughout the rest of the year in Chicago, Denver and San Francisco.

The reason an Event Apart is so near-and-dear to the CSS-Tricks family is that it scratches a common itch that we see come up around here often: how can we possibly stay on top of our careers as front-enders when our industry is changing at lightning speed and when we’re all-consumed trying to keep on top of our actual jobs? An Event Apart is our chance to take intention time away from the day-to-day and invest in our careers by learning from some of the best in the business, meeting folks who do what we do, and having those micro-interactions with others in the hallways that spark the interesting types of dialogues you just can’t get from Twitter.

Think about it: 17 speakers over three days covering everything from design systems and Progressive Web Apps to variable fonts and CSS Grid Layout. There’s so much to gain by attending. Just look at the awesome takeaways Chris got from An Event Apart Seattle in March.

And, to sweeten the pot, An Event Apart gave us a special discount code for CSS-Tricksters like yourself. Enter the AEACP at checkout to knock $100 off the price.

Hope to see you at one of the upcoming events!

Register Today

Direct Link to …