It makes intuitive sense to write up multiple lines, select them and then try to convert them to a list. We should add that option to the paragraph menu.

It would also make sense to also allow "*" to make lists, like we do for "-"

We tried to make the editor work with a fixed position when in focus. We ran into a lot of issues and we're going to try a different approach:

• Get rid of the fixed positionning
• Sticky menu on top when editing
• Sticky menu stops sticking 1 line from end
• Browser testing (also test on real devices)

Updated spec 2018-06-06:

• No sticky embed menu for now, just leave it on the bottom
• Try and only show header on scroll down (start off absolute top 0)
  • Start with header showing
  • Listen to scroll and if scroll up, menu is position fixed
  • When scrolling down, we position absolute, with top being its location when we changed direction and it'll scroll out of view normally
• Make utility class so we can use it on client headers too
• If we need animations to make it less "jankey", make it snappy

Things to keep in mind.

• Do we want automatic link transforms.
• Should the user be able to edit the links afterwards.
• Should the we automatically format links that are pasted in.
• Should command k automatically transform a link into its contents (if it matches a link), or just prefill the box (prefill the box is the current behaviour).
• Should editing the text content of a link with an identical href change both?

I was going to use the separate embed issues we had, but those have been closed. So I'm editing this issue to contain changes for the

• Fix any issues with embeds we have
  • Twitter
  • Youtube
  • Instagram
  • SoundCloud
  • Imgur
  • Giphy
  • Getty
  • Twitch
  • Vimeo
  • Generic Link
  • Wistia
• Refactor classes to be consistent
• There are still width issues with external embeds and their width. I think there's a clash with styles for embeds that are not just a straight URL.

The inline menu shows up when you have selected text and should remain open if you select an option from the inline menu. It's weird to need to reselect it. The user may want to select bold and italic in one shot. It may also be confusing to not see the menu anymore.

• Hover: is background color
• Focus: is darker background color
• Selected: is brand FG color (opacity: 1)
• Change padding on sides of editor
• Match @mention "select" style to hover/focus styles
• pointer events none of "nub"
• Copy changes from Todd's PR: vanilla/vanilla#7551
• Hover has lower priority than focus
• Get rid of "nub" for paragraph menu
• Open for paragraph menu user lighter version of fg color
• Add max-height on @mention
• background on emoji buttons need to take the full 36px
• 36px for toolbar buttons (bottom), icons 24px
• 36px for emoji header and for emoji footer
• Variable size for "free floating" button (paragraph menu - 28px)
• Border radius for buttons, excludes "menu" buttons , i.e. paragraph/inline/emoji groups
• Active buttons get own class, and get the same as "active" styles
• Do variations with mixin for open styles
• Remove last of hard coded variables

FocusModule.getEmbedBlotForFocusedElement() should be using a utility class. Right now it is not clear that using the embed class nested inside of an embed will break keyboard handling.

When you load the page, the "insert" button is disabled. It gets enabled if you put in a valid url. However, if you open the flyout again, it doesn't get reset to be disabled.

We want to have proper styles for the hover/focus states in the rich editor.

Also check compatibility with other themes.

We do not currently clear the comment box after a comment is posted.

We did some changes to the loaders and errors. Although they work, the class names need to be refactored and split into a few partials.

Currently the error/warning/loading states for external embeds are not recoverable. Your link is immediately removed and replaced with a large loader and a large error if an issue was encountered.

These states should be inline, appearing next to (on the left/right to be determined) of the link. The link should always be visible until a successful state is reached.

Loading/Warning/Error

• Displayed inline next to the link
• The link is treated as an embed (all focusable/deletable at once).
• Do not appear in the rendered document. These are in editor only.

Warning states

The warning states are all recoverable errors. This is usually an error related to a user's specific browser. All of the data needed for the post has been fetched, but the current user making the post is able to render all of the rich content. In this case we want the user to still be able to make the post, but know that the contents may appear differently for a user a of a more permissive browser.

• If the user's browser (or an ad blocker etc.) blocks the loading of an external script needed to display the rich content (eg. twitter, instagram). Scripts like these are automatically blocked in Firefox and Safari due to privacy concerns, but are not blocked in chrome and likely will not be for the foreseeable future.

