webf-api-compatibility_skill

This skill quickly reveals WebF API and CSS compatibility, guiding feature planning and providing alternatives for unsupported features.
  • C++

2.3k

GitHub Stars

3

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill openwebf/webf --skill webf-api-compatibility

  • alternatives.md13.8 KB
  • reference.md13.0 KB
  • SKILL.md13.6 KB

Overview

This skill checks Web API and CSS feature compatibility for WebF so you can plan features and avoid surprises. It identifies which JavaScript APIs, DOM methods, CSS properties, and layout modes are supported, coming soon, or not available, and offers practical alternatives and workarounds. Use it to validate choices before implementation or to debug why an API fails in WebF.

How this skill works

When asked about a specific API or CSS feature, the skill looks up the supported list and returns a clear status: Supported, Coming Soon, or Not Supported. It explains reasons for missing features (runtime, rendering, or architecture differences) and recommends concrete alternatives such as native plugins, Flexbox for layout, Canvas 2D for graphics, or localStorage/sqflite for storage. It also suggests feature-detection snippets and environment-specific next steps.

When to use it

  • Planning UI/layout choices and deciding between Flexbox vs Grid vs float
  • Debugging why a JavaScript API or DOM method works in browser but not in WebF
  • Choosing a storage solution (localStorage vs IndexedDB vs native plugin)
  • Selecting a graphics approach (Canvas 2D, SVG, or native Flutter rendering)
  • Evaluating third-party libraries that depend on specific web features
  • Preparing integration steps for native device features via WebF plugins

Best practices

  • Always use feature detection before relying on an API in runtime code
  • Prefer Flexbox for layouts; switch to CSS Grid only after it’s marked supported
  • Use localStorage for simple key-value needs; request or build native plugins for complex databases
  • Test in WebF Go early to confirm behaviors and avoid assumptions from browser-only testing
  • Coordinate with the Flutter team when a native plugin is required for production

Example use cases

  • Checking whether IndexedDB is available and recommending sqflite/Hive plugins when it's not
  • Confirming that WebGL is unavailable and suggesting Canvas 2D or Flutter rendering instead
  • Verifying CSS support so Tailwind v3 utilities will work and flagging v4 as not yet supported
  • Replacing float- or table-based layouts with Flexbox patterns for reliable rendering
  • Advising how to add a native share feature depending on WebF Go vs embedded Flutter app

FAQ

No. IndexedDB is not supported; use localStorage for simple use cases or request/create a native plugin (sqflite, Hive, Isar) for complex databases.

Is CSS Grid available?

Not yet. CSS Grid is planned; use Flexbox for most layouts until Grid support is released.

Why are Web Workers not supported?

WebF runs JavaScript on a dedicated thread already, so Web Workers provide no performance benefit and are unnecessary.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational