Do not build features that only one browser supports. Test with feature detection and on real browsers and devices you choose from your audience data. To bring readers back, rely on newsletters, RSS or web feeds, and optionally an installable web app, because browsers no longer let sites set a visitor's homepage.
From the original phpWordPress forum · archived copy
a forum member ·
We have found that the "make home page" feature doesn't work with any recent Mac browser, although Mac users only make up a small percentage on our other sites, I don't like anyone finding a function not working on any of our sites. So anyone got a fix or work around for this?
phpWordPress staff (Product Line Manager) ·
Nope, no work around for this. Sadly, this is not a Mac issue at all. The "Set as Homepage" feature is supported only for Internet Explorer. Firefox, Safari and other browsers do not allow this.
a forum member ·
Thanks for clearing that one up!
View the archived thread on the Wayback Machine. Usernames and contact details have been removed.
In 2006 a site owner found that a “make this my home page” link failed in every recent Mac browser. The vendor explained it was not a Mac issue: the feature worked only in Internet Explorer, and Firefox, Safari and others did not allow it. The lesson holds. Features that only one browser supports are a risk, and a site that depends on one cannot control whether readers come back.
Why did “set as homepage” stop working?
The thread’s own answer was that browsers other than Internet Explorer did not allow it. Plan on the basis that a site cannot set a visitor’s homepage: the choice of start page and bookmarks belongs to the reader, and no site should be able to rewrite a browser’s settings.
What publishers want from the button is a habit. The replacement is an invitation the reader accepts, and several reliable ones exist.
What replaced the homepage button for audience retention?
| Method | How it works | Notes |
|---|---|---|
| Newsletter | Readers give an email address and receive new stories | You control the relationship, independent of any browser |
| RSS or web feed | Readers follow your feed in a reader app | The RSS specification calls it a Web content syndication format; each item can be a story with a synopsis and link |
| Installable web app (PWA) | Readers add your site to their home screen or dock | Support varies by browser and platform |
| Bookmark prompt | A line suggesting readers bookmark the site | Low-tech; works anywhere |
Newsletters and feeds do not rely on any browser feature, so they are the sturdier base. Make sure your CMS outputs a valid feed and that your feature checklist includes it.
How do progressive web apps fit?
MDN says an installable PWA needs a web app manifest linked from every page and served over https. For Chromium-based browsers, the manifest needs a name or short_name, icons including 192px and 512px sizes, a start_url, and a display or display_override member.
Support is uneven. MDN says Safari supports Add to Dock on macOS Sonoma (Safari 17 and later), Firefox does not support installing PWAs from a manifest on desktop, and on iOS 16.4 and later installation is available from the Share menu in several browsers. A PWA is therefore an optional extra for loyal readers, not a replacement for the channels above. If your CMS has a PWA plugin, test the install flow in each target browser before promoting it.
How do I avoid browser-specific features?
Detect capabilities instead of browsers. MDN defines feature detection as working out whether a browser supports a block of code and running different code accordingly, so the browser always gets a working experience. It calls browser sniffing, which identifies the browser by name, a terrible practice to discourage. For CSS, MDN points to the @supports at-rule, which applies styles only where a feature is supported.
In practice:
- Build the article page with plain HTML and CSS that works without scripts, and add enhancements on top.
- Check whether a feature is supported before using it, with a fallback.
- Avoid code that branches on the user-agent string.
- Keep third-party widgets, such as embeds and comment systems, behind a fallback in case they fail to load.
Which browsers should I test?
Choose from your own audience. MDN suggests a graded approach:
| Grade | Browsers | What to do |
|---|---|---|
| A | Common, modern browsers | Test thoroughly; full support |
| B | Older or less capable browsers | Test for a basic experience |
| C | Rare or unknown browsers | Do not test; serve the full site with fallbacks |
To decide what falls in each grade, use analytics, with MDN’s caveat: low usage might mean the site was broken in that browser, not that nobody uses it.
How do I test on real browsers?
MDN describes a modest device lab: a Mac with Firefox, Chrome, Opera and Safari, a Windows PC with Edge, Chrome, Firefox and Opera, a higher-spec Android phone and tablet, a higher-spec iOS phone and tablet, and lower-spec mobile devices for checking performance. Most newsrooms do not have all of these, but the principle is to include Safari on a real Apple device, since Safari is a separate browser from Chrome and Edge and should be checked on its own.
For quick checks MDN lists emulators: Firefox Responsive Design Mode, Safari Responsive Design Mode, Chrome Device Mode, the Android Studio emulator and Apple’s Simulator. Virtual machines can run other operating systems. Emulators help with layout, but test performance and touch behaviour on real devices.
A simple routine for each theme or template change:
- Load the home, article, section and search pages in each A-grade browser.
- Check images, fonts, embeds, video, ads and forms.
- Test on a phone over a mobile connection, not just a resized window.
- Check keyboard navigation and text zoom.
- Record what you tested, and fix before release.
What should the editorial team own?
Assign one person to keep the browser list, the test routine and the retention channels current. Review the list when your analytics show a new browser or device taking a meaningful share, and when a redesign or major CMS release changes the templates. Treat newsletter signups and feed subscriptions as audience numbers worth reporting, because they are the readers you can reach without depending on any browser.
This page summarises MDN and the RSS specification; Word & Press has not run these browser tests, and our method page says what we do verify. For the upgrade side of theme changes, see planning a major CMS upgrade.
Questions people ask
Can a website set itself as a visitor's browser homepage?
Do not rely on it. The 2006 vendor reply said the feature worked only in Internet Explorer and that Firefox and Safari did not allow it. Today you invite readers to bookmark, subscribe or install, and the visitor decides.
Which browsers should a news site test?
Those your readers use. MDN suggests grading support: test common modern browsers thoroughly, give older ones a basic experience, and do not test rare ones. Use your analytics to choose, remembering that low numbers can mean the site was broken there.
Is feature detection better than checking the browser name?
Yes. MDN calls browser sniffing a practice to discourage and recommends detecting whether a feature is supported. In CSS, the @supports rule does this. It keeps working when browsers change names, versions or engines.
Do I need a progressive web app for my publication?
Not necessarily. A PWA can be installed from supporting browsers, but MDN notes support differs: Firefox on desktop does not install PWAs from a manifest. Treat it as an extra for loyal readers, with newsletters and feeds as the base.
Sources
- MDN defines feature detection as working out whether a browser supports a certain block of code and running different code depending on whether it does, so that the browser can always provide a working experience rather than erroring in some browsers. — source, checked 10 October 2026.
- MDN says not to confuse feature detection with browser sniffing (detecting which browser is accessing the site), describing sniffing as a terrible practice that should be discouraged at all costs. — source, checked 10 October 2026.
- MDN describes the CSS @supports at-rule as a native feature detection mechanism that applies CSS depending on whether a CSS feature is supported. — source, checked 10 October 2026.
- MDN's cross-browser testing strategies article suggests grading browser support, with common modern browsers tested thoroughly and given full support, older or less capable browsers tested for a basic experience, and rare or unknown browsers not tested but served the full site with fallbacks. — source, checked 10 October 2026.
- MDN's testing strategies article describes a device lab of a Mac with Firefox, Chrome, Opera and Safari, a Windows PC with Edge, Chrome, Firefox and Opera, higher-spec Android and iOS phone and tablet, and lower-spec mobile devices for performance testing. — source, checked 10 October 2026.
- MDN lists emulators and simulators for quick testing, including Firefox Responsive Design Mode, Safari Responsive Design Mode, Chrome Device Mode, the Android Studio emulator and Apple's Simulator, and says virtual machines can test other operating systems. — source, checked 10 October 2026.
- MDN advises using analytics to see which browsers your visitors use, with the caveat that low usage of a browser might mean the site was broken in it, not that users do not exist there. — source, checked 10 October 2026.
- MDN says that for Chromium-based browsers an installable PWA manifest needs a name or short_name, icons including 192px and 512px, a start_url, a display or display_override member and no prefer_related_applications set to true, linked from every page, and that the PWA must be served over https. — source, checked 10 October 2026.
- MDN says Safari supports Add to Dock on macOS Sonoma (Safari 17 and later), Firefox does not support installing PWAs using a manifest file on desktop, and on iOS 16.4 and later installation is available from the Share menu in Safari, Chrome, Edge, Firefox and Orion. — source, checked 10 October 2026.
- The RSS 2.0 specification says RSS is a Web content syndication format, an acronym for Really Simple Syndication, and that a channel contains items that may each represent a story with a synopsis and a link to the full story. — source, checked 10 October 2026.