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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use the "old" editor as the freeform block #1394

Merged
merged 3 commits into from Jul 14, 2017

Conversation

Projects
None yet
6 participants
@iseulde
Member

iseulde commented Jun 23, 2017

  • Easiest way to add the old editor as a block in Gutenberg (removes a lot of current and future complexity).
  • With the same setting, plugins that currently work in WP will keep on working.
  • With some styling, it can fit perfectly well inside Gutenberg.
  • Can be used on old content without destroying anything.

This is still a WIP! 馃毀

@iseulde

This comment has been minimized.

Show comment
Hide comment
@iseulde

iseulde Jun 23, 2017

Member

While still a work in progress, it would be good to get some feedback as this is quite different from the current implementation.

Member

iseulde commented Jun 23, 2017

While still a work in progress, it would be good to get some feedback as this is quite different from the current implementation.

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Jun 23, 2017

Contributor

Very nice! I might have a few suggestions to making the kitchen sink button look closer to how James did it in his approach, and I'd want to separately see how I could make this responsive. But there's nothing about this, visually, that offends :)

Does it work with custom tinymce buttons? (Not that it has to)

BTW I noticed that if you accidentally click the space between the toolbar groups and drag even ever so slightly, you invoke multi select. I think this might be an issue in master also, but figured I'd mention.

@EphoxJames Compared to your branch, what are your thoughts on this one? Is it better or worse, what are the pros and cons from a code simplicity point of view? Thanks so much.

Contributor

jasmussen commented Jun 23, 2017

Very nice! I might have a few suggestions to making the kitchen sink button look closer to how James did it in his approach, and I'd want to separately see how I could make this responsive. But there's nothing about this, visually, that offends :)

Does it work with custom tinymce buttons? (Not that it has to)

BTW I noticed that if you accidentally click the space between the toolbar groups and drag even ever so slightly, you invoke multi select. I think this might be an issue in master also, but figured I'd mention.

@EphoxJames Compared to your branch, what are your thoughts on this one? Is it better or worse, what are the pros and cons from a code simplicity point of view? Thanks so much.

@iseulde

This comment has been minimized.

Show comment
Hide comment
@iseulde

iseulde Jun 23, 2017

Member

@jasmussen Yeah it's still a WP. All works like the current editor, just need to add the filter for the buttons, and it will work with custom MCE buttons as well. Not much work.

Regarding the kitchen sink, yes, I'll have see how we can do it better on this branch. Note though that there can be many buttons, and up to 4 toolbars in total (3 additional). We could just merge the additional ones into one, but it will need to wrap in case there are many buttons.

BTW I noticed that if you accidentally click the space between the toolbar groups and drag even ever so slightly, you invoke multi select. I think this might be an issue in master also, but figured I'd mention.

That's only on this branch, because for now, the toolbar is literally part of the content. I'll fix this.

Member

iseulde commented Jun 23, 2017

@jasmussen Yeah it's still a WP. All works like the current editor, just need to add the filter for the buttons, and it will work with custom MCE buttons as well. Not much work.

Regarding the kitchen sink, yes, I'll have see how we can do it better on this branch. Note though that there can be many buttons, and up to 4 toolbars in total (3 additional). We could just merge the additional ones into one, but it will need to wrap in case there are many buttons.

BTW I noticed that if you accidentally click the space between the toolbar groups and drag even ever so slightly, you invoke multi select. I think this might be an issue in master also, but figured I'd mention.

That's only on this branch, because for now, the toolbar is literally part of the content. I'll fix this.

@EphoxJames

This is great! I like this solution much more than trying to rewrite all the tool bar components in react (which was where I was going to end up).

The only problem I saw aside from those pointed out by @jasmussen is that the kitchen-sink can scroll off the top of the page:

scrolling-cuts-off-toolbar

