PlainText: Add multiline and isStylable props#18238
Conversation
| onChange={ setTitle } | ||
| allowedFormats={ [] } | ||
| isStylable | ||
| onKeyDown={ preventNewlines } |
There was a problem hiding this comment.
I think instead of onKeyDown here, we might want to align the API with how RichText works, I think it's onSplit or something like that cc @ellatrix
There was a problem hiding this comment.
The difference here is that onSplit is an actual RichText method created for handling a block split, while in this case I'm just passing the native onKeyDown handler through to the textarea element.
There was a problem hiding this comment.
This is another reason why I think it would be better to do this through (Rich)Text. The API's already there, and they would be the same.
| onChange, | ||
| className, | ||
| multiline, | ||
| isStylable, |
There was a problem hiding this comment.
Should this be a prop, or should this be by default? I mean if users of PlainText don't want the styled behavior, they can always use TextAreaAutosize or just set styles on the wrapper? or do you think this behavior is too common to warrant a prop?
There was a problem hiding this comment.
This is a good question.
Mainly, I wanted to affect as little as possible the other components using PlainText, to avoid introducing visual regressions that might be hard to catch.
At the same time, those other components currently use PlainText exactly like a normal textarea (plus the auto-resize, of course)... 🤔
Why not just use an input element? |
you still want the autosize behavior. Not sure how easy/redundunt this would be with an input. |
|
In that case, I'd recommend using RichText without any formatting, which has native autoresizing. Maybe we should consider wrapping it in another component for such use cases. The cool thing would be that you still have access to all other APIs such as splitting, autocomplete text... all without the text formatting. |
That's a great argument, I feel we shouldn't use RichText though as semantically it's about "Rich Text", and using code, you can always pass content with formatted content and it will be rendered as formatted content. It definitely means there's a lot of refactoring needed to extract/share things between a base |
@ellatrix @youknowriad AFAIK there is no way to make an
Yes, I really agree with you, and I argued for this solution at length in this thread: #17207 (review) Though, it is my understanding that the proposed direction though would be to keep things as semantically correct as possible, so I went ahead with a very light implementation of a resizable single-line
To be honest at this point I don't think there is a need for such thing. |
Not necessarily. In a normal text version, we wouldn't allow any formatting.
The way I see it, this wouldn't be a big refactor at all. I'm not sure if I'll find the time right now, but I can try to spin up a PR today or tomorrow. |
@ellatrix I'd be very happy to see that! Let me know if I can be of any help, or just add me as reviewer. 🙇 |
|
#18361 introduces a <Text value="some <b>tags</b>" />will be editable as some <b>tags</b> (normally those tags would be interpreted as formatting) |
|
@Copons should this PR be closed now? |
|
@noahtallen Yes, let's see if the proper |
Description
PlainTextcomponent.multiline: keeps the previous behaviour of allowing line breaks.If not set, it prevents line breaks in two ways: it replaces
\n\rcharacters with spaces, and on press ENTER it insert a new default block instead.isStylable: prepares the textarea to be styled with block attributes (e.g. color and background color).It also set the default background color of the textarea as transparent, to match the editor background color set by the theme.
SiteTitleblock to be a "stylable, single line"PlainText.Code,HTML, andShortcodeblocks (only ones that currently usePlainText) to be multilinePlainText, which is their original behaviour.Notes
isStylablesounds very awkward, I know!I also know that it currently is hard to see its point, but I didn't want to add too much stuff in the
SiteTitlecomponent yet, to avoid making this PR more confusing.Though, its purpose can be tested by adding the
.has-background.has-accent-background-colorclasses (in Twenty Twenty) to the textarea to simulate the background color block attribute.I've chosen to add a backward-incompatible
multilineinstead of something likesingleLineto keep the naming consistent withRichTextetc. Though, I don't have a strong opinion on this, and I wouldn't be opposed to "invert" it.How has this been tested?
Tested on the Gutenberg Docker with the Full Site Experiment enabled.
Checked if the new props caused regressions in other uses of the
PlainTextcomponent.Types of changes
Breaking change
Checklist: