Select Page

Category: Link

A Course About CSS Layout and Animations

Christina Gorton just released a new course called CSS Layout and Animations as a part of Design+Code, which is a $9/month. That includes a ton of video training on everything from stuff like this to React to Sketch to iOS development… and beyond! Christina approaches the course with my favorite way to learn this stuff: by starting from a lovely design and then pulling it off with code. That’s Figma as the design tool, which is another tool I love. Of course, what I really love is that: The course is full of CSS trickery and modern HTML &...

Read More

WorldWideWeb

For the 30th anniversary of the web, CERN brought nine web nerds together to recreate the very first web browser — Or a working replication of it anyway, as you use it from your web browser, inception style. Well done, Mark Boulton, John Allsopp, Kimberly Blessing, Jeremy Keith, Remy Sharp, Craig Mod, Martin Akolo Chiteri, Angela Ricci, and Brian Suda! I love that it was written in React and the font is an actual replication of what was used back then. What a cool project. They even opened-sourced the code. You can visit any site with Document > Open...

Read More

Prototypes and production

There’s an interesting distinction that Jeremy Keith defines between prototype code and production code in this post and I’ve been thinking about it all week: …every so often, we use the materials of front-end development—HTML, CSS, and JavaScript—to produce something that isn’t intended for production. I’m talking about prototyping. What’s interesting is that—when it comes to prototyping—our usual front-end priorities can and should go out the window. The priority now is speed. If that means sacrificing semantics or performance, then so be it. If I’m building a prototype and I find myself thinking “now, what’s the right class name for this component?”, then I know I’m in the wrong mindset. That question might be valid for production code, but it’s a waste of time for prototypes. I love the way that Jeremy phrases all of this and how he describes that these two environments require entirely separate mindsets. When prototyping, for instance, we can probably overlook optimizing for accessibility or performance and even let our CSS standards slip in order to get something in the browser and test it as quickly as possible. Earlier this year, I echoed some of the same thoughts when I wrote a little bit about prototyping in the browser: I reckon that the first time a designer and/or front-end developer writes code, it should never be in a production environment. Having the leeway and...

Read More

The Software We Pay For

We did a Web Developer Economics series a few years ago, where we looked at the various costs of being a web developer: Web Developer Economics: One-Off Software Costs Web Developer Economics: Hardware Costs Web Developer Economics: Monthly Service Costs Web Developer Economics: The Wrapup I’m sure some of that software and hardware has changed since then, but the spirit is the same. It costs money to have the things you need to do this job. I just wrote a similar article, but from the perspective of a business paying for the software it needs. That link is to Medium, but it was posted on the CodePen blog originally. Just giving that a shot to see what all the hubbub about Medium is about. Direct Link to Article — Permalink The post The Software We Pay For appeared first on CSS-Tricks....

Read More

It’s not about the device.

Ever have that, “Ugighgk, another device to support?!” feeling? Like, perhaps when you heard that wrist devices have browsers? Ethan’s latest post is about that. Personally, the Apple Watch is interesting to me not because it’s a watch. Rather, it’s interesting to me because it’s a smaller-than-normal touchscreen attached to a cellular antenna, and one that’s not necessarily on the most reliable connection. It helps me look past the device, and to think about how someone will interact with my work under those conditions. Once I do that, I can start to design accordingly. The post is nice reminder to revisit the idea of responsive design in our heads. The seismic shifts in how we consume the web is why web design and development shifted this way. So, enough thinking about specific devices. Instead, let’s make our approaches responsive and flexible, then new devices will come along. They will inevitably slot themselves right in without us having to re-design or re-code anything. Direct Link to Article — Permalink The post It’s not about the device. appeared first on CSS-Tricks....

Read More

Blue Beanie Day 2018

Another year! You better not cry, you better not shout, I’m telling you why: @BlueBeanieDay is coming Nov. 30! Start sharing your #bbd photos, links, articles, and videos now: https://t.co/3US4vHBsDR#a11y #WebStandards #InclusiveDesign #ProgressiveEnhancement pic.twitter.com/AiV3ktRqka — zeldman (@zeldman) October 24, 2018 I feel the same this year as I have in the past. Web standards, as an overall idea, has entirely taken hold and won the day. That’s worth celebrating, as the web would be kind of a joke without them. So now, our job is to uphold them. We need to cry foul when we see a browser go rogue and ship an API outside the standards process. That version of competition is what could lead the web back to a dark place where we’re creating browser-specific versions. That becomes painful, we stop doing it, and slowly, the web loses. Direct Link to Article — Permalink The post Blue Beanie Day 2018 appeared first on CSS-Tricks....

Read More

What If?

Harry Roberts writes about working on a project with a rather nasty design flaw. The website was entirely dependent on images loading before rendering any of the content. He digs into why this bad for accessibility and performance but goes further to describe how this can ripple into other problems: While ever you build under the assumption that things will always work smoothly, you’re leaving yourself completely ill-equipped to handle the scenario that they don’t. Remember the fallacies; think about resilience. Harry then suggests that we should always ask ourselves a key question when developing a website: what if this image doesn’t load? For example, if the user is on a low-end device, using a flakey network, using an obscure browser, looking at the site without a crucial API or feature available… you get the idea. While we’re on this note, we asked what makes a good front-end developer a little while back and I think this is the best answer to that question after reading Harry’s post: a good front-end developer is constantly asking themselves, “What if?” Direct Link to Article — Permalink The post What If? appeared first on CSS-Tricks....

Read More

State of Houdini (Chrome Dev Summit 2018)

Here’s a great talk by Das Surma where he looks into what Houdini is and how much of it is implemented in browsers. If you’re unfamiliar with that, Houdini is a series of technologies and APIs that gives developers low level access to how CSS properties work in a fundamental way. Check out Ana Tudor’s deep dive into its impact on animations for some incredible examples of it in practice. What I particularly like about this video is the way Das mentions the CSS Paint API which lets you do a bunch of bizarre things with CSS, such as creating “squircle” shapes and changing how borders work. It looks wonderfully robust and it should give us super powers in the near future. Ruth John wrote up this extensive overview on the topic earlier this year and it’s worth a read as well. Direct Link to Article — Permalink The post State of Houdini (Chrome Dev Summit 2018) appeared first on CSS-Tricks....

Read More

Simplify Styling with Functional CSS

There is no doubt that “functional CSS” resonates strongly with some people. If that term is new to you, I belive it’s come to mean the same thing as “Atomic CSS” as defined by John Polacek here. Harry Nicholls likens it to a function that can only produce one result (although I’d call that a pure function or pure component), but instead of a return value being entirely predictable based on inputs, it is an application of style that only does one thing. I’m of two minds here. People say how fast they can work this way. Great! They like how predictable the applied styles are. Great! I can understand how a tiny stylesheet that doesn’t grow over time is appealing as well. At the same time, I haven’t seen writing about other styling concerns. What happens with big redesigns? Is it about the same, time- and difficulty-wise, or do you spend more time tearing down all those classes? What happens when you need a style that isn’t available? Write your own? Or does that ruin the spirit of all this and put you in dangerous territory? How intense can all the class names get? I can think of areas I’ve styled that have three or more media queries that dramatically re-style an element. Putting all that information in HTML seems like it could get awfully messy. Is consistency...

Read More
www.000webhost.com