Forem: Ryuya

Bringing Baseline into Product Development — and Keeping It Safe in Practice

Ryuya — Wed, 10 Sep 2025 04:10:25 +0000

Baseline gives teams a simple way to answer a hard question: when is a web platform feature safe to use everywhere that matters? Instead of juggling browser-version matrices, you align on a shared, function-level line and make consistent, defensible decisions.

There is also a clear business angle. If a user’s browser silently lacks a feature you rely on, you can lose conversions, trigger avoidable support tickets, and erode trust without anyone noticing the root cause. Treating Baseline as a product standard reduces that risk. It turns a nebulous, recurring debate into a policy you can document, audit, and enforce automatically.

A quick primer on Baseline

Baseline tracks when a feature reaches parity across the four major engines (Safari, Chrome, Edge, and Firefox). It communicates readiness in three stages:

Limited availability — Not yet supported in all Baseline browsers; treat as experimental and avoid for production unless you have a well‑designed fallback.
Newly available — Supported in all current stable releases; good default for early adoption with care.
Widely available — Newly, plus 30 months of universal support; practical proxy for very low risk in the wild.

You can also target by year. For example, “2023” means: allow anything that became Baseline newly available in 2023 or earlier.

It is a feature‑first lens. Rather than anchoring on version lists for each browser, you ask, “Has this capability reached the line?” and get a single answer you can reason about.

Choosing “our Baseline”

Start with Widely as the default. It’s a conservative, low‑friction starting point because it bakes in real‑world adoption time after universal support lands.

Then estimate “our Year.” Use your analytics or RUM to understand the browsers your users actually run. Vary the year (2021, 2022, 2023, …) and estimate coverage. If you use Google Analytics, the Google Analytics Baseline Checker can visualize this; otherwise, you can massage internal logs into the same shape.

Finally, define your exception policy. Some features come with reasonable fallbacks you can ship today and progressively enhance later. Others carry more cross-browser risk and should wait even if they are technically Widely. Write down how exceptions are proposed, reviewed, and documented.

This sequence—safe default, data-informed tuning, explicit exceptions—makes the policy clear and keeps decisions explainable.

Why not rely on UA tables alone?

User-Agent strings are easy to spoof and often polluted by crawlers and scanners. Even when they are accurate, a version label does not capture enterprise policies, flags, or safety modes that can disable capabilities. UA-led policies also force you to manage version matrices, which age poorly and rarely map cleanly to how specifications group features.

Baseline draws the line at the capability itself. Keep UA data for coverage estimates and stakeholder communication, but let features drive the decision.

Bringing it into the workflow

First, set your build/transpile targets to align with your chosen Baseline. Some tools default to Widely already; others let you convert Baseline to a Browserslist query or an esbuild target. The goal is that the code you ship matches the line you agreed on.

Second, catch issues where they happen: in the editor and in CI. ESLint can enforce Baseline for JavaScript, and complementary plugins can do the same for CSS and HTML. When someone reaches for a feature that sits beyond the line, they see a precise, actionable message before it merges.

Third, document the policy. State the default (for example, “Widely”), the way you set the year, and how exceptions work. That turns a tribal norm into policy-as-code and keeps newcomers aligned.

Example: don’t use `Date#getYear()/setYear()`

Date#getYear() and Date#setYear() are deprecated. They also fall below a sensible Baseline threshold. Reaching for them is a recipe for subtle bugs.

With a Baseline rule enabled, you would see a message like:

One policy, three surfaces: JS, CSS, and HTML

The easiest way to make Baseline “real” for your team is to enable it where code is written. JavaScript is the obvious starting point, but it helps to bring CSS and HTML into the same conversation so your policy feels coherent.

Here is a Flat Config example that wires the three together. Adjust the file globs and the strictness to match your repo. The JavaScript section uses the built‑in presets exposed by eslint-plugin-baseline-js.

// eslint.config.js (Flat Config)
import tsParser from "@typescript-eslint/parser";
import baselineJs, { BASELINE } from "eslint-plugin-baseline-js";
import cssPlugin from "@eslint/css";
import htmlPlugin from "@html-eslint/eslint-plugin";
import htmlParser from "@html-eslint/parser";

