Skip to content
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

[EuiMarkdownEditor] Add readOnly prop #5627

Merged
merged 22 commits into from
Feb 23, 2022

Conversation

elizabetdev
Copy link
Contributor

@elizabetdev elizabetdev commented Feb 10, 2022

Summary

Closes #5129. This PR adds a readOnly prop to EuiMarkdownEditor.

Initially, I started this PR by adding an isDisabled prop. But after some discussion, I decided to add a readOnly prop instead. The reasoning for this decision can be found in the following comment: #5627 (comment).

Design

markdown-editor-read-only@2x

Checklist

  • Check against all themes for compatibility in both light and dark modes
  • [ ] Checked in mobile
  • Checked in Chrome, Safari, Edge, and Firefox
  • Props have proper autodocs and playground toggles
  • Added documentation
  • [ ] Checked Code Sandbox works for any docs examples
  • Added or updated jest and cypress tests
  • [ ] Checked for breaking changes and labeled appropriately
  • Checked for accessibility including keyboard-only and screenreader modes
  • A changelog entry exists and is marked appropriately

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_5627/

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_5627/

@chandlerprall
Copy link
Contributor

@miukimiu I pushed a small change that makes the checkbox plugin respect your isDisabled context

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_5627/

@elizabetdev elizabetdev marked this pull request as ready for review February 15, 2022 13:47
@elizabetdev
Copy link
Contributor Author

Thanks, @chandlerprall for helping with the issue with the checkboxes not getting disabled.

I have another question. How should we handle the isDisabled state for custom plugins? For example, in our custom plugin (https://eui.elastic.co/pr_5627/#/editors-syntax/markdown-plugins), the consumer application could use CSS and apply an opacity by targeting .euiMarkdownEditorPreview-isDisabled .myCustomChartPlugin

Screenshot 2022-02-15 at 13 50 14

But we can have more complex plugins that the consumer would need to get the state because not always just CSS would work. Like in the checkboxes plugin for example where we got the isDisabled state from EuiMarkdownContext.

When creating plugins is this state exposed so that consumers can get it? Do we need to expose it? And how do we document this?

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_5627/

@cee-chen
Copy link
Contributor

cee-chen commented Feb 15, 2022

I haven't looked super closely at this PR at all but just wanted to suggest something potentially very dumb.

Why not cover the entire editable contentarea of the editor with an overlay div of the same background color as the editor and a 50% opacity? This serves the following:

  1. No need to set manually set any child plugins to any kind of opacity. The overlay takes care of it (edit: would also solve the linked emoji problem)
  2. Blocks mouse clicks entirely, no need to dive into every single child to make sure they are also disabled or uninteractive

This may need some extra finagling to ensure that the underlying editor is inaccessible to keyboard/screen reader users, but for visual and mouse users it should work 🤷‍♀️

EDIT: If an overlay div is too basic we could also look into CSS filters

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_5627/

@elizabetdev elizabetdev marked this pull request as draft February 16, 2022 16:28
@elizabetdev
Copy link
Contributor Author

elizabetdev commented Feb 16, 2022

Thanks, @constancecchen for suggesting the overlay div.

I changed the PR back to draft. Based on our weekly sync discussion I decided to add a readOnly prop to the EuiMarkdownEditor instead of an isDisabled prop.

For our use case "adding a comment", we just want to restrict editing but users should be able to read properly what they wrote once they post the comment.

If we decided to add an isDisabled prop the styles would make the text grayed out. This would make users not see properly what they are submitting.

But how do we notice that editing is restricted?

In editing mode, all toolbar and footer buttons get disabled. This would make it more visible to users that the editor is in a different state and no more editing is possible. The textarea gets a readonly attribute. Visually the textarea looks the same, but the content cannot be changed.

read-only-editing@2x

In previewing mode the toolbar buttons are already disabled. The only difference from a normal state is the editor mode button gets also disabled. All the rest look the same.

Components that allow changing the content like checkboxes should not be clickable. Plugins that can modify the content, should implement their logic to respect the readOnly state. @chandlerprall is going to expose this readOnly state to use in plugins.

read-only-previewing

This can be tested in https://eui.elastic.co/pr_5627/#/editors-syntax/markdown-editor. The logic for the checkboxes plugin in previewing mode is not implemented yet. For now, they just get disabled.

Any thoughts on this new approach?

@elizabetdev elizabetdev changed the title [EuiMarkdownEditor] Add isDisabled prop [EuiMarkdownEditor] Add readOnly prop Feb 16, 2022
@@ -32,3 +32,13 @@
background-size: 100% 100%;
}
}

