WAIT — Stale — last commit 2y ago

• 17 active contributors
• Distributed ownership (top contributor 47% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 2y ago
• ⚠ Scorecard: marked unmaintained (0/10)
• ⚠ Scorecard: default branch unprotected (0/10)

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests + OpenSSF Scorecard}

Web Font Loader is a JavaScript library that provides unified control over loading web fonts from multiple sources (Google Fonts, Typekit, Fonts.com, Fontdeck, and self-hosted @font-face) via a single API. It adds standardized lifecycle events (loading, active, inactive) so developers can manage font loading state and control page rendering while fonts are fetched, solving the invisible text flash (FOIT) and flash of unstyled text (FOUT) problems. Modular architecture with separate loader modules per font service. Core engine in spec/core/ with modules: CssClassName, DomHelper, EventDispatcher, Font, FontWatcher, FontWatchRunner, NativeFontWatchRunner. Font providers (Google, Typekit, Fonts.com, Fontdeck, custom) are loaded via FontModuleLoader. Demo server at lib/webfontloader/demo/server.rb serves 40+ test HTML files demonstrating each feature (google.html, typekit.html, event-js-loading.html, etc.).

Frontend developers and web designers who need reliable font loading with fallback handling across multiple font services. Particularly useful for developers at Google and Typekit (co-maintainers) building sites where font loading performance and user experience during the font fetch window is critical.

Production-ready and actively maintained. The project is at v1.6.28 with comprehensive test coverage (Jasmine specs in spec/core/), CI via Travis CI (.travis.yml present), and explicit browser support matrix (browsers.json). The large JavaScript codebase (143KB) and presence on multiple CDNs (Google Hosted Libraries, jsDelivr, CDNJS) indicate production adoption.

Low risk for a mature library. No npm dependencies listed (devDependencies empty), reducing supply chain risk. However, the last visible activity and commit recency are not shown in provided data, so current maintenance status cannot be fully assessed. The library depends on accurate DOM inspection and font metrics detection, which can be fragile across browser versions—reliance on FontRuler pattern (spec/core/fontruler_spec.js) suggests ongoing browser compatibility work needed.

Not explicitly visible from file structure, but the presence of events-variations.html and typekit-variations.html demos suggests active work on variable font support. The Rake build system (Rakefile) and bin/webfontloader-demos script indicate ongoing tooling and demo maintenance.

Clone the repo, then run: git clone https://github.com/typekit/webfontloader.git && cd webfontloader && npm install. Run tests with npm test (uses Phantomjs + Jasmine). Start the demo server with Ruby: ruby lib/webfontloader/demo/server.rb.

Daily commands: Build: rake build (inferred from Rakefile). Run tests: npm test. Run demo server locally: ruby lib/webfontloader/demo/server.rb, then visit http://localhost:5000/index.html (based on lib/webfontloader/demo/public/index.html).

• spec/core/fontwatchrunner_spec.js: Core font loading state machine—determines when a font is loaded by comparing rendered text metrics against fallback baselines
• spec/core/eventdispatcher_spec.js: Central event bus that fires all lifecycle events (wfloading, wfactive, wfinactive, wffontactive, wffontinactive) consumed by client code
• spec/core/fontmoduleloader_spec.js: Dynamic module loader that instantiates provider-specific loaders (Google, Typekit, etc.) based on WebFontConfig
• lib/webfontloader/modules.rb: Ruby build config that specifies which provider modules to compile into the final webfontloader.js bundle
• spec/core/fontruler_spec.js: Font metric measurement utility that detects when a font is loaded by observing glyph widths—critical for cross-browser font detection
• browsers.json: Explicit browser support matrix defining which browsers are tested and supported (critical for validation)

To add a new font provider: create a module in src/modules/ following the pattern of existing providers (google, typekit, etc.). To modify font detection logic: edit spec/core/fontruler_spec.js and src files. To add events: extend EventDispatcher in spec/core/eventdispatcher_spec.js. To test font loading from a new service: add demo HTML in lib/webfontloader/demo/public/. Browser-specific fixes go in spec/core/nativefontwatchrunner_spec.js.

The FontRuler metric detection is timing-sensitive and can produce false positives/negatives if polling interval is too long or too short—see fontwatchrunner_spec.js timeout constants. The library must be loaded early in page lifecycle to catch font events; late injection may miss the loading phase. Some font providers (Typekit, Fonts.com) require API keys/IDs in WebFontConfig, which are not validated at load time—errors surface only when requests fail. The demo server uses port 5000 (hardcoded in server.rb); will fail silently if port is already bound.