Show outdated Hide outdated blocks/library/freeform/old-editor.js
content_css: false,
fixed_toolbar_container: '#' + id + '-toolbar',
toolbar1: 'formatselect | alignleft aligncenter alignright | bullist numlist blockquote | bold italic strikethrough link | kitchensink',
toolbar2: 'hr wp_more forecolor pastetext removeformat charmap outdent indent undo redo',

This comment has been minimized.

@EphoxJames

EphoxJames Jun 26, 2017

Contributor

I could not get the wp_more button do do anything. Is it working as intended?

@EphoxJames

EphoxJames Jun 26, 2017

Contributor

I could not get the wp_more button do do anything. Is it working as intended?

@EphoxJames

This comment has been minimized.

Show comment
Hide comment
@EphoxJames

EphoxJames Jun 26, 2017

Contributor

Another minor difference compared to the other gutenberg blocks is that the controls don't hide while typing and show on mouse move. You can probably fix this and the multi-select issue by putting it into the <BlockControls/> and copying across the relevant code from editable. There's also an issue to delete the freeform block on backspace when there's nothing in it ( #1273 (comment) ).

Contributor

EphoxJames commented Jun 26, 2017

Another minor difference compared to the other gutenberg blocks is that the controls don't hide while typing and show on mouse move. You can probably fix this and the multi-select issue by putting it into the <BlockControls/> and copying across the relevant code from editable. There's also an issue to delete the freeform block on backspace when there's nothing in it ( #1273 (comment) ).

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Jun 26, 2017

Contributor

Thanks James, appreciate your input. Let's explore this branch further then! 馃帀

Contributor

jasmussen commented Jun 26, 2017

Thanks James, appreciate your input. Let's explore this branch further then! 馃帀

@iseulde

This comment has been minimized.

Show comment
Hide comment
@iseulde

iseulde Jun 26, 2017

Member

I'm aware of the issues, it's also still a WIP. Thanks for the initial feedback, I'll try to get everything working then. One thing that's kind of annoying is trying put the non-React toolbar in the slots, which are always hiding and showing, while MCE's toolbar is supposed to render just once. That's why I've added it to the content div for now. @EphoxJames Ideas welcome. :) It would we nice to get this to work somehow, then we could also show advanced buttons in the inspector, maybe. :) Kind of like #1383. Cc @jasmussen

Member

iseulde commented Jun 26, 2017

I'm aware of the issues, it's also still a WIP. Thanks for the initial feedback, I'll try to get everything working then. One thing that's kind of annoying is trying put the non-React toolbar in the slots, which are always hiding and showing, while MCE's toolbar is supposed to render just once. That's why I've added it to the content div for now. @EphoxJames Ideas welcome. :) It would we nice to get this to work somehow, then we could also show advanced buttons in the inspector, maybe. :) Kind of like #1383. Cc @jasmussen

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Jun 26, 2017

Contributor

One thing that's kind of annoying is trying put the non-React toolbar in the slots, which are always hiding and showing, while MCE's toolbar is supposed to render just once. That's why I've added it to the content div for now.

It's important that we consider code simplicity too. If making the toolbars auto hide for this block adds complexity, maybe we are okay with not adding it for now, or if it can't be done in a nice way_ ever_. It's a tradeoff we're willing to make, and not something that should hold up this PR.

Contributor

jasmussen commented Jun 26, 2017

One thing that's kind of annoying is trying put the non-React toolbar in the slots, which are always hiding and showing, while MCE's toolbar is supposed to render just once. That's why I've added it to the content div for now.

It's important that we consider code simplicity too. If making the toolbars auto hide for this block adds complexity, maybe we are okay with not adding it for now, or if it can't be done in a nice way_ ever_. It's a tradeoff we're willing to make, and not something that should hold up this PR.

@iseulde

This comment has been minimized.

Show comment
Hide comment
@iseulde

iseulde Jun 26, 2017

Member

Okay, I've fixed the wp_more stuff for now here, but ideally should be fixed in core. Will make a patch there.

I've included the plugin and toolbar filters that target the old editor, so that should work now. (Try the TinyMCE Advanced plugin). This will still need further CSS tweaking though, as the toolbars will wrap over a certain length. Maybe scroll like it does in Calypso?

