Idle Dom Laravel Package

Product Decisions This Supports

• Build vs. buy for HTML5 DOM manipulation in PHP. IDLeDOM is not a parser or a widget library — it is a set of WebIDL-derived PHP interfaces and traits that model the WHATWG DOM spec (Node, Element, Document, DocumentFragment, etc.). If your roadmap includes rich HTML transformation — wikitext rendering, template expansion, HTML sanitization, content migration, diffing, structured editors — this is the "buy/borrow" answer to "should we write our own DOM abstraction?" You should not.
• Feature scoping: interface layer vs. full stack. Adopting IDLeDOM is a commitment to a stack, not a single dependency. It gives you the contracts; you still need a concrete implementation (e.g. Dodo, as used by Parsoid) and an HTML5 parser/serializer (e.g. RemexHtml). Scope the work as "integrate a DOM stack," not "install a package."
• Use cases where it is a strong fit: server-side rendering pipelines that must produce spec-correct HTML5 trees, content pipelines that need programmatic node mutation with type safety, interoperability with MediaWiki/Parsoid output, and any feature where PHP's ext-dom (DOMDocument) is too lossy for HTML5 (implied tags, foster parenting, malformed markup recovery).
• Roadmap signal: standards alignment as a moat. Because the interfaces are generated from the specification, they are a stable contract. New HTML/DOM spec features can be adopted incrementally, and implementations can be swapped without rewriting product code. That is a multi-year architectural decision, not a sprint decision.
• Tech radar / procurement calibration. The public metrics are misleading: 1 GitHub star, 0 listed dependents, automated score 0.005. This is a Gerrit-hosted mirror of a library that underpins Wikipedia-scale parsing via Parsoid. Treat the score as an artifact of mirror-based development, not as a quality signal — otherwise your dependency-scoring tooling will systematically deprioritize institutional open source.

When to Consider This Package

Adopt when:

• You are building in or alongside the MediaWiki/Parsoid ecosystem — that is the primary, best-supported use case, and matching interfaces buys you interoperability for free.
• You need HTML5-spec-correct DOM behavior in PHP and have already determined ext-dom is insufficient (fragment parsing, node-type fidelity, mutation semantics, serialization round-tripping).
• Your team is comfortable owning integration and implementation choices — you will be wiring interfaces to a concrete DOM implementation and parser yourself.
• You value spec-derived, MIT-licensed contracts over framework-flavored convenience APIs, and you expect the HTML surface area you touch to grow.
• You can accept Gerrit-based contribution (mediawiki.org developer access) rather than GitHub PRs. If your org's policy requires GitHub-native contribution or a vendor support contract, plan accordingly.

Look elsewhere when:

• You just need to scrape or lightly traverse HTML. symfony/dom-crawler, masterminds/html5, or QueryPath-style tools are lower-ceremony and better documented.
• You need a batteries-included parser with a polished public API and a large GitHub community. IDLeDOM deliberately is the abstraction, not the product.
• Your team cannot take on a multi-package stack (interfaces + implementation + parser) or lacks PHP depth to debug node-tree semantics.
• You require predictable release cadence and public issue-tracker visibility tied to a familiar vendor relationship; a Wikimedia-maintained Gerrit project may not satisfy enterprise procurement checklists even though it is institutionally backed.
• Your use case is client-side or Node-based — this is a PHP library and offers no cross-language portability.

How to Pitch It (Stakeholders)

For executives: We are evaluating a small, MIT-licensed PHP library maintained by the Wikimedia Foundation — the interface layer that powers HTML processing behind Wikipedia via Parsoid. It is not a flashy dependency by GitHub metrics, because development happens on Wikimedia's Gerrit rather than GitHub, which makes standard "star and dependent" scoring misleading. The strategic value is that it gives us a specification-derived contract for HTML document manipulation, so we can build content-processing features on a stable foundation instead of a bespoke one, and swap the underlying implementation later without rewriting product code. The main risk is not technical quality but support posture: it is community/institution-maintained with no vendor SLA, so we should treat integration effort as ours and keep a fallback path.

For engineering: IDLeDOM provides WebIDL-generated PHP interfaces and traits mirroring the WHATWG DOM. It does not parse or serialize HTML — pair it with an implementation (Dodo) and a parser (RemexHtml), the same combination Parsoid uses in production. Expect to write adapter code, expect to read specs rather than blog posts, and expect contributions to go through Gerrit. In exchange you get strong typing over the DOM, HTML5-correct semantics that ext-dom does not reliably give us, and a contract stable enough that we can change implementations without touching feature code. Recommendation: spike one pipeline end-to-end (parse → mutate → serialize) before committing, and pin versions given the mirror release flow.