• Font Metric Detection (Width-based FOIT/FOUT detection) — Web Font Loader uses FontRuler to measure glyph widths against known fallback fonts to infer when a web font is loaded—this is the core technique avoiding blocking page rendering while waiting for fonts.
• Font Face Observer Pattern — FontWatcher polls font metrics repeatedly to observe state transitions (loading → active/inactive), implementing a polling observer without native FontFaceSet API (required for old browser support).
• Service Provider Pattern / Module Injection — FontModuleLoader dynamically loads provider-specific modules (Google, Typekit, Fonts.com) at runtime based on config, avoiding bundling code for unused services and enabling extensibility.
• FOIT (Flash of Invisible Text) and FOUT (Flash of Unstyled Text) — Understanding the difference between these two rendering problems is critical to designing font loading strategy; Web Font Loader lets developers choose which they prefer via event hooks.
• Event-Driven Architecture with Custom Events — Web Font Loader communicates font state (loading, active, inactive) via custom DOM events (wfloading, wfactive, etc.) that client code listens to—decouples loader from UI concerns.
• Cross-Origin Resource Loading and CORS — Font providers (Google, Typekit, Fonts.com) serve fonts from different origins; Web Font Loader must handle CORS restrictions and cross-origin iframe loading (see custom-iframe.html, google-iframe.html).
• Timeout and Fallback Strategies — Web Font Loader implements configurable timeouts (see CONTRIBUTING.md timeout section) so pages don't wait forever if font fetches fail—critical for production reliability.

• google/fonts — Google Fonts is one of the primary font sources supported by Web Font Loader; understanding the Google Fonts API and font file availability is essential for the google.html module.
• typekit/typekit-js — Typekit's own JavaScript library for loading fonts; Web Font Loader provides a unified abstraction over this and other services, so comparing both approaches is useful.
• fonttools/fonttools — Low-level font file parsing and metrics extraction library; used for understanding font file structure when building font detection heuristics.
• bram-stein/fontfaceobserver — Alternative font loading library using Promise-based API and native FontFaceSet.load() where available; shows modern approach to same problem (good reference for future Web Font Loader enhancements).
• google/closure-compiler — The JavaScript compiler used to minify and optimize webfontloader.js (externs.js references it); understanding Closure Compiler flags is needed to modify build process.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for lib/webfontloader/modules.rb

The modules.rb file is referenced in the package.json and file structure but has no corresponding spec file in spec/. This is a core file that likely handles module loading logic. Adding tests would ensure reliability of the module system and prevent regressions when adding support for new font providers (Google Fonts, Typekit, Fonts.com, Fontdeck).

• [ ] Create spec/lib/webfontloader/modules_spec.rb
• [ ] Review lib/webfontloader/modules.rb to understand module initialization and loading
• [ ] Write tests for each module registration method
• [ ] Write tests for module dependency resolution if applicable
• [ ] Run full test suite to verify no regressions

Add GitHub Actions workflow to replace Travis CI (.travis.yml)

The repo still uses Travis CI (.travis.yml) which is now deprecated/EOL. The project has a test suite defined in package.json (phantomjs jasmine tests). Converting to GitHub Actions would use modern CI/CD, reduce maintenance burden, and provide better integration with GitHub issues/PRs.

• [ ] Create .github/workflows/test.yml with Node.js and phantomjs setup
• [ ] Configure the workflow to run: npm test on push and pull requests
• [ ] Test the workflow in a feature branch
• [ ] Update README.md build badge to point to GitHub Actions instead of Travis CI
• [ ] Delete .travis.yml once workflow is verified working

Add integration tests for each font provider module (Google, Typekit, Fonts.com, Fontdeck)

The spec/core/ directory has unit tests for core components, but there are no integration tests verifying that each font provider (Google, Typekit, Fontdeck, Monotype/Fonts.com) actually loads fonts correctly. The demo files (lib/webfontloader/demo/public/*.html) suggest these providers are supported but lack automated test coverage. This is critical for a font-loading library.

• [ ] Review lib/webfontloader/demo/public/google.html, typekit.html, fontdeck.html, monotype.html for actual provider configs
• [ ] Create spec/integrations/ directory
• [ ] Add spec/integrations/google_fonts_spec.js with tests for real font loading
• [ ] Add spec/integrations/typekit_spec.js with tests for Typekit API responses
• [ ] Add spec/integrations/fontdeck_spec.js and spec/integrations/monotype_spec.js
• [ ] Update spec/index.html to include new integration specs
• [ ] Ensure phantomjs test runner executes these new specs

• Add test coverage for CSS class name transitions: spec/core/cssclassname_spec.js is minimal. Add tests verifying the correct sequence of class additions (wf-loading → wf-active/wf-inactive) across rapid font loading scenarios.
• Document provider module API: Create an example custom provider module in src/modules/custom/ with inline JSDoc comments showing how new font service providers should implement the loader interface (must return fonts array, fire loading/active events).
• Add missing event-variation tests: The typekit-variations.html demo exists but no spec/core/fontvariation_spec.js covers variable font weight/style selection. Add tests verifying FontWatcher correctly detects loads for 'Open Sans:300,700' syntax.

• High · No devDependencies Specified — package.json - devDependencies. The package.json has an empty devDependencies object. This makes it impossible to verify that the build and test tools (phantomjs, jasmine, closure compiler, etc.) are pinned to specific versions. This could allow supply chain attacks or unexpected behavior from uncontrolled dependency versions during development and CI/CD. Fix: Explicitly specify and pin all devDependencies including test runners, compilers, and linters with exact versions. Use npm audit and npm ci for reproducible builds.
• High · Missing Content Security Policy (CSP) Headers — lib/webfontloader/demo/server.rb. The demo server (lib/webfontloader/demo/server.rb) likely does not implement CSP headers. Since this project loads and executes web fonts dynamically, the absence of CSP makes it vulnerable to script injection attacks and style-based attacks. Fix: Implement strict CSP headers, particularly restricting font-src and script-src directives. Include: Content-Security-Policy header with appropriate directives like font-src 'self' and script-src 'self'
• High · Cross-Origin Resource Sharing (CORS) Not Configured — src/ (entire codebase), lib/webfontloader/demo/server.rb. The library loads fonts from multiple external sources (Google Fonts, Typekit, Fonts.com, Fontdeck). The demo and library do not appear to have CORS handling or validation. This could allow malicious font sources or CORS bypass attacks. Fix: Implement proper CORS validation and only allow fonts from whitelisted origins. Add CORS headers appropriately and validate font sources before loading.
• Medium · Potential XSS via Font Metadata — src/core/ (particularly domhelper.js, webfont.js, font.js). The library processes font data from external sources and likely manipulates the DOM. Without proper sanitization of font names, families, and metadata from external APIs (Google Fonts, Typekit, etc.), there is risk of Stored XSS attacks. Fix: Implement strict input validation and HTML entity encoding for all font metadata received from external sources. Use textContent instead of innerHTML when possible. Validate API responses against expected schemas.
• Medium · Missing Subresource Integrity (SRI) — Demo files in lib/webfontloader/demo/public/ and src/modules/. The library loads external fonts and stylesheets from multiple third-party sources without Subresource Integrity validation. This allows potential MITM attacks or compromised font sources. Fix: Implement SRI checks for all external resources. Provide SRI hashes in documentation and enforce integrity verification for font sources.
• Medium · Insufficient Validation of External APIs — src/modules/ (google, typekit, monotype, fontdeck modules). The library integrates with multiple external font services (Google Fonts, Typekit, Fonts.com, Fontdeck). API responses are not visibly validated against expected formats, which could allow injection of malicious font URLs or metadata. Fix: Implement strict schema validation for all API responses. Whitelist expected font file extensions (.woff, .ttf, .otf, .eot, .svg). Reject unexpected response formats.
• Medium · No HTTPS Enforcement — README.md, lib/webfontloader/demo/public/. The README and code do not explicitly document or enforce HTTPS for font loading. Loading fonts over HTTP could expose users to MITM attacks and font substitution attacks. Fix: Enforce HTTPS for all font sources. Add warnings in documentation. Consider implementing strict-transport-security (HSTS) headers in demo server.
• Low · Missing Security Headers in Demo Server — lib/webfontloader/demo/server.rb. The demo server does not appear to implement standard security headers like X-Content-Type-Options, X-Frame-Options, and X-XSS-Protection. Fix: Add security headers: X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN, X-XSS-Protection: 1; mode=block, Referrer-Policy: strict

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/typekit/webfontloader shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live typekit/webfontloader repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/typekit/webfontloader.

What it runs against: a local clone of typekit/webfontloader — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in typekit/webfontloader | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 888 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of typekit/webfontloader. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/typekit/webfontloader.git
#   cd webfontloader
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of typekit/webfontloader and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "typekit/webfontloader(\\.git)?\\b" \\
  && ok "origin remote is typekit/webfontloader" \\
  || miss "origin remote is not typekit/webfontloader (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 888 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~858d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/typekit/webfontloader"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.