Also still needs the kitchen sink figured out... Also keep in mind that there is a potential menu bar (I've not added that filter yet):

menu bar

Member

iseulde commented Jun 26, 2017

Okay, I've fixed the wp_more stuff for now here, but ideally should be fixed in core. Will make a patch there.

I've included the plugin and toolbar filters that target the old editor, so that should work now. (Try the TinyMCE Advanced plugin). This will still need further CSS tweaking though, as the toolbars will wrap over a certain length. Maybe scroll like it does in Calypso?

Also still needs the kitchen sink figured out... Also keep in mind that there is a potential menu bar (I've not added that filter yet):

menu bar

@iseulde

This comment has been minimized.

Show comment
Hide comment
@iseulde

iseulde Jun 26, 2017

Member

Idea: Have the trimmed down version of the toolbar display like the other block toolbars, but when the kitchen sink is toggled, display it within the block (not even hide on blur). To go back to the trimmed down one you press the kitchen sink button again.

Member

iseulde commented Jun 26, 2017

Idea: Have the trimmed down version of the toolbar display like the other block toolbars, but when the kitchen sink is toggled, display it within the block (not even hide on blur). To go back to the trimmed down one you press the kitchen sink button again.

@Sofian777

This comment has been minimized.

Show comment
Hide comment
@Sofian777

Sofian777 Jun 26, 2017

I just wanted to drop an enormous thanks to iseulde for her work. I consider it fundamental to offer a block that does exactly what the current WP editor does, including custom stuff and plugins. It is essential to keep the backwards compatibility, from a technical perspective but also from a human perspective. Especially in the beginning period of transition to the new editor.

Any other attempt would leave millions of broken plugins and sites and millions of sad and angry users. Wouldn't fit to WP which is very user oriented.

Plus the Tiny MCE is a much better editor for webdesigners, who don't need a block to create a h3, but simply a shortcode Shift-Ctrl-3 to quickly format through the text and sometimes the text editor to add manual classes to the code. Sometimes I need to copy the whole HTML code into another editor to perform some tricks and copying it back. The block concept is easier for non techies and hobby bloggers, but don't take out the editing and html tools that webdesigners need, they are the ones making great websites with WP and raised it above a blogging platform. I love the block concept for images and videos and the like, but for regular text, I wouldn't like to loose the simplicity of easily formatting it through.

I hope to see a Gutenberg that is fusing a supereasy intuitive creation for newbies with the tools that professional webdesigners need.

A supergreat thanks and virtual hug from my part.

Sofian777 commented Jun 26, 2017

I just wanted to drop an enormous thanks to iseulde for her work. I consider it fundamental to offer a block that does exactly what the current WP editor does, including custom stuff and plugins. It is essential to keep the backwards compatibility, from a technical perspective but also from a human perspective. Especially in the beginning period of transition to the new editor.

Any other attempt would leave millions of broken plugins and sites and millions of sad and angry users. Wouldn't fit to WP which is very user oriented.

Plus the Tiny MCE is a much better editor for webdesigners, who don't need a block to create a h3, but simply a shortcode Shift-Ctrl-3 to quickly format through the text and sometimes the text editor to add manual classes to the code. Sometimes I need to copy the whole HTML code into another editor to perform some tricks and copying it back. The block concept is easier for non techies and hobby bloggers, but don't take out the editing and html tools that webdesigners need, they are the ones making great websites with WP and raised it above a blogging platform. I love the block concept for images and videos and the like, but for regular text, I wouldn't like to loose the simplicity of easily formatting it through.

I hope to see a Gutenberg that is fusing a supereasy intuitive creation for newbies with the tools that professional webdesigners need.

A supergreat thanks and virtual hug from my part.

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Jun 27, 2017

Contributor

Love the work that's ongoing here. A few tweaks and then I think we should get it in.

Lineheight could use a little tweaking:

screen shot 2017-06-27 at 10 13 12

I like how you renamed Kitchen Sink, but can we call it "More"?

screen shot 2017-06-27 at 10 13 44

Perhaps we can fix the position sticky issue by changing the "top" value for the toolbar when the toolbar is open:

screen shot 2017-06-27 at 10 14 39

Maybe we make an exception for toolbar spacing and positioning here, and collapse it all, or use the separators that James built. Quick mockup:

screen shot 2017-06-27 at 10 15 34

Responsive is going to be a challenge. But probably easiest to simply let the toolbars stack, like the old editor does:

screen shot 2017-06-27 at 10 19 27

That there is half hearted, and probably best tackled in a separate PR. It's a bit of a headache what with the sticky stuff, and we might simply decide to not use negative vertical margins to place the toolbar on the "edge" of the block, depending on what's simplest.

Contributor

jasmussen commented Jun 27, 2017

Love the work that's ongoing here. A few tweaks and then I think we should get it in.

Lineheight could use a little tweaking:

screen shot 2017-06-27 at 10 13 12

I like how you renamed Kitchen Sink, but can we call it "More"?

screen shot 2017-06-27 at 10 13 44

Perhaps we can fix the position sticky issue by changing the "top" value for the toolbar when the toolbar is open:

screen shot 2017-06-27 at 10 14 39

Maybe we make an exception for toolbar spacing and positioning here, and collapse it all, or use the separators that James built. Quick mockup:

screen shot 2017-06-27 at 10 15 34

Responsive is going to be a challenge. But probably easiest to simply let the toolbars stack, like the old editor does:

screen shot 2017-06-27 at 10 19 27

That there is half hearted, and probably best tackled in a separate PR. It's a bit of a headache what with the sticky stuff, and we might simply decide to not use negative vertical margins to place the toolbar on the "edge" of the block, depending on what's simplest.

@iseulde

This comment has been minimized.

Show comment
Hide comment
@iseulde

iseulde Jun 27, 2017

Member

Lineheight could use a little tweaking:

Yeah, left most of the previous freeform styles in place.

I like how you renamed Kitchen Sink, but can we call it "More"?

Did not rename it, it's called that way in core, just copied the buttons. But sure. :)

Perhaps we can fix the position sticky issue by changing the "top" value for the toolbar when the toolbar is open:

Yeah this fits in with all the other comments about responsiveness. I have no idea here. There can be up to 4 toolbars, and there can also be a menu bar which hasn't been added yet.

Previous comments:

This will still need further CSS tweaking though, as the toolbars will wrap over a certain length. Maybe scroll like it does in Calypso?

Idea: Have the trimmed down version of the toolbar display like the other block toolbars, but when the kitchen sink is toggled, display it within the block (not even hide on blur). To go back to the trimmed down one you press the kitchen sink button again.

Maybe it's best not do do all the sticky and hiding stuff for now, and display the big toggled toolbar inside the block, while having a smaller basic one in the normal position if not toggled?

Member

iseulde commented Jun 27, 2017

Lineheight could use a little tweaking:

Yeah, left most of the previous freeform styles in place.

I like how you renamed Kitchen Sink, but can we call it "More"?

Did not rename it, it's called that way in core, just copied the buttons. But sure. :)

Perhaps we can fix the position sticky issue by changing the "top" value for the toolbar when the toolbar is open:

Yeah this fits in with all the other comments about responsiveness. I have no idea here. There can be up to 4 toolbars, and there can also be a menu bar which hasn't been added yet.

Previous comments:

This will still need further CSS tweaking though, as the toolbars will wrap over a certain length. Maybe scroll like it does in Calypso?

Idea: Have the trimmed down version of the toolbar display like the other block toolbars, but when the kitchen sink is toggled, display it within the block (not even hide on blur). To go back to the trimmed down one you press the kitchen sink button again.

Maybe it's best not do do all the sticky and hiding stuff for now, and display the big toggled toolbar inside the block, while having a smaller basic one in the normal position if not toggled?

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Jun 27, 2017

Contributor

Did not rename it, it's called that way in core, just copied the buttons. But sure. :)

Ah, then no need to change. I could swear it was called "Kitchen Sink" in core, but that may have changed recently.

Maybe it's best not do do all the sticky and hiding stuff for now, and display the big toggled toolbar inside the block, while having a smaller basic one in the normal position if not toggled?

I like the sticky toolbar, it'd be nice if we could find a way to get it to work.

Contributor

jasmussen commented Jun 27, 2017

Did not rename it, it's called that way in core, just copied the buttons. But sure. :)

Ah, then no need to change. I could swear it was called "Kitchen Sink" in core, but that may have changed recently.

Maybe it's best not do do all the sticky and hiding stuff for now, and display the big toggled toolbar inside the block, while having a smaller basic one in the normal position if not toggled?

I like the sticky toolbar, it'd be nice if we could find a way to get it to work.

@androb

This comment has been minimized.

Show comment
Hide comment
@androb

androb Jun 27, 2017

Contributor

@iseulde one thought is that for v4.9 we make style and other changes so that a) we move user experience (toolbar color, fonts) closer to Gutenberg (less shock) and b) make this block easier/simpler.

