February 23, 2021 – Fuel Your Blog

We’ve covered the idea of hiding things in CSS many times here, the most recent post being Marko Ilic’s “Comparing Various Ways to Hide Things in CSS” which did a nice job of comparing different techniques which you’d use in different situations. Hugo “Kitty” Giraudel has done something similar in “Hiding Content Responsibly” which looks at 10 methods—and even those, you could say, aren’t totally comprehensive.

Does this mean CSS is messy and incomprehensible? Nah. I feel like all the methods are logical, have good use cases, and result in good outcomes. Allow me to do a have a pretend conversation walking through my thought process here.

I need to hide this thing completely. For everyone.

No problem, use display: none;.

I need to hide this thing, but only hide it for screen readers, not visually. (For example, an icon that has no additional meaning for screen readers, as there is an accessible label nearby.)

No problem, that’s what the aria-hidden attribute is for.

I need to hide this thing, but only visually, not for screen readers. (For example, the contents of non-active tabs.)

No problem, use a .sr-only class. That leaves it accessible but hides it visually until you remove that class.

Oops, I actually want to hide this thing visually, but I still want it to take up physical space, not collapse. (For example, say a button has a loading spinner icon that is only needed when performing an action. The size of the button should factor in the size of that icon all the time, not just when the spinner is visible. That way, there’s no layout shifting when that icon comes and goes.)

No problem, use transform: scale(0) which will visually collapse it, but the original space will remain, and will leave it accessible to screen readers.

Oh nice, I could transition the transform, too, I suppose. But actually, that transition doesn’t fit my site well. I just want something I can fade out and fade in.

The opacity property is transitional, so transition that between 0 and 1 for fades. The good news is that visibility is also transitional. When fading out, use visibility: hidden, and when fading in, use visibility: visible to hide and unhide the thing from screen readers.

That’s not entirely comprehensive, but I find that covers 95% of hiding cases.

The post Hiding Content Responsibly appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

It’s that time in the release cycle when all the dev notes are rolling out ahead of the next major update. These notes include technical summaries of all the goodies coming in the next release. If you haven’t been paying close attention, there are always a few happy surprises in there that pop up as conclusions to tickets that contributors have been working on for years.

The new password reset feature coming in WordPress 5.7 allows administrators to manually send a password reset link to users, resolving a five-year old ticket. Instead of having to instruct a user about where to go to click on the lost password link and follow the steps, this new feature lets administrators push a button in the admin to send the link. If you have ever had to support clients or a community of users who may not be very technically inclined, this new password reset feature will save lots of time in helping users regain access to their accounts.

The “Send password reset” link is available in several places. Administrators can find the link on the Users screen, as well as in the bulk actions dropdown menu.

It is also available on the individual user screen with a button and a note clarifying that this action will not change the user’s password or force the user to change it.

The password reset email notification includes the site name, username, a password reset link, and the IP address where the request originated:

This password reset request originated from the IP address [IPADDRESS].

There is an open discussion on the original ticket regarding whether this email notification should include the administrator’s IP address.

“The IP address (while fraught with privacy concerns) is the only thing validating that this email came from the website and is not a phishing email,” contributor Gabriel Mariani said. “Unless there is a better way to validate the authenticity of the email I’d say it would be worthwhile to keep it.”

Others see the IP address as useful only if a user is attempting to verify that it is their own IP address or collecting the information to prevent a phishing attack. Giving out the administrator’s IP address doesn’t seem pertinent to either of those concerns.

“I could use my phone to send a reset, and I would have no idea what my IP was,” Mika Epstein said. “And that can easily be faked. Omitting the IP actually reduces the data being sent out that could be used by bad-actors.

“I think it’s more likely we’d have a savvy bad actor than end users who would need to ask for a password reset but also know what a valid IP is and how to ask about it.”

This part of the email text may be iterated on in subsequent patches or future releases of WordPress. Check out the dev note for more discussion on this feature, along with information about further customizing the notification email.

Day: February 23, 2021

Hiding Content Responsibly

WordPress 5.7 Lets Administrators Send Password Reset Links