Error states

Error states are 100% failures an are not recoverable. These need to be resolved and should block the post from loading. Ideally the error state should have a button to retry the action or dismiss the error. These should block the form from being submitted.

• API request failed to complete (for an external embed).
• Image upload failed.

Currently the embed insertion module will insert embeds in the incorrect position, particularly if the cursor is positioned multiple lines down the document. I believe this is due to some poor math when calculating the insert position.

Additionally new embeds seem to be focused at the wrong.

Currently They get focused only when they are finalized

They should Only get focused when they are first created. If the user's cursor is somewhere else when a blot finalizes, it should be be left alone.

• Add unit tests for the various additional functions and behaviours in the modules
• Pay additional attention to issues that may pop up from embed insertion in when a post is edited or reloaded from a draft. I've split this issue in two. The new issue for this part is here #78

Looks like the twitter embed expects to always get a post, but someone could be sharing a user page.

Example: http://twitter.com/vanilla generates: "Attempted to embed a tweet but the statusID could not be found"

It should fallback to just a regular url embed.

It seems odd to me that we can input e-mails as embeds and it validates. Looks like the @ and everything before gets stripped.

Steps to reproduce:

• Write something else and then your code inline.
• select your code and change the style to "code".
• Try to get out of the "code" style (I this case I tried with "space", "enter", "esc"...nothing works)
  The only thing that worked was to hit enter and select "paragraph" styles again. (not very accessible)

Btw, earlier today I selected the "code" style by mistake and wanted to unselect but it doesn't unselect if you click again on the same option. idk if this is a behaviour it wasn't implemented on purpose but I find myself doing that a lot whenever I want to unselect something.

Quill's built in list-item needs to be modified to allow our combobox as a child.

Just add formats/list-item here https://github.com/vanilla/rich-editor/blob/master/plugins/rich-editor/src/scripts/quill/index.ts#L82-L88.

It's not really useful to have the plain paragraph style be the first option in the paragraph menu. Let's bump it to the last element on the list.

Since it also behaves differently than the rest of the styles, we should either disable it or hide it when it is plain text. If we take the heading for example, clicking the heading once makes it a heading, hitting it again removes the heading. The paragraph doesn't "undo" like the other styles, so it should be handled differently.

Twitter embeds (and maybe others) don't work at all in safari and Firefox.

In the Firefox the main cause I'm seeing is the twitter script being blocked entirely from loading because tracking protection is enabled by default.

• Firefox properly throws an error.
• Safari silently blocks the script.

This might also be an issue with ad blockers.

After talking with @tburry the solution will be as follows:

• All embed link transformations will display as a normal link, but with either a small inline loader or warning next to them if they are faulty. Initially these will still be be "embed" elements that get deleted all at once.
• A successful embed state will still be the same.
• On hover on the warning icon, a message similar to this will be displayed: "The embed script failed to load in your browser."
• Ensure we can properly handle errors in safari. This might take the form of a much shorter timeout. Currently the timeout is 30s.

They get stuck forever in a loading state. This fix will need to occur in the ExternalEmbedBlot. It is likely because the data format is different after being finalized, then when being created.

Unit tests are needed for this, as well as a utility function to convert back finalized data to a "loadable" form.

On the staff forum while writing a post, I highlighted 3 words in the middle of a paragraph sentence and the inline formatting menu appeared. I clicked the last option, the link icon, and that caused the menu to disappear. Nothing further happened. Repeating the tasks had the same outcome each time.

Firefox 61

For the mobile view, we want to close the "full screen" mode when the tab goes out of the full screen.

We need to properly detect the tab focus going off (either tabbing up, or down). We can't rely only on the editor focus, because we want to include the embed buttons as well and the embed flyout.

We also need to worry about embedded elements, they can get focus. I add a "isFocused" class on the editor when we get focus. There's some work needed for that to be always accurate.

We want to the user to be able to easily create text space after a block at the bottom of the document. After assessing the situation the simplest scenario I could think of is.

Add a click listener on the document. Then:

