Lin gives a deep dive into Firefox’s new CSS engine specifically, but this is also an excellent primer on how browsers handle CSS in general: parsing, styling, layout, painting, compositing, and rendering.
I’ve never been so excited by a single diff in a JSON file.
Service workers are coming to Safari.
Ben takes us on a journey inside the mind of a browser (Chrome in this case). It’s all about priorities when it comes to the critical path.
Cameron counts the ways in which Flash was like a polyfill.
Yeah, that’s right: The Man In Blue is back!
Rachel is maintaining this (short) list of browser bugs with CSS Grid, inspired by the excellent Flexbugs.
Grid shipped into browsers](https://gridbyexample.com/browsers) in a highly interoperable state, however there are a few issues - let’s document any we find here.
Hadley points to the serious security concerns with AMP:
Fundamentally, we think that it’s crucial to the web ecosystem for you to understand where content comes from and for the browser to protect you from harm. We are seriously concerned about publication strategies that undermine them.
The anchor element is designed to allow one website to refer visitors to content on another website, whilst retaining all the features of the web platform. We encourage distribution platforms to use this mechanism where appropriate. We encourage the loading of pages from original source origins, rather than re-hosted, non-canonical locations.
That last sentence there? That’s what I’m talking about!
Web developers aren’t going to shed many tears for Flash, but as Bruce rightly points out, it led the way for many standards that followed. Flash was the kick up the arse that the web needed.
He also brings up this very important question:
I’m also nervous; one of the central tenets of HTML is to be backwards-compatible and not to break the web. It would be a huge loss if millions of Flash movies become unplayable. How can we preserve this part of our digital heritage?
This is true of the extinction of any format. Perhaps this is an opportunity for us to tackle this problem head on.
A great example of progressive enhancement in action.
You can perfectly use CSS grid layout today if you don’t expect exactly the same appearance in every single browser, which isn’t possible to achieve nowadays anyway. I’m well aware that this decision isn’t always up to us developers, but I believe that our clients are willing to accept those differences if they understand the benefits (future-proof design, better accessibility and better performance). On top of that, I believe that our clients and users have — thanks to responsive design — already learned that websites don’t look the same in every device and browser.
Thanks to jQuery, you probably don’t need jQuery. Just look at all these methods that started life in jQuery, that are now part of the standardised DOM API:
Rachel uncovers a great phrase for dealing with older browsers:
It isn’t your fault, but it is your problem.
She points to multiple ways of using CSS Grid today while still providing a decent experience for older browsers.
Crucially, there’s one message that hasn’t changed in fifteen years:
Websites do not need to look the same in every browser.
It’s crazy that there are still designers and developers who haven’t internalised this. And before anyone starts claiming that the problem is with the clients and the bosses, Rachel has plenty of advice for talking with them too.
Your job is to learn about new things, and advise your client or your boss in the best way to achieve their business goals through your use of the available technology. You can only do that if you have learned about the new things. You can then advise them which compromises are worth making.
This is an excellent proposal from Emil. If we can apply
display: contents to fieldsets, then we would finally have a way of undoing the byzantine browser styles that have hindered adoption of this element. This proposal also ensures backwards compatibility so there’d be no breakage of older sites:
The legacy appearance of fieldsets probably needs to be preserved for compatibility reasons. But
display: contentsis not supported in any old browsers, and is most likely used on exactly zero sites using the legacy look of fieldsets.
Whaddya say, browser makers?
A website should not fight the browser. Let the browser provide the chrome, and simply provide the content.
This post is about Medium, but I think there’s a lesson here for progressive web apps too. A progressive web app should not fight the browser. Are you listening, Google?
How the IETF redefined the process of creating standards.
To some visionary pioneers, such as Ted Nelson, who had been developing a purist hypertext paradigm called Xanadu for decades, the browser represented an undesirably messy direction for the evolution of the Internet. To pragmatists, the browser represented important software evolving as it should: in a pluralistic way, embodying many contending ideas, through what the Internet Engineering Task Force (IETF) calls “rough consensus and running code.”
Analysing what the web is. It’s not the technology stack.
To count as being part of the web, your app or page must:
- Be linkable, and
- Allow any client to access it.
I think that’s a pretty good definition.
Mind you, I think this is a bit rich in an article published on The Verge:
The HTML web may be slow and annoying and processor intensive, but before we rush too fast into replacing it, let’s not lose what’s good about it.
Still, we can agree on this:
Preserving the web, or more specifically the open principles behind it, means protecting one of the few paths for innovation left in the modern tech world that doesn’t have a giant company acting as a gatekeeper.
With New Browser Tech, Apple Preserves Privacy and Google Preserves Trackers | Electronic Frontier Foundation
It’s interesting to see how excessive surveillance is (finally!) being treated as damage and routed around. Apple seem to get it—they’re tackling the tracking issue. Meanwhile Google are focusing purely on the visibility and UX of invasive advertising, without taking steps against tracking.
There’s a huge opportunity here for Chrome’s competitors—if Firefox and Safari protect users from unwarranted tracking, that could be enough to get people to switch, regardless of the feature sets of the browsers.
This is an excellent move by Apple—interpreting cross-site tracking as damage and routing around it.
Got questions about the security of service workers? This document probably has the answer.
Domains registered with punycode names (and then given TLS certificates) are worryingly indistinguishable from their ASCII counterparts.
Can you spot the difference between the URLs https://adactio.com and https://аdаctіо.com?
This is a really clear explanation of how CSS works.
So do you really know which are the top browsers, both amongst your existing customers and your potential audience? Perhaps it’s worth taking a closer look; it might just be time to check your site in some of the lesser-known, yet popular browsers like UC, Yandex and Samsung Internet.