Select Page

Category: Link

The Dark Side of the Grid

Manuel Matuzovic makes the point that in order to use CSS grid in some fairly simple markup scenarios, we might be tempted to flatten our HTML to make sure all the elements we need to can participate on the grid. What we need is subgrid and non-buggy display: contents;, so I’d like to think in a year or so we’ll be past this. Direct Link to Article — Permalink The post The Dark Side of the Grid appeared first on CSS-Tricks....

Read More

The Dark Side of the Grid

Manuel Matuzovic makes the point that in order to use CSS grid in some fairly simple markup scenarios, we might be tempted to flatten our HTML to make sure all the elements we need to can participate on the grid. What we need is subgrid and non-buggy display: contents;, so I’d like to think in a year or so we’ll be past this. Direct Link to Article — Permalink The post The Dark Side of the Grid appeared first on CSS-Tricks....

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