[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71MP5YYXXX5MS6VNB6VJMY3":3,"skill-same:01M71MP5YYXXX5MS6VNB6VJMY3":98},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":34,"publishedAt":55,"linkOnly":56,"markdownContent":57,"markdownBody":58,"frontMatter":59,"refName":63,"commitSha":64,"skillDirectory":65,"forksCount":14,"repositoryHtmlUrl":66,"repositoryHomepageUrl":67,"ownerHtmlUrl":68,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":69,"install":70,"resources":83},"01M71MP5YYXXX5MS6VNB6VJMY3","cross-browser-testing",null,"Design analytics-driven browser test matrices and execute cross-browser tests. Covers BrowserStack\u002FSauce Labs configuration, Playwright browser channels, common cross-browser CSS\u002FJS divergences, a known-issues documentation log, and progressive enhancement validation. Use when: \"cross-browser,\" \"browser matrix,\" \"BrowserStack,\" \"Safari issues,\" \"browser compatibility,\" \"Edge,\" \"works in Chrome but not Safari.\" Not for: pixel-level baseline strategy and threshold tuning — use visual-testing; device-farm testing of native\u002Fhybrid apps — use mobile-testing. Related: visual-testing, playwright-automation, ci-cd-integration, mobile-testing.","pattanation\u002FNorvik","pattanation","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F235419268?v=4","01M71M5THHYYB15ME8R2E4FCZG","Patta","01M71M5TJM1NDM992M8PDKYR2K",0,"MIT","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fcross-browser-testing\u002FSKILL.md",[18,23,26,29],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000013","分析与可视化",{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":30,"categoryName":31,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54],"cross browser testing","browser","browser testing","testing","log","when","progressive enhancement","apps","safari","farm","hybrid apps","pixel","mobile-testing","browser test","specialized","common","ci","issues","css","design","2026-11-10 10:56:23",false,"---\nname: cross-browser-testing\ndescription: >-\n  Design analytics-driven browser test matrices and execute cross-browser tests.\n  Covers BrowserStack\u002FSauce Labs configuration, Playwright browser channels, common\n  cross-browser CSS\u002FJS divergences, a known-issues documentation log, and progressive\n  enhancement validation.\n  Use when: \"cross-browser,\" \"browser matrix,\" \"BrowserStack,\" \"Safari issues,\"\n  \"browser compatibility,\" \"Edge,\" \"works in Chrome but not Safari.\"\n  Not for: pixel-level baseline strategy and threshold tuning — use visual-testing;\n  device-farm testing of native\u002Fhybrid apps — use mobile-testing.\n  Related: visual-testing, playwright-automation, ci-cd-integration, mobile-testing.\nlicense: MIT\nmetadata:\n  author: kindlmann\n  version: \"2.0\"\n  category: specialized\n---\n\n\u003Cobjective>\nChrome-only testing gives false confidence: a layout that works in Chromium can break in WebKit, a clipboard call that succeeds in Chrome silently no-ops in Firefox, and a partitioned-cookie flow can pass everywhere except the one engine your users are on. This skill produces an analytics-driven browser matrix, a Playwright (or cloud-platform) config that runs it, and a committed log of known browser divergences — each verified by a test that asserts the user outcome, not the CSS.\n\u003C\u002Fobjective>\n\n## Quick Route\n\n| Situation | Go to |\n|-----------|-------|\n| Need to decide *which* browsers to test | Browser Matrix Design |\n| Already on Playwright, just add browsers | Playwright Browser Configuration → `references\u002Fplaywright-and-cloud-config.md` |\n| Need real Safari\u002FWindows\u002Folder OS, not engines | Cloud Platform Setup |\n| One browser misbehaves; want a test for it | Common Cross-Browser Issues + `browserName` branch in `references\u002Ftesting-patterns.md` |\n| Need to record a divergence so it is not re-debugged | Known-Issues Log |\n| Pixel diffs \u002F baseline thresholds | use `visual-testing` |\n\n## Discovery Questions\n\nCheck `.agents\u002Fqa-project-context.md` first — if it exists, use it and skip anything already answered there. Then:\n\n1. **Target browsers from analytics:** What do actual users use? Pull browser\u002FOS data from your analytics tool. Testing browsers nobody uses is waste; missing a browser 15% of users rely on is a bug.\n2. **Desktop and mobile?** Mobile Safari on iOS and Chrome on Android render differently than their desktop counterparts. Treat them as separate matrix entries.\n3. **Cloud platform:** BrowserStack, Sauce Labs, LambdaTest, or local engines only? Cloud platforms provide real branded browsers and OSes; Playwright's bundled engines cover Chromium, Firefox, and WebKit (not Chrome\u002FSafari themselves).\n4. **Progressive enhancement or pixel-perfect?** Progressive enhancement accepts graceful degradation. Pixel-perfect demands identical rendering. The answer determines pass\u002Ffail criteria.\n5. **Existing Playwright config?** If the project already uses Playwright, cross-browser testing is a configuration change, not a new tool.\n\n---\n\n## Core Principles\n\n1. **Analytics-driven matrix.** Test what your users actually use. A browser at 0.3% traffic does not need the same investment as one at 40%. Check analytics quarterly — browser share shifts.\n\n2. **Progressive enhancement over pixel-perfect.** Identical rendering across all browsers is neither achievable nor necessary. Define what \"works\" means: core functionality operates, content is accessible, layout is usable. Visual differences in shadows, gradients, or animation timing are acceptable.\n\n3. **Safari and Firefox surface the most cross-browser bugs.** Chrome-only testing catches Chrome bugs. Safari's WebKit engine and Firefox's Gecko engine have the most behavioral differences from Chromium. Prioritize them.\n\n4. **Test functionality, not rendering-engine internals.** A cross-browser test should verify that the user can complete a task, not that a CSS property renders identically. Visual comparison tools handle pixel-level differences.\n\n5. **Engines are not brands.** Playwright's WebKit is *not* Safari and its Chromium is *not* Chrome — they share an engine, not the shipped product (codecs, fonts, enterprise policy, update cadence all differ). Report \"WebKit coverage,\" not \"Safari coverage,\" unless you ran real Safari on a cloud grid.\n\n6. **One test, multiple browsers.** Write tests once. Run them across browser configurations. Never duplicate test logic for different browsers.\n\n---\n\n## Browser Matrix Design\n\n### Analytics-Based Methodology\n\n```\nStep 1: Export browser\u002FOS data from analytics (last 90 days)\nStep 2: Rank by session share\nStep 3: Group into tiers\nStep 4: Assign test coverage per tier\nStep 5: Review quarterly\n```\n\n### Tier System\n\n| Tier | Criteria | Coverage | When to run |\n|------|----------|----------|-------------|\n| **P0** | >10% traffic share | Full test suite | Every PR, every deploy |\n| **P1** | 3-10% traffic share | Smoke + critical paths | Nightly, pre-release |\n| **P2** | 1-3% traffic share | Smoke tests only | Weekly, pre-release |\n| **Skip** | \u003C1% traffic share | Not tested | Manual spot-check if reported |\n\n### Example Matrix (derived from analytics)\n\n```markdown\n## Browser Matrix — Q1 2026 (next-review: 2026-04-01)\n\n| Browser | Version | Platform | Traffic % | Tier | Notes |\n|---------|---------|----------|-----------|------|-------|\n| Chrome | Latest | Windows | 34% | P0 | |\n| Chrome | Latest | macOS | 12% | P0 | |\n| Safari | Latest | macOS | 11% | P0 | WebKit-specific issues |\n| Chrome | Latest | Android | 15% | P0 | Mobile viewport |\n| Safari | Latest | iOS | 14% | P0 | Mobile Safari quirks |\n| Firefox | Latest | Windows | 5% | P1 | Gecko rendering |\n| Edge | Latest | Windows | 4% | P1 | Chromium-based but different UA\u002Fpolicy |\n| Samsung Internet | Latest | Android | 3% | P1 | Chromium fork, lagging engine |\n| Firefox | Latest | macOS | 1.5% | P2 | |\n| Chrome | N-1 | Windows | 1.2% | P2 | Previous major version |\n```\n\n### Version Coverage Strategy\n\n- **Latest:** Always test current stable release.\n- **Latest - 1:** Test previous major version only for P0 browsers where analytics show >1% on older versions.\n- **Extended Support Release (ESR):** Test Firefox ESR only if enterprise users are a significant segment.\n- **Do not test:** Beta\u002FCanary\u002FNightly releases unless you are a browser vendor or building browser-facing tools.\n\n---\n\n## Playwright Browser Configuration\n\nPlaywright ships three browser *engines* — Chromium, Firefox, WebKit — so no cloud platform is needed for basic engine-level coverage. This is engine coverage, not brand coverage: bundled WebKit ≠ Safari and bundled Chromium ≠ Chrome (see Core Principle 5). Define one project per matrix entry, map mobile devices via `devices[...]`, and drive locally installed branded browsers with the `channel` option.\n\nSee `references\u002Fplaywright-and-cloud-config.md` for the full `playwright.config.ts` project list, branded-channel snippets, and `--project` run commands.\n\n**When to use channels:** When you need real branded behavior that differs from the bundled engine — installed Chrome (`channel: 'chrome'`) or Edge (`channel: 'msedge'`) for extension support, enterprise policy, or codecs. WebKit and Firefox have no channel option; they are always Playwright's bundled engines. Note the `edge` project in the config and the `msedge` channel snippet are illustrative alternatives, not two projects to merge — a config needs one `edge` project, not both.\n\n**`page.screencast()` (Playwright 1.59+, current in 1.60)** captures annotated video of a cross-browser run — useful when a matrix failure needs human review across engines. For agent-driven re-runs and stepping through a failure, use `--ui` (UI mode) or `--debug` (Inspector); `PWDEBUG=1` and `--headed` are the other real entry points. There is no `--debug=cli` flag.\n\n---\n\n## Cloud Platform Setup\n\nCloud platforms (BrowserStack, Sauce Labs) provide real branded-browser\u002FOS instances Playwright connects to over a CDP\u002FPlaywright WebSocket endpoint. Pass credentials and capabilities via environment variables, and keep the platform's `playwrightVersion` aligned with the Playwright version in `package.json` (currently 1.60.x — a client\u002Fserver mismatch causes socket errors).\n\n**BrowserStack now recommends** the `npx browserstack-node-sdk` runner plus a `client.playwrightVersion` capability (in addition to `browserstack.playwrightVersion`) to keep the client and grid sockets in lock-step. The raw `wsEndpoint`\u002FCDP config below still works for direct connections; use the SDK path for new setups.\n\nSee `references\u002Fplaywright-and-cloud-config.md` for the BrowserStack config (with the `client.playwrightVersion` cap), the Sauce Labs config, and the GitHub Actions parallel matrix that fans out across cloud browsers.\n\n---\n\n## Common Cross-Browser Issues\n\nReal divergences that surface in cross-browser testing, with detection patterns and fixes. The CSS workarounds and Playwright tests for each are in `references\u002Fcommon-browser-issues.md`, covering: partitioned cookies \u002F CHIPS in iframes, `\u003Cinput type=\"date\">`, the Clipboard API, `scroll-behavior`, `backdrop-filter`, the `\u003Cdialog>` element, View Transitions, and Web Animations timing.\n\n### Modern Cross-Browser Gotchas (2026)\n\nThe classic Safari-laggard list is mostly resolved (flexbox `gap`, `:has()` shipping, same-document View Transitions are all Baseline). Today's real divergences:\n\n- **Partitioned cookies \u002F partitioned storage:** Chrome's CHIPS (`Partitioned` attribute), Safari's ITP, and Firefox's State Partitioning each behave differently for embedded third-party contexts. Test third-party cookies *in an iframe per engine*, not just \"the browser supports cookies.\" See the runnable per-engine iframe test in `references\u002Fcommon-browser-issues.md`.\n- **`:has()` selector performance:** Universally supported since 2023, but a `:has()`-heavy page can have very different style-recalc cost across engines. Watch list — profile if a page feels janky in one engine; visual-regression it in `visual-testing`.\n- **View Transitions API:** Same-document transitions are Baseline (Chrome 111, Safari 18, Firefox 144 — Oct 2025), so they are no longer a divergence. **Cross-document** transitions are still the gap: Chrome 126+, Safari 18.2+, Firefox behind a flag. Treat cross-document as progressive enhancement and verify the no-transition fallback.\n- **WebDriver BiDi:** Production-ready in Selenium 4, partially supported in Playwright. For new cross-runner projects, BiDi is the convergence point. Watch list.\n\n---\n\n## Known-Issues Log\n\nWhen a divergence is real and you cannot fix the app immediately, record it in a committed file (`docs\u002Fbrowser-issues.md`) so it is not re-debugged from scratch. The table is the artifact `Done When` checks for, and every row's test must assert the **user outcome, not the CSS property**:\n\n```markdown\n| Affected browser | Repro | Workaround \u002F fallback \u002F ticket | Test asserts (user outcome, not CSS) |\n|------------------|-------|--------------------------------|--------------------------------------|\n| Safari (WebKit) ≤17 | scroll-behavior: smooth is partial | rely on anchor nav; no JS scroll dependency | anchor link puts heading in viewport (`toBeInViewport`) |\n| Firefox ≤102 | backdrop-filter unsupported | -webkit- prefix + rgba background fallback | overlay readable; modal content visible |\n| Firefox (current) | cross-document View Transitions flagged off | progressive enhancement; instant nav fallback | navigation completes; target page heading visible |\n```\n\nKeep one row per divergence. A row with no ticket and no fallback is an open bug, not a documented issue.\n\n---\n\n## Testing Patterns\n\nThe core patterns and the rules that govern them:\n\n- **Same test, multiple browsers** — the default. Write the test once; configure projects to run it everywhere. Never duplicate test logic per browser.\n- **Browser-specific test logic** — branch on `browserName` only when behavior *genuinely* differs (the WebKit date-input fallback and Chromium-only clipboard permission are real cases). **Rule:** keep this rare. Many browser branches signal application compatibility bugs to fix, not work around.\n- **Visual cross-browser comparison** — `toHaveScreenshot` with a `maxDiffPixelRatio` tolerance; each browser project generates its own baseline (`homepage-chromium.png`, `homepage-webkit.png`, …). For threshold strategy and baseline management, use `visual-testing`.\n- **Progressive enhancement validation** — abort script requests (Chromium only) and verify core functionality still works via native HTML.\n\nSee `references\u002Ftesting-patterns.md` for the runnable code for all four patterns.\n\n---\n\n## Anti-Patterns\n\n**Testing only on Chrome.** Chrome is the largest desktop share but uses the same engine as Edge, Opera, and Brave. Safari (WebKit) and Firefox (Gecko) surface the real cross-browser issues. Chrome-only testing gives false confidence.\n\n**Reporting WebKit\u002FChromium as Safari\u002FChrome.** Bundled engines share rendering, not the shipped browser. Claiming \"Safari coverage\" off a WebKit project hides codec, font, and policy bugs that only real Safari shows.\n\n**Testing every browser equally.** A browser at 1% traffic share does not need the same investment as one at 30%. Use the tier system to allocate effort proportionally.\n\n**Duplicating tests per browser.** Write tests once, run them across browser projects via configuration. A `checkout.chrome.spec.ts` and `checkout.safari.spec.ts` with identical logic is the wrong shape.\n\n**`browserName` checks everywhere.** Excessive browser branching in tests signals application compatibility issues. Fix the app, do not work around it in tests.\n\n**Pixel-perfect assertions without tolerance.** Font rendering, anti-aliasing, and sub-pixel rounding differ between browsers and platforms. Use `maxDiffPixelRatio` or `maxDiffPixels` in visual comparisons.\n\n**Ignoring mobile browsers.** Mobile Chrome and mobile Safari are not their desktop counterparts — different viewport behavior, touch handling, and CSS support. Test them as separate matrix entries.\n\n**Static browser matrix.** Browser usage changes. A matrix based on data from two years ago is wrong. Review analytics quarterly and update the `next-review` date.\n\n**Documenting a divergence with no fallback or ticket.** A known-issues row that lists no workaround and no open ticket is an undocumented bug pretending to be documented.\n\n---\n\n## Failure Modes\n\n| Symptom | Likely cause | Fix or check |\n|---------|--------------|--------------|\n| Cloud tests fail with a socket\u002Fhandshake error | Grid Playwright version ≠ local | Set `playwrightVersion`\u002F`client.playwrightVersion` to match `npx playwright --version`; use the `browserstack-node-sdk` runner |\n| Clipboard test passes in Chromium, fails in Firefox\u002FWebKit | `grantPermissions` only works in Chromium | Assert UI feedback (`Copied!`), not the clipboard API; gate `grantPermissions` on `browserName === 'chromium'` |\n| Progressive-enhancement test errors in Firefox\u002FWebKit | Script-abort route interception is Chromium-only | Gate the route on `browserName === 'chromium'`; skip the JS-disabled assertion elsewhere |\n| WebKit project \"passes\" but real users on Safari report breakage | WebKit engine ≠ shipped Safari | Add a real-Safari row on a cloud grid for the affected flow |\n| Visual baseline diff explodes for one browser only | Single baseline shared across browsers | Generate per-project baselines; each browser keeps its own `*-\u003Cproject>.png` |\n| `:has()`-heavy page janky in one engine only | Style-recalc cost differs by engine | Profile in that engine; reduce `:has()` scope; visual-regress in `visual-testing` |\n\n---\n\n## Done When\n\n- Browser matrix defined using real analytics data (last 90 days), with tier assignments (P0\u002FP1\u002FP2) documented and justified by traffic share, committed to a file carrying a dated `next-review` field.\n- Playwright project config (or BrowserStack\u002FSauce Labs config) reflects the matrix and runs P0 browsers on every PR; cloud configs pin `playwrightVersion` to match `package.json`.\n- `docs\u002Fbrowser-issues.md` exists with one row per known divergence: affected browser, repro, workaround\u002Ffallback or linked ticket, and the test that asserts the user outcome (not the CSS).\n- Common-divergence checklist (partitioned cookies, date inputs, clipboard, scroll behavior, backdrop-filter, `\u003Cdialog>`, View Transitions) has a test or a known-issues row for each item relevant to P0\u002FP1 browsers.\n- A tracked issue exists for the next quarterly matrix review (or the matrix file's `next-review` date is in the future), so the refresh is not lost.\n\n## Related Skills\n\n- **visual-testing** — Owns pixel-level baseline strategy, threshold tables, and `toHaveScreenshot` config. Go there for *how tolerant* a screenshot diff should be; this skill only decides *which browsers* get a baseline.\n- **playwright-automation** — Core Playwright patterns, fixtures, and CI configuration that cross-browser testing builds on.\n- **ci-cd-integration** — Pipeline configuration for parallel browser-matrix execution and artifact collection.\n- **mobile-testing** — Device-farm and native\u002Fhybrid app testing (Appium\u002FDetox); go there when the target is an app, not a browser viewport.\n- **accessibility-testing** — Cross-browser accessibility differences (screen-reader behavior, ARIA support) that overlap with this matrix.\n\n## Reference Files (in `references\u002F`)\n\n- **playwright-and-cloud-config.md** — `playwright.config.ts` project list, branded channels, `--project` run commands, and BrowserStack (SDK + `client.playwrightVersion`)\u002FSauce Labs\u002FCI matrix configs.\n- **common-browser-issues.md** — Per-engine partitioned-cookie iframe test, date-input WebKit fallback, clipboard, scroll behavior, backdrop-filter, `\u003Cdialog>`, View Transitions, and Web Animations.\n- **testing-patterns.md** — Same-test-multiple-browsers, `browserName` branching, visual comparison, and progressive-enhancement code.\n","\u003Cobjective>\nChrome-only testing gives false confidence: a layout that works in Chromium can break in WebKit, a clipboard call that succeeds in Chrome silently no-ops in Firefox, and a partitioned-cookie flow can pass everywhere except the one engine your users are on. This skill produces an analytics-driven browser matrix, a Playwright (or cloud-platform) config that runs it, and a committed log of known browser divergences — each verified by a test that asserts the user outcome, not the CSS.\n\u003C\u002Fobjective>\n\n## Quick Route\n\n| Situation | Go to |\n|-----------|-------|\n| Need to decide *which* browsers to test | Browser Matrix Design |\n| Already on Playwright, just add browsers | Playwright Browser Configuration → `references\u002Fplaywright-and-cloud-config.md` |\n| Need real Safari\u002FWindows\u002Folder OS, not engines | Cloud Platform Setup |\n| One browser misbehaves; want a test for it | Common Cross-Browser Issues + `browserName` branch in `references\u002Ftesting-patterns.md` |\n| Need to record a divergence so it is not re-debugged | Known-Issues Log |\n| Pixel diffs \u002F baseline thresholds | use `visual-testing` |\n\n## Discovery Questions\n\nCheck `.agents\u002Fqa-project-context.md` first — if it exists, use it and skip anything already answered there. Then:\n\n1. **Target browsers from analytics:** What do actual users use? Pull browser\u002FOS data from your analytics tool. Testing browsers nobody uses is waste; missing a browser 15% of users rely on is a bug.\n2. **Desktop and mobile?** Mobile Safari on iOS and Chrome on Android render differently than their desktop counterparts. Treat them as separate matrix entries.\n3. **Cloud platform:** BrowserStack, Sauce Labs, LambdaTest, or local engines only? Cloud platforms provide real branded browsers and OSes; Playwright's bundled engines cover Chromium, Firefox, and WebKit (not Chrome\u002FSafari themselves).\n4. **Progressive enhancement or pixel-perfect?** Progressive enhancement accepts graceful degradation. Pixel-perfect demands identical rendering. The answer determines pass\u002Ffail criteria.\n5. **Existing Playwright config?** If the project already uses Playwright, cross-browser testing is a configuration change, not a new tool.\n\n---\n\n## Core Principles\n\n1. **Analytics-driven matrix.** Test what your users actually use. A browser at 0.3% traffic does not need the same investment as one at 40%. Check analytics quarterly — browser share shifts.\n\n2. **Progressive enhancement over pixel-perfect.** Identical rendering across all browsers is neither achievable nor necessary. Define what \"works\" means: core functionality operates, content is accessible, layout is usable. Visual differences in shadows, gradients, or animation timing are acceptable.\n\n3. **Safari and Firefox surface the most cross-browser bugs.** Chrome-only testing catches Chrome bugs. Safari's WebKit engine and Firefox's Gecko engine have the most behavioral differences from Chromium. Prioritize them.\n\n4. **Test functionality, not rendering-engine internals.** A cross-browser test should verify that the user can complete a task, not that a CSS property renders identically. Visual comparison tools handle pixel-level differences.\n\n5. **Engines are not brands.** Playwright's WebKit is *not* Safari and its Chromium is *not* Chrome — they share an engine, not the shipped product (codecs, fonts, enterprise policy, update cadence all differ). Report \"WebKit coverage,\" not \"Safari coverage,\" unless you ran real Safari on a cloud grid.\n\n6. **One test, multiple browsers.** Write tests once. Run them across browser configurations. Never duplicate test logic for different browsers.\n\n---\n\n## Browser Matrix Design\n\n### Analytics-Based Methodology\n\n```\nStep 1: Export browser\u002FOS data from analytics (last 90 days)\nStep 2: Rank by session share\nStep 3: Group into tiers\nStep 4: Assign test coverage per tier\nStep 5: Review quarterly\n```\n\n### Tier System\n\n| Tier | Criteria | Coverage | When to run |\n|------|----------|----------|-------------|\n| **P0** | >10% traffic share | Full test suite | Every PR, every deploy |\n| **P1** | 3-10% traffic share | Smoke + critical paths | Nightly, pre-release |\n| **P2** | 1-3% traffic share | Smoke tests only | Weekly, pre-release |\n| **Skip** | \u003C1% traffic share | Not tested | Manual spot-check if reported |\n\n### Example Matrix (derived from analytics)\n\n```markdown\n## Browser Matrix — Q1 2026 (next-review: 2026-04-01)\n\n| Browser | Version | Platform | Traffic % | Tier | Notes |\n|---------|---------|----------|-----------|------|-------|\n| Chrome | Latest | Windows | 34% | P0 | |\n| Chrome | Latest | macOS | 12% | P0 | |\n| Safari | Latest | macOS | 11% | P0 | WebKit-specific issues |\n| Chrome | Latest | Android | 15% | P0 | Mobile viewport |\n| Safari | Latest | iOS | 14% | P0 | Mobile Safari quirks |\n| Firefox | Latest | Windows | 5% | P1 | Gecko rendering |\n| Edge | Latest | Windows | 4% | P1 | Chromium-based but different UA\u002Fpolicy |\n| Samsung Internet | Latest | Android | 3% | P1 | Chromium fork, lagging engine |\n| Firefox | Latest | macOS | 1.5% | P2 | |\n| Chrome | N-1 | Windows | 1.2% | P2 | Previous major version |\n```\n\n### Version Coverage Strategy\n\n- **Latest:** Always test current stable release.\n- **Latest - 1:** Test previous major version only for P0 browsers where analytics show >1% on older versions.\n- **Extended Support Release (ESR):** Test Firefox ESR only if enterprise users are a significant segment.\n- **Do not test:** Beta\u002FCanary\u002FNightly releases unless you are a browser vendor or building browser-facing tools.\n\n---\n\n## Playwright Browser Configuration\n\nPlaywright ships three browser *engines* — Chromium, Firefox, WebKit — so no cloud platform is needed for basic engine-level coverage. This is engine coverage, not brand coverage: bundled WebKit ≠ Safari and bundled Chromium ≠ Chrome (see Core Principle 5). Define one project per matrix entry, map mobile devices via `devices[...]`, and drive locally installed branded browsers with the `channel` option.\n\nSee `references\u002Fplaywright-and-cloud-config.md` for the full `playwright.config.ts` project list, branded-channel snippets, and `--project` run commands.\n\n**When to use channels:** When you need real branded behavior that differs from the bundled engine — installed Chrome (`channel: 'chrome'`) or Edge (`channel: 'msedge'`) for extension support, enterprise policy, or codecs. WebKit and Firefox have no channel option; they are always Playwright's bundled engines. Note the `edge` project in the config and the `msedge` channel snippet are illustrative alternatives, not two projects to merge — a config needs one `edge` project, not both.\n\n**`page.screencast()` (Playwright 1.59+, current in 1.60)** captures annotated video of a cross-browser run — useful when a matrix failure needs human review across engines. For agent-driven re-runs and stepping through a failure, use `--ui` (UI mode) or `--debug` (Inspector); `PWDEBUG=1` and `--headed` are the other real entry points. There is no `--debug=cli` flag.\n\n---\n\n## Cloud Platform Setup\n\nCloud platforms (BrowserStack, Sauce Labs) provide real branded-browser\u002FOS instances Playwright connects to over a CDP\u002FPlaywright WebSocket endpoint. Pass credentials and capabilities via environment variables, and keep the platform's `playwrightVersion` aligned with the Playwright version in `package.json` (currently 1.60.x — a client\u002Fserver mismatch causes socket errors).\n\n**BrowserStack now recommends** the `npx browserstack-node-sdk` runner plus a `client.playwrightVersion` capability (in addition to `browserstack.playwrightVersion`) to keep the client and grid sockets in lock-step. The raw `wsEndpoint`\u002FCDP config below still works for direct connections; use the SDK path for new setups.\n\nSee `references\u002Fplaywright-and-cloud-config.md` for the BrowserStack config (with the `client.playwrightVersion` cap), the Sauce Labs config, and the GitHub Actions parallel matrix that fans out across cloud browsers.\n\n---\n\n## Common Cross-Browser Issues\n\nReal divergences that surface in cross-browser testing, with detection patterns and fixes. The CSS workarounds and Playwright tests for each are in `references\u002Fcommon-browser-issues.md`, covering: partitioned cookies \u002F CHIPS in iframes, `\u003Cinput type=\"date\">`, the Clipboard API, `scroll-behavior`, `backdrop-filter`, the `\u003Cdialog>` element, View Transitions, and Web Animations timing.\n\n### Modern Cross-Browser Gotchas (2026)\n\nThe classic Safari-laggard list is mostly resolved (flexbox `gap`, `:has()` shipping, same-document View Transitions are all Baseline). Today's real divergences:\n\n- **Partitioned cookies \u002F partitioned storage:** Chrome's CHIPS (`Partitioned` attribute), Safari's ITP, and Firefox's State Partitioning each behave differently for embedded third-party contexts. Test third-party cookies *in an iframe per engine*, not just \"the browser supports cookies.\" See the runnable per-engine iframe test in `references\u002Fcommon-browser-issues.md`.\n- **`:has()` selector performance:** Universally supported since 2023, but a `:has()`-heavy page can have very different style-recalc cost across engines. Watch list — profile if a page feels janky in one engine; visual-regression it in `visual-testing`.\n- **View Transitions API:** Same-document transitions are Baseline (Chrome 111, Safari 18, Firefox 144 — Oct 2025), so they are no longer a divergence. **Cross-document** transitions are still the gap: Chrome 126+, Safari 18.2+, Firefox behind a flag. Treat cross-document as progressive enhancement and verify the no-transition fallback.\n- **WebDriver BiDi:** Production-ready in Selenium 4, partially supported in Playwright. For new cross-runner projects, BiDi is the convergence point. Watch list.\n\n---\n\n## Known-Issues Log\n\nWhen a divergence is real and you cannot fix the app immediately, record it in a committed file (`docs\u002Fbrowser-issues.md`) so it is not re-debugged from scratch. The table is the artifact `Done When` checks for, and every row's test must assert the **user outcome, not the CSS property**:\n\n```markdown\n| Affected browser | Repro | Workaround \u002F fallback \u002F ticket | Test asserts (user outcome, not CSS) |\n|------------------|-------|--------------------------------|--------------------------------------|\n| Safari (WebKit) ≤17 | scroll-behavior: smooth is partial | rely on anchor nav; no JS scroll dependency | anchor link puts heading in viewport (`toBeInViewport`) |\n| Firefox ≤102 | backdrop-filter unsupported | -webkit- prefix + rgba background fallback | overlay readable; modal content visible |\n| Firefox (current) | cross-document View Transitions flagged off | progressive enhancement; instant nav fallback | navigation completes; target page heading visible |\n```\n\nKeep one row per divergence. A row with no ticket and no fallback is an open bug, not a documented issue.\n\n---\n\n## Testing Patterns\n\nThe core patterns and the rules that govern them:\n\n- **Same test, multiple browsers** — the default. Write the test once; configure projects to run it everywhere. Never duplicate test logic per browser.\n- **Browser-specific test logic** — branch on `browserName` only when behavior *genuinely* differs (the WebKit date-input fallback and Chromium-only clipboard permission are real cases). **Rule:** keep this rare. Many browser branches signal application compatibility bugs to fix, not work around.\n- **Visual cross-browser comparison** — `toHaveScreenshot` with a `maxDiffPixelRatio` tolerance; each browser project generates its own baseline (`homepage-chromium.png`, `homepage-webkit.png`, …). For threshold strategy and baseline management, use `visual-testing`.\n- **Progressive enhancement validation** — abort script requests (Chromium only) and verify core functionality still works via native HTML.\n\nSee `references\u002Ftesting-patterns.md` for the runnable code for all four patterns.\n\n---\n\n## Anti-Patterns\n\n**Testing only on Chrome.** Chrome is the largest desktop share but uses the same engine as Edge, Opera, and Brave. Safari (WebKit) and Firefox (Gecko) surface the real cross-browser issues. Chrome-only testing gives false confidence.\n\n**Reporting WebKit\u002FChromium as Safari\u002FChrome.** Bundled engines share rendering, not the shipped browser. Claiming \"Safari coverage\" off a WebKit project hides codec, font, and policy bugs that only real Safari shows.\n\n**Testing every browser equally.** A browser at 1% traffic share does not need the same investment as one at 30%. Use the tier system to allocate effort proportionally.\n\n**Duplicating tests per browser.** Write tests once, run them across browser projects via configuration. A `checkout.chrome.spec.ts` and `checkout.safari.spec.ts` with identical logic is the wrong shape.\n\n**`browserName` checks everywhere.** Excessive browser branching in tests signals application compatibility issues. Fix the app, do not work around it in tests.\n\n**Pixel-perfect assertions without tolerance.** Font rendering, anti-aliasing, and sub-pixel rounding differ between browsers and platforms. Use `maxDiffPixelRatio` or `maxDiffPixels` in visual comparisons.\n\n**Ignoring mobile browsers.** Mobile Chrome and mobile Safari are not their desktop counterparts — different viewport behavior, touch handling, and CSS support. Test them as separate matrix entries.\n\n**Static browser matrix.** Browser usage changes. A matrix based on data from two years ago is wrong. Review analytics quarterly and update the `next-review` date.\n\n**Documenting a divergence with no fallback or ticket.** A known-issues row that lists no workaround and no open ticket is an undocumented bug pretending to be documented.\n\n---\n\n## Failure Modes\n\n| Symptom | Likely cause | Fix or check |\n|---------|--------------|--------------|\n| Cloud tests fail with a socket\u002Fhandshake error | Grid Playwright version ≠ local | Set `playwrightVersion`\u002F`client.playwrightVersion` to match `npx playwright --version`; use the `browserstack-node-sdk` runner |\n| Clipboard test passes in Chromium, fails in Firefox\u002FWebKit | `grantPermissions` only works in Chromium | Assert UI feedback (`Copied!`), not the clipboard API; gate `grantPermissions` on `browserName === 'chromium'` |\n| Progressive-enhancement test errors in Firefox\u002FWebKit | Script-abort route interception is Chromium-only | Gate the route on `browserName === 'chromium'`; skip the JS-disabled assertion elsewhere |\n| WebKit project \"passes\" but real users on Safari report breakage | WebKit engine ≠ shipped Safari | Add a real-Safari row on a cloud grid for the affected flow |\n| Visual baseline diff explodes for one browser only | Single baseline shared across browsers | Generate per-project baselines; each browser keeps its own `*-\u003Cproject>.png` |\n| `:has()`-heavy page janky in one engine only | Style-recalc cost differs by engine | Profile in that engine; reduce `:has()` scope; visual-regress in `visual-testing` |\n\n---\n\n## Done When\n\n- Browser matrix defined using real analytics data (last 90 days), with tier assignments (P0\u002FP1\u002FP2) documented and justified by traffic share, committed to a file carrying a dated `next-review` field.\n- Playwright project config (or BrowserStack\u002FSauce Labs config) reflects the matrix and runs P0 browsers on every PR; cloud configs pin `playwrightVersion` to match `package.json`.\n- `docs\u002Fbrowser-issues.md` exists with one row per known divergence: affected browser, repro, workaround\u002Ffallback or linked ticket, and the test that asserts the user outcome (not the CSS).\n- Common-divergence checklist (partitioned cookies, date inputs, clipboard, scroll behavior, backdrop-filter, `\u003Cdialog>`, View Transitions) has a test or a known-issues row for each item relevant to P0\u002FP1 browsers.\n- A tracked issue exists for the next quarterly matrix review (or the matrix file's `next-review` date is in the future), so the refresh is not lost.\n\n## Related Skills\n\n- **visual-testing** — Owns pixel-level baseline strategy, threshold tables, and `toHaveScreenshot` config. Go there for *how tolerant* a screenshot diff should be; this skill only decides *which browsers* get a baseline.\n- **playwright-automation** — Core Playwright patterns, fixtures, and CI configuration that cross-browser testing builds on.\n- **ci-cd-integration** — Pipeline configuration for parallel browser-matrix execution and artifact collection.\n- **mobile-testing** — Device-farm and native\u002Fhybrid app testing (Appium\u002FDetox); go there when the target is an app, not a browser viewport.\n- **accessibility-testing** — Cross-browser accessibility differences (screen-reader behavior, ARIA support) that overlap with this matrix.\n\n## Reference Files (in `references\u002F`)\n\n- **playwright-and-cloud-config.md** — `playwright.config.ts` project list, branded channels, `--project` run commands, and BrowserStack (SDK + `client.playwrightVersion`)\u002FSauce Labs\u002FCI matrix configs.\n- **common-browser-issues.md** — Per-engine partitioned-cookie iframe test, date-input WebKit fallback, clipboard, scroll behavior, backdrop-filter, `\u003Cdialog>`, View Transitions, and Web Animations.\n- **testing-patterns.md** — Same-test-multiple-browsers, `browserName` branching, visual comparison, and progressive-enhancement code.\n",{"name":5,"license":15,"metadata":60,"description":7},{"author":61,"version":62,"category":49},"kindlmann","2.0","claude\u002Finstall-gsd-build-foQdV","d86cd127f527124b5fd0fd0bc679a4d79b7d01d7",".agents\u002Fskills\u002Fcross-browser-testing","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik","https:\u002F\u002Fnorvik-orpin.vercel.app","https:\u002F\u002Fgithub.com\u002Fpattanation","2026-07-17 11:17:04",{"source":8,"skillName":5,"commands":71,"prompt":81,"zipAvailable":82},[72,75,78],{"tool":73,"command":74},"npx","npx skills add pattanation\u002FNorvik --skill cross-browser-testing",{"tool":76,"command":77},"bunx","bunx skills add pattanation\u002FNorvik --skill cross-browser-testing",{"tool":79,"command":80},"pnpm","pnpm dlx skills add pattanation\u002FNorvik --skill cross-browser-testing","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fcross-browser-testing\u002FSKILL.md",true,[84,90,94],{"path":85,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":88,"sourceHtmlUrl":89},"references\u002Fcommon-browser-issues.md","REFERENCE","参考文档",7125,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fcross-browser-testing\u002Freferences\u002Fcommon-browser-issues.md",{"path":91,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":92,"sourceHtmlUrl":93},"references\u002Fplaywright-and-cloud-config.md",5310,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fcross-browser-testing\u002Freferences\u002Fplaywright-and-cloud-config.md",{"path":95,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":96,"sourceHtmlUrl":97},"references\u002Ftesting-patterns.md",3098,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fcross-browser-testing\u002Freferences\u002Ftesting-patterns.md",[99,128,153,176,198,213],{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":103,"licenseFileUrl":104,"sourceHtmlUrl":105,"categories":106,"keywords":111,"publishedAt":127},"01M71QDV4DM8T19HEHWATEF1K4","webapp-testing","Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fwebapp-testing\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fwebapp-testing\u002FSKILL.md",[107,108],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":109,"categoryName":110,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[112,38,113,114,115,116,117,118,119,120,36,121,122,123,124,125,126],"webapp","webapp testing","for","applications","local","frontend","debugging","toolkit","logs","with","playwright","web","behavior","ui","screenshots","2026-11-10 13:02:02",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":103,"licenseFileUrl":132,"sourceHtmlUrl":133,"categories":134,"keywords":136,"publishedAt":127},"01M71QDH2GGMXGA9105C9W1N7B","web-artifacts-builder","Suite of tools for creating elaborate, multi-component claude.ai HTML artifacts using modern frontend web technologies (React, Tailwind CSS, shadcn\u002Fui). Use for complex artifacts requiring state management, routing, or shadcn\u002Fui components - not for simple single-file HTML\u002FJSX artifacts.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fweb-artifacts-builder\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fweb-artifacts-builder\u002FSKILL.md",[135],{"categoryNo":109,"categoryName":110,"taxonomyType":21,"taxonomyTypeDesc":22},[137,138,139,123,140,141,53,114,142,143,117,144,145,146,147,148,149,150,151,152],"builder","artifacts builder","artifacts","web artifacts builder","single-file","Tailwind","ui components","single","use","file","components","react","multi","state","routing","state management",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":157,"sourceHtmlUrl":158,"categories":159,"keywords":161,"publishedAt":127},"01M71QD9T2XC3EWMQNN9ACNWQ1","vueuse-functions","Apply VueUse composables where appropriate to build concise, maintainable Vue.js \u002F Nuxt features.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvueuse-functions\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvueuse-functions\u002FSKILL.md",[160],{"categoryNo":109,"categoryName":110,"taxonomyType":21,"taxonomyTypeDesc":22},[162,163,164,165,166,167,168,169,170,171,172,173,174,175],"functions","vueuse","vueuse functions","project","nuxt","apply","github","concise","build","https","features","vue","js","composables",{"skillNo":177,"name":178,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":180,"sourceHtmlUrl":181,"categories":182,"keywords":185,"publishedAt":127},"01M71QD51HWSGYMCMB7RW7PGK8","vue-testing-best-practices","Use for Vue.js testing. Covers Vitest, Vue Test Utils, component testing, mocking, testing patterns, and Playwright for E2E testing.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-testing-best-practices\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-testing-best-practices\u002FSKILL.md",[183,184],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":109,"categoryName":110,"taxonomyType":21,"taxonomyTypeDesc":22},[186,38,187,173,188,122,189,190,191,168,192,114,193,194,195,145,196,174,197],"vue testing best practices","testing best practices","best practices","test","testing patterns","component","vitest","mocking","e2e","utils","patterns","e2e testing",{"skillNo":199,"name":200,"nameZh":6,"description":201,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":202,"sourceHtmlUrl":203,"categories":204,"keywords":206,"publishedAt":127},"01M71QD358H2DJ9THJRBP77T3T","vue-router-best-practices","Vue Router 4 patterns, navigation guards, route params, and route-component lifecycle interactions.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-router-best-practices\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-router-best-practices\u002FSKILL.md",[205],{"categoryNo":109,"categoryName":110,"taxonomyType":21,"taxonomyTypeDesc":22},[207,173,208,188,209,191,210,168,196,211,212],"router","vue router best practices","route","guards","navigation","lifecycle",{"skillNo":214,"name":215,"nameZh":6,"description":216,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":217,"sourceHtmlUrl":218,"categories":219,"keywords":221,"publishedAt":127},"01M71QCYPNWDE2MQZ1TF3ED5S4","vue-best-practices","MUST be used for Vue.js tasks. Strongly recommends Composition API with `\u003Cscript setup>` and TypeScript as the standard approach. Covers Vue 3, SSR, Volar, vue-tsc. Load for any Vue, .vue files, Vue Router, Pinia, or Vite with Vue work. ALWAYS use Composition API unless the project explicitly requires Options API.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-best-practices\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-best-practices\u002FSKILL.md",[220],{"categoryNo":109,"categoryName":110,"taxonomyType":21,"taxonomyTypeDesc":22},[222,173,188,223,165,224,225,226,207,227,228,229,230,231,232,114,233,145,234,235],"vue best practices","Composition","files","tasks","api","pinia","work","options","ssr","typescript","as","vite","load","standard"]