Instant Web Site Tools

There’s a 33-minute video (and resources) over on apple.com covering the upcoming Safari changes we saw in the WWDC keynote this year in much more detail. Look who’s got a little cameo in there:

Perhaps the most noticeable thing there in Safari 15 on iOS is URL bar at the bottom! Dave was speculating in our little Discord watch party that this probably fixes the weird issues with 100vh stuff on iOS. But I really just don’t know, we’ll have to see when it comes out and we can play with it. I’d guess the expectation is that, in order for us to do our own fixed-bottom-UI stuff, we’d be doing:

.bottom-nav { 
  position: fixed; /* maybe sticky is better if part of overall page layout? */
  bottom: 100vh; /* fallback? */
  bottom: calc(100vh - env(safe-area-inset-bottom); /* new thing */
}

On desktop, the most noticeable visual feature is probably the theme-color meta tags.

This isn’t even a brand new Apple-only thing. This is the same <meta tag that Chrome’s Android app has used since 2014, so you might already be sporting it on your own site. The addition is that it supports media queries.

<meta name="theme-color" 
      content="#ecd96f" 
      media="(prefers-color-scheme: light)"<meta name="theme-color" 
      content="#0b3e05" 
      media="(prefers-color-scheme: dark)"

It’s great to see Safari get aspect-ratio and the new fancy color systems like lab() and lch() as well. Top-level await in JavaScript is great as it makes patterns like conditional imports easier.

I don’t think all this would satisfy Alex. We didn’t exactly get alternative browser engines on iOS or signifiant PWA enhancements (both of which would be really great to see). But I applaud it all, and it’s good stuff. While I do think Google generally takes privacy more seriously than what general internet chatter would have to believe, it’s notable to compare each company’s newly-released features. If you’ll forgive a bit of cherry-picking, Google is working on FLoC, a technology very specifically designed to help targeted advertising. Apple is working on Private Relay, a technology very specifically …

That’s the one word that isn’t an adjective in the acronym RSS.

Really Simple Syndication.

RSS isn’t just about RSS readers. Even though, gosh if I don’t love RSS readers. It’s about putting content in a format that is designed to be portable. An API for content isn’t a metaphor, that’s literally what it is.

RSS is always on my mind, because it’s like my daily newspaper, but I’d wager it’s not exactly at the peak of people’s attention, even developers. It’s been getting a smidge of attention though, as Google is dipping it’s toes back into RSS with a “following” feature in Android Chrome. Publishers (like me) are always interested in ways we can help people read our stuff, and in this case, the way we help is by having an RSS feed. Sweet.

But again, it’s not just about reader apps. For example: every single podcast (every single podcast) is an RSS feed. That’s notable to say the least.

I also see apps that take advantage of it in unique ways. MonitoRSS is one of them. The whole point of it is kicking content over to Discord channels by — you guessed it — RSS feeds.

You can also build literal websites from aggregated content. For example, your WordPress site can suck in RSS feeds and re-display the content. I’m not 100% sure how it works but the Sidebar Webring is presumably powered by RSS as well. It’s just like CSS-Trickz. Alex could have used RSS to grab that content, it just so happens WordPress also has a JSON API which is often easier than parsing the XML of RSS. Dave and Robin have used Feedbin’s API to display posts that they read and “like” via RSS.

Having an RSS feed opens doors to all sorts of user-friendly ways for people to follow and read your content, above and beyond RSS readers.

---

The post The Possibilities of Syndication appeared first on CSS-Tricks.

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

Does that make your eye twitch a little bit? Like… it’s a typo. It should be target="_blank" with an underscore to start the value. As in…

<a target="_blank" href="https://codepen.io"Open CodePen in a New Tab
</a

Welp, that’s correct syntax!

In the case of the no-underscore target="blank", the blank part is just a name. It could be anything. It could be target="foo" or, perhaps to foreshadow the purpose here: target="open-new-links-in-this-space".

The difference:

• target="_blank" is a special keyword that will open links in a new tab every time.
• target="blank" will open the first-clicked link in a new tab, but any future links that share target="blank" will open in that same newly-opened tab.

I never knew this! I credit this tweet explanation.

I created a very basic demo page to show off the functionality (code). Watch as a new tab opens when I click the first link. Then, subsequent clicks from either also open tab open that link in that new second tab.

Why?

I think use cases here are few and far between. Heck, I’m not even that big of a fan of target="_blank". But here’s one I could imagine: documentation.

Say you’ve got a web app where people actively do work. It might make sense to open links to documentation from within that app in a new tab, so they aren’t navigating away from active work. But, maybe you think they don’t need a new tab for every documentation link. You could do like…

<a target="codepen-documentation" 
  href="https://blog.codepen.io/documentation/"View CodePen Documentation
</a<!-- elsewhere --<a target="codepen-documentation" 
  href="https://blog.codepen.io/documentation/"About Asset Hosting
</a

---

The post target=”blank” appeared first on CSS-Tricks.

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

from CSS-Tricks https://css-tricks.com/targetblank/…

WordPress sites have an API by default. Wanna see this site’s most recent posts, with just a specific set of data… in JSON format? Here ya go. Alex Riviere made a joke site using that.

At first, the site would fetch from that API client-side when it loaded. Fine, but if we take it seriously for a second, it’s very inefficient for people visiting the site (i.e. slower than server-rendered HTML), nor very efficient on API hits. So, Alex re-wrote it using a Netlify Function. The Netlify Function then would fetch (in Node-in-the-cloud) from the API and serve the pre-rendered HTML. That’s probably a bit better, but as Alex says:

This actually gives us a new problem that the function runs on MY dime every time someone comes to the site.

The free-tier of Netlify Functions is for a generous 125,000 requests per month, which should be plenty for a little site like this, but still, as Alex said, he’d “rather not become a victim of internet popularity.”

Good timing, as Netlify just released On-Demand builders, which make caching the results of something like this fairly easy. It’s just like creating any other function, except the signature looks like this:

const { builder } = require("@netlify/functions")

async function myfunction(event, context) {
  // logic to generate the required content
}

exports.handler = builder(myfunction);

I like what Andrew said in our ShopTalk D-D-D-Discord — this concept is widely applicable to API usage in general. Free blog post idea: Maximize Your API Free Tier with On-Demand Builders.

Direct Link to Article — Permalink

---

The post CSS-Trickz: An Experiment with Netlify’s On-Demand Builders appeared first on CSS-Tricks.

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

from CSS-Tricks https://alex.party/posts/2021-05-31-css-trickz-an-experiment-with-netlify-s-on-demand-builders/…

• Show/Hide password accessibility and password hints tutorial — Nicolas Steenhout goes deep on <input type="password"> accessibility. For one thing, being able to toggle it to type="text" should be possible, while announcing, politely, the change. But also, put the password hints (for choosing a password) before the input and programmatically connect them. And a bunch of other stuff. (Video version)
• Practical accessibility, part 2: Name (almost) everything — Maggie Wachs explains how it’s all about the ability to move about the page.
• Modern CSS Upgrades To Improve Accessibility — Stephanie Eckles shows off :focus-visible, outline-offset, order and other properties that can both help and hurt accessibility. My favorite are the clever uses of min() and max() which do things like reduce excessive margin on page zoom and maintain tappable area sizes.
• WebAIM Million – 2021 Update — Jared Smith notes that things are getting better, even if just a bit. Is that the first time ever?! Things certainly aren’t “good” but it’s an encouraging trend.
• Shift further left with Deque’s axe-linter for VS Code — Jonathan Thickens intros this new editor plugin which calls out errors just as if they were syntax, spelling, or formatting errors. As it should be! I’m using it and it works great. “Shift left” means “test earlier in the process” and “as you code” is about as early as it gets.
• Content-visibility and Accessible Semantics — Marcy Sutton notes that the accessibility issues that hurt content-visibility when it first rolled have been resolved. This is the original blog post that documented what they were.
• More Accessible Skeletons — Adrian Roselli notes that aria-busy="true" for a bit of skeleton HTML isn’t enough, as there is a little more attribute-shuffling to do, paired with CSS selectors to hide what needs to be hidden. (Demo)
• Giving a damn about accessibility — Sheri Byrne-Haber’s “candid and practical handbook for designers.” Free digital (and audio) book. 📒

---

The post Links on Accessibility appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP …

• Show/Hide password accessibility and password hints tutorial — Nicolas Steenhout goes deep on <input type="password"> accessibility. For one thing, being able to toggle it to type="text" should be possible, while announcing, politely, the change. But also, put the password hints (for choosing a password) before the input and programmatically connect them. And a bunch of other stuff. (Video version)
• Practical accessibility, part 2: Name (almost) everything — Maggie Wachs explains how it’s all about the ability to move about the page.
• Modern CSS Upgrades To Improve Accessibility — Stephanie Eckles shows off :focus-visible, outline-offset, order and other properties that can both help and hurt accessibility. My favorite are the clever uses of min() and max() which do things like reduce excessive margin on page zoom and maintain tappable area sizes.
• WebAIM Million – 2021 Update — Jared Smith notes that things are getting better, even if just a bit. Is that the first time ever?! Things certainly aren’t “good” but it’s an encouraging trend.
• Shift further left with Deque’s axe-linter for VS Code — Jonathan Thickens intros this new editor plugin which calls out errors just as if they were syntax, spelling, or formatting errors. As it should be! I’m using it and it works great. “Shift left” means “test earlier in the process” and “as you code” is about as early as it gets.
• Content-visibility and Accessible Semantics — Marcy Sutton notes that the accessibility issues that hurt content-visibility when it first rolled have been resolved. This is the original blog post that documented what they were.
• More Accessible Skeletons — Adrian Roselli notes that aria-busy="true" for a bit of skeleton HTML isn’t enough, as there is a little more attribute-shuffling to do, paired with CSS selectors to hide what needs to be hidden. (Demo)
• Giving a damn about accessibility — Sheri Byrne-Haber’s “candid and practical handbook for designers.” Free digital (and audio) book. 📒

---

The post Links on Accessibility appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP …

Let’s look at some extensions for VS Code that make writing and editing HTML (and languages that are basically HTML with extra powers) better. You may not like all of them. Maybe some of them don’t appeal to you, solve a problem you don’t have, or feel like more clutter than you need. That’s OK. These are just a handful that I’ve tried and liked to some degree.

I’d start with Emmet here, even thought it’s not technically an extension¹ for VS Code. It’s built right in. You should know about it though because it’s very useful. It does “HTML Expansions” like this, which I use pretty much every day of my life:

HTML End Tag Labels

I heard about this one from Stefan Judis who blogged about it the other day and inspired this post idea.

The whole idea is that rather than you leaving comments in your HTML to indicate what HTML element it is closing (a somewhat common practice, especially for partials that close elements that might not be opened in the same document).

<div class="main"</div<!-- / div.main --<?php /* / div.main */ ?<?php /* Sometimes I'd do it in a server side language so it didn't go over the wire. */ ?

This extension shows you UI about what HTML is being closed:

Auto Close Tag

As soon as you type the > in an HTML element, like the last bracket in <div>, the closing tag is automatically created for you.

It can be configured to only auto close after you’ve typed the </ to indicate you’re about to close a tag, which is a default in Sublime Text 3. Speaking of which, if you install the Sublime Text Keymap, you’d get that automatically, plus a handful of other fancy key commands.

There is also Close HTML/XML tag, but it only works via key command. With Auto Close Tag you can configure it either way, and it has far more installs for whatever reason.

Highlight Matching Tag

Here’s …

Colin Oakley:

• Accessible — Use semantic HTML, and make sure we meet the WCAG 2.1 AA standard as a minimum and it works with assisted technologies (this sits alongside the DWP Accessibility Manual)

• Agnostic — Build mobile-first and make it work across a range of devices, and user contexts

• Robust — Use progressive enhancement, make sure what we build fails gracefully

• Performant — Optimise our code/assets for the best possible performance across a range of networks and devices

• Secure — Create a secure service which protects users’ privacy. Use strict content security policies and guard against common OWASP attacks.

Direct Link to Article — Permalink

---

The post Principles for user-centered front-end development appeared first on CSS-Tricks.

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

from CSS-Tricks https://colinoakley.medium.com/the-web-we-choose-to-build-e921510e3f1b…

I just joked that we’re basically getting everything we want in CSS super fast (mostly referring to container queries, my gosh, can you imagine they are actually coming?). Now we might actually get parent selectors?! As in .parent:has(.child) { }. Traditionally it’s been nope, too slow, browsers can’t do it. Brian Kardell:

Igalia engineers have been looking into this problem. We’ve been having discussions with Chromium developers, looking into Firefox and WebKit codebases and doing some initial protypes and tests to really get our heads around it. Through this, we’ve provided lots of data about performance of what we have already and where we believe challenges and possibilities lie. We’ve begun sketching out an explainer with all of our design notes and questions linked up

Like I said in 2010: Want!

Here’s some other use cases in the blog post and comment section.

Direct Link to Article — Permalink

---

The post Can I :has() appeared first on CSS-Tricks.

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

from CSS-Tricks https://bkardell.com/blog/canihas.html…

DebugBear takes just a few seconds to start using. You literally point it at a URL you want to watch, and it’ll start watching it. You install nothing.

It’ll start running tests, and you’ve immediately got performance charts you can start looking at that are tracked over time, not just one-offs.

I’ve got full Lighthouse reports right in there, showing me stuff I really need to work on.

Because all these changes are tracked over time, you can see exactly what changed and when. That’s pretty big. Did your JavaScript bundle jump up in size? When? Why? Did your SEO score take a dip? When? Why?

Another great thing: DebugBear will email you (or send a Slack message) when you have regressions. So, even though the charts are amazing, it’s not like you have to log in every time to see what’s up. You can also set very clear performance budgets to test against:

Break a performance budget? You’ll be notified:

Want to compare across different areas/pages of your site? (You can log in to them before you test them, by the way.) Or compare yourself to competitors to make sure you aren’t falling behind? No problem, monitor those too:

Testing production is a very good thing. It’s measuring reality and you can get started quickly. But it can also be a very good thing to measure things before they become a problem. You know how you get deploy previews on services like Netlify and Vercel? Well, DebugBear has integrations built just for for services like Netlify and Vercel.

Now, when you’ve got a Pull Request with a deploy preview, …