Contributor

androb commented Jun 27, 2017

@iseulde one thought is that for v4.9 we make style and other changes so that a) we move user experience (toolbar color, fonts) closer to Gutenberg (less shock) and b) make this block easier/simpler.

@iseulde

This comment has been minimized.

Show comment
Hide comment
@iseulde

iseulde Jul 3, 2017

Member

Fixed some more issues. Looking into the sticky styling.

Member

iseulde commented Jul 3, 2017

Fixed some more issues. Looking into the sticky styling.

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Jul 3, 2017

Contributor

I was thinking about the toolbar here (and perhaps for the other toolbars also) 鈥 the big challenge here is that flex-wrap would make the toolbar taller in a downwards direction. What if we could make it taller in the upwards direction? Can we make the container grow upwards instead, when toolbars wrap?

Contributor

jasmussen commented Jul 3, 2017

I was thinking about the toolbar here (and perhaps for the other toolbars also) 鈥 the big challenge here is that flex-wrap would make the toolbar taller in a downwards direction. What if we could make it taller in the upwards direction? Can we make the container grow upwards instead, when toolbars wrap?

@iseulde

This comment has been minimized.

Show comment
Hide comment
@iseulde

iseulde Jul 3, 2017

Member

How about this, @jasmussen? ^

Member

