WordPress 3.2 And The End Of Designing Around IE6 In The Admin

WordPress 3.2 felt like a release with a clear message. The admin needed to become faster, lighter and less tied to old browser constraints. The decision to move away from supporting IE6 in the admin was important because it reflected a wider change in how web tools were being built.

For years, older Internet Explorer versions had shaped the way developers approached front-end work. Even when the public website still needed support for older browsers, the admin environment was a different question. It was used by a smaller group of people and could reasonably ask more from the browser.

That distinction mattered. The visitor-facing site still needed to serve the audience properly, but the editing interface did not necessarily need to be held back by the oldest browser in use somewhere else.

Why The Admin Could Move Faster

The admin area is a working tool. If a business depends on it to publish content, manage pages and update the site, then the quality of that tool affects day-to-day work. Keeping it tied to very old browser behaviour can make the experience worse for the people using it regularly.

By requiring a more capable browser, WordPress could improve the admin without carrying the same amount of legacy weight. That made sense to me because the admin was not a public access requirement in the same way the front end was.

The Fullscreen Writing Experience

The fullscreen writing mode also pointed in an interesting direction. Instead of showing every admin panel and option at once, the interface gave writers more space to focus. That was useful because content editing is not only a technical task. It is a practical writing task.

For clients, this mattered. A cleaner writing experience could make WordPress feel less like a control panel and more like a publishing tool. That changed how comfortable people felt managing their own content.

What It Meant For Client Conversations

The browser support conversation did not disappear, but it became easier to separate. We could still discuss which browsers the public website needed to support, while also expecting site administrators to use a modern browser for editing.

For me, the important part was deciding where legacy support genuinely mattered. The public site and the admin did not have to follow the exact same rules, because they served different people in different contexts.