export default [
  // Register the JS plugin once
  { plugins: { "baseline-js": baselineJs } },

  // JavaScript (JS) — recommended preset (auto Web APIs + JS builtins)
  baselineJs.configs.recommended({ available: BASELINE.WIDELY, level: "warn" }),

  // TypeScript (TS) — attach parser + type-aware preset
  {
    files: ["**/*.{ts,tsx}"],
    languageOptions: { parser: tsParser, parserOptions: { project: ["./tsconfig.json"] } },
  },
  baselineJs.configs["recommended-ts"]({ available: BASELINE.WIDELY, level: "warn" }),

  // CSS: Baseline
  {
    files: ["**/*.{css,scss}"],
    plugins: { "@css": cssPlugin },
    language: "@css/css",
    rules: { "@css/use-baseline": ["warn", { available: "widely" }] },
  },

  // HTML: Baseline
  {
    files: ["**/*.{html,htm}"],
    plugins: { "@html-eslint": htmlPlugin },
    languageOptions: { parser: htmlParser },
    rules: { "@html-eslint/use-baseline": ["warn", { available: "widely" }] },
  },
];

Notes

You can target a specific year (e.g., { available: 2022 }). Items with “Limited availability” are treated as beyond the configured year, so they will be flagged until they enter Baseline.
The single rule is baseline-js/use-baseline. Presets above expand it for JS and TS with sensible defaults (auto for JS, type‑aware for TS).

Closing thought

Baseline is a way to agree on reality. Pick a line, show your work, and let tooling hold it for you. That is how teams move fast without gambling with user experience.

Translate Markdown to Any Language (GitHub Bot)

Ryuya — Fri, 31 Mar 2023 14:38:32 +0000

Most open-source projects are written in English, raising barriers to participation from speakers of other languages. In addition, translation is a labor-intensive process, so documentation has yet to be internationalized to a great extent.
I have created a GitHub Actions that automatically translate documents using multiple AI models.
It is open source and requires an individual API key, but it is free.

Setup

All you need is an Open AI API Key and Actions workflow settings. Please see README for details.

To prevent your API KEY from being misused, we only allow people who have write permission to access the repository to run the bot.

Usage

Once the workflow is set up, comment on the issue or pr with a command to translate the input file.

/gpt-translate [input filepath] [output filepath] [target language]

Comment on Issues

View Actual Issues

Auto-generated PR

A PR is created depending on where the command is entered. (If you comment on a PR, the commit is added to that PR.)

View actual PR

Interestingly, I could translate Voynich's Manuscript (undeciphered script), ancient Greek, and other languages. (Not possible with GPT-4)
We could also build a kind of OSS document for time travelers :)

Human-in-the-Loop

Originally, the texts translated by GPT are of fairly high quality.

However, a human can also review the translation files created by this bot to perfect the translation further.

GitHub's function to accept reviews as is on a new commit allows us to build a very seamless translation experience.

If you have any suggestions for improvement or bugs, please feel free to write them in Issues!

🌎As a non-English speaking person, I would be happy if the various OSS are easier to understand!

Repo

Thanks for the 250 stars🌟

3ru / gpt-translate

💬Translate Files into Any Languages with AI

🌎 Markdown Translation BOT

This GitHub action translates your markdown files into multiple languages using multiple AI models.

Tip

Now Available: AI Models from Multiple Providers✨
We've expanded beyond OpenAI to support various AI model providers.
For a comprehensive list of supported providers and detailed information, please refer to our release notes.

🧐 Current Status

The action supports translating markdown(.md), markdown-jsx(.mdx), json(.json) files only.
The command can be executed exclusively by individuals with write permissions to the repository.

These limitations prevent API abuse by non-trusted parties.

🔧 Setup

Repository Settings

1. Settings > Actions > General

Enable Read and write permissions
Enable Allow GitHub Actions to create and approve pull requests

2. Settings > Secrets and variables > Actions

Set your API key(OPENAI_API_KEY) to…

View on GitHub

This is my very first OSS and I would be happy if you like it.