Earlier this year, Microsoft announced that Edge, which relies on the same core Chromium technologies as Google’s Chrome, would follow that rival in shortening the interval between releases to four weeks. The first in the four-week cycle will be version 94 of both Chrome and Edge. Google plans to debut Chrome 94 on Sept. 21 with the follow-on v. 95 appearings Oct. 19. Meanwhile, Microsoft will launch Edge 94 on Sept. 23 and Edge 95 on Oct. 21.

Starting with version 94, Chrome and Edge will also offer what’s called an “Extended Stable” release that will use an eight-week interval rather than the default four. Obviously, a sop to enterprise IT admins unhappy at the idea of a sped-up update tempo, Extended Stable releases will occur at every even-numbered version. The next Extended Stable releases will then be v. 96, v. 98 and so on for Edge.

By default, Edge will update automatically every four weeks. The eight-week interval is thus opt-in, with the opting requiring use of the as-yet-undocumented TargetChannel group policy on the part of admins, or alternately, Intune from the Microsoft Endpoint Manager. Some details about how Microsoft will keep Extended Stable secure are still cloudy.

Microsoft said last month that “important security patches and fixes will be delivered as needed independent of the selected release option,” which implied that security updates for Extended Stable will continue in their current no-schedule-here fashion.

But Google, which as the power behind Chromium should be the outfit in the know, said in March that, “security updates on Extended Stable will be released every two weeks to fix important issues, but those updates won’t contain new features or all security fixes that the 4-week option will receive.”

Because of the long interval between releases for Edge’s Extended Stable, Microsoft has also altered its support policy for the browser. Prior to Extended Stable — and still applicable to all four-week-cycle copies of Edge — Microsoft provided what it called “Assisted Support” for the current version (call it N) and the two previous versions (N-1 and N-2). Here’s an example: The now-current version is v. 92, so Microsoft Assisted Support goes to v. 92, 91 and 90.

Extended Stable Edge, on the other hand, will be supported for N and N-1 only. When Edge 96 shows up, it and v. 94 will be eligible for Assisted Support.

The teams unveiled a discussion and development forum at the World Wide Web Consortium, or W3C, dedicated to developing standards for extensions. The forum, the WebExtensions Community Group, gives engineers a place to build a unified and more secure core foundation for extensions. The main aim is to make it easier for developers to write extensions because a shared standard will help bridge differences between browsers.

There’s not yet a public timeline for publishing a draft of the standard or building it into browsers.

Extensions are crucial to browsers on PCs. The bits of software can block ads, integrate with password managers, strip out code that tracks you on the internet and find coupons as you put items into your shopping cart. What is more, one extension lets users replace photos of Donald Trump with cats.

Google’s Chrome is the most widely used browser in the world. But differences among browsers mean it’s less likely that an extension developer will support other browsers. Standardization should align browsers to reduce developers’ difficulties. There will still be differences among browsers, but the community group plans to ensure a common core of abilities.

The Chrome browser modernized extensions by adopting some of the same technologies, JavaScript and Cascading Style Sheets used to display web pages. Firefox and more recently Safari have followed Chrome’s lead. Edge also tapped into Chrome’s extension when Microsoft adopted Chrome’s open-source Chromium technology.

The news comes from the Apple developers conference WWDC where Apple announced it was embracing Chrome’s extension approach in Safari, despite significant differences in packaging extensions for Safari remain. The idea of standardizing extension technology has been around for years.

Opera, another browser maker, tried to unify extension technology when it adopted Chrome’s extension approach in 2010. One thing that won’t change is how you get your extensions. Each browser maker has its own extensions download site, as well as procedures for vetting them.

Several aspects of the technology are up for discussion, according to the browser extension group’s charter. The group hopes to set programming interfaces that are compatible with today’s extensions as much as possible, that doesn’t slow website performance, that doesn’t hurt privacy and that beef up security to “reduce the harm compromised or malicious browser extensions can do.”

Compatibility is the top priority on the list. The group’s charter commented that it should be relatively straightforward for developers to port extensions from one browser to another and for browsers to support extensions on a variety of devices and operating systems.

Version 90 of Google Chrome is rolling out now, and it includes a new value for the CSS overflow property, the renaming of the Feature Policy API to Permissions Policy, a new way to implement and use Shadow DOM directly in HTML, and more. In his latest article Pete LePage, a developer advocate, showed how to do 411 for developers in Chrome 90 in 1990’s style. In addition, in honour of Chrome 90, here’s a 90s style video running through the changes.

Accessibility is a critical skill for developers doing work at any point in the stack. For front-end tasks, modern CSS provides capabilities to make layouts more accessible and inclusive for users. If you are interested in Modern CSS and you are wondering how to improve your accessibility, you definitely have to check Stephanie Eckles’s article. Stephanie covered a round of interesting topics like Focus visibility, Focus vs Source Order, Desktop Zoom and Reflow, Sizing Interactive Targets, Respecting Color and Contrast Settings and Accessibility Learning Resources.

Here is another amazing frontend master, Jon Kuperman, who will help us to go beyond console.log to master all the built-in tools available in Google’s Chrome Developer Tools to edit, debug, and profile your web applications. Jon’s course will teach us how to step through our code with the debugger, audit web page performance on top of simulated network conditions and remove “page jank” when a site isn’t keeping up. Do not miss to check Jon’s course “Introduction to Dev Tools, v3” and more from here.

Vitaly Friedman loves beautiful content and doesn’t like to give in easily. When he is not writing, he’s most probably running front-end & UX. In his latest article “ A Complete Guide To HTML Email”, Vitaly helped us understand everything that’s happening behind the scenes of a quirky world of HTML email including accessibility, bugs, dark modes, editors and IDes, feature support, frameworks and more. Go and check his article.

Hugh Haworth, a failed musician and JavaScript cowboy, made a detailed evaluation of a bunch of new developer tools (like Snowpack, rebuild, etc) and how they improve the developer experience. For more information check Hugh’s articles from here.

And if these five wasn’t enough for you, here are a few more quick bites for your Dev soul:

• why the Vivaldi browser will not support Google’s new FLoC ad tech.
• Did you know about the HTML ping attribute for anchor elements
• Wix CEO Avishai Abrahami and WordPress founder Matt Mullenweg are having something of a spat following a Wix marketing campaign