Snippets

I love stumbling upon CSS properties in time of great need. Recently, I was working on a personal project, and I wanted to have multi-line highlighted text. My requirements were pretty simple from a design point of view:

1. Text should be highlighted, i.e. have a background colour
2. Highlights should only cover areas where there is text
3. Each line should have a little left and right padding so that the text isn’t flush against the highlight box

My desired HTML was something like this:

And the desired output something like this:

If I used it as is, the output would look something like this:

So, how can we solve this? Luckily, CSS has thrown us a piece of candy in the box-decoration-break property. Let’s take a look.

[…]

Here’s an excerpt from the MDN:

The box-decoration-break CSS property specifies how the background, padding, border, border-image, box-shadow, margin and clip of an element is applied when the box for the element is fragmented. Fragmentation occurs when an inline box wraps onto multiple lines…

Basically, this property is giving us a bit more granularity in how an inline element gets rendered. By default, it’s set to slice, which means that it treats the inline box as if it weren’t fragmented at all. I like to think of it like this. Imagine that we took that multi-line inline element, stretched it out onto one line, applied the styling, sliced it into pieces, then moved each piece back to a new line. The result would be that the properties mentioned above would act on the entire box of the element, rather than each of its parts.

However, there is a second option for us, and that is:

When we set the property to clone, we can imagine a similar scenario as above, except one important thing. This time, let’s imagine that all the styles get applied after the element gets fragmented and distributed on multiple lines. In other words, paddings, borders, etc would be applied to each fragment almost as if they were separate elements.

That’s pretty awesome, and with one simple property, we’ve unleashed a ton of possibilities! Here’s a CodePen link with various demos for you to play around with.

Portier (pronounced “Por-tee-ay”) is a self-hostable login service that you can use instead of passwords. Portier sits between your website and third-party services like Google Sign-In to provide your users the fastest and easiest login experience, without ever needing a new password.

Best of all, Portier works for everyone, because it can fall back to traditional “click the link” methods of email confirmation.

• Email-first: Email addresses are decentralized, self-hostable, and useful on their own, so Portier uses email addresses instead of usernames to identify users.

• Connected: Whenever possible, Portier integrates with major APIs like Google Sign-In to provide seamless, in-browser identity verification.

• Decentralized: Anyone can host their own Portier Broker; there are no centralized dependencies.

• Open and Transparent: Because Portier uses email addresses, there is never any lock-in.

Portier is inspired by many projects and considers itself a spiritual successor to Mozilla Persona.

There’s a × character in most common fonts which you should use instead of an x for close, but getting it to look right across devices requires an eye for the detail.

Here’s a screenshot of the simulator vs. the real device, with exactly the same CSS applied to create the effect. Notice that the vertical align is off?

It took me a while to work out what was different, but it’s the font. The font I’m using (if you’re on a Mac - as I was), is Helvetia Neue, but my Android doesn’t have that font, so it was falling back to the next default (possibly set as sans-serif, which could be Open Sans, or it could be something else). In this case, the different font had a slightly different letter height, so it caused (obviously) as slightly different result.

The pro tip: make sure to use a common font, probably Arial (IHMO ideally a font that doesn’t need to be downloaded) for button icons.

Yes, I know this is obvious if you’re using an icon font…but maybe not immediately obvious if you’re re-using system fonts.

Opening links in a new window [or tab] allows users to explore related materials without losing contact with the originating site; removing link underlines makes pages cleaner and easier to read because underlines are distracting and interfere with letterforms; and creating fixed-width pages restricts line length so users are not forced to read long lines of text. However, each decision has the potential of causing usability problems for some users: When links open in a new window, users who rely on the back button to navigate the Web will not have access to that functionality; when links are not underlined, users who cannot distinguish colors may not be able to identify links; and when pages are set to a fixed width, users who need to enlarge text will be forced to read narrow text columns.

I love SVG. It’s elegant, scalable and works everywhere. It’s perfect for mobile… as long as it doesn’t move. There is no way to animate it smoothly on Android - rasterization won’t give you a chance:

You can use a little-known, yet important and powerful CSS property to make text run vertically.

Or instead of running text vertically, you can layout a set of icons or interface buttons in this way. Or, of course, with anything on your page.

[…]

If you do want a bit more of a taste, look at this example that adds text-orientation: upright; to the mix — turning the individual letters of the latin font to be upright instead of sideways.

I built text sizing widgets for years, every damn site. I was so proud of them too. It was a way of showing I care about users. It was all ego. As soon as I could start tracking clicks on those widgets I found they were not used. Even on sites I built for low vision communities.

Instead, a good design with non-hardcoded typefaces that is responsive and does not disable zoom was all I needed. In short, good development techniques and best practices. That handled most of my edge cases just fine. For the remainder, a little documentation in the form of simple, contextual help text.

Notice I am not referencing assistive technology. For the most part, those users don’t need your widgets, they have already obtained tools to work around a non-inclusive web.

[…]

Instead of custom widget, maybe help educate users on how to use their own web browser. Perhaps link to, or offer as pop-up help, quick instructions on how to scale text in the user’s current browser.

Now you will have educated a user. You will have armed a user to have a better experience across the whole of the web. You will have stopped selfishly building a widget for just your users and contributed to empowering all users.

What could be more inclusive than that?