Let's Build the Web We Want
Hot on the heels of our last major release, we just released a new minor version of HTML5 Boilerplate, v7.1.0. The biggest changes in this release are an upgraded version of Modernizr (which is on a steady release schedule again) and an update to the Google Analytics snippet/docs.
Here are the full release notes:
After a few months of starts and stops while I wrestled my SVG book into submission and released main.css as a standalone project, I’m pleased to announce that HTML5 Boilerplate v7 was released on Friday February 8, 2019.
The biggest change is the way that we include the aforementioned main.css. Since it’s now a standalone project we include it as an npm dependency at build-time. This change still allows people (including HTML5 Boilerplate itself) to consume main.css as a whole, but also allows the component styles to be used individually in different, and hopefully interesting, ways. You can access the component styles to mix and match directly through the main.css npm package.
We also dropped support for IE9/10. That was not as cathartic as dropping support for IE6 or IE8, but it was still nice. It feels like we’re living in the future.
The docs also got a big upgrade. We could use more help there, but we’ve done a couple of really good passes at the documentation and I think it’s in a good place now.
Thanks again to Christian Oliff for his work on this release. He’s proven to be an invaluable team member over the past couple of years. I really appreciate his help on tasks and his attention to detail.
And, as always, thanks to our many contributors. You are the best!
Are you interested in helping out? Check out our current issues, submit an idea for a new feature or look at one of the other H5BP projects to see if there’s something else you’re interested in helping with. It’s fun.
Here’s the full release notes:
shrink-to-fit=no (#2103)This is great news. One of the worst chapters from a standards perspective in The Uncertain Web was on user input. At the time I wrote the chapter, I had a relatively positive tone. The flow of the chapter led to a discussion of Pointer Events and how, with support in IE and intended implementation in both Firefox and Chrome, we were on the cusp of having a sane way to deal with user input across devices and form factors.
Then it all went to hell.
Here’s what I wrote in the book:
As you’ve read in the chapter on user input, the Pointer Events specification, proposed by Microsoft, favored by Firefox and adopted by the W3C, is up in the air because Chrome isn’t sure whether or not they are going to support it. This was announced after I finished the chapter on user input. I found out via Twitter that Chrome was going to pull planned support for Pointer Events and felt about as deflated as I’ve ever felt about a web standards topic. For one thing, I like Pointer Events. I’m not sharing them as the way of the future just to be hip and share the new stuff. I really like them. Secondly, Google’s proposed alternative, “incrementally extending our existing input APIs” doesn’t really offer much of a salve to the wound of two wasted years looking for this specification to get off the ground and into browsers.
Maybe, like the door on +picture+ being reopened and bursting through to get into the specification, the already specified Pointer Events’ work will come back from the dead and make it into Chrome and the rest of modern browsers. The Chrome team are listening to feedback, so hopefully that’s just what’s going to happen.
We shall see.
Here’s what I wrote when Chrome announced the changed status of the original intent to implement:
I’ve already had to rewrite a book chapter on input on the web because of Chrome dropping support for Pointer Events (you were the good guys- along with IE you form an 800lb gorilla) to be a lot more bleak (now Chrome is the bad guys and we don’t have any solution on the horizon.) Nothing would please me more than to revert to the original take on that chapter.
I also don’t want to pin my hopes on this issue getting sorted out on the vague promise of “extensions” to the existing screwed up mess. What guarantee do we have that Apple will be any more interested in “extensions.” Will Chrome’s BFFs on the IE team be interested in “extensions?” If we’re looking at incremental extensions as the solution (with no more details than that,) I will be retired, drinking coffee at Sant’Eustachio Il Caffè and struggling my way through La Gazzetta dello Sport before the issue of user input on the modern web is sorted out in a way that benefits developers and end users. Smart people are doing stupid things with this stuff because it’s a complicated issue. Browser vendors and the W3C have to lead on this and sort it out from up on high because the bottom up approach isn’t working right now.
Thankfully, the Chrome team listened to reason (and a flood of negative feedback for their decision) and have reversed course.
Now we just need to get the new jQuery-driven version of the Pointer Events polyfill project ready for prime time and we’ll be all set.
As an aside, if there’s one good thing that came out of Chrome’s decision is that they Polymer team deprecated the Pointer Events Polyfill and passed the codebase over to jQuery. The Polymer version of the polyfill had a high barrier to entry to even get to use. I just linked to a version in my own code repo for the book because I hated the idea of forcing people to go through a multiple-dependency, poorly documented rigmarole just to “install” the polyfill. The jQuery team will, eventually, have a handy download link right on the site- like a normal project.
Hey everybody, I’ve got a new book coming out. It’s called The Uncertain Web and it’s being published by O’Reilly. Right now we’re targeting a November release.
Just in time for Christmas. Buy a dozen and hand them out like candy canes.
If that seems like too long to wait, never fear. I’m about 50% finished and once that chunk has been hammered on by a hand-picked team of geniuses, it will be available as an Early Release.
So, what’s it all about?
Here’s my original pitch:
The best way to approach the web today is to forgo hard and fast rules and design for uncertainty. Embracing uncertainty as a core tenet of web development and scrapping the rules we’ve relied on in the past few years is the best bet for creating future proof web solutions.
In the early 2000s, there was basically one browser (Internet Explorer 6,) one platform (Windows XP) and one screen resolution (1024 by 768) that mattered. With that set up you could design, develop and test against the vast majority of web users with one desktop computer. The biggest question on the horizon, it seemed, was when it would be viable to design for 1280 pixel screens
This limited field of play meant that there was an expectation that sites and applications would look the same everywhere for everyone. Best practices were honed and codified into hard and fast rules which drove design and development. Major choices, such as the size of the basic grid to design for, were no longer choices. You started with a static, 960 pixel grid and sliced and diced it as needed.
Today, things couldn’t be more different. With the launch of the iPhone and the iPad, the rise of Android and the growth of not just one, but two real contenders to Microsoft’s position as the dominant web browser (Firefox and Chrome), developers and designers have an ocean of variables to navigate. Every question around a site design is now pregnant with options.
Initially, developers and designers tried to navigate this new reality by creating new rules.
The problem was, the goalposts kept moving. As soon as a new hard and fast rule was created, some new wrinkle would render it impotent.
People designed and built “iPhone” sites, assuming that Apple’s dominance in the smartphone market was somehow a permanent condition. They tested for touch capabilities and assumed that touch users would never have a mouse.
As Android’s huge growth over the past few years, and the presence of devices like the Chromebooks and Windows 8 laptops with both mouse and touch capabilities have proved that those new rules have a short shelf life.
Even patterns like Responsive Web Design, which some saw as a single solution for design and development moving forward fall apart when applied against complicated application patterns and the vagaries of bandwidth and mobile performance.
By combining web standards, progressive enhancement, an iterative approach to design and development and embracing a desire to question the status quo and perceived wisdom; teams can create dynamic web sites and applications that should perform admirably in future devices, with unknown capabilities. By focusing on optimal solutions with intelligent fallbacks and forgoing the desire for absolute solutions design and development can work together to create the web of today and tomorrow.
This book will outline both the concept and underlying principles of the Uncertain Web and introduce some of the techniques necessary to make the successful transition.
So, that’s the thing.
I’m really excited about this one. I hope you enjoy it.
My slides from HTML5DevConf are now up for viewing on Github pages, so you don’t even need to type node web-server.js to view them. There’s one hitch where svgz files aren’t rendering, but I’m not going to worry about that right now. If, in the interim, you really want to see that image, you can grab it from the repo.
There should be video at some point in the future. When there is, I will be sure to let you all know.
I’m also going to be giving this talk at the Boston Front End Developers meetup in May. I’ll be sure to share that as well, once the meetup announcement is online.