.euiMarkdownEditorTextArea-isReadOnly {
cursor: default;
Copy link
Contributor Author

@elizabetdev elizabetdev Feb 16, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This cursor: default is following our EuiTextArea styles. But I'm not quite sure is really necessary... If we can copy the text shouldn't we keep the cursor that a textarea gets by default cursor: text;?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When hovering on an enable textarea, the cursor everywhere is text indicating it is enabled and to click anywhere to insert text. The default cursor overrides this behavior to try to indicate that you can no longer edit by showing the arrow cursor everywhere. What we probably want to do instead is cursor: unset; which defaults back to the browser's behavior of arrow cursor until hovering over text. I checked this specifically on our EuiTextArea and it works the way I'd expect, but I didn't check the Markdown editor.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The EuiTextArea and other form controls when in readOnly get a cursor: default;:

@mixin euiFormControlReadOnlyStyle {
cursor: default;
// Use transparency since there is no border and in case form is on a non-white background
background: $euiFormBackgroundReadOnlyColor;
border-color: transparent;
box-shadow: inset 0 0 0 1px $euiFormBorderDisabledColor;
}

But almost every browser behavior when in readOnly gets a cursor: text;. This cursor indicates that the text can be selected (https://developer.mozilla.org/en-US/docs/Web/CSS/cursor).

So I'm just adding this cursor: default; because I'm following the pattern of our EuiTextArea. Is this the behavior we want to maintain?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right so, we probably want to align better with browser's innate use of cursor. If we're using the HTLM property readonly which applies the pseudo class :read-only we shouldn't have to change the cursor. You can undo our non-readonly cursor by just reverting it back to the browser's default via cursor: unset. But I can't be positive that all uses of the mixin is in fact applying the readonly property directly.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we can copy the test shouldn't we keep the cursor that a textarea gets by default cursor: text;?

Agreed. It feels weird with this set to default

@chandlerprall
Copy link
Contributor

Changed the replaceNode and openPluginEditor functions, which are given to plugins, to do nothing when in read only mode.

I played with the checkbox styles some but didn't like anything, and I couldn't find an established pattern anywhere around what a readonly checkbox should look like - best I came up with was cursor: default to remove the visual indication that it's clickable.

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_5627/

@elizabetdev elizabetdev requested a review from i-a-n February 17, 2022 12:54
@elizabetdev elizabetdev marked this pull request as ready for review February 17, 2022 13:07
@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_5627/

@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_5627/

Copy link
Contributor

@i-a-n i-a-n left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just wanted to say from a UI/UX standpoint I really like it, and it solves our use-case perfectly 👍

Copy link
Contributor

@cchaos cchaos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Visually & functionally everything works great. Had a couple code & docs suggestions.

Comment on lines +79 to +85
<EuiFlexItem grow={true}>
<EuiSwitch
label="Read-only"
checked={isReadOnly}
onChange={onChange}
/>
</EuiFlexItem>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I highly suggest adding a sentence about the use of this prop to the text of this example. Maybe explaining, that if the consumer needs to disallow editing while submission is happening, then they should manually update this prop.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think of this text?
Base editor@2x

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like it! I just have a quick suggestion to tighten up the language.

src/components/markdown_editor/markdown_editor_toolbar.tsx Outdated Show resolved Hide resolved
@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_5627/

Copy link
Contributor

@cchaos cchaos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

Comment on lines +79 to +85
<EuiFlexItem grow={true}>
<EuiSwitch
label="Read-only"
checked={isReadOnly}
onChange={onChange}
/>
</EuiFlexItem>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like it! I just have a quick suggestion to tighten up the language.

elizabetdev and others added 2 commits February 23, 2022 15:17
Co-authored-by: Caroline Horn <549577+cchaos@users.noreply.github.com>
@kibanamachine
Copy link

Preview documentation changes for this PR: https://eui.elastic.co/pr_5627/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[EuiMarkdownEditor] Enhancement request: Disabled state
6 participants