iseulde commented Jul 3, 2017

How about this, @jasmussen? ^

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Jul 3, 2017

Contributor

How about this, @jasmussen? ^

I think this can probably work for us. It's not ideal, as it sort of makes it seem like the block has an extra linebreak at the top. But unless we can do something like what #1394 (comment), it's probably a tradeoff we can make. At least for now.

One issue though, if you deselect the block by clicking the gray area in the sidebar, you get this:

screen shot 2017-07-03 at 11 10 09

Contributor

jasmussen commented Jul 3, 2017

How about this, @jasmussen? ^

I think this can probably work for us. It's not ideal, as it sort of makes it seem like the block has an extra linebreak at the top. But unless we can do something like what #1394 (comment), it's probably a tradeoff we can make. At least for now.

One issue though, if you deselect the block by clicking the gray area in the sidebar, you get this:

screen shot 2017-07-03 at 11 10 09

@iseulde

This comment has been minimized.

Show comment
Hide comment
@iseulde

iseulde Jul 3, 2017

Member

I'll fix the issues. The tradeoff with the other approach is that if you have a big toolbar (max. 4 rows + menu bar) it will overlap the previous block so much. Feel free to try the styling like that though. :) This is all CSS we can adjust later on I guess, in the worst case we just leave it in the block and add sticky positioning to it.

Member

iseulde commented Jul 3, 2017