1. Get the last blot in the document.
2. If top level container is anything but plaintext (Block) such as quote, spoiler, code, embed, header, etc.
3. Get the Y coordinate of the last blot in the document.
4. If the Y coordinate of the click was below that point:
5. Create a newline at the end of the document.

Twitter embeds aren't centered in the editor.

Also, there's an issue with the focus style of the editor in FireFox.

External site embeds.

When you have an inline code block, you can't keep typing on the same line. You need to make a new line, and delete the new line. Once you've deleted the new line however, there's no way to add a space between the inline code and the plain text. You either go inside the code block or after the first letter.

As a user, I think we expect there to be a possible cursor position outside an inside the code block. You should be able to arrow or click outside the code block and keep typing.

Our Getty and Imgur styles are responsive, but the focus area is bigger than the contents. We need to get the height and width info from the scraper and use the same technique we use for giphy embeds.

I also noticed a max-width issues with:

• Giphy
• Plain images

The mobile keyboard causes a lot of problem for the editor's mobile view.

On android it's not too bad, but it does overlay our "full screen" editing mode. For the first iteration, I moved the menu up top to solve this issue. It works ok, but further testing needs to be done on various devices.

An iOS it's not good. The viewport seems to be off the first time it loads (tested on latest iPhone X). It fixes its self if you rotate the phone to landscape and back again. The keyboard does not adjust the viewport either.

If we are to allow inline styles, they're in conflict with the native menu for copying and pasting.

We currently support enabling/disabling of image/video upload. Additionally we should look into a prop driven approach to enabling/disabling.

• Embeds
• Particular embeds
• Mentions?
• Emojis?

The bottom toolbar should hide if it is empty as well.

Similar types of changes would also need to be implemented on the server side.

From @tburry vanilla/vanilla#7162

Page up/down in emoji list jumps around

Priority: low

Steps to reproduce

1. Open the emoji editor.
2. Hit tab to make sure your cursor is in the editor.
3. Page up/down with cmd-up or cmd-down.
4. The cursor jumps to a different column each time.

I'm okay leaving this one, but if it's possible to make the cursor jump a multiple of the column count so that it stays in the same column I think that would look better. Only do this if you already coded the page up/down amount and it isn't just built in.

My notes

The jumping being incorrect seems to some bad math. This is actually a regression because this was explicitly programmed.

On the staff forum using Firefox, I authored a post in the following format:

Paragraph
Paragraph
Unordered List
Paragraph
Paragraph

The first paragraph after the unordered list appeared correctly in the editor. However, upon posting, the same paragraph was added to the unordered list as a new bullet point. Editing the post revealed the same formatting as when I was authoring the post (showing the paragraph correctly, not part of the list).

#54 leaves behind a partially styled "loading" mention. Coordinate with @tburry to find out exactly what we want it to look like. It should be easy enough to force it to display by changing the showLoader prop.

I would like, moving forward, that all our HTML passes W3C validation. I noticed that vanilla uses a non standard "format" attribute on textareas. This is invalid HTML. Any custom attributes need to be prefixed with "data".

Our flyouts are pretty complicated and hard to understand currently. We should do some refactoring. I like the way we handled the flyouts in our base theme prototype. The "dropdown" component takes 2 components, 1 for the contents of the toggle button and the other for the contents of the flyout.

It's true that our flyouts aren't always that style in the editor. We've got some special positioning, but I think we can simplify

We should be hiding the preview button in ours forms. It really isn't necessary when we have the input/output looking identical (including embeds).

Steps to reproduce:

1. Open Embed popover
2. Open Emoji Popover

The embed popover doesn't close.

This issue is to keep track of questions we have for the editor's accessibility.

