We are currently experiencing payment processing issues. Our team is working to resolve the problem as quickly as possible. Thank you for your patience
Tiny bugs (nesting, wysiwyg editor, etc.)
0
Hey,
after perusing the search function as usual, and nothing turning up, I made this little thread of abysmally tiny, and low-profile bugs.
1. Nested spoilers
CURRENT BEHAVIOR:
When nesting spoilers, the nested spoilers break, making it impossible to use them.
EXPECTED BEHAVIOR:
When nesting spoilers, they form a set of spoilers residing within each other, akin to nested quotes. This use case might seem purely academic and hypothetical, but I found myself wishing for that functionality repeatedly. For example: One might want to spoiler a piece of text, and within that, an array of images.
PROOF CONCEPT:
{spoil}this {spoil}is {spoil}a {spoil}spoiler {/spoil}{/spoil}{/spoil}{/spoil}
2. {URL} wrap-around
CURRENT BEHAVIOR:
When inserting a hyperlink by marking a piece of text, then hitting the "insert URL" button in the editor, the editor prompts 2 input alerts; one for the URL (expected), one for the page name (unexpected). The resulting url-tag is then wrapped around the text entered in the page name query, not around the marked text. There is no way to cancel the second query (cancelling it will yield the error "You have not entered the page title", and aborts the entire process), or to otherwise ensure that the link is wrapped around marked text.
EXPECTED BEHAVIOR:
When inserting a hyperlink by marking a piece of text, then hitting the "link" button in the WYSIWYG editor, the "page name" query is either omitted, or can be cancelled, resulting in the link being wrapped around the marked text. Formatting tags (bold, italics, etc.) already behave this way. For posts where a lot of links are to be inserted after writing out the text, this would increase usability.
PLATFORMS:
All tested browsers (firefox, safari, ie, ...)
3. Tag insertion in mid-text
CURRENT BEHAVIOR:
When inserting a tag in the middle of a post, using one of the editor's buttons, without marking any particular piece of text to wrap the tag around, tags are not being inserted at the cursor position, but at the end of the post.
EXPECTED BEHAVIOR:
When inserting a tag in the middle of a post, tags are being inserted at the cursor position. This is especially useful when working with posts that involve a number of quotations, when inserting images after post composition, etc.
PLATFORMS:
All tested browsers (firefox, safari, ie, ...)
I'm well aware that this is probably nit-picking and these are all extremely low-profile bugs, but figured it might be worth a quick fix at some point in the distant future. Please, forgive me if I was mistaken.
after perusing the search function as usual, and nothing turning up, I made this little thread of abysmally tiny, and low-profile bugs.
1. Nested spoilers
CURRENT BEHAVIOR:
When nesting spoilers, the nested spoilers break, making it impossible to use them.
EXPECTED BEHAVIOR:
When nesting spoilers, they form a set of spoilers residing within each other, akin to nested quotes. This use case might seem purely academic and hypothetical, but I found myself wishing for that functionality repeatedly. For example: One might want to spoiler a piece of text, and within that, an array of images.
PROOF CONCEPT:
{spoil}this {spoil}is {spoil}a {spoil}spoiler {/spoil}{/spoil}{/spoil}{/spoil}
Spoiler:
2. {URL} wrap-around
CURRENT BEHAVIOR:
When inserting a hyperlink by marking a piece of text, then hitting the "insert URL" button in the editor, the editor prompts 2 input alerts; one for the URL (expected), one for the page name (unexpected). The resulting url-tag is then wrapped around the text entered in the page name query, not around the marked text. There is no way to cancel the second query (cancelling it will yield the error "You have not entered the page title", and aborts the entire process), or to otherwise ensure that the link is wrapped around marked text.
EXPECTED BEHAVIOR:
When inserting a hyperlink by marking a piece of text, then hitting the "link" button in the WYSIWYG editor, the "page name" query is either omitted, or can be cancelled, resulting in the link being wrapped around the marked text. Formatting tags (bold, italics, etc.) already behave this way. For posts where a lot of links are to be inserted after writing out the text, this would increase usability.
PLATFORMS:
All tested browsers (firefox, safari, ie, ...)
3. Tag insertion in mid-text
CURRENT BEHAVIOR:
When inserting a tag in the middle of a post, using one of the editor's buttons, without marking any particular piece of text to wrap the tag around, tags are not being inserted at the cursor position, but at the end of the post.
EXPECTED BEHAVIOR:
When inserting a tag in the middle of a post, tags are being inserted at the cursor position. This is especially useful when working with posts that involve a number of quotations, when inserting images after post composition, etc.
PLATFORMS:
All tested browsers (firefox, safari, ie, ...)
I'm well aware that this is probably nit-picking and these are all extremely low-profile bugs, but figured it might be worth a quick fix at some point in the distant future. Please, forgive me if I was mistaken.
0
UPDATE:
4. Editor drop-downs
CURRENT BEHAVIOUR:
When perusing the editor drop-down lists for font properties (size, color, type) to format marked text, the drop down lists do not reset to the original state upon completion of the process. It is thus impossible to format several, different pieces of text perusing the mark-and-format method; instead, the drop down lists have to be reset manually, each time resulting in the insertion of undesired tags, such as {font type="Font type"} or {color=font color"}. These then have to be elided manually.
EXPECTED BEHAVIOUR:
When perusing the editor drop-down lists for font properties (size, color, type) to format marked text, the drop-down lists reset to the default state upon completion of the process, without inserting undesired tags.
PLATFORMS:
All tested browsers (firefox, safari, ie, ...)
Same disclaimer as previous applies regarding zero-priority, etc. pp.
4. Editor drop-downs
CURRENT BEHAVIOUR:
When perusing the editor drop-down lists for font properties (size, color, type) to format marked text, the drop down lists do not reset to the original state upon completion of the process. It is thus impossible to format several, different pieces of text perusing the mark-and-format method; instead, the drop down lists have to be reset manually, each time resulting in the insertion of undesired tags, such as {font type="Font type"} or {color=font color"}. These then have to be elided manually.
EXPECTED BEHAVIOUR:
When perusing the editor drop-down lists for font properties (size, color, type) to format marked text, the drop-down lists reset to the default state upon completion of the process, without inserting undesired tags.
PLATFORMS:
All tested browsers (firefox, safari, ie, ...)
Same disclaimer as previous applies regarding zero-priority, etc. pp.
