Articles by
Robin Rendle

Technical writer, CEO of staring blankly at a screen full of CSS, pro-blogger

Announcing JSON Feed

Manton Reece and Brent Simmons have just published their thoughts on JSON Feed which is a new standard for making a feed, like a collection of blog posts. The format itself is similar to RSS and Atom but since it's in JSON it's easier to read and a lot more familiar to developers:

For most developers, JSON is far easier to read and write than XML. Developers may groan at picking up an XML parser, but decoding JSON is often just a single line of code.

Our hope is that, because of the lightness of JSON and simplicity of the JSON Feed format, developers will be more attracted to developing for the open web.

My favorite part about this project? The spec is just so gosh darn easy to read.

Financial Times Redesign

Late last year the team at the Financial Times launched a redesign that focused specifically on web performance and improving the user experience. And so in a post detailing their findings, James Webb writes about how this design impacted their business:

We wanted to keep page load time to an absolute minimum; our target was to become the fastest site in the publishing industry.

To emphasize the importance of a faster website to key internal stakeholders, we had to understand the true impact site speed had on user engagement. Fortunately, our analytics team had developed a sophisticated internal engagement metric that accurately predicts the likelihood of renewing a subscription.

Through a rough a series of A/B tests, we slowed the site down to see how site speed correlates to the loss of engagement and revenue. Test results showed that for every one-second increase in speed, our engagement score increased by 5%. In subscription and ads inventory, this translates into millions in revenue. Speed therefore became a principal element of the site.

If you find case studies like this useful, see WPO Stats.

Tracing the History of CSS Fonts

Chen Hui Jing has written an excellent post on the history of CSS fonts and the way that the W3C writes the specification and strange CSS properties like font-effect, font-emphasize and font-presentation.

As part of my perpetual obsession with typography, as well as CSS, I've been looking into how we got to having more web fonts than we can shake a stick at. What I love about how the W3C does things is that there are always links to previous versions of the specification, all the way back to the first drafts.

Although those are missing the full picture of the various discussions and meetings among all the individuals involved in crafting and implementing the specifications, it does offer some clues to how things got to where they are.

Implementing system fonts on Booking.com — A lesson learned

Stuart Frisby documents that you shouldn't use the font shorthand when using a System Font Stack:

...don't use -apple-system at the head of a shorthand font declaration, and test thoroughly, especially when playing around with proprietary stuff like system font declarations. If it looks like a vendor prefix and smells like a vendor prefix, chances are at least one browser is going to treat it like a vendor prefix.

Use font-family instead.

ECMAScript Modules in Browsers

As Jake Archibald says, they are starting to land! The support landscape is already:

  • Safari 10.1.
  • Chrome Canary 60 – behind the Experimental Web Platform flag in chrome:flags.
  • Firefox 54 – behind the dom.moduleScripts.enabled setting in about:config.
  • Edge 15 – behind the Experimental JavaScript Features setting in about:flags.

There are plenty of weird gotchas to be aware of, like minor syntax things that are intentionally not supported, and the order of script execution.

We covered Stefan Judis's post, who's sure we'll continue to bundle:

Just because we might have support for ES6 modules in browsers soon, it doesn't mean that we can get rid of a build process and a proper "bundle strategy".

But there are folks who wish all this wasn't so complicated, like Pawel Grzybek:

Three things that I wish I could ditch from my everyday front-end workflow: CSS preprocessors, JavaScript transpilers and module bundlers.

Does CSS Grid Replace Flexbox?

No. Well. Mostly No.

Grid is much newer than Flexbox and has a bit less browser support. That's why it makes perfect sense if people are wondering if CSS grid is here to replace Flexbox.

To put a point on it:

  1. Grid can do things Flexbox can't do.
  2. Flexbox can do things Grid can't do.
  3. They can work together: a grid item can be a flexbox container. A flex item can be a grid container.

(more…)

Getting Started with CSS Grid

This was a blockbuster week for front-end developers as CSS Grid landed in the latest versions of Firefox and Chrome without a feature flag. That's right: we can now go and play with Grid in two of the most popular browsers right away.

But why is CSS Grid a big deal and why should we care?

Well, CSS Grid is the first real layout system for the web. (more…)

Annotation is Now a Web Standard

This sure is exciting news: the various groups that make up the W3C have agreed upon a set of rules by which we’ll be able to annotate, highlight and make comments to a webpage without the need of a third party script or framework.

Dan Whaley describes why this could be a big deal:

The W3C standards are a key milestone towards a future in which all pages could support rich layers of conversation without requiring any action by their publishers—because that capability can be built into the browser itself and be available as a native feature, just like like web search. The shared vision is that conversations will be able happen anywhere on the Web, or even on documents in native apps, and inline instead of below-the fold, in a federated, standards-based way.

icon-anchoricon-closeicon-emailicon-linkicon-logo-staricon-menuicon-nav-guideicon-searchicon-staricon-tag