• Normal typing/editing
• inline menu
• paragraph menu
• Embed flyout
• Various embeds (twitter, youtube, etc)
• Embed Errors
• Embed Focus handing
• @mention (does it read as combo box, is it usable?
• Emoji picker

We currently show our link menu only if there is a selection.

An example from another product (my cursor is in the link, but I have no selection made).

This could be easily implemented by changing the conditions in the InlineToolbar. The utility rangeContainsBlot(LinkBlot) would simplify this.

Send notifications for our new mentions.

Requirements

• Sends notifications everywhere our existing mentions send notifications
  • On comment save.
  • On discussion save.
• Does not send notifications for mentions that are inside of blockquotes.

Tips

Look for usages of getMentions in functions.general.php.

We need to rework a bit the position of the inline menu for large selections. Sometimes it stays in a place that blocks part of the selection from view. We should also consider huge selections, where the menu could be off screen. Maybe we want to implement some type of "sticky" position if it goes offscreen.

#4 implements link->embed transforms when typing enter at the end of a line containing only a valid link.

After talking with @tburry

On paste

• It's pasted onto an empty line with no formatting

• It's a valid link

• Transform into and embed

• It's a valid link

• Anywhere else but a code block, or inline code

• Transform into a normal link

On keydown

On enter

• If the text before the cursor is a plaintext node or a link node
• The previous text is a valid URL
• Transform that text or link into an embed.

Steps to reproduce

1. Create a post with the following delta:

[{"insert":"Block code Block"},{"attributes":{"code-block":true},"insert":"\n"},{"insert":"    Block Code Block"},{"attributes":{"code-block":true},"insert":"\n"},{"insert":"    Block Code Block"},{"attributes":{"code-block":true},"insert":"\n"},{"insert":"Block code block"},{"attributes":{"code-block":true},"insert":"\n"},{"insert":"\nInline "},{"attributes":{"code-inline":true},"insert":"code block"},{"insert":" inline\n"}]

2. Edit this post
3. Place cursor on the empty line between the code block and the paragraph

(First odd thing: the paragraph style in between is set to code, and yet when I type, it's paragraph)

4. Copy the contents of the code block here: https://docs.vanillaforums.com/developer/addons/theme-hooks/#example-themehooks

5. Paste code between code block and paragraph.

Result:

This is the result, which is odd:

Trying to undo also breaks and gives the following result:

Expected Result

I don't expect the paragraph style to be code in between the code block and the paragraph.

After pasting, I would expect plain text, or the whole thing to be detected as being in a code block (if possible, but really not necessary).

I expect to be able to undo the paste.

We still have a few spacing and height issues with embeds from last sprint.

There's also likely tweaks to be done for new embeds this sprint.

If you click anywhere in the red area in the screen shot, it closes the flyout. It shouldn't. You should be able to click inside flyouts.

While embeds are in the editor, we don't want to be able to click inside them. We want to allow clicking on them, but only for deleting or copy/paste type operations.

The twitter embed has a style, but we should have a generic solution for that.

Also, don't allow border on embeds once they've been posted. It should only be for the edit mode.

We never did any testing with e-mail notifications from rich editor posts.

@adrianspeyer reported an issue with images leaving big gaps... We may need a simplified rendering of embeds for e-mails.

We should get this up on the test cluster so that people can test it out during this sprint. That way we can have a bit of internal feedback before release.

• Setup on the test cluster
• Configure test cluster theme
• Configure welcome post on the test cluster
• Add template to this post https://app.zenhub.com/workspace/o/vanilla/vanilla/issues/7162

Not as an immediate priority, but I think we should organize this project so that it can be structured to be used without a "full" vanilla install. I'd like to use it in a side project I'm working on and could do a lot of the restructuring myself.

A few things that would need to be changed:

• Remove the last few references from the editor that require vanilla's exact current for structure to load.
• Pull many of the utilities from vanilla used here into an npm package. Anything imported from @dashboard/ will need to either be moved into an npm package or move to this repo. Much of the code can still live in the vanilla/vanilla repo but would need to be packaged properly.
• Move code from \Vanilla\Quill and \Vanilla\Embed into this repo. These would then be published through packagist for consumption in vanilla/vanilla.
• Ensure translations can be passed in as a prop.
• Document setup and integration (props for the Editor component).
• Document registering embeds.

The metaKey + K keyboard shortcut is no longer opening the link menu. This deserves a unit test to go with it.

Update

After doing some work on this, there are some deeper issue with the inline menu not reflecting link changes immediately.