doc: updated README with latest info on legacy browser tests

Author: cure53

README.md

@@ -12,7 +12,7 @@ DOMPurify runs as JavaScript and works in all modern browsers (Safari (10+), Ope
 
 **Note that [DOMPurify v2.5.9](https://github.com/cure53/DOMPurify/releases/tag/2.5.9) is the latest version supporting MSIE. For important security updates compatible with MSIE, please use the [2.x branch](https://github.com/cure53/DOMPurify/tree/2.x).**
 
-Our automated tests cover 9 browser/OS combinations (Chromium, Firefox, and WebKit across Ubuntu, macOS, and Windows) on every push, plus Node.js v20, v22, v24, v25 and v26 running DOMPurify on [jsdom](https://github.com/jsdom/jsdom). Older Node versions are known to work as well, but hey... no guarantees.
+Our automated tests cover 9 browser/OS combinations on the current engines (Chromium, Firefox, and WebKit across Ubuntu, macOS, and Windows) on every push, and a separate matrix re-runs the suite on older engine snapshots (back to roughly Chromium 110, Firefox 108 and WebKit 16.4, around three years old) so regressions on outdated browsers get caught too. We also run Node.js v20, v22, v24, v25 and v26 with DOMPurify on [jsdom](https://github.com/jsdom/jsdom). Older Node versions are known to work as well, but hey... no guarantees.
 
 DOMPurify is written by security people who have vast background in web attacks and XSS. Fear not. For more details please also read about our [Security Goals & Threat Model](https://github.com/cure53/DOMPurify/wiki/Security-Goals-&-Threat-Model). Please, read it. Like, really. And if you enjoy the gory details, the [Attack Classes & Bypass History](https://github.com/cure53/DOMPurify/wiki/Attack-Classes-&-Bypass-History) page catalogs the parser-mutation, namespace, clobbering, and template tricks DOMPurify defends against.
 
@@ -61,9 +61,7 @@ const clean = DOMPurify.sanitize(dirty, { USE_PROFILES: { html: true } });
 
 ### Is there any foot-gun potential?
 
-Well, please note, if you _first_ sanitize HTML and then modify it _afterwards_, you might easily **void the effects of sanitization**. If you feed the sanitized markup to another library _after_ sanitization, please be certain that the library doesn't mess around with the HTML on its own.
-
-See the [Security Goals & Threat Model](https://github.com/cure53/DOMPurify/wiki/Security-Goals-&-Threat-Model) for safe-usage recipes and the tags/attributes worth thinking twice about, and [Attack Classes & Bypass History](https://github.com/cure53/DOMPurify/wiki/Attack-Classes-&-Bypass-History) for why post-processing and changing the markup context defeat sanitization.
+Well, please note, if you _first_ sanitize HTML and then modify it _afterwards_, you might easily **void the effects of sanitization**. If you feed the sanitized markup to another library _after_ sanitization, please be certain that the library doesn't mess around with the HTML on its own. See the [Security Goals & Threat Model](https://github.com/cure53/DOMPurify/wiki/Security-Goals-&-Threat-Model) for safe-usage recipes and the tags/attributes worth thinking twice about, and [Attack Classes & Bypass History](https://github.com/cure53/DOMPurify/wiki/Attack-Classes-&-Bypass-History) for why post-processing and changing the markup context defeat sanitization.
 
 ### Okay, makes sense, let's move on
 
@@ -486,7 +484,7 @@ DOMPurify.addHook(
 
 ## Continuous Integration
 
-We are currently using GitHub Actions in combination with Playwright. This gives us the possibility to confirm for each and every commit that all is going according to plan in relevant modern browsers. Check out the build logs here: https://github.com/cure53/DOMPurify/actions
+We are currently using GitHub Actions in combination with Playwright. This lets us confirm on every commit that everything works in the relevant modern browsers, and a separate scheduled and on-merge workflow re-runs the suite on older engine snapshots so breakage on outdated browsers is caught too. Check out the build logs here: https://github.com/cure53/DOMPurify/actions
 
 You can further run local tests by executing `npm run test`.
 
@@ -505,10 +503,11 @@ We use ESLint via `xo` as part of our pre-commit workflow to help ensure code co
 These are our npm scripts:
 
 - `npm run dev` to build the unminified UMD bundle while watching sources for changes
-- `npm run test` to lint the sources, run tests through jsdom, and run Karma tests in Chrome
+- `npm run test` to lint the sources, run tests through jsdom, and run browser tests in Chromium via Playwright
   - `npm run test:jsdom` to only run tests through jsdom
   - `npm run test:browser` to only run tests through Playwright
-  - `npm run test:ci` to run the CI test flow for jsdom and Karma/BrowserStack
+  - `npm run test:browser:legacy` to run the suite on older browser engines (point `PW_MODULE` at a pinned old Playwright install; see `.github/workflows/legacy-browsers.yml`)
+  - `npm run test:ci` to run the CI test flow for jsdom and Playwright
   - `npm run test:fuzz` to run a small fuzzer covering `sanitize()` and CONFIG
 - `npm run lint` to lint the sources using ESLint via xo
 - `npm run format` to format JavaScript/TypeScript and Markdown sources with Prettier