A nice and clear description of how browsers parse and render web pages.
Thursday, January 19th, 2017
Following from that great post about the “zone of death” in browsers, Eric Law looks at security and trust in a world where certificates are free and easily available …even to the bad guys.
PPK has posted some excellent thinking on calendar widgets to Ev’s blog.
Monday, January 16th, 2017
A thoroughly fascinating look at which parts of a browser’s interface are available to prevent phishing attacks, and which parts are available to enable phishing attacks. It’s like trench warfare for pixels.
Sunday, January 15th, 2017
Oh, how I wished everyone approached building for the web the way that Rachel does. Smart, sensible, pragmatic, and exciting!
Wednesday, January 11th, 2017
A cute explanation of different browser caches:
- memory cache,
- service worker cache,
- disk cache, and
- push cache.
Tuesday, January 3rd, 2017
When I was first styling Resilient Web Design, I made heavy use of
vh units. The vertical spacing between elements—headings, paragraphs, images—was all proportional to the overall viewport height. It looked great!
Then I tested it on real devices.
Here’s the problem: when a page loads up in a mobile browser—like, say, Chrome on an Android device—the URL bar is at the top of the screen. The height of that piece of the browser interface isn’t taken into account for the viewport height. That makes sense: the viewport height is the amount of screen real estate available for the content. The content doesn’t extend into the URL bar, therefore the height of the URL bar shouldn’t be part of the viewport height.
But then if you start scrolling down, the URL bar scrolls away off the top of the screen. So now it’s behaving as though it is part of the content rather than part of the browser interface. At this point, the value of the viewport height changes: now it’s the previous value plus the height of the URL bar that was previously there but which has now disappeared.
I totally understand why the URL bar is squirrelled away once the user starts scrolling—it frees up some valuable vertical space. But because that necessarily means recalculating the viewport height, it effectively makes the
vh unit in CSS very, very limited in scope.
In my initial implementation of Resilient Web Design, the one where I was styling almost everything with
vh, the site was unusable. Every time you started scrolling, things would jump around. I had to go back to the drawing board and remove almost all instances of
vh from the styles.
I’ve left it in for one use case and I think it’s the most common use of
vh: making an element take up exactly the height of the viewport. The front page of the web book uses
min-height: 100vh for the title.
But as soon as you scroll down from there, that element changes height. The content below it suddenly moves.
Let’s say the overall height of the browser window is 600 pixels, of which 50 pixels are taken up by the URL bar. When the page loads,
100vh is 550 pixels. But as soon as you scroll down and the URL bar floats away, the value of
100vh becomes 600 pixels.
(This also causes problems if you’re using vertical media queries. If you choose the wrong vertical breakpoint, then the media query won’t kick in when the page loads but will kick in once the user starts scrolling …or vice-versa.)
There’s a mixed message here. On the one hand, the browser is declaring that the URL bar is part of its interface; that the space is off-limits for content. But then, once scrolling starts, that is invalidated. Now the URL bar is behaving as though it is part of the content scrolling off the top of the viewport.
The result of this messiness is that the
vh unit is practically useless for real-world situations with real-world devices. It works great for desktop browsers if you’re grabbing the browser window and resizing, but that’s not exactly a common scenario for anyone other than web developers.
It’s such a shame. A piece of CSS that’s great in theory, and is really well supported, just falls apart where it matters most.
Update: There’s a two-year old bug report on this for Chrome, and it looks like it might actually get fixed in February.
Paul takes a look at the year ahead on the web and likes what he sees. There’s plenty of new browser features and APIs of course, but more interesting:
The web reaching more people as they come online with Mobile. There is still a huge amount of potential and growth in India, Indonesia, China, Thailand, Vietnam, all of Africa. You name it, mobile is growing massively still and the web is accessible on all of these devices.
Monday, December 26th, 2016
I really like this list of observations (Vasilis pointed it my way). I feel like it encapsulates some of what I was talking about in chapter two of Resilient Web Design. The only point I’d take issue with now is the very last one.
Did you know that Ilya’s book was available in its entirety online? I didn’t. But now that I do, I think it’s time I got stuck in and tried to understand the low-level underpinnings of the internet and the web.
Monday, December 19th, 2016
A run-down of all the functionality that you get in browsers these days. One small quibble with the title: most of the features and APIs described here aren’t limited to mobile browsers. Still, this is a great reminder that you probably don’t need to create a native app to get the most out of a mobile device.
Wednesday, December 7th, 2016
Eric is excited about the imminent arrival of grid layout in browsers. And after reading the answers to these sure-to-be-frequently asked questions, you’ll be excited too!
There’s a whole category of native apps that could just as easily be described as “artisanal web browsers” (and if someone wants to write a browser extension that replaces every mention of “native app” with “artisanal web browser” that would be just peachy).
Here’s some more thoughts along the same lines:
We’re spending increasing amounts of time inside messaging apps and social networks, themselves wrappers for the mobile web. They’re actually browsers.
There’s an important take-away to this:
The web is and will always be the most popular mobile operating system in the world – not iOS or Android. It’s important that the next generation of software companies don’t focus exclusively on building native iOS or Android versions of existing web apps.
Just make sure those web apps render and work well in the new wave of mobile browsers – messengers. Don’t build for iOS or Android just for an imaginary distribution opportunity. Distribution exists where people spend most of their time today – social and messaging apps, the new mobile browser for a bot-enabled world.
Sunday, December 4th, 2016
This is a fun—and accurate—explanation of service workers.
There’s definitely something “alien” about a service worker—it’s kind of like a virus that gets installed on the user’s device. I’ve taken to describing it as “a man-in-the-middle attack on your own website” which makes sound a bit scarier than is necessary.
Monday, November 14th, 2016
This is a thorough write-up of an interesting case where SVG looks like the right tool for the job, but further research leads to some sad-making conclusions.
I love SVG. It’s elegant, scalable and works everywhere. It’s perfect for mobile… as long as it doesn’t move. There is no way to animate it smoothly on Android.
Tuesday, November 1st, 2016
Rodney has done some great research into how different browsers respond to a focusable element becoming inactive (by being made disabled, hidden, or removed).
Sunday, October 16th, 2016
Equal parts clever and scary. By using
autocomplete in HTML and some offscreen positioning in CSS, it’s possible to extract some unexpected personal information.
I expect browsers will be closing these holes pretty quickly.
Monday, October 10th, 2016
This is such a great perspective on what it’s like to build for the web over the long term. The web will always be a little bit broken, and that’s okay—we can plan for that.
The Web has history. If you build with web technology it will stick around. We try not to break the web even if it means the mistakes and bad decisions we have made in the past (and will make in the future) get set in stone.
Saturday, October 8th, 2016
Finally! Apple are being sued for refusing to allow any non-Webkit browsers to be installed on iOS.
I’m not usually in favour of legal action but in this case, there doesn’t seem to be any other recourse.
We would be delighted at Nexedi to create a Web browser for iOS with better HTML5 support based on a recent version of Blink library for example. But as soon as we would publish it, it would be banned from Apple’s AppStore. Many developers have experienced this situation already. Many companies are being hurt by this situation. Some companies have already begged Apple to improve HTML5 support in iOS with little significant results.
Friday, October 7th, 2016
Charlotte is a big fan of feature queries.