Open Bug 1291467 (contenteditable-plaintext-only) Opened 8 years ago Updated 15 days ago

Implement contenteditable="plaintext-only"

Categories

(Core :: DOM: Editor, enhancement, P3)

48 Branch
enhancement

Tracking

()

Webcompat Priority P2

People

(Reporter: noms, Unassigned)

References

(Blocks 3 open bugs, )

Details

(Keywords: parity-chrome, parity-safari, Whiteboard: [h2review-noted])

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36

Steps to reproduce:

Chrome, Safari and (recently) Edge now all support `<div contenteditable="plaintext-only">`, to remove formatting from the div contents

Sample JSBin: http://jsbin.com/kaladi/edit?html,output


Actual results:

Cannot paste content at all in a `<div contenteditable="plaintext-only">`


Expected results:

It should behave like a normal `<div contenteditable>`, but formatting should always be removed.
Masayuki-san or Aryeh, who are the right people at Mozilla to CC here?
Hmm, the behavior of <div contenteditable="plaintext-only"> is really different between Edge vs. Chrome.

Looks like that Chrome uses |white-space: pre-wrap;| and inserts "\n" at pressing Enter key. So, this is similar to <textarea> handling in Gecko.

On the other hand, Edge uses |white-space: normal;| (but it's odd, two or more whitespaces are not collapsed!) and inserts <br> at pressing Enter key. This looks like "limited" HTML editor.

I'm not sure what the standardized spec of this feature...

Ojan, do you have draft of this feature?
Oops, and I forgot to reply to your question.

Temporarily, I'm an unofficial module owner of editor. But nobody including me are not working on editor aggressively.
As a user (and I don't know if this is a view that matters), entering "<br>"s instead of "\n"s is preferable because you can get easy single-line inputs by hiding the <br>: http://jsbin.com/sukelu/edit?html,output

Although that demo looks like it works fine in Safari, but on Chrome, the single-line trick only works for the contenteditables that don't have plaintext-only. I will file a separate Chromium bug for that.
We need to wait the decision of W3C which line breaker is "correct" behavior because it's really important difference in Gecko's implementation. If it's different from first implementation, we need to reimplement it again with other feature.
Component: Untriaged → Editor
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → All
We should probably take this in theory, but I don't know if anyone actually wants to do it.  If anyone does it, they should follow the WebKit/Chrome behavior, since that's the original behavior, and ideally write a spec that reverse-engineers that behavior.  It could probably be put in the HTML spec if it needs a home.
Priority: -- → P3
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hmm, now ContentEditable spec said "The state "plaintext-only" is deprecated and its usage is discouraged".
https://w3c.github.io/editing/contentEditable.html#meaning-of-states
I didn't find anything that says plaintext-only for contenteditable is discouraged.

I only saw use of "true" is discouraged.
Flags: webcompat?
Whiteboard: [webcompat]
Whiteboard: [webcompat] → [webcompat-revisit]

See bug 1547409. Moving webcompat whiteboard tags to project flags.

Webcompat Priority: --- → ?
Type: defect → enhancement
Webcompat Priority: ? → revisit
Whiteboard: [webcompat-revisit]
Flags: webcompat?

(In reply to Kagami :saschanaz from comment #11)

Note that plaintext-only is removed from the spec:

Does it mean this bug can be closed with WONTFIX?
Since beforeinput is standardised, the same effect of plaintext-only can be achieved via beforeinput.

(In reply to 張俊芝(ZHANG Junzhi) from comment #12)

Does it mean this bug can be closed with WONTFIX?

Depends on existing web apps. If web apps won't stop using the non-standardized API, we would need to implement it for Firefox users.
(The main issue of plaintext-only is, there are no agreement of what can be called as "plaintext" from point of innerHTML view.)

Since beforeinput is standardised, the same effect of plaintext-only can be achieved via beforeinput.

Well, sorry for the delay to implement beforeinput. I'm still struggling with setting proper target ranges at deletion. You can test our beforeinput event behavior on your own apps with setting dom.input_events.beforeinput.enabled to true in about:config.

Whiteboard: [h2review-noted]
Webcompat Priority: revisit → ?
Webcompat Priority: ? → P3
Severity: normal → S3

The following spec PRs specify the contenteditable="plaintext-only" which is supported in WebKit and Chromium:

(In reply to Howard Edwards [:howard-e] from comment #14)

The following spec PRs specify the contenteditable="plaintext-only" which is supported in WebKit and Chromium:

Unfortunately, the PRs do not standardize the behavior enough...

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #15)

Unfortunately, the PRs do not standardize the behavior enough...

Other than line breaks (LF vs <br>), what should the spec for plaintext-only cover?

I checked the behavior in Chrome roughly now, then, I see only the following commands work, so their definitions are required:

  • Handling steps of Document.execCommand("insertParagraph") (Chrome/Safari handle this command differently from pressing Enter)
  • Handling steps of Document.execCommand("insertLineBreak") (LF vs <br> (Chrome vs. Safari)
  • Handling steps of the commands when caret is in special elements such as <li>
  • Handling steps of Document.execCommand("insertText") (including line breaks causes insertParagraph in both, but I'm not sure it's intended since the behavior looks odd)
  • Handling steps of Document.execCommand("insertHTML") (especially which elements need to be handled as line breaks)

And the other commands (except undo, redo and clipboard commands) should be defined as NOOP (including not deleting Selection).

Duplicate of this bug: 1820187
Webcompat Priority: P3 → ?

Bumping the priority a bit higher because we've now found more implementations that break (see the see-also's)

Webcompat Priority: ? → P2

Am I right in thinking that the open spec issue https://github.com/w3c/editing/issues/419 still blocks the implementation of this bug?

Flags: needinfo?(zcorpan)
Flags: needinfo?(masayuki)

Yes and no. No standardized spec blocks us to implement this, and there are too few tests. Additionally, the examples in the issue may not all of what should be standardized.

Flags: needinfo?(masayuki)

Yeah I think we can plan to implement. The spec issue should be fixed but it seems relatively easy.

Flags: needinfo?(zcorpan)
Alias: conternteditable-plaintext-only
Alias: conternteditable-plaintext-only → contenteditable-plaintext-only
You need to log in before you can comment on or make changes to this bug.