Select Page

Category: Link

Well, Typetura seems fun

I came across this update from Scott Kellum’s and Sal Hernandez’s project Typetura via my Medium feed this morning, and what a delight?! (Also, wow, I really have been out of the game for a minute.) Typetura.js is a fluid design solution, for any property, based on any input. It’s not for just typography across screen sizes. Transition between anything — width, height, scroll position, cursor position, and more.https://t.co/EoouX0PkGC — typetura (@typetura) January 18, 2019 This is quite exciting! Typetura wants to deal with some of the main problems that come up when utilizing fluid type in your CSS. > Typetura is a fluid typesetting tool. Use the slider at the top of the screen to select the breakpoint you want to style, then use the panel on the left of the screen to style your page.https://t.co/6cjgdEylwY — CSS-Tricks (@css) November 22, 2018 Typetura was created to make fluid typography mainstream. To do this there were two problems to solve. First, develop an implementation that is feature rich and easy to implement with CSS. Second, create a design tool that designers can use to illustrate how they want fluid typography to look. I love a tool that tries to remove friction and make technologies easier to use. To ensure the implementation was easy to use and understand, Typetura needed a simple, declarative syntax in vanilla CSS. This means no...

Read More

How do you figure?

Scott O’Hara digs into the and elements. Gotta love a good ol’ HTML deep dive. I use these on just about every blog post here on CSS-Tricks, and as I’ve suspected, I’ve basically been doing it wrong forever. My original thinking was that a figcaption was just as good as the alt attribute. I generally use it to describe the image. The Starry Night, a famous painting by Vincent van Gogh I intentionally left off the alt text, because the figcaption is saying what I would want to say in the alt text and I thought duplicating it would...

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
www.000webhost.com