fix: treat contenteditable="plaintext-only" as editable

[cpruijsen]

What

Treat contenteditable="plaintext-only" as an editing host so user.type() and the other edit/focus paths that share the same checks insert text the same way they already do for contenteditable="true" / contenteditable.

Fixes #1197.

Why

The HTML spec lists plaintext-only as a contenteditable keyword. An editing host is an element in the true or plaintext-only state. jsdom does not implement HTMLElement.isContentEditable, and this library's polyfill only treated true and the empty attribute as editable, so type() clicked a non-focusable node and never dispatched input.

How

• Extend isContentEditable() with the plaintext-only attribute value.
• Include [contenteditable="plaintext-only"] in FOCUSABLE_SELECTOR so click/tab focus the host.
• Resolve the editing host in getContentEditable() by walking ancestors with isContentEditable() so the allow-list lives in one place.

Walk with isContentEditable instead of adding a third element.closest('[contenteditable="plaintext-only"]'). Chained closest() returned a farther ancestor instead of the nearest editing host, which affected contenteditable="true" as well as plaintext-only. Both are covered by tests.

Enter on plaintext-only reports insertLineBreak. A plaintext-only host has no paragraphs to break, and editContenteditable inserts \n for either inputType, so this corrects the reported type rather than the content.

Checklist

• [N/A] Documentation (no API change)
• Tests
• Ready to be merged

[snowystinger]

Thanks for the PR, can you provide a test for

Chained closest() can return a farther true ancestor instead of a nearer plaintext-only host

I imagine it'd be something like this setup

<div contenteditable="">
  <div contenteditable="true">
    <span>

It'd also be good to include a paste test for "plaintext-only".

Enter on plaintext-only still uses insertParagraph (same as contenteditable="true"). No plaintext-only special case for insertLineBreak. Can add that as a follow-up.

I don't think this should be follow-up, code will start going through here as soon as it's released, so we should have this complete before releasing. I can take a look later if you don't have time.

[cpruijsen]

Pushed the tests and the Enter change in 1c33ed9.

The chained closest() case fails on contenteditable="true" too, not only plaintext-only: closest('[contenteditable=""]') matched a farther ancestor before the nearer host was considered. The test covers both values.

For Enter I went with insertLineBreak on plaintext-only rather than asking which browser to follow. A plaintext-only host has no paragraphs to break, and editContenteditable inserts \n for either inputType, so this corrects the reported type rather than the resulting content.

[snowystinger]

For Enter I went with insertLineBreak on plaintext-only rather than asking which browser to follow

Ah, didn't realise it was a difference between browsers. Does the spec say anything more official? The other way would've tried to insert a <br />? that shouldn't be a difference between browsers.
What would be the followup here?
Thanks for your patience with my questions, just trying to make sure I understand what's going on here.