-
-
Notifications
You must be signed in to change notification settings - Fork 52
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
CMS editor improvements #233
Comments
I wrestled with fixing the plaintext fields to stop getting unwanted HTML and encoding artifacts. I thought it would be easiest to just use a regular text input, or more appropriately using a textarea since that's what these fields were made for, but getting this to resize correctly was maddening: <script>
import { onMount } from 'svelte';
export let field;
let textarea;
onMount(async () => {
setHeight();
});
const resize = () => {
setHeight();
}
const setHeight = () => {
//if (textarea.scrollHeight > 30) {
textarea.style.height = 0;
textarea.style.height = (textarea.scrollHeight) + "px";
//}
}
</script>
<textarea
on:input={resize}
bind:this={textarea}
bind:value={field}
></textarea>
<style>
textarea {
resize: vertical;
width: 100%;
box-sizing: border-box;
border: 1px solid gainsboro;
height: 30px;
padding: 6px;
font-family: sans-serif;
font-size: small;
scrollbar-width: none;
}
textarea::-webkit-scrollbar {
display: none;
}
</style> This ^ generally worked, but there was weirdness around loading the appropriate height initially (once set, you could remount the component fine) and the padding caused a slight scrolling effect that was unwanted. So I thought maybe we should stick with the original contenteditable element and <script>
export let field;
const stripHTML = () => {
// Remove HTML here...
}
</script>
<div
class="textarea"
role="textbox"
contenteditable=true
on:input={stripHTML}
bind:innerHTML={field}
></div>
<style>
.textarea {
background: white;
border: 1px solid gainsboro;
resize: vertical;
overflow: auto;
padding: 7px;
font-family: sans-serif;
font-size: small;
white-space: pre-wrap;
}
</style> But that was over-engineering as well. Ultimately doing a simple |
Deletion shouldn't display a popup: https://alistapart.com/article/neveruseawarning/ |
I hadn't thought of using an "undo" function like gmail's undo send extension. It would be easy enough to implement with a timeout function. I had also thought about using a multi-function, dropdown button that defaults to "cancel" instead of "delete." That way someone would have to consciously switch to the delete option before using it. Drupal uses dropdown buttons to group related operations. I'd also like the success / failure on save to be more apparent. Currently the save button flashes "changes committed" or "could not commit changes" but you'd have to be paying attention to even notice. At the very least we could change the button from its default blue to green on success and red on failure to provide a visual queue. |
Release v0.5.24 has:
Remaining items from this ticket:
This still needs to be addressed, I created a separate issue to track progress: #247
I need more details on this, so @stephanieluz if that's still an issue can you please open a new ticket with details
As noted previously, there's already a separate issue for this: #221 |
CMS issues identified by @stephanieluz:
The text was updated successfully, but these errors were encountered: