-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PlainText: Add multiline
and isStylable
props
#18238
Conversation
placeholder={ __( 'Site Title' ) } | ||
value={ title } | ||
onChange={ setTitle } | ||
allowedFormats={ [] } | ||
isStylable | ||
onKeyDown={ preventNewlines } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
PlainText
component.multiline
: keeps the previous behaviour of allowing line breaks.If not set, it prevents line breaks in two ways: it replaces
\n\r
characters 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.
SiteTitle
block to be a "stylable, single line"PlainText
.Code
,HTML
, andShortcode
blocks (only ones that currently usePlainText
) to be multilinePlainText
, which is their original behaviour.Notes
isStylable
sounds 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
SiteTitle
component yet, to avoid making this PR more confusing.Though, its purpose can be tested by adding the
.has-background.has-accent-background-color
classes (in Twenty Twenty) to the textarea to simulate the background color block attribute.I've chosen to add a backward-incompatible
multiline
instead of something likesingleLine
to keep the naming consistent withRichText
etc. 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
PlainText
component.Types of changes
Breaking change
Checklist: