Léonie Watson (@LeonieWatson) explains the difference between aria-label and aria-labelledby:
The aria-label and aria-labelledby attributes are both used to give an element it’s accessible name. The difference between aria-label and aria-labelledby is where they get that piece of text, and the clue is in the name. The aria-label attribute gives an element its label; an element with the aria-labelledby attribute is labelled by something else.
But don’t go adding of them everywhere, as you might not need ARIA (see The First Rule of ARIA) 😉
If you’re unfamiliar with some of the CSS terms like Selector, Attribute Selector, Expression, Declaration, etc. then CSS Vocabulary will come in handy. It’s a page containing a CSS code snippet. You can click on each part of the code (or in the sidebar) to see which part is what.
Have a static site but looking to add backendy stuff — such as subscribing to a newsletter — to it? Geoffrey Dhuyvetters from madewithlove walks us trough setting up a serverless function with Vercel (formerly known as Zeit):
In this article I’ll walk you through the steps to create serverless functions with Vercel. These functions will provide you with a place to add server side logic like verifying captcha’s, sending emails or liking posts that you can use in your static sites.
At Google Cloud Next ’20, Cloud Run Product Manager Steren Giannini (@steren) walked us through some of the new things that are coming to Google Cloud Run.
Some highlights:
VPC Peering
Gradual Rollouts (with custom URLs per tagged release)
New Load-Balancing Features (Multi Region, Cloud CDN, IAP)
Cloud Run is a fully managed compute platform by Google that automatically scales stateless containers. By abstracting away all infrastructure management, us developers can focus on what matters most: building great applications.
In this talk I’ll show you not only how to deploy PHP/Node applications onto Cloud Run, but also how to create a build pipeline using either Google Cloud Build or Github Actions.
In mid August the video got released, which I’ve embedded below:
Thanks to the organisers for having me, and thanks to the attendees for coming to see me. I hope you all had fun attending this talk. I know I had making it (and whilst bringing it forward) 🙂
One of the features of the Web Share API is that it allows you to share files along with your share intent:
if (navigator.canShare && navigator.canShare({ files: filesArray })) {
navigator.share({
files: filesArray,
title: 'Vacation Pictures',
text: 'Photos from September 27 to October 14.',
})
.then(() => console.log('Share was successful.'))
.catch((error) => console.log('Sharing failed', error));
} else {
console.log(`Your system doesn't support sharing files.`);
}
As unearthed by redteam.pl there’s a big security issue with it in Safari/MobileSafari:
The problem is that file: scheme is allowed and when a website points to such URL unexpected behavior occurs. In case such a link is passed to the navigator.share function an actual file from the user file system is included in the shared message which leads to local file disclosure when a user is sharing it unknowingly. The problem is not very serious as user interaction is required, however it is quite easy to make the shared file invisible to the user. The closest comparison that comes to mind is clickjacking as we try to convince the unsuspecting user to perform some action.
In their tests they’ve successfully stolen the local /etc/passwd or even the entire MobileSafari history (which is nothing more than a .sqlite file).
Apple first stated that they are only going to fix it in the Spring 2021 (!) Security Update, but after the post went public it now looks that they’ve changed course, as by now a fix has been committed into the Webkit Source:
+static Optional<URL> shareableURLForShareData(ScriptExecutionContext& context, const ShareData& data)
+{
+ if (data.url.isNull())
+ return WTF::nullopt;
+
+ auto url = context.completeURL(data.url);
+ if (!url.isValid())
+ return WTF::nullopt;
+ if (!url.protocolIsInHTTPFamily() && !url.protocolIsData())
+ return WTF::nullopt;
+
+ return url;
+}
+
- Optional<URL> url;
- if (!data.url.isNull()) {
- url = context.completeURL(data.url);
- if (!url->isValid())
- return false;
- }
+ if (!data.url.isNull() && !shareableURLForShareData(context, data))
+ return false;
+
Bonus points for naming that class WTF 😅
Apart from that quick fix in the code, the issue is also being discussed at the spec level in order to prevent other implementers from making the same mistake.
🤔 What about Chrome you might ask? Google Chrome does currently not support the Web Share API yet. And if it did — and above that also were to allow file: attachments — it has an allowlist of permitted file extensions in place.
Over at CSS-Tricks, Chris takes a look at how to mark up a “Double Heading”, a common pattern where you have a big heading with a little one preceding/succeeding it (as pictured above).
