Increment is a beautiful quarterly magazine (print and web) published by Stripe “about how teams build and operate software systems at scale”. While there is always stuff about making websites in general, this issue is the first focused on front-end¹ development.
I’ve got an article in there: When frontend means full stack. I’ll probably someday port it over here and perhaps add some more context (there were some constraints for print) but I love how it turned out on their site! A taste:
We handle this growing responsibility in different ways. Even though we all technically fall within the same big-tent title, many frontend developers wind up specializing. Often, we don’t have a choice. The term “unicorn” once described the extremely rare person who was good at both frontend and backend development, but these days it’s just as rare to find people skilled at the full spectrum of frontend development. In fact, the term “full stack” has largely come to mean “a frontend developer who does a good amount of the stuff a backend developer used to do.”
The whole issue is chock full of wonderful authors:
And the article that is the most right up my alley, Why is CSS . . . the way it is? by Chris Lilley. It’s somehow astonishing, gutwrenching, understandable, and comfortable to know that CSS evolves like any other software project. Sometimes thoughtfully and carefully, and sometimes with a meh, we’ll fix it later.
Once a feature is in place, it’s easier to slightly improve it than to add a new, better, but completely different feature that does the same thing.
This explains, for example, why list markers were initially specified in CSS by expanding the role offloat. (The list marker was floated left so the list item text wrapped around it to the right.) That effort was abandoned and replaced by thelist-style-positionproperty, whose definition currently has the following, not very confidence-inspiring inline issue: “This is handwavey nonsense from CSS2, and needs a real definition.”
That’s a damn fine collection of writings on front end if you ask me.
A big thank you to Sid Orlando and Molly McArdle who helped me through the process and seem to do a great job running the ship over there.
The post Increment Issue 13: Frontend appeared first on CSS-Tricks.
With a preprocessor, like Sass, building a logical “do this or don’t” setting is fairly straightforward:
$option: false;
@mixin doThing {
@if $option {
do-thing: yep;
}
}
.el {
@include doThing;
}Can we do that in native CSS with custom properties? Mark Otto shows that we can. It’s just a smidge different.
html {
--component-shadow: 0 .5rem 1rem rgba(0,0,0,.1);
}
.component {
box-shadow: var(--component-shadow);
}
<!-- override the global anywhere more specific! like
<div class="component remove-shadow">
or
<body class="remove-shadow"> -->
.remove-shadow {
--component-shadow: none;
}Direct Link to Article — Permalink
The post Global CSS options with custom properties appeared first on CSS-Tricks.
The global spread of COVID-19 and resulting orders to shelter in place have hit retailers hard.
As the pandemic drags on, temporary halts are becoming permanent closures, whether it’s the coffee shop next door, a historic bar or a well-known lifestyle brand.
But while the present is largely bleak, preparing for the future has retailers adopting technologies faster than ever. Their resilience and innovation means retail will look and fee different when the world reopens.
We gathered four views on the future of retail from the TechCrunch team:
Natasha Mascarenhas
Introduced in mid-2017, the Look was one of the more obscure — and, honestly, kind of bizarre — entries in the Echo line. It was a small camera designed to take videos and selfies of its owner, using machine learning to help choose outfits.
No surprise, really, that it never caught fire. And now, three years after its introduction, it’s dead. First noted by Voicebot.ai, Amazon sent a letter to customers noting that the camera has been discontinued — what’s more, service is going to completely shuttered in July.
Amazon confirmed the end of what seems to have amounted to an experiment and exercise in training a machine learning algorithm. The company tells TechCrunch,
When we introduced Echo Look three years ago, our goal was to train Alexa to become a style assistant as a novel way to apply AI and machine learning to fashion. With the help of our customers we evolved the service, enabling Alexa to give outfit advice and offer style recommendations. We’ve since moved Style by Alexa features into the Amazon Shopping app and to Alexa-enabled devices making them even more convenient and available to more Amazon customers. For that reason, we have decided it’s time to wind down Echo Look. Beginning July 24, 2020, both Echo Look and its app will no longer function. Customers will still be able to enjoy style advice from Alexa through the Amazon Shopping app and other Alexa-enabled devices. We look forward to continuing to support our customers and their style needs with Alexa.
Not a surprise, perhaps. But a bummer for those who spent the $200 on the product. For the looks of it, though, I don’t think the Look exactly caught the world on fire. It’s currently listed as the 51st best seller on Amazon’s list of Echo products. Honestly, there’s a decent chance this is the first time you’re hearing about it. Again, not surprising for what was always destined to be a niche addition to the Echo line.
Many developers are at least marginally familiar with AWS Lambda functions. They’re reasonably straightforward to set up, but the vast AWS landscape can make it hard to see the big picture. With so many different pieces it can be daunting, and frustratingly hard to see how they fit seamlessly into a normal web application.
The Serverless framework is a huge help here. It streamlines the creation, deployment, and most significantly, the integration of Lambda functions into a web app. To be clear, it does much, much more than that, but these are the pieces I’ll be focusing on. Hopefully, this post strikes your interest and encourages you to check out the many other things Serverless supports. If you’re completely new to Lambda you might first want to check out this AWS intro.
There’s no way I can cover the initial installation and setup better than the quick start guide, so start there to get up and running. Assuming you already have an AWS account, you might be up and running in 5–10 minutes; and if you don’t, the guide covers that as well.
Before we get to cool things like file uploads and S3 buckets, let’s create a basic Lambda function, connect it to an HTTP endpoint, and call it from an existing web app. The Lambda won’t do anything useful or interesting, but this will give us a nice opportunity to see how pleasant it is to work with Serverless.
First, let’s create our service. Open any new, or existing web app you might have (create-react-app is a great way to quickly spin up a new one) and find a place to create our services. For me, it’s my lambda folder. Whatever directory you choose, cd into it from terminal and run the following command:
sls create -t aws-nodejs --path hello-worldThat creates a new directory called hello-world. Let’s crack it open and see what’s in there.
If you look in handler.js, you should see an async function that returns a message. We could hit sls deploy in our terminal right now, and deploy that Lambda function, which could then be invoked. But before we do that, let’s make it callable over the web.
Working with AWS manually, we’d normally need to go into the AWS API Gateway, create an endpoint, then create a stage, and tell it to proxy to our Lambda. With serverless, all we need is a little bit of config.
Still in the hello-world directory? Open the serverless.yaml file that was created in there.
The config file actually comes with boilerplate for the most common setups. Let’s uncomment the http entries, and add a more sensible path. Something like this:
functions:
hello:
handler: handler.hello
# The following are a few example events you can configure
# NOTE: Please make sure to change your handler code to work with those events
# Check the event documentation for details
events:
- http:
path: msg
method: getThat’s it. Serverless does all the grunt work described above.
Ideally, we want to call this from front-end JavaScript code with the Fetch API, but that unfortunately means we need CORS to be configured. This section will walk you through that.
Below the configuration above, add cors: true, like this
functions:
hello:
handler: handler.hello
events:
- http:
path: msg
method: get
cors: trueThat’s the section! CORS is now configured on our API endpoint, allowing cross-origin communication.
While our HTTP endpoint is configured for CORS, it’s up to our Lambda to return the right headers. That’s just how CORS works. Let’s automate that by heading back into handler.js, and adding this function:
const CorsResponse = obj => ({
statusCode: 200,
headers: {
"Access-Control-Allow-Origin": "*",
"Access-Control-Allow-Headers": "*",
"Access-Control-Allow-Methods": "*"
},
body: JSON.stringify(obj)
});Before returning from the Lambda, we’ll send the return value through that function. Here’s the entirety of handler.js with everything we’ve done up to this point:
'use strict';
const CorsResponse = obj => ({
statusCode: 200,
headers: {
"Access-Control-Allow-Origin": "*",
"Access-Control-Allow-Headers": "*",
"Access-Control-Allow-Methods": "*"
},
body: JSON.stringify(obj)
});
module.exports.hello = async event => {
return CorsResponse("HELLO, WORLD!");
};Let’s run it. Type sls deploy into your terminal from the hello-world folder.
When that runs, we’ll have deployed our Lambda function to an HTTP endpoint that we can call via Fetch. But… where is it? We could crack open our AWS console, find the gateway API that serverless created for us, then find the Invoke URL. It would look something like this.
Fortunately, there is an easier way, which is to type sls info into our terminal:
Just like that, we can see that our Lambda function is available at the following path:
https://6xpmc3g0ch.execute-api.us-east-1.amazonaws.com/dev/msNow let’s open up a web app and try fetching it. Here’s what our Fetch will look like:
fetch("https://6xpmc3g0ch.execute-api.us-east-1.amazonaws.com/dev/msg")
.then(resp => resp.json())
.then(resp => {
console.log(resp);
});We should see our message in the dev console.
Now that we’ve gotten our feet wet, let’s repeat this process. This time, though, let’s make a more interesting, useful service. Specifically, let’s make the canonical “resize an image” Lambda, but instead of being triggered by a new S3 bucket upload, let’s let the user upload an image directly to our Lambda. That’ll remove the need to bundle any kind of aws-sdk resources in our client-side bundle.
OK, from the start! This particular Lambda will take an image, resize it, then upload it to an S3 bucket. First, let’s create a new service. I’m calling it cover-art but it could certainly be anything else.
sls create -t aws-nodejs --path cover-artAs before, we’ll add a path to our HTTP endpoint (which in this case will be a POST, instead of GET, since we’re sending the file instead of receiving it) and enable CORS:
// Same as before
events:
- http:
path: upload
method: post
cors: trueNext, let’s grant our Lambda access to whatever S3 buckets we’re going to use for the upload. Look in your YAML file — there should be a iamRoleStatements section that contains boilerplate code that’s been commented out. We can leverage some of that by uncommenting it. Here’s the config we’ll use to enable the S3 buckets we want:
iamRoleStatements:
- Effect: "Allow"
Action:
- "s3:*"
Resource: ["arn:aws:s3:::your-bucket-name/*"]Note the /* on the end. We don’t list specific bucket names in isolation, but rather paths to resources; in this case, that’s any resources that happen to exist inside your-bucket-name.
Since we want to upload files directly to our Lambda, we need to make one more tweak. Specifically, we need to configure the API endpoint to accept multipart/form-data as a binary media type. Locate the provider section in the YAML file:
provider:
name: aws
runtime: nodejs12.x…and modify if it to:
provider:
name: aws
runtime: nodejs12.x
apiGateway:
binaryMediaTypes:
- 'multipart/form-data'For good measure, let’s give our function an intelligent name. Replace handler: handler.hello with handler: handler.upload, then change module.exports.hello to module.exports.upload in handler.js.
First, let’s grab some helpers.
npm i jimp uuid lambda-multipart-parserWait, what’s Jimp? It’s the library I’m using to resize uploaded images. uuid will be for creating new, unique file names of the sized resources, before uploading to S3. Oh, and lambda-multipart-parser? That’s for parsing the file info inside our Lambda.
Next, let’s make a convenience helper for S3 uploading:
const uploadToS3 = (fileName, body) => {
const s3 = new S3({});
const params = { Bucket: "your-bucket-name", Key: `/${fileName}`, Body: body };
return new Promise(res => {
s3.upload(params, function(err, data) {
if (err) {
return res(CorsResponse({ error: true, message: err }));
}
res(CorsResponse({
success: true,
url: `https://${params.Bucket}.s3.amazonaws.com/${params.Key}`
}));
});
});
};Lastly, we’ll plug in some code that reads the upload files, resizes them with Jimp (if needed) and uploads the result to S3. The final result is below.
'use strict';
const AWS = require("aws-sdk");
const { S3 } = AWS;
const path = require("path");
const Jimp = require("jimp");
const uuid = require("uuid/v4");
const awsMultiPartParser = require("lambda-multipart-parser");
const CorsResponse = obj => ({
statusCode: 200,
headers: {
"Access-Control-Allow-Origin": "*",
"Access-Control-Allow-Headers": "*",
"Access-Control-Allow-Methods": "*"
},
body: JSON.stringify(obj)
});
const uploadToS3 = (fileName, body) => {
const s3 = new S3({});
var params = { Bucket: "your-bucket-name", Key: `/${fileName}`, Body: body };
return new Promise(res => {
s3.upload(params, function(err, data) {
if (err) {
return res(CorsResponse({ error: true, message: err }));
}
res(CorsResponse({
success: true,
url: `https://${params.Bucket}.s3.amazonaws.com/${params.Key}`
}));
});
});
};
module.exports.upload = async event => {
const formPayload = await awsMultiPartParser.parse(event);
const MAX_WIDTH = 50;
return new Promise(res => {
Jimp.read(formPayload.files[0].content, function(err, image) {
if (err || !image) {
return res(CorsResponse({ error: true, message: err }));
}
const newName = `${uuid()}${path.extname(formPayload.files[0].filename)}`;
if (image.bitmap.width > MAX_WIDTH) {
image.resize(MAX_WIDTH, Jimp.AUTO);
image.getBuffer(image.getMIME(), (err, body) => {
if (err) {
return res(CorsResponse({ error: true, message: err }));
}
return res(uploadToS3(newName, body));
});
} else {
image.getBuffer(image.getMIME(), (err, body) => {
if (err) {
return res(CorsResponse({ error: true, message: err }));
}
return res(uploadToS3(newName, body));
});
}
});
});
};I’m sorry to dump so much code on you but — this being a post about Amazon Lambda and serverless — I’d rather not belabor the grunt work within the serverless function. Of course, yours might look completely different if you’re using an image library other than Jimp.
Let’s run it by uploading a file from our client. I’m using the react-dropzone library, so my JSX looks like this:
<Dropzone
onDrop={files => onDrop(files)}
multiple={false}
>
<div>Click or drag to upload a new cover</div>
</Dropzone>The onDrop function looks like this:
const onDrop = files => {
let request = new FormData();
request.append("fileUploaded", files[0]);
fetch("https://yb1ihnzpy8.execute-api.us-east-1.amazonaws.com/dev/upload", {
method: "POST",
mode: "cors",
body: request
})
.then(resp => resp.json())
.then(res => {
if (res.error) {
// handle errors
} else {
// success - woo hoo - update state as needed
}
});
};And just like that, we can upload a file and see it appear in our S3 bucket!
There’s one optional enhancement we could make to our setup. Right now, when we deploy our service, Serverless is zipping up the entire services folder and sending all of it to our Lambda. The content currently weighs in at 10MB, since all of our node_modules are getting dragged along for the ride. We can use a bundler to drastically reduce that size. Not only that, but a bundler will cut deploy time, data usage, cold start performance, etc. In other words, it’s a nice thing to have.
Fortunately for us, there’s a plugin that easily integrates webpack into the serverless build process. Let’s install it with:
npm i serverless-webpack --save-dev…and add it via our YAML config file. We can drop this in at the very end:
// Same as before
plugins:
- serverless-webpackNaturally, we need a webpack.config.js file, so let’s add that to the mix:
const path = require("path");
module.exports = {
entry: "./handler.js",
output: {
libraryTarget: 'commonjs2',
path: path.join(__dirname, '.webpack'),
filename: 'handler.js',
},
target: "node",
mode: "production",
externals: ["aws-sdk"],
resolve: {
mainFields: ["main"]
}
};Notice that we’re setting target: node so Node-specific assets are treated properly. Also note that you may need to set the output filename to handler.js. I’m also adding aws-sdk to the externals array so webpack doesn’t bundle it at all; instead, it’ll leave the call to const AWS = require("aws-sdk"); alone, allowing it to be handled by our Lamdba, at runtime. This is OK since Lambdas already have the aws-sdk available implicitly, meaning there’s no need for us to send it over the wire. Finally, the mainFields: ["main"] is to tell webpack to ignore any ESM module fields. This is necessary to fix some issues with the Jimp library.
Now let’s re-deploy, and hopefully we’ll see webpack running.
Now our code is bundled nicely into a single file that’s 935K, which zips down further to a mere 337K. That’s a lot of savings!
If you’re wondering how you’d send other data to the Lambda, you’d add what you want to the request object, of type FormData, from before. For example:
request.append("xyz", "Hi there");…and then read formPayload.xyz in the Lambda. This can be useful if you need to send a security token, or other file info.
If you’re wondering how you might configure env variables for your Lambda, you might have guessed by now that it’s as simple as adding some fields to your serverless.yaml file. It even supports reading the values from an external file (presumably not committed to git). This blog post by Philipp Müns covers it well.
Serverless is an incredible framework. I promise, we’ve barely scratched the surface. Hopefully this post has shown you its potential, and motivated you to check it out even further.
If you’re interested in learning more, I’d recommend the learning materials from David Wells, an engineer at Netlify, and former member of the serverless team, as well as the Serverless Handbook by Swizec Teller
The post Building Your First Serverless Service With AWS Lambda Functions appeared first on CSS-Tricks.
I totally forgot that the Jamstack Conf was this week but thankfully they’ve already published the talks on the Jamstack YouTube channel. I’m really looking forward to sitting down with these over a coffee while I also check out Netlify’s other big release today: Build Plugins.
These are plugins that run whenever your site is building. One example is the A11y plugin that will fail a build if accessibility failures are detected. Another minifies HTML and there’s even one that inlines critical CSS. What’s exciting is that these build plugins are kinda making complex Gulp/Grunt environments the stuff of legend. Instead of going through the hassle of config stuff, build plugins let Netlify figure it all out for you. And that’s pretty neat.
Also, our very own Sarah Drasner wrote just about how to create your first Netlify Build Plugin. So, if you have an idea for something that you could share with the community, then that may be the best place to start.
Direct Link to Article — Permalink
The post Jamstack News! appeared first on CSS-Tricks.
In this instalment of our ongoing series around making the most of your at-home video setup, we’re going to focus on one of the most important, but least well understood or implemented parts of the equation: Lighting. While it isn’t actually something that requires a lot of training, expertise or even equipment to get right, it’s probably the number one culprit for subpar video quality on most conference calls – and it can mean the difference between looking like someone who knows what they talk about, and someone who might not inspire too much confidence on seminars, speaking gigs and remote broadcast appearances.
You can make a very big improvement in your lighting with just a little work, and without spending any money. The secret is all in being aware of your surroundings and optimizing your camera placement relative to any light sources that might be present. Consider not only any ceiling lights or lamps in your room, but also natural light sources like windows.
Ideally, you should position yourself so that the source of brightest light is positioned behind your camera (and above it, if possible). You should also make sure that there aren’t any strong competing light sources behind you that might blow out the image. If you have a large window and it’s daytime, face the window with your back to a wall, for instance. And if you have a moveable light or a overhead lamp, either move it so it’s behind and above your computer facing you, or move yourself if possible to achieve the same effect with a fixed position light fixture, like a ceiling pendant.
Ideally, any bright light source should be positioned behind and slightly above your camera for best results.
Even if the light seems aggressively bright to you, it should make for an even, clear image on your webcam. Even though most webcams have auto-balancing software features that attempt to produce the best results regardless of lighting, they can only do so much, and especially lower-end camera hardware like the webcam built into MacBooks will benefit greatly from some physical lighting position optimization.
This is an example of what not to do: Having a bright light source behind you will make your face hard to see, and the background blown out.
The best way to step up beyond the basics is to learn some of the fundamentals of good video lighting. Again, this doesn’t necessarily require any purchases – it could be as simple as taking what you already have and using it in creative ways.
Beyond just the above advice about putting your strongest light source behind your camera pointed towards your face, you can get a little more sophisticated by adopting the principles of two- and three-point lighting. You don’t need special lights to make this work – you just need to use what you have available and place them for optimal effect.
A very basic, but effective video lighting setup involves positioning not just one, but two lights pointed towards your face behind, or parallel with your camera. Instead of putting them directly in line with your face, however, for maximum effect you can place them to either side, and angle them in towards you.
A simple representation of how to position lights for a proper two-point video lighting setup.
Note that if you can, it’s best to make one of these two lights brighter than the other. This will provide a subtle bit of shadow and depth to the lighting on your face, resulting in a more pleasing and professional look. As mentioned, it doesn’t really matter what kind of light you use, but it’s best to try to make sure that both are the same temperature (for ordinary household bulbs, how ‘soft,’ ‘bright’ or ‘warm’ they are) and if your lights are less powerful, try to position them closer in.
Similar to two-point lighting, but with a third light added positioned somewhere behind you. This extra light is used in broadcast interview lighting setups to provide a slight halo effect on the subject, which further helps separate you from the background, and provides a bit more depth and professional look. Ideally, you’d place this out of frame of your camera (you don’t want a big, bright light shining right into the lens) and off to the side, as indicated in the diagram below.
In a three-point lighting setup, you add a third light behind you to provide a bit more subject separation and pop.
If you’re looking to improve the flexibility of this kind of setup, a simple way to do that is by using light sources with Philips Hue bulbs. They can let you tune the temperature and brightness of your lights, together or individually, to get the most out of this kind of arrangement. Modern Hue bulbs might produce some weird flickering effects on your video depending on what framerate you’re using, but if you output your video at 30fps, that should address any problems there.
All lights can be used to improve your video lighting setup, but dedicated video lights will provide the best results. If you really plan on doing a bunch of video calls, virtual talks and streaming, you should consider investing in some purpose-built hardware to get even better results.
At the entry level, there are plenty of offerings on Amazon that work well and offer good value for money, including full lighting kits like this one from Neewer that offers everything you need for a two-point lighting setup in one package. These might seem intimidating if you’re new to lighting, but they’re extremely easy to set up, and really only require that you learn a bit about light temperature (as measured in kelvins) and how that affects the image output on your video capture device.
If you’re willing to invest a bit more money, you can get some better quality lights that include additional features including wifi connectivity and remote control. The best all-around video lights for home studio use that I’ve found are Elgato’s Key Lights. These come in two variants, Key Light and Key Light Air, which retail for $199.99 and $129.99 respectively. The Key Light is larger, offers brighter maximum output, and comes with a sturdier, heavy-duty clamp mount for attaching to tables and desks. The Key Light Air is smaller, more portable, puts out less light at max settings and comes with a tabletop stand with a weighted base.
Both versions of the Key Light offer light that you can tune form very warm white (2900K) to bright white (7000K) and connect to your wifi network for remote control, either from your computer or your mobile device. They easily work together with Elgato’s Stream Deck for hardware controls, too, and have highly adjustable brightness and plenty of mounting options – especially with extra accessories like the Multi-Mount extension kit.
With plenty of standard tripod mounts on each Key Light, high-quality durable construction and connected control features, these lights are the easiest to make work in whatever space you have available. The quality of the light they put out is also excellent, and they’re great for lighting pros and newbies alike since it’s very easy to tune them as needed to produce the effect you want.
Beyond subject lighting, you can look at different kinds of accent lighting to make your overall home studio more visually interesting or appealing. Again, there are a number of options here, but if you’re looking for something that also complements your home furnishings and won’t make your house look too much like a studio set, check out some of the more advanced versions of Hue’s connected lighting system.
The Hue Play light bar is a great accent light, for instance. You can pick up a two pack, which includes two of the full-color connected RGB lights. You’ll need a Hue hub for these to work, but you can also get a starter pack that includes two lights and the hub if you don’t have one yet. I like these because you can easily hide them behind cushions, chairs, or other furniture. They provide awesome uplight effects on light-colored walls, especially if you get rid of other ambient light (beyond your main video lights).
To really amplify the effect, consider pairing these up with something one the Philips Hue Signe floor or table lamps. The Signe series is a long LED light mounted to a weighted base that provide strong, even accent light with any color you choose. You can sync these with other Hue lights for a consistent look, or mix and max colors for different dynamic effects.
On video, this helps with subject/background separation, and just looks a lot more polished than a standard background, especially when paired with defocused effects when you’re using better quality cameras. As a side benefit, these lights can be synced to movie and video playback for when you’re consuming video, instead of producing it, for really cool home theater effects.
If you’re satisfied with your lighting setup but are still looking for other pointers, check out our original guide, as well as our deep dive on microphones for better audio quality.
Core Web Vitals is what Google is calling a a new collection of three web performance metrics:
These are all measurable. They aren’t in Lighthouse (e.g. the Audits tab in Chrome DevTools) just yet, but sounds like that’s coming up soon. For now, an open source library will get you the numbers. There is also a browser extension (that feels pretty alpha as you have to install it manually).
That’s all good to me. I like seeing web performance metrics evolve into more meaningful numbers. I’ve spent a lot of time in my days just doing stuff like reducing requests and shrinking assets, which is useful, but kind of a side attack to web performance. These metrics are what really matter because they are what users actually see and experience.
The bigger news came today though in that they are straight up telling us: Core Web Vitals matter for your SEO:
Today, we’re building on this work and providing an early look at an upcoming Search ranking change that incorporates these page experience metrics. We will introduce a new signal that combines Core Web Vitals with our existing signals for page experience to provide a holistic picture of the quality of a user’s experience on a web page.
Straight up, these numbers matter for SEO (or they will soon).
And they didn’t bury the other lede either:
As part of this update, we’ll also incorporate the page experience metrics into our ranking criteria for the Top Stories feature in Search on mobile, and remove the AMP requirement from Top Stories eligibility.
AMP won’t be required for SERP carousel thing, which was the #1 driver of AMP adoption. I can’t wait to see my first non-AMP page up there! I know some features will be unavailable, like the ability to swipe between stories (because that relies on things like the Google AMP cache), but whatever, bring it on. Let AMP just be a thing people use because they want to not because they have to.
The post Core Web Vitals appeared first on CSS-Tricks.
Oh hey! A brand new property that affects how a box is sized! That’s a big deal. There are lots of ways already to make an aspect-ratio sized box (and I’d say this custom properties based solution is the best), but none of them are particularly intuitive and certainly not as straightforward as declaring a single property.
So, with the impending arrival of aspect-ratio (MDN, and not to be confused with the media query version), I thought I’d take a look at how it works and try to wrap my mind around it.
Shout out to Una where I first saw this. Boy howdy did it strike interest in folks:
aspect-ratio on an element alone will calculate a height based on the auto width.Without setting a width, an element will still have a natural auto width. So the height can be calculated from the aspect ratio and the rendered width.
.el {
aspect-ratio: 16 / 9;
}
The aspect ratio becomes ignored in that situation, which is actually nice. Better to avoid potential data loss. If you prefer it doesn’t do this, you can always use the padding hack style.
So aspect-ratio is basically a way of seeing the other direction when you only have one (demo).
aspect-ratio is ignored.The combination of an explicit height and width is “stronger” than the aspect ratio.
min-* and max-*There is always a little tension between width, min-width, and max-width (or the height versions). One of them always “wins.” It’s generally pretty intuitive.
If you set width: 100px; and min-width: 200px; then min-width will win. So, min-width is either ignored because you’re already over it, or wins. Same deal with max-width: if you set width: 100px; and max-width: 50px; then max-width will win. So, max-width is either ignored because you’re already under it, or wins.
It looks like that general intuitiveness carries on here: the min-* and max-* properties will either win or are irrelevant. And if they win, they break the aspect-ratio.
.el {
aspect-ratio: 1 / 4;
height: 500px;
/* Ignored, because width is calculated to be 125px */
/* min-width: 100px; */
/* Wins, making the aspect ratio 1 / 2 */
/* min-width: 250px; */
}
Aspect ratios are always most useful in fluid situations, or anytime you essentially don’t know one of the dimensions ahead of time. But even when you don’t know, you’re often putting constraints on things. Say 50% wide is cool, but you only want it to shrink as far as 200px. You might do width: max(50%, 200px);. Or constrain on both sides with clamp(200px, 50%, 400px);.
This seems to work inutitively:
.el {
aspect-ratio: 4 / 3;
width: clamp(200px, 50%, 400px);
}But say you run into that minimum 200px, and then apply a min-width of 300px? The min-width wins. It’s still intuitive, but it gets brain-bending because of how many properties, functions, and values can be involved.
aspect-ratio as the weakest way to size an element?It will never beat any other sizing information out, but it will always do its sizing if there is no other information available for that dimension.
The post A First Look at `aspect-ratio` appeared first on CSS-Tricks.
After careful consideration, we settled on rearchitecting our platform to use $FLASHY_LANGUAGE and $HYPED_TECHNOLOGY. Not only is $FLASHY_LANGUAGE popular according to the Stack Overflow developer survey, it’s also cross platform; we’re using it to reimplement our mobile apps as well. Rewriting our core infrastructure was fairly straightforward: as we have more engineers than we could possibly ever need or even know what to do with, we simply put a freeze on handling bug reports and shifted our effort to $HYPED_TECHNOLOGY instead. We originally had some trouble with adapting to some of $FLASHY_LANGUAGE’s quirks, and ran into a couple of bugs with $HYPED_TECHNOLOGY, but overall their powerful new features let us remove some of the complexity that our previous solution had to handle.
There is absolutely no way Saagar Jha is poking at this or this.
Direct Link to Article — Permalink
The post Why we at $FAMOUS_COMPANY Switched to $HYPED_TECHNOLOGY appeared first on CSS-Tricks.
Amazon customers in nearly a dozen more U.S. states are now able to use their SNAP (Supplemental Nutrition Assistance Program) benefits to purchase groceries online, the retailer announced on Thursday. The news represents a significant expansion of a United States Department of Agriculture (USDA) pilot program introduced in 2019 that aimed to open up online grocery shopping to those on public assistance. This program is even more critical now, as in-store shopping puts consumers at risk of contracting the deadly novel coronavirus.
To date, participating retailers in the USDA pilot program have included Walmart, Amazon, ShopRite, and other smaller chains.
Amazon confirmed to TechCrunch that the 11 new states that now support using SNAP for online grocery, include those that were added starting last week through today, Thursday, May 28.
The initial expansion of the pilot added New Mexico, Vermont, West Virginia, and Wisconsin, which all became active last week. On Tuesday of this week, Colorado, Maryland, Minnesota, and New Jersey rolled out. And today, Massachusetts, Michigan, and Virginia were added as well.
With these new additions, Amazon customers on public assistance can shop online for groceries across a total of 25 U.S. states plus Washington D.C. At checkout, they can pay for groceries using their SNAP EBT.
Including the new states, Amazon now offers the use of SNAP EBT for online grocery in Alabama, Arizona, California, Colorado, Florida, Idaho, Iowa, Kentucky, Maryland, Massachusetts, Michigan, Minnesota, Missouri, Nebraska, New Jersey, New Mexico, New York, North Carolina, Oregon, Texas, Vermont, Virginia, Washington, West Virginia, and Wisconsin.
However, Amazon is not the only retailer offering online grocery for SNAP EBT customers in these 25 states.
According to the USDA’s website, SNAP users can now order their groceries online through either Amazon or Walmart in these markets.
The site also indicates that Amazon is the only retailer supporting the District of Columbia at present. In addition, ShopRite supports the use of SNAP for online groceries in Maryland, New Jersey, and New York. And Wright’s Markets is participating in the pilot program in Alabama.
The USDA’s website indicates several more states are now in the planning phase so they can add online purchasing as a shopping option soon. These include Connecticut, Georgia, Illinois, Indiana, Nevada, Ohio, Oklahoma, Pennsylvania, Rhode Island, Tennessee, and Wyoming.
As part of Amazon’s participation in the USDA program, it not only enabled the use of SNAP EBT as a payment method, it also made its Amazon Fresh service available to SNAP recipients in states where Fresh is available without requiring a Prime membership. And it offered free shipping on both Amazon Fresh and Amazon Pantry orders.
At launch, Amazon had said the USDA pilot program would “dramatically increase access to food for more remote customers.”
However, in the coronavirus era, access to online grocery can be a life-saving measure for some.
The pandemic has complicated access to food for those on SNAP benefits, and for high-risk individuals on SNAP in particular. These consumers now have to risk getting COVID-19 every time they out for groceries themselves. And as more workers become unemployed due to the economic impacts from the pandemic, more people are joining public assistance programs like SNAP.
In light of the pandemic, the USDA said it would fast-track any state that wanted to join the pilot. California, Arizona, Florida, Idaho, Kentucky, Missouri, Texas, West Virginia, D.C., North Carolina, and Vermont, were just approved in April, for example. In May, the USDA approved Minnesota, Colorado, Nevada, Wisconsin, Rhode Island, New Mexico, and Wyoming.
In under 6 weeks, the USDA has expanded access to the program to a total of 36 states plus D.C., it say, though many are not yet live. When they launch, however, online purchasing for groceries will be available to more than 90% of SNAP participants, the USDA has noted.
Rivian, the electric vehicle company backed by Amazon, Cox Automotive and Ford, has resumed work at its factory in Normal, Ill. following a temporary shutdown due to the COVID-19 pandemic.
Construction on the factory, which will eventually produce its R1T and R1S electric vehicles for consumers as well as 100,000 delivery vans for Amazon, has restarted with employees returning in phases. Despite the shutdown and gradual restart, the timeline for the Amazon delivery vans is still on track, according to a statement from Amazon released Thursday.
In September, Amazon announced it had ordered 100,000 electric delivery vehicles from Rivian as part of its commitment to The Climate Pledge to become net zero carbon by 2040. Vans will begin delivering to customers in 2021, as previously planned. About 10,000 electric vehicles will be on the road as early as 2022 and all 100,000 vehicles will be on the road by 2030, Amazon said in a statement Thursday.
Rivian has pushed the start of production on the R1T and R1S to 2021. The company had initially planned to start production and begin deliveries of the electric pickup truck and SUV in late 2020. That timeline has been adjusted. Rivian had always planned to deliver the R1T truck first, followed by the R1S.
The COVID-19 pandemic forced the company to adjust its timeline due to supply constraints. However, Rivian is now working on bringing the production and delivery timeline of the R1T and R1S closer together.
For now, the company is focused on work inside and outside the factory. About 335 Rivian employees were on site before COVID hit. Today, about 116 are on site with plans to gradually bring back the remaining employees. Rivian did not furlough any employees and continues to pay all workers their wages.
About 109 contractors are also back at the factory working on the interior. Another 120 to 140 contractors are working outside to expand the factory from 2.6 million to 3 million square feet.
The company has implemented new safety practices under a four-phase plan, according to Rivian CEO RJ Scaringe. Temperature checks are carried out and workers are supplied with protective clothing and equipment.
The vehicle engineering and design teams have also developed digital methods to make sure that program timing remains on track, according to Scaringe.
In a blog post today, Amazon announced plans to offer permanent jobs to around 70% of the 175,000 temporary workers it brought on to meet demand amid a COVID-19-fueled surge. Initially filled as seasonal positions, the company will be transferring 125,000 people to full-time roles next month, as the pandemic-fueled push theoretically dies down.
Those roles will earn workers a minimum wage of $15 and hour (after pushback from lawmakers like Bernie Sanders) and access to some training programs designed to help them work their way up at the company. The full-time jobs will kick in the same month Amazon winds down its $2 an hour hazard pay for workers.
Amazon has been the subject of criticism for its handling of the COVID-19 crisis, including letters from senators and attorneys general aimed at getting a better picture of its worker health policies, along with numbers of employees who have been infected or died from the novel coronavirus.
Another asked the company to offer insight into why the company had fired a number of staff who had been vocally critical of its policies. Amazon has denied any wrongdoing in all of this and insisted that COVID-19 rates among staff are lower than the general population.
This latest move comes amid the worst U.S. unemployment rate since the Great Depression. This week, an additional 2.1 million Americans applied for unemployment, bringing the total up to 41 million since the beginning of the pandemic. Economists are hopeful that reopening sectors of the country will help reverse those figures, assuming that such actions don’t lead to massive spikes in COVID-19 cases and deaths.
Diana Smith with another mind-bending all HTML & CSS painting.
I love that these occupy a special place on the “Should I draw this in CSS?” curve. Things like simple shapes are definitely on the “yes” side of the curve. Then there’s a large valley where things get a little too impractical to draw that way, and using some other image format (e.g. SVG) makes way more sense.
Diana’s work pulls the curve back up to the “yes” side. Not only because it’s proof that CSS can be an amazing expressionistic art tool, but also from a performance standpoint — it’s only 2 KB of HTML and 10 KB of CSS.
Direct Link to Article — Permalink
The post PureCSS Gaze appeared first on CSS-Tricks.
For those who have missed the big news, Firefox now supports conic gradients!
Starting with Firefox 75, released on the April 7, we can go to about:config, look for the layout.css.conic-gradient.enabled flag and set its value to true (it’s false by default and all it takes to switch is double-clicking it).
With that enabled, now we can test our CSS including conic gradients in Firefox as well.
While some of the demos in this article work just fine when using a polyfill, some use CSS variables inside the conic gradient and therefore require native support for this feature.
One thing I particularly like about conic gradients is just how much they can simplify background patterns. So let’s take a few linear-gradient() patterns from the gallery created by Lea Verou about a decade ago and see how we can now simplify them with conic-gradient!
The pattern above uses four linear gradients:
background:
linear-gradient(315deg, transparent 75%, #d45d55 0) -10px 0,
linear-gradient(45deg, transparent 75%, #d45d55 0) -10px 0,
linear-gradient(135deg, #a7332b 50%, transparent 0) 0 0,
linear-gradient(45deg, #6a201b 50%, #561a16 0) 0 0 #561a16;
background-size: 20px 20px;That’s quite a bit of CSS and perhaps even a bit intimidating. It’s not easy to just look at this and understand how it all adds up to give us the pyramid pattern. I certainly couldn’t do it. It took me a while to get it, even though gradients are one of the CSS features I’m most comfortable with. So don’t worry if you don’t understand how those gradients manage to create the pyramid pattern because, one, it is complicated and, two, you don’t even need to understand that!
Using conic-gradient(), we can now get the same result in a much simpler manner, with a single background layer instead of four!
What I like to do when coding repeating patterns is draw equidistant vertical and horizontal lines delimiting the rectangular boxes defined by the background-size. In this case, it’s pretty obvious we have square boxes and where their limits are, but it’s a really useful technique for more complex patterns.
By default, conic gradients start from 12 o’clock and go clockwise. However, in our case, we want to offset the start of the gradient by 45° in the clockwise direction and afterwards make every one of the four shades occupy a quarter (25%) of the available space around the midpoint of our square box.
25% starting from 45° w.r.t. the vertical axis (live).This means our pyramid pattern can be reduced to:
$s: 20px;
background:
conic-gradient(from 45deg,
#561a16 25%,
#6a201b 0% 50%,
#a7332b 0% 75%,
#d45d55 0%)
50%/ #{$s $s};Not only does the code look simpler, but we’ve also gone from 260 bytes to 103 bytes, reducing the code needed to get this pattern by more than half.
We’re using the double position syntax as that’s also well supported these days.
We can see it in action in the Pen below:
This pattern above is created with two linear gradients:
background-color: #eee;
background-image:
linear-gradient(45deg, black 25%, transparent 25%,
transparent 75%, black 75%, black),
linear-gradient(45deg, black 25%, transparent 25%,
transparent 75%, black 75%, black);
background-size: 60px 60px;
background-position: 0 0, 30px 30px;Let’s see how we can simplify this CSS when replacing these linear gradients with a conic one!
Just like in the previous case, we draw vertical and horizontal lines in order to better see the rectangles defined by the background-size.
Looking at the square highlighted in deeppink in the illustration above, we see that, in this case, our conic gradient starts from the default position at 12 o’clock. A quarter of it is black, the next quarter is dirty white and then we have repetition (the same black and then dirty white quarter slices once more).
This repetition in the second half of the [0%, 100%] interval means we can use a repeating-conic-gradient(), which gives us the following code (bringing the compiled CSS from 263 bytes down to only 73 bytes – that’s reducing it by over 70%):
$s: 60px;
background:
repeating-conic-gradient(#000 0% 25%, #eee 0% 50%)
50%/ #{$s $s};The Pen below shows it in action:
Again, we have a pattern created with two linear gradients:
background-color: #eee;
background-image:
linear-gradient(45deg, black 25%, transparent 25%,
transparent 75%, black 75%, black),
linear-gradient(-45deg, black 25%, transparent 25%,
transparent 75%, black 75%, black);
background-size: 60px 60px;We draw horizontal and vertical lines to split this pattern into identical rectangles:
What we now have is pretty much the same checkerbox pattern as before, with the sole difference that we don’t start from the default position at 12 o’clock, but from 45° in the clockwise direction.
If you’re having trouble visualising how simply changing the start angle can make us go from the previous pattern to this one, you can play with it in the interactive demo below:
Note that this demo does not work in browsers that have no native support for conic gradients.
This means our code looks as follows:
$s: 60px;
background:
repeating-conic-gradient(from 45deg,
#000 0% 25%, #eee 0% 50%)
50%/ #{$s $s};We can see it in action below:
Again, not only is the code simpler to understand, but we’ve also gone from 229 bytes to only 83 bytes in the compiled CSS, reducing it by almost two-thirds!
This pattern was created with four linear gradients:
background: #36c;
background:
linear-gradient(115deg, transparent 75%, rgba(255,255,255,.8) 75%) 0 0,
linear-gradient(245deg, transparent 75%, rgba(255,255,255,.8) 75%) 0 0,
linear-gradient(115deg, transparent 75%, rgba(255,255,255,.8) 75%) 7px -15px,
linear-gradient(245deg, transparent 75%, rgba(255,255,255,.8) 75%) 7px -15px,
#36c;
background-size: 15px 30px;Just like in the previous cases, we draw equidistant vertical and horizontal lines in order to better see the repeating unit:
What we have here is a pattern that’s made up of congruent isosceles triangles (the angled edges are equal and the dark blue triangles are a reflection of the light blue ones) formed by the intersection of equidistant parallel lines that are either horizontal, angled clockwise, or the other way. Each of these three types of parallel lines is highlighted in the illustration below:
Every pattern cell contains a full triangle and two adjacent triangle halves in the upper part, then a reflection of this upper part in the lower part. This means we can identify a bunch of congruent right triangles that will help us get the angles we need for our conic-gradient():
This illustration shows us that the gradient starts from an angle, β, away from the default conic gradient start point at 12 o’clock. The first conic slice (the top right half triangle) goes up to α, the second one (the bottom right dark triangle) up to 2·α, and the third one (the bottom light triangle) goes halfway around the circle from the start (that’s 180°, or 50%). The fourth one (the bottom left dark triangle) goes to 180° + α and the fifth one (the top left light triangle) goes to 180° + 2·α, while the sixth one covers the rest.
α and β (demo)From the highlighted right triangle we get that:
tan(α) = (.5·h)/(.5·w) = h/wKnowing the width (w) and height (h) of a pattern cell, we can get the angles α and β:
α = atan(h/w)
β = 90° - αIt results in the pattern that’s generated by the following code:
$w: 15px;
$h: 30px;
$a: atan($h/$w)*180deg/pi();
$b: 90deg - $a;
$c0: #36c;
$c1: #d6e0f5;
html {
background:
conic-gradient(from $b,
$c1 0% $a,
$c0 0% 2*$a,
$c1 0% 50%,
$c0 0% 180deg + $a,
$c1 0% 180deg + 2*$a,
$c0 0%)
0 0/ #{$w $h};
}This means going from 343 bytes to only 157 bytes in the compiled CSS. The result can be seen below:
You can tweak the pattern width ($w) and height ($h) in the Sass code in order to see how the pattern gets squished and stretched for different aspect ratios.
In the particular case where the angle between 2*$a and 50% (or 180deg) is also $a, it results that $a is 60deg, our isosceles triangles are equilateral, and our gradient can be reduced to a repeating one (and under 100 bytes in the compiled CSS):
$a: 60deg;
$b: 90deg - $a;
$w: 15px;
$h: $w*tan($a);
$c0: #36c;
$c1: #d6e0f5;
html {
background:
repeating-conic-gradient(from $b,
$c1 0% $a, $c0 0% 2*$a)
0 0/ #{$w $h}
}The live result can be seen below:
While these are not repeating patterns, they’re examples of a situation where a single conic gradient achieves an effect that would have previously needed a bunch of linear ones.
What we have here is a conic-gradient() created starting from two straight lines intersecting within the rectangular box where we set the background.
The gradient goes around the point of coordinates, x,y, where the two straight lines intersect. It starts from an angle, β, which is the angle of the line segment that’s closest to the top-right corner, then has hard stops at α, 50% (or 180°) and 180° + α.
If we want to have multiple elements with similar such patterns created with the help of different intersecting lines and different palettes, we have the perfect use case for CSS variables:
.panel {
background:
conic-gradient(from var(--b) at var(--xy),
var(--c0) var(--a), var(--c1) 0% 50%,
var(--c2) 0% calc(180deg + var(--a)), var(--c3) 0%);
}All we have to do is set the position (--xy), the start angle (--b), the first angle (--a) and the palette (--c0 through --c3).
.panel {
/* same as before */
&:nth-child(1) {
--xy: 80% 65%;
--b: 31deg;
--a: 121deg;
--c0: #be5128;
--c1: #ce9248;
--c2: #e4c060;
--c3: #db9c4e
}
/* similarly for the other panels */
}Instead of hardcoding, we could also generate these values randomly or extract them from a data object with the help of a CSS or HTML preprocessor. In this second case, we’d set these custom properties inline, which is precisely what I did in the Pen below:
Since we’re using custom properties inside the conic gradients, this demo does not work in browsers that don’t support them natively.
Well, that’s it! I hope you’ve enjoyed this article and that it gives you some ideas about how conic gradients can make your life easier.
The post Background Patterns, Simplified by Conic Gradients appeared first on CSS-Tricks.
With a high of F and a low of 15F. Currently, it's 14F and Clear outside. Current wind speeds: 13 from the Southwest Pollen: 0 S...