I'll fix the issues. The tradeoff with the other approach is that if you have a big toolbar (max. 4 rows + menu bar) it will overlap the previous block so much. Feel free to try the styling like that though. :) This is all CSS we can adjust later on I guess, in the worst case we just leave it in the block and add sticky positioning to it.

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Jul 3, 2017

Contributor

The tradeoff with the other approach is that if you have a big toolbar (max. 4 rows + menu bar) it will overlap the previous block so much.

Yep, will definitely take a look at the styles as soon as I can.

I think it's a better tradeoff, though, and long term I think we should explore something like the following:

screen shot 2017-07-03 at 11 37 08

Contributor

jasmussen commented Jul 3, 2017

The tradeoff with the other approach is that if you have a big toolbar (max. 4 rows + menu bar) it will overlap the previous block so much.

Yep, will definitely take a look at the styles as soon as I can.

I think it's a better tradeoff, though, and long term I think we should explore something like the following:

screen shot 2017-07-03 at 11 37 08

@iseulde

This comment has been minimized.

Show comment
Hide comment
@iseulde

iseulde Jul 3, 2017

Member

Sure, okay, but I think we should design for a bit more buttons than that. Additionally there's also a menu bar which will have to go in here as well. We can style the old toolbars in any way we'd like, but I think we should stick with the current layout at least.

Member

iseulde commented Jul 3, 2017

Sure, okay, but I think we should design for a bit more buttons than that. Additionally there's also a menu bar which will have to go in here as well. We can style the old toolbars in any way we'd like, but I think we should stick with the current layout at least.

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Jul 3, 2017

Contributor

We're sort of in the weeds, design wise, with this one, and I think it would be good to get it stabilized the way you are already doing right now, then merge it in and iterate on it.

But yet another alternative is this:

screen shot 2017-07-03 at 11 49 22

It's essentially what you had before, but instead of "growing upwards" like I suggested, we embrace that the toolbar wraps downwards, but we add a gray chrome area to the top border to account for the extra padding we need. I know this seems overly complex, but in my head the gray can help explain the discrepancy margins that happens when you select the block.

Contributor

jasmussen commented Jul 3, 2017

We're sort of in the weeds, design wise, with this one, and I think it would be good to get it stabilized the way you are already doing right now, then merge it in and iterate on it.

But yet another alternative is this:

screen shot 2017-07-03 at 11 49 22

It's essentially what you had before, but instead of "growing upwards" like I suggested, we embrace that the toolbar wraps downwards, but we add a gray chrome area to the top border to account for the extra padding we need. I know this seems overly complex, but in my head the gray can help explain the discrepancy margins that happens when you select the block.

@iseulde

This comment has been minimized.

Show comment
Hide comment
Member

iseulde commented Jul 3, 2017

@iseulde

This comment has been minimized.

Show comment
Hide comment
@iseulde

iseulde Jul 3, 2017

Member

@jasmussen To me, that looks more like a bug than what it looks like now. :) Alternatively, we could not raise the toolbars to the some level as other toolbars, or not raise it if "more" is toggled.

Member

iseulde commented Jul 3, 2017

@jasmussen To me, that looks more like a bug than what it looks like now. :) Alternatively, we could not raise the toolbars to the some level as other toolbars, or not raise it if "more" is toggled.

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Jul 3, 2017

Contributor

To clarify a bit on the following:

screen shot 2017-07-03 at 15 54 10

I imagine the behavior of this mockup to be a dropdown only. That is, if you don't have enough space to see the list buttons, you select text, click the ellipsis, click the list button, and as soon as you've done that the dropdown closes again. So that mockup is not showing a permanently open tray of extra buttons. Just a temporary one. I like this solution because it scales to almost any amount of buttons.

Contributor

jasmussen commented Jul 3, 2017

To clarify a bit on the following:

screen shot 2017-07-03 at 15 54 10

I imagine the behavior of this mockup to be a dropdown only. That is, if you don't have enough space to see the list buttons, you select text, click the ellipsis, click the list button, and as soon as you've done that the dropdown closes again. So that mockup is not showing a permanently open tray of extra buttons. Just a temporary one. I like this solution because it scales to almost any amount of buttons.

