Hardware APIs coming to browsers

There are many future web stack features that I see as being vitally important to the long-term health of the web. These include extensible web projects such as web components and CSS Houdini, as well as the scripting capabilities in ES7 and beyond. These features give developers better tools, and more fine control and power.

But I feel that what’s more important to the immediate success of the web are features that provide parity with native mobile apps. I’ve written previously about the importance of service workers in providing this parity, but there are also a few new features breaking through that I’m equally excited about, as they provide access to previously unavailable hardware.

Read the full article


Eddystone — A Briefing Note on Google’s New Beacon Format

Yesterday Google announced ‘Eddystone’, a new open Bluetooth beacon format which works on Android and iOS. I’ve been doing a bit of reading about it to understand the technology and its potential, and I put together a briefing note about it for my colleagues. I’m a believer in maximising returns on my content, so it seems like a good opportunity to republish that briefing note here.

This is a very rapid and shallow look into beacons, and I’ve no doubt made some omissions or inaccuracies, so apologies in advance for that. If you think I’ve made any huge oversights or errors, please feel free to let me know in the comments.

Read the full article


The drawbacks of post-processing

In the last few days I’ve been investigating CSS post-processing, the idea behind which – writing stylesheets using partially implemented or emerging standards, which are then transpiled to make files which work in current browsers — is more pleasing to me than the abstractions of pre-processors like Sass. I’ve been experimenting with PostCSS (or rather, cssnext, which is to PostCSS as (broadly) Bourbon is to Sass); however, there are a couple of problems with post-processing, at least in the way that PostCSS approaches it, which makes me question its utitility.

NB I must state clearly that these observations are based on a very shallow understanding from my initial investigations of how PostCSS works, and perhaps they would be clarified and resolved if I tried to use it on a full project. Update: See also the comments below this article, which clear up some of my misconceptions.

The first is that post-processing uses syntax from proposed standards which have yet to be ratified. For example, the variables syntax is based on Custom Properties which, athough implemented in Firefox, are yet to have any firm commitment from other browser vendors; the syntax could still be changed, or indeed dropped entirely. That would mean PostCSS would have to either retain an outdated syntax for backwards compatibility, or change it completely to match future decisions, making maintainability of old projects harder for developers.

The second problem is that the features of Sass which are most useful (and widely used) are those which greatly extend the core CSS syntax – notably, nesting and mixins. While there are PostCSS plugins that add extensions to match pre-processing features, using them means that your source stylesheet is no longer ‘proper’ CSS — which is the main attraction of a post-processor to me. If your source stylesheet is largely invalid, you might as well use a pre-processor.

Perhaps, as Lyza Danger Gardner concluded, using post-processors means giving up certain features:

Taking a path paved with lean, modular post-processing plugins involves sacrifices. No more nesting. Instead of an endless horizon of mixin possibilities, you may be bound to CSS spec realities, like calc or CSS variables.

I still like the idea of post-processing, but perhaps I need a longer period of acclimatisation before it fully makes sense to me.

 


The Future of the Open Web

I’ve spent a lot of time in my career writing and talking about future web features, from CSS3 to Web Components. But I’ve recently come to realise that, while I still think these features are important, I’ve been missing out on the bigger picture: the survival of the open web. That sounds hyperbolic, I know, but so many articles I’ve read, conversations I’ve had, and behaviours I’ve observed, have led me to the conclusion that the open web, in the form we know it now, is under threat.

Read the full article


International Book Giveaway

My two books, The Book of CSS3 and The Modern Web, have been translated into many different languages, and I get sent courtesy copies of most of the translations. However, I’m running out of space on my bookshelves so I’m going to give some of them away to anyone who’s interested. Lists of all the spare copies I have are below; if you’d like one, email peter@​broken-​links.​com with your postal address (nb: see criteria at the end of this post) and the edition you want.

Also, a quick reminder: The Book of CSS3, Second Edition is still on sale. Fully revised and updated, with two all-new chapters.

Read the full article


On Flipboard.com and Idealism vs. Pragmatism

I’ve been thinking a lot recently about the clash between idealism and pragmatism. I’ve been working on the Web for many years, and for much of that time I’ve tried to do things the ‘right’ way; standards-compliant, validated, mobile-first, responsive, accessible, clean, extensible, etc. I’m definitely not claiming that I’ve always succeeded, but the intention and effort was there.

In the past few years the explosive growth of the Web, and the devices used to access it, has meant a parallel increase in the power and complexity of the tools needed to build it. And of course we want to make sites that are fast and light and perform competitively with native apps. But I think in this sharp focus on the technical side of building, we risk losing sight of why we are building, and who for.

Read the full article


Archive by category and date