Remex Html Laravel Package

Product Decisions This Supports

• Build vs. buy on HTML handling. Writing a spec-compliant HTML5 tokenizer and tree builder is a multi-year, tens-of-thousands-of-lines effort that tracks a moving spec. This package converts an entire category of "we need to understand messy HTML" roadmap work into a composer dependency. Any feature that ingests, transforms, or renders third-party or user-generated HTML should default to leverage rather than build.
• Feature decisions enabled: content ingestion from CMS exports, scraped pages, or customer-supplied HTML; text/link/metadata extraction for search indexing or RAG pipelines; HTML normalization for diffing or version comparison; tolerant fragment parsing for user-authored widgets and rich-text fields; email-to-web or web-to-plaintext rendering; accessibility audits (heading order, alt text, landmarks) and content QA rules layered on the parse tree.
• Sanitization and trust-boundary decisions. Because it is spec-correct with error recovery, it gives you a reliable "what the browser will actually build" tree — the right foundation before you apply an allowlist policy. Note the package parses; it does not sanitize. Budget for the mutation/allowlist layer explicitly; do not market it internally as a security control on its own.
• Roadmap sequencing. Lower-level API (tokenizer, tree builder, serializer as separate pieces) means you can ship a read-only analysis feature first and defer write-back/serialization, or vice versa. That supports incremental delivery rather than a big-bang HTML subsystem.
• Adoption/expansion signal to weigh: 12 stars, 0 dependents, adoption score 0.09 vs. opportunity 43.75. Read that as underserved need in the PHP ecosystem rather than immature library — this is a read-only GitHub mirror; canonical development and issue tracking live on Wikimedia Gerrit/Phabricator, and the real dependent is MediaWiki itself. Low GitHub numbers are a distribution artifact, not a quality signal. The real risk is ecosystem ergonomics, not correctness.

When to Consider This Package

Adopt when:

• You must parse real-world, malformed, or adversarial HTML the way a browser would, including implied tags, foster parenting, and fragment parsing.
• You need parse-error reporting or source position tracking — e.g., linting, authoring feedback, or pinpointing where a transform broke markup.
• You need a pluggable tree (build into your own node objects rather than DOMDocument) or fine-grained control over serialization output.
• You are already in or adjacent to the MediaWiki/Parsoid ecosystem, where it is the native choice.
• Your workload is request- or job-scale, not bulk — per-document parsing happens in tens of milliseconds, which is fine for page renders and queued jobs.

Look elsewhere when:

• You only need to parse well-formed or near-well-formed HTML into a DOM — DOMDocument::loadHTML or masterminds/html5-php gets you there with a friendlier API and vastly larger community footprint.
• You need CSS selectors or XPath ergonomics out of the box; plan to pair with symfony/css-selector or ext-dom, and account for that glue work in estimates.
• You are doing high-volume batch parsing (millions of documents, tight latency SLOs) — pure-PHP parsing is the bottleneck; benchmark against ext-dom/libxml or an out-of-process Node parse5 worker before committing.
• Your team cannot absorb a low-level, low-documentation, small-community API or is uncomfortable with Gerrit/Phabricator contribution and support workflows instead of GitHub issues and PRs.
• You need a turnkey sanitizer with a maintained policy engine — use a dedicated sanitizer and treat this as an optional parser backend.

Adoption checklist: pin a version and verify PHP 8.x support on your target release line; confirm the transitive dependency footprint; write a thin internal wrapper interface so you can swap to masterminds/html5-php if needed; add a fixture corpus of your own worst-case HTML to your test suite, since that corpus is your real compatibility contract.

How to Pitch It (Stakeholders)

To executives: This is the HTML5 parser built and maintained by Wikimedia engineering — the organization that has spent two decades processing some of the most hostile, malformed, user-edited HTML on the internet. Adopting it lets us ship content ingestion, extraction, and HTML transformation features in weeks instead of quarters, and it eliminates a whole class of "our parser disagreed with the browser" production incidents. MIT licensed, no vendor lock-in, no licensing cost. The main trade-off is that it is infrastructure, not a product: it hands us a correct parse tree, and we own the policy layer on top. That is exactly where we want our engineering investment, because that is where our product differentiation lives.

To engineering: Spec-compliant tokenizer and tree builder, separable serializer, parse-error and source-position support, pluggable tree construction so we are not forced into DOMDocument. It is the parser behind MediaWiki, so correctness under real-world markup is proven. Costs: the API is low-level and you will write visitor/traversal code; community support happens on Gerrit and Phabricator, not GitHub; and pure-PHP throughput means we benchmark before we put it on a hot path. Mitigation: wrap it behind our own parser interface, add a golden-file test corpus now, and keep masterminds/html5-php as a documented fallback. Do not treat low GitHub stars as a health signal — this repository is a mirror.