@iseulde

This comment has been minimized.

Show comment
Hide comment
@iseulde

iseulde Jul 3, 2017

Member

I'm fine with whatever moves this forward. :) Feel free to adjust any way you'd like.

Member

iseulde commented Jul 3, 2017

I'm fine with whatever moves this forward. :) Feel free to adjust any way you'd like.

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Jul 3, 2017

Contributor

I'll take a look, but I think we might want to merge this in soon and then iterate further in other branches.

One thing worth looking at first, though 鈥 if you select a freeform block and deselect by clicking on the white area, toolbars and block outlines disappear as they should. But if you deselect by clicking on the gray area of the sidebar, only the toolbar disappears. The block still stays highlighted with block boundaries.

Contributor

jasmussen commented Jul 3, 2017

I'll take a look, but I think we might want to merge this in soon and then iterate further in other branches.

One thing worth looking at first, though 鈥 if you select a freeform block and deselect by clicking on the white area, toolbars and block outlines disappear as they should. But if you deselect by clicking on the gray area of the sidebar, only the toolbar disappears. The block still stays highlighted with block boundaries.

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Jul 3, 2017

Contributor

Another idea, building on your ideas. What if we made an exception to the Gutenberg toolbar style, to truly embrace the "old editor" idea. Basically this:

screen-shot-2017-07-03-at-16 43 22

That way, the toolbar could have the same markup it has in the old editor, and buttons inside could wrap as they do today. What do you think @iseulde ?

Contributor

jasmussen commented Jul 3, 2017

Another idea, building on your ideas. What if we made an exception to the Gutenberg toolbar style, to truly embrace the "old editor" idea. Basically this:

screen-shot-2017-07-03-at-16 43 22

That way, the toolbar could have the same markup it has in the old editor, and buttons inside could wrap as they do today. What do you think @iseulde ?

@iseulde

This comment has been minimized.

Show comment
Hide comment
@iseulde

iseulde Jul 3, 2017

Member

That's good to me. That's the same but without the space in between? What if we just drop the lines as well and have it a full width toolbar (as the old editor)?

Member

iseulde commented Jul 3, 2017

That's good to me. That's the same but without the space in between? What if we just drop the lines as well and have it a full width toolbar (as the old editor)?

@iseulde

This comment has been minimized.

Show comment
Hide comment
@iseulde

iseulde Jul 3, 2017

Member

Worth noting that buttons at the top, like the switcher, do different things anyway, even though they look the same. It's not a block switcher or block level alignment.

Member

iseulde commented Jul 3, 2017

Worth noting that buttons at the top, like the switcher, do different things anyway, even though they look the same. It's not a block switcher or block level alignment.

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Jul 3, 2017

Contributor

That's good to me. That's the same but without the space in between?

Well, the vertical lines could be separators, so it's a single div containing all the elements. Then they would flex wrap, right?

What if we just drop the lines as well and have it a full width toolbar (as the old editor)?

We could do that as well. In fact we might even consider keeping the sort order of the buttons the same as in the old editor.

Full width is also on the table ;) but it's also the last step away from the gutenberg toolbar style. I think we should try and see if we can do without the full width for now.

Contributor

jasmussen commented Jul 3, 2017

That's good to me. That's the same but without the space in between?

Well, the vertical lines could be separators, so it's a single div containing all the elements. Then they would flex wrap, right?

What if we just drop the lines as well and have it a full width toolbar (as the old editor)?

We could do that as well. In fact we might even consider keeping the sort order of the buttons the same as in the old editor.

Full width is also on the table ;) but it's also the last step away from the gutenberg toolbar style. I think we should try and see if we can do without the full width for now.

@EphoxJames

This comment has been minimized.

Show comment
Hide comment
@EphoxJames

EphoxJames Jul 4, 2017

Contributor

I started a branch off this branch to test out some styling ideas "try/freeform-old-editor-floating-toolbar".

