Select Page

Category: Article

Nobody is quite wrong.

There are two opposing views on using non-polyfillable new web features that I find are both equally common in our industry: Websites don’t need to look the same in every browser. The concept of progressive enhancement helps with that. There are tools, even native language features, that help with this. If browser support isn’t where I want it to be, it’s just exotic eye candy for demos and not to be used. I’m not sure I’d say either one of these is more or less correct than the other. I also imagine it doesn’t come as much of surprise that I support the thinking behind #1. It’s perfectly possible to design and implement things that behave differently in different browsers and conditions. That’s essentially what responsive design is, and that’s pretty much the entire internet now. The backbone of progressive enhancement is starting with a working foundation that works everywhere and layering design and functionality on top of that, when possible. There are even native language features to support the idea. @supports rules allow us to write CSS that can do something if a feature is supported and do something else if it isn’t. This is the entire use case for Modernizr and it has 22,804 stars. I don’t want to argue against progressive enhancement. Remember, I just said I support that thinking. But I do have some empathy...

Read More

Annotated Build Processes

When you’re putting together a build process for a site, it’s so dang useful to look at other people’s processes. I ran across Andrew Welch’s “An Annotated webpack 4 Config for Frontend Web Development” the other day and was glad he blogged it. If I was kicking off a new site where I wanted a webpack build, then I’d almost certainly reference something like this rather than start from scratch. At the same time, it made me realize how build processes all have such different needs and how unique those needs are now from even a few years ago in the hay day of Grunt and Gulp build processes. I was looking around for an annotated Gulp reference file and came across another one of Andrew’s articles — “A Gulp Workflow for Frontend Development Automation” — from just one year earlier! Here’s a simplified list of what he was doing with Gulp (which he explains in more detail in the post): Compile Sass Run Autoprefixer Create Sourcemaps Minify Inject critical CSS and bits of scripts Run Babel Uglify Do style injection/reloading Run accessibility audit Generate icon font Optimize images Speaking of Gulp and annotated build processes, I’m working on a CSS-Tricks redesign and, for various reasons, went with a Gulp build. Against my better judgment, I wrote it from scratch, and this is how far I’ve gotten. It doesn’t...

Read More

JavaScript to Native (and Back!)

I admit I’m quite intrigued by frameworks that allow you write apps in web frameworks because they do magic to make them into native apps for you. There are loads of players here. You’ve got NativeScript, Cordova, PhoneGap, Tabris, React Native, and Flutter. For deskop apps, we’ve got Electron. What’s interesting now is to see what’s important to these frameworks by honing in on their focus. Hummingbird is Flutter for the web. (There is a fun series on Flutter over on the Bendworks blog in addition to a post we published earlier this year.) The idea being you get super high performance ,thanks to the framework, and you’ve theoretically built one app that runs both on the web and natively. I don’t know of any real success stories I can point to, but it does seem like an awesome possibility. Nicolas Gallagher has been a strong proponent of React Native for the web. The post JavaScript to Native (and Back!) appeared first on CSS-Tricks....

Read More

Keep Math in the CSS

There is a sentiment that leaving math calculations in your CSS is a good idea that I agree with. This is for math that you could calculate at authoring time, but specifically chose not to. For instance, if you needed a 7-column float-based grid (don’t ask), it’s cleaner and more intuitive: .col { /* groan */ width: 14.2857142857%; /* oh, I get it */ width: calc(100% / 7); } You could probably prove that the calc() takes the computer 0.0000001% longer, so explicitly defining the width is technically faster for performance reason — but that is about the equivalent...

Read More

Why isn’t it <style src=””>?

The way JavaScript works is we can do scripts as an inline block: let foo = "bar"; Or, if the script should be fetched from the network… With CSS, we can do an inline block of styles: .foo { color: red; } So why not ? Instead, we have . Harry Roberts asked about that the other day on Twitter: Can any W3 historians tell us why it’s “ and not “? — Harry Roberts (@csswizardry) November 29, 2018 There is lots of speculation in that thread, but Bruce has a pretty clear answer: AFAIK, tells the browser to get something and insert it here – eg , “. Stylesheets aren’t ‘inserted’, they are related to the current doc, but typically style more than 1 page. declares a block of rules for this page only — Bruce Lawson (@brucel) November 29, 2018 I sort of get that. The location in the document matters with src, but not with — that relates to the entire document instead. I guess the crack in that reasoning is that the order of stylesheets does matter for order-specificity, but I take the point. The W3C chimed to confirm that logic: was completely obvious at the time, with for external resources that apply to the whole document (copyright, parent document, alternative formats, translations, style sheets); was never discussed. (1/2) — W3C (@w3c) November 29, 2018...

Read More