Published: November 7, 2025
Managing browser compatibility for over 38,000 enterprise customers across Japan isn't trivial. When Kintone powers critical business operations for over 1.5 million applications daily, every browser support decision matters.
Cybozu, a leading groupware company in Japan, faced a fundamental challenge: How to maintain consistent web standards across products while avoiding the maintenance burden of custom browser support matrixes.
The solution? Adopting Baseline as a development standard—a move that transformed their approach to web platform feature adoption!
The challenge: Browser support with the guesswork
Before Baseline, Cybozu maintained their own browser support criteria based on access logs and manual version tracking. Their standard was to support browsers that covered the top 98% of access logs—and users on browsers outside that threshold were shown a browser update prompt.
Every quarter, Cybozu's engineering teams spent approximately an hour in total for criteria updates. Still, the criteria integration to the development team was not seamless, and it was quite common to have questions: When could new CSS features be used? When could polyfills for new JavaScript APIs be removed? And really, which features can be used now?
Not only did Cybozu's custom criteria lack maintainability and usability for developers, they also realized that building on top of user agent detection and manual version tracking couldn't keep pace with the speed of the modern web's evolution.
Can the User-Agent string be relied on
Cybozu's previous approach derived browser names and versions from User-Agent strings, then aggregated these results as "user" data—but does this truly reflect the reality of users?
User-Agent is an HTTP request header—information that any client can claim to be anything. Product access logs contain massive volumes of requests from bots, crawlers, attackers, and other sources. Some clients intentionally send old User-Agent strings for various purposes, such as vulnerability scanning. Therefore, access logs can't represent the users that should be supported.
User-Agent cannot reflect available features
Browser versions don't map to features. The same version number might have different capabilities depending on channel (Stable/Beta/Dev/Canary), feature flags, Finch experiments, or enterprise policies, for example. Moreover, different browsers implement features at different timelines—CSS Nesting shipped in Safari 16.5 (May 2023) but Chrome 112 (April 2023). The User-Agent string doesn't indicate feature availability.
Responsibility to support browser versions ourselves
Browser updates aren't just about new features—regular browser releases include critical security patches and bug fixes alongside new capabilities. When outdated versions are supported, avoidance of using new features isn't the only problem—it's a decision that directly impacts user safety at the same time. In enterprise environments, some users can face legitimate constraints. For example:
- Organizations may have strict browser policies preventing updates.
- Legacy hardware doesn't support updating modern browsers.
- Users in regulated industries with slow change approval processes.
However, supporting those users also means that it enables them to remain vulnerable.
If a security incident occurred by exploiting a known vulnerability in an old browser version, it wouldn't be a reasonable explanation to say "this browser was supported because users requested it". If the attack spreads to other users who properly maintain updated browsers, developers and other project stakeholders bear the responsibility for failing to cut support for unsafe browsers.
Cybozu realised this approach creates risks for the majority of users who keep their browsers updated. Supporting browsers based solely on log counts lacks proper security validation. This isn't just about missing out on new features—it's about failing in the responsibility to protect users.
The question shifts from "How many users are on this version?" to "Should we be supporting users based on browser versions at all?"
Why Baseline is the right answer for Cybozu
Cybozu needed a new approach that addressed not just the operational overhead of maintaining browser support criteria but the fundamental flaws in the old methodology. Baseline provided Cybozu exactly that.
Externally maintained, evolving criteria
Instead of manually reassessing browser versions every quarter, Baseline provides a moving target maintained by the W3C WebDX Community Group—not by individual companies making arbitrary decisions. This means the criteria automatically evolve with input from browser vendors and standards bodies.
Kintone no longer needed to manage version thresholds by themselves—Baseline evolves without any action. The Baseline status for features answers availability questions definitively, and the answer updates itself as the platform evolves.
Feature-level precision
Instead of trying to track an individual browser's situation, Baseline takes a fundamentally different approach.
Baseline Widely available represents web features available for 30 or more months across major browsers. This timeframe was determined to "approximate developer signals, browser release uptake over time, an estimate of high total market share support, and the WebDX Community Group's best judgment". By setting this threshold, Baseline eliminates the task of tracking unobservable individual browser situations.
With Baseline, developers get a direct answer about that specific feature's availability across browsers. "Can we use CSS container queries?" is now an answerable question. Developers can check Baseline status on MDN or other documents instantly, without cross-referencing compatibility matrixes.
Security-conscious by design
By adopting Baseline Widely available as our standard, Cybozu aligned our support policy with a timeframe that naturally correlates with browser vendors' support lifecycles. Browsers that are still actively maintained will support all Widely available features while also receiving critical security updates.
Access log-based criteria had the potential to anchor support to outdated browsers, which removes the incentive for users to update. By adopting Baseline, not only can we confidently use modern features, but users on outdated browsers naturally encounter the need to update as the web platform moves forward.
Baseline doesn't explicitly exclude vulnerable browsers—it gives natural incentives for users to keep their browsers updated.
Adopting Baseline
Adopting Baseline required a shift from Cybozu's legacy version management. This meant Cybozu needed confidence that Baseline would work without significant drawbacks. Knowing what percentage of users it would affect was crucial for enterprise-level adoption.
Google Analytics Baseline Checker is a tool that analyzes data exported from Google Analytics to show what percentage of your users support features from each Baseline year. This tool helped Cybozu check the actual impact of choosing a Baseline target on their users. After running Baseline Checker, Cybozu discovered something remarkable:
Baseline Checker revealed that 98.8% of users Cybozu's users used browsers that support the Baseline Widely available target. This is broader coverage than Cybozu's previous internal standard of at least 98% of users. Three key points could be analysed based on the provided data:
- Previously supported browsers are not impacted.
- Previously unsupported browsers: represent approximately 0.8% that meet Baseline Widely available criteria, but no longer see the browser update prompt.
- Remaining browsers keep receiving the browser update prompt as before.
Notably, this meant that false positives could be eliminated—the ~0.8% of users who had been unnecessarily shown warnings despite using capable browsers. At the same time, false negatives couldn't be introduced by warning users who were previously supported.
With this data, Cybozu could confidently adopt Baseline Widely available as a target.
The impact of Baseline in practice
Adopting Baseline as a policy was one thing, but making it operational required building tooling and processes. It was necessary to ensure developers couldn't accidentally use unsupported features without manually checking Baseline status.
Static analysis based on ESLint configuration
@cybozu/eslint-config is an OSS-based config used across Cybozu products. It was supported starting with the css-baseline preset that checks CSS features against Baseline at build time:
// eslint.config.mjs
import cybozuEslintConfigBaseline from '@cybozu/eslint-config/flat/presets/css-baseline.js';
export default [
...cybozuEslintConfigBaseline.map((config) => ({
...config,
files: ['**/*.css']
})),
];
When developers use features not yet Baseline Widely available, they get immediate feedback from ESLint:
This prevents compatibility issues from reaching production. Developers can make informed decisions early in the development process: Either wait for the feature to become Widely available, or implement progressive enhancement knowing exactly which users will be affected. (Learn more about ESLint's CSS and Baseline support.)
Configure transpilers to target Baseline Widely available
Modern build tools have started supporting Baseline as a target. For example, Vite automatically targets Baseline Widely Available in production without additional configuration. Browserslist now supports Baseline as well.
Using various compiler settings ensures that our JavaScript and CSS are transpiled only when necessary, avoiding unnecessary transforms and polyfills for features that are already widely supported.
Eliminate manual criteria maintenance and browser detection system for user feedback
The biggest maintenance win came from eliminating manual browser version tracking. Instead of quarterly meetings to debate which browser versions to support, Cybozu now relies on the openly maintained @web-platform-dx/baseline-browser-mapping package to answer these questions.
Cybozu also built automated browser detection to show upgrade prompts to users on outdated browsers.
Their browser detection fetches compatible browser versions directly from the @web-platform-dx/baseline-browser-mapping package.
This runs during our build process, and generates warning banners that are shared across all product teams. As the Baseline Widely available window moves to include newer browsers, our system automatically picks up the changes with no manual intervention required.
Streamlined communication
One of the most significant yet unexpected benefits was how Baseline simplified cross-team communication. Previously, browser compatibility discussions required company-specific domain knowledge—which browsers we support, which versions, and what features are available now. Newcomers needed time to learn our internal standards. With Baseline, we now reference the same compatibility criteria that's widely recognised across the web community.
This also creates a shared vocabulary within both our engineering teams and with the wider web community. When discussing feature adoption, everyone is referencing the same data from the same source, eliminating the need to explain internal policies or translate between different compatibility frameworks.
Development tools have also caught up: Visual Studio Code and the Style panel in Chrome DevTools now display Baseline compatibility information directly. Developers no longer need to constantly check MDN or Can I use to verify if a feature is safe to use. The tooling tells them immediately.
Make the product work for everyone with confidence
With Baseline, we could fundamentally shift our thinking on browser compatibility from a burden we manage to a foundation we trust. Our implementation strategy centred on automation at every stage:
- Development-time feedback: Static analysis and Baseline status card.
- Build-time validation: Transpilers automatically target Baseline Widely available.
- Runtime detection: User-facing warnings for unsupported browsers using
baseline-browser-mapping. - Continuous updates: Automated syncing with Baseline data eliminates manual maintenance.
The results speak for themselves:
- Zero hours spent on browser version maintenance.
- Over 98.8% user coverage is maintained with feature-level certainty.
- Instant and spontaneous answers to FAQ, which answers the question of "can we use this feature on this browser version?"
- Shared vocabulary across engineering teams.
- Clearer path to feature adoption prompts teams to discuss new-feature integration and timing of removing polyfills, if necessary.
For organizations considering Baseline adoption, it is critical to know how the shift will affect your users. Tools like Google Analytics Baseline Checker make this measurement more straightforward and explanatory. Once you have confidence in the data and decide to adopt Baseline, you can use the growing ecosystem of Baseline to organise your development workflow.
The web platform is more powerful, more consistent, more reliable, and evolving more quickly than in the past. With Baseline, we can harness that power in production with confidence.
Resources
- Original article in Japanese: プロダクト開発の基準に Baseline を取り入れるまで - Cybozu Inside Out
- Cybozu ESLint config:
@cybozu/eslint-configon GitHub - Google Analytics Baseline Checker: Google Analytics Baseline Checker
- Baseline browser mapping:
@web-platform-dx/baseline-browser-mapping - Learn about Baseline: Baseline at MDN