It revises the floating toolbar from the first version but uses a "flex-direction: column-reverse" to reverse the toolbar ordering so more than one toolbar can be stacked.

The end result looks the same as the first version except the extra toolbars don't scroll off the top of the page.

selection_042

Contributor

EphoxJames commented Jul 4, 2017

I started a branch off this branch to test out some styling ideas "try/freeform-old-editor-floating-toolbar".

It revises the floating toolbar from the first version but uses a "flex-direction: column-reverse" to reverse the toolbar ordering so more than one toolbar can be stacked.

The end result looks the same as the first version except the extra toolbars don't scroll off the top of the page.

selection_042

@iseulde

This comment has been minimized.

Show comment
Hide comment
@iseulde

iseulde Jul 7, 2017

Member

@jasmussen Adjusted based on your feedback. I think this is much better now, and more like the old editor. Still needs some small styling tweaks here and there.

Member

iseulde commented Jul 7, 2017

@jasmussen Adjusted based on your feedback. I think this is much better now, and more like the old editor. Still needs some small styling tweaks here and there.

@jasmussen

Love it!

I think we're 90% there. I think we should include at least a separator (border-right) on the paragraph dropdown, so it looks like its own thing. Possibly a few more, but if we add that border, it's cool.

@iseulde

This comment has been minimized.

Show comment
Hide comment
@iseulde

iseulde Jul 14, 2017

Member

Okay, let's merge an iterate. This seems to be a good base.

Member

iseulde commented Jul 14, 2017

Okay, let's merge an iterate. This seems to be a good base.

@iseulde iseulde merged commit 57d068b into master Jul 14, 2017

3 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
coverage/coveralls First build on try/freeform-old-editor at 17.987%
Details

@iseulde iseulde deleted the try/freeform-old-editor branch Jul 14, 2017

@@ -20,30 +20,10 @@ registerBlockType( 'core/freeform', {
category: 'formatting',
attributes: {
content: children(),
content: prop( 'innerHTML' ),

This comment has been minimized.

@aduth

aduth Jul 14, 2017

Member

The html matcher is a shorthand for prop( 'innerHTML' )

https://github.com/aduth/hpq#api

Per effort to discourage treating as DOM node (#624), have considered whether prop can even be dropped.

@aduth

aduth Jul 14, 2017

Member

The html matcher is a shorthand for prop( 'innerHTML' )

https://github.com/aduth/hpq#api

Per effort to discourage treating as DOM node (#624), have considered whether prop can even be dropped.

This comment has been minimized.

@iseulde

iseulde Jul 18, 2017

Member

Ah, didn't realise, sorry. :)

@iseulde

iseulde Jul 18, 2017

Member

Ah, didn't realise, sorry. :)

},
} );
/* eslint-disable */

This comment has been minimized.

@aduth

aduth Jul 14, 2017

Member

Could we be more specific here with what we're disabling (i.e. list rule names) to avoid introducing errors, and/or a comment to explain why we're disabling.

@aduth

aduth Jul 14, 2017

Member

Could we be more specific here with what we're disabling (i.e. list rule names) to avoid introducing errors, and/or a comment to explain why we're disabling.

tag = tag || 'more';
classname += ' mce-wp-' + tag;
title = tag === 'more' ? 'Read more...' : 'Next page';

This comment has been minimized.

@aduth

aduth Jul 14, 2017

Member

Should these be translated? Also ellipsis character as more semantically meaningful than three dots.

@aduth

aduth Jul 14, 2017

Member

Should these be translated? Also ellipsis character as more semantically meaningful than three dots.

This comment has been minimized.

@iseulde

iseulde Jul 18, 2017

Member

As commented, this is just slightly modified core code... I'm even thinking we should drop this and let it fail for the current WordPress version as it is fixed in trunk and will be in 4.9.

@iseulde

iseulde Jul 18, 2017

Member

As commented, this is just slightly modified core code... I'm even thinking we should drop this and let it fail for the current WordPress version as it is fixed in trunk and will be in 4.9.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment