Select Page

Category: Article

That Time I Tried Browsing the Web Without CSS

CSS is what gives every website its design. Websites sure aren’t very fun and friendly without it! I’ve read about somebody going a week without JavaScript and how the experience resulted in websites that were faster, though certain aspects of them would not function as expected. But CSS. Turning off CSS while browsing the web wouldn’t exactly make the web far less usable… right? Or, like JavaScript, would some features not work as expected? Out of curiosity, I decided to give it a whirl and rip the CSS flesh off the HTML skeleton while browsing a few sites. Why, you might ask? Are there any non-masochistic reasons for turning off CSS? Heydon Pickering once tweeted that disabling CSS is a good way to check some accessibility standards: Common elements like headings, lists, and form controls are semantic and still look good. A visual hierarchy is still established with default styles. The content can still be read in a logical order. Images still exist as tags rather than getting lost as CSS backgrounds. A WebAIM survey from 2018 reported that 12.5% of users who rely on any sort of assisted technology browse the web with custom stylesheets, which can include doing away with every CSS declaration across a site. And, if we’re talking about slow internet connections, ditching CSS could be one way to consume content faster. There’s also the...

Read More

The Circle of a React Lifecycle

A React component goes through different phases as it lives in an application, though it might not be evident that anything is happening behind the scenes. Those phases are: mounting updating unmounting error handling There are methods in each of these phases that make it possible to perform specific actions on the component during that phase. For example, when fetching data from a network, you’d want to call the function that handles the API call in the componentDidMount() method, which is available during the mounting phase. Knowing the different lifecycle methods is important in the development of React applications, because it allows us to trigger actions exactly when they’re needed without getting tangled up with others. We’re going to look at each lifecycle in this post, including the methods that are available to them and the types of scenarios we’d use them. The Mounting Phase Think of mounting as the initial phase of a component’s lifecycle. Before mounting occurs, a component has yet to exist — it’s merely a twinkle in the eyes of the DOM until mounting takes place and hooks the component up as part of the document. There are plenty of methods we can leverage once a component is mounted: constructor() , render(), componentDidMount() and static getDerivedStateFromProps(). Each one is handy in it’s own right, so let’s look at them in that order. constructor() The constructor()...

Read More

So, You Wanna Submit a Proposal to Speak at an Event

You’ve been scouring the web for upcoming events. You’ve subscribed to Developer Avocados and you’ve bookmarked conferences.css-tricks.com. And now you’ve found a call for proposals (CFP) that you can’t wait to enter. You quickly fill out the online form and your pinky races towards the Enter button… Stop. Take a deep breath. And move slowly away from the keyboard. As a conference organizer, I’ve gone through hundreds — if not thousands — of speaking proposals. While many are excellent, there are always a bunch that show a profound misunderstanding of the event, audience, and duties of a speaker. These are the ones that immediately get dumped onto the “No Thanks” list on my Trello board. And, as a regular speaker, I’ve learned more than a few things about getting proposals accepted. While there’s no magic bullet for fast tracking your talk, there are a number of habits you can develop and questions you can ask yourself before hitting “submit” to improve your chances of getting invited to events. If you’re a fan of checklists, I’ve put one together to guide you through the process of submitting a proposal. It’s even available on CodePen. 😉 See the Pen The CFP Checklist by Jason Rodriguez (@rodriguezcommaj) on CodePen. Start with some research The first thing before submitting a proposal is to research the heck out of the event. There are a...

Read More

Faking env() to Use it Now

There is already an env() function in CSS, but it kinda came out of nowhere as an Apple thing for dealing with “The Notch” but it has made it’s way to be a draft spec. The point will be for UAs or authors to declare variables that cannot be changed. Global const for CSS, sorta. That spec doesn’t seem to suggest how we’ll actually set those env() values just yet. If you want them now, the easiest way to fake them would be using regular ol’ CSS custom properties and simply not change them. But if you want that env() syntax though, there is a PostCSS plugin for emulating it. The way the plugin handles them is through a JavaScript file that declares them. postcssCustomProperties({ importFrom: 'path/to/file.js' /* module.exports = { environmentVariables: { '--branding-padding': '20px', '--branding-small': '600px' } } */ }); Having them start life as JavaScript is interesting, as it means we could perhaps have a single place to set variables that are accessible both to JavaScript and CSS. That’s what Harry Nicholls covers more in his article, “Why you should use CSS env()” like some gotchas when dealing with units and such. But if you really needed a single source for unchangeable variables in both CSS and JavaScript, then I’d say this is a good way to go — and could potentially be ripped out once support...

Read More

Clever code

This week, Chris Ferdinandi examined a clever JavaScript snippet, one that’s written creatively with new syntax features, but is perhaps less readable and performant. It’s a quick read, but his callout of our industry’s fixation on cleverness is worth… calling out: …we’ve become obsessed as an industry with brevity and clever code, and it results in code that’s sometimes less performant, and typically harder to read and make sense of for most people. He made a similar argument late last month when he wrote about code readability, noting that brevity might look cool but ultimately leads to all sorts of issues in a codebase: Often, web developers are obsessed with brevity. There’s this thing were developers will try to write the same function in the fewest number of characters possible. Personally, I think brevity is pointless. Readability is a lot more important. I entirely agree with Chris on this point, however, I think there is one important distinction to make and that’s the difference between code that’s intended as a prototype and code that’s intended for production. As Jeremy Keith argued a short while ago: 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...

Read More
www.000webhost.com