fix(html/parser): fence in html files

[ematipico]

Summary

Closes #9238

Test Plan

Added a test

Docs

N/A

[changeset-bot]

🦋 Changeset detected

Latest commit: 14ceb85

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 13 packages

Name	Type
@biomejs/biome	Patch
@biomejs/cli-win32-x64	Patch
@biomejs/cli-win32-arm64	Patch
@biomejs/cli-darwin-x64	Patch
@biomejs/cli-darwin-arm64	Patch
@biomejs/cli-linux-x64	Patch
@biomejs/cli-linux-arm64	Patch
@biomejs/cli-linux-x64-musl	Patch
@biomejs/cli-linux-arm64-musl	Patch
@biomejs/wasm-web	Patch
@biomejs/wasm-bundler	Patch
@biomejs/wasm-nodejs	Patch
@biomejs/backend-jsonrpc	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 2865cf4b-c24c-48ba-bae5-ed80fed9937d

📥 Commits

Reviewing files that changed from the base of the PR and between c23272c and 14ceb85.

⛔ Files ignored due to path filters (1)

• crates/biome_html_parser/tests/html_specs/ok/dashes_in_element_content.html.snap is excluded by !**/*.snap and included by **

📒 Files selected for processing (3)

• .changeset/fix-html-dashes-in-element-content.md
• crates/biome_html_parser/src/syntax/mod.rs
• crates/biome_html_parser/tests/html_specs/ok/dashes_in_element_content.html

---

Walkthrough

The PR fixes an HTML parser issue where sequences of three or more dashes (---) within element content were incorrectly triggering parse errors. The fix modifies parser state management in crates/biome_html_parser/src/syntax/mod.rs to unconditionally set the after-frontmatter state, removing the previous conditional check. A test fixture validates the fix across various HTML elements including table cells, divs, paragraphs, and spans containing dash sequences. A changelog entry documents the patch-level fix.

Possibly related PRs

• fix(parse/html): don't lex square brackets as special tokens in contexts where they don't mean anything #9150: Modifies HTML parser frontmatter handling with an after_frontmatter flag, directly related to this PR's unconditional state-setting approach for handling triple-dash sequences.

Suggested labels

A-Parser, L-HTML

🚥 Pre-merge checks | ✅ 3 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Title check	❓ Inconclusive	The title 'fix(html/parser): fence in html files' is vague and doesn't clearly describe the actual fix—allowing horizontal line markers ('---') in HTML content.	Consider a more descriptive title such as 'fix(html/parser): allow horizontal line markers in element content' to better reflect the actual change.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description check	✅ Passed	The description references issue #9238 and mentions a test was added, which aligns with the changeset and code changes provided.
Linked Issues check	✅ Passed	The PR addresses issue #9238 by fixing the HTML parser to accept horizontal line markers ('---') in table cells and other element contexts without throwing errors.
Out of Scope Changes check	✅ Passed	All changes align with the linked issue's objective: a changelog entry, parser logic modification, and new test fixture for validating horizontal line content in HTML.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/html-parser-fence

📝 Coding Plan

• Generate coding plan for human review comments

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[codspeed-hq]

Merging this PR will not alter performance

✅ 64 untouched benchmarks
⏩ 152 skipped benchmarks¹

---

_{Comparing fix/html-parser-fence (14ceb85) with main (1302740)²}

Footnotes

1. 152 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

2. No successful run was found on main (c23272c) during the generation of this report, so 1302740 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