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

Update/972 freeform block add format selector #1030

Merged
merged 19 commits into from
Jun 12, 2017

Conversation

BoardJames
Copy link

The purpose of this pull request is to update the freeform block to add a format selector.

Currently the result looks like this:
freeform-block-format-selector

This is a part of the process of recreating the mockups shown here:
#972

@BoardJames BoardJames mentioned this pull request Jun 6, 2017
@jasmussen
Copy link
Contributor

Nice! This is coming together fast, cool!

I noticed outlines don't fade out when you type. This seems to be causing some conflicts, where if you select a line of text with the intention of going to the paragraph dropdown, then they actually fade out, when in fact the behavior should be the reverse:

  • Type text and outlines fade out.
  • As soon as you move the mouse, or hold shift or another modifier key, or use the arrow keys, outlines fade back in.

See also #657.

}

render() {
const { formats = [ { text: '', value: '', textStyle: () => '' } ] } = this.props;
Copy link
Contributor

Choose a reason for hiding this comment

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

Is the default empty format here required?

Copy link
Author

Choose a reason for hiding this comment

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

Probably not.
I was thinking that there would be a render step when the editor hadn't loaded and there would be no formats. I can probably handle this cleaner though so I will revise it.

aria-label={ wp.i18n.__( 'Change format' ) }
>
<div className="formats">
{ formats.map( ( { text, value } ) => (
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we avoid mapping here and display only the active format? instead of hiding the other formats with CSS.

Copy link
Author

Choose a reason for hiding this comment

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

Well they're there so the dropdown stays the size of the largest item.

I am stacking the lines on top of each other while hiding all but the active item. This results in the width of the button matching the largest item which appears to be how it was in the mockup.

I am happy to take suggestions on how to achieve this effect in another way.

className={ value === selectedValue ? 'active' : null }
aria-hidden={ value !== selectedValue }
>
{ text }<br />
Copy link
Contributor

Choose a reason for hiding this comment

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

What is the br for?

Copy link
Author

Choose a reason for hiding this comment

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

It allows me to stack the lines of text by setting the line-height to 0. As stated above I'm using them to achieve the effect of the dropdown staying the width of the largest item.

{ text: 'Heading 6', value: 'h6', textStyle: () => '' },
{ text: 'Preformatted', value: 'pre', textStyle: () => '' },
],
handleFormatChange: null,
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there any value in storing formats and handlFormatChange in the state? These variables don't look like state to me.

Copy link
Author

Choose a reason for hiding this comment

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

They are drawn from the editor but I suppose I could keep them outside of the state. I do need to re-render when I set the formats array (in onInit) but I suppose I could force that instead of updating state.

Copy link
Contributor

@youknowriad youknowriad left a comment

Choose a reason for hiding this comment

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

Thanks for doing this, the toolbar is working great. i left some comments above

@BoardJames
Copy link
Author

@jasmussen I can't figure out how to make the tool-bar fade out when typing starts even looking at the pull request you linked. Any idea what I'm missing?

@jasmussen
Copy link
Contributor

I can't figure out how to make the tool-bar fade out when typing starts even looking at the pull request you linked. Any idea what I'm missing?

@iseulde can you give some pointers? ❤️

@ellatrix
Copy link
Member

ellatrix commented Jun 7, 2017

@BoardJames
Copy link
Author

@jasmussen After adding another function from editable the freeform block seems to be behaving the same as the text block now. Note that the toolbar only seems to come back on mouse click but that is the same behaviour as the text block for me.

@BoardJames
Copy link
Author

BoardJames commented Jun 8, 2017

Hmm, merging master broke it. (forgot npm install)

@BoardJames
Copy link
Author

BoardJames commented Jun 8, 2017

@youknowriad @jasmussen I think I've addressed the review comments. Any more changes needed or is it good to merge?

@jasmussen
Copy link
Contributor

Nice work!

I think we're very close at this point. There are some fade issues unrelated to this PR we still need to address separately ( #958 ).

I think people are going to love this block 🌟

A few things:

screen shot 2017-06-08 at 09 42 52

Thanks!

@BoardJames
Copy link
Author

BoardJames commented Jun 9, 2017

@jasmussen
I have done the left and top margin tweaks and I have done my best with the z-index problem - I hope I have not introduced more z-index bugs in the process.

I can mostly implement what you request for the styling though the key problem is that I'm pulling all the information to populate the format menu (including the styling) from TinyMCE so in theory it could have a menu item called 'preformatted' that was actually h1.

Here is what I got:
freeform-block-styled-format-menu

I am not very happy with the result and I would welcome suggestions and mockups. Maybe it could be done with a preview that pops-up next to the menu so it doesn't mess-up the list size?

@jasmussen
Copy link
Contributor

I can mostly implement what you request for the styling though the key problem is that I'm pulling all the information to populate the format menu (including the styling) from TinyMCE so in theory it could have a menu item called 'preformatted' that was actually h1.

Can you clarify this a little bit, especially the last bit about an H1?

Visually and functionally this looks pretty good to me. I'd like to see if we can do a few more tweaks to it — the font sizes for the headings don't have to be identical to the ones actually in the document, we can relax those a bit, and preformatted needs to match a font both in the freeform block and the dropdown to the font stack used by the separate preformatted block. Se might also want to change the color of items in this dropdown. But none of those changes need to block this PR from getting into master — I dig what I'm seeing!

I am not very happy with the result and I would welcome suggestions and mockups. Maybe it could be done with a preview that pops-up next to the menu so it doesn't mess-up the list size?

Can you clarify what bugs you the most about this? Is it the font size in the menus?

I do realize the menu we are mimicking here looks pretty big too, and we can certainly do better. But this is how it looks in the current editor:

screen shot 2017-06-09 at 09 19 27

But let me know what your primary concerns are, and I'll see if I can think up something to make us all happy. Right now I'm pretty happy though, and I think if we can get a signoff from @youknowriad we might just want to merge this in and iterate.

styleText.split( ';' ).map(
( stylePart ) => {
const [ cssKey, cssValue ] = stylePart.split( ':', 2 );
const reactKey = cssKey.split( '-' ).map(
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we use lodash's camelCase utility?

Copy link
Author

Choose a reason for hiding this comment

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

Yep that seems to work perfectly. I did not know it existed.

*/
import './format-list.scss';

function naiveCss2Jsx( styleText ) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we unit test this utility?

Copy link
Author

Choose a reason for hiding this comment

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

Certainly can. I have added unit tests for the format stylings that TinyMCE is outputting.

render() {
const { formats } = this.props;
const selectedValue = this.props.value;
const noFormat = { text: wp.i18n.__( 'No format' ), value: null };
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we use the gutenberg wp modules consistently? I mean avoid using the global wp and use import { __ } from 'i18n';?

Copy link
Author

Choose a reason for hiding this comment

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

Ok, I have done that.

@jasmussen
Copy link
Contributor

Did text selection break in this branch? I can't seem to select text.

@androb
Copy link
Contributor

androb commented Jun 9, 2017

@jasmussen I'm seeing selection problems too

@jasmussen
Copy link
Contributor

To be clear I'm not convinced they are from this branch. I could swear I saw it in master recently.

@BoardJames
Copy link
Author

Note that the failing checks are also failing on master - it looks like someone merged a broken test.

@BoardJames
Copy link
Author

Text selection is currently broken on master and as far as I can tell the problems have nothing to do with this block.

@BoardJames
Copy link
Author

@jasmussen

Can you clarify this a little bit, especially the last bit about an H1?

I am accessing the format levels from TinyMCE. The TinyMCE editor object has a property called buttons which contains a list of all the buttons that have been registered either by the TinyMCE core or by plugins. Included in that list is the formatselect which contains a list of available TinyMCE formats.
tinyMCE.activeEditor.buttons.formatselect().values
Each of those values has 3 properties:

  • text - the text representation i.e. "Paragraph"
  • value - the editor representation i.e. "p"
  • textStyle - a function that returns the css representing the format i.e. 'font-family:"Noto Serif",serif;font-size:16px;font-weight:400;font-style:normal;text-decoration:none;text-transform:none;color:rgb(68, 68, 68);background-color:transparent;border:;border-radius:;outline:;text-shadow:none;'

At run time I am converting the output from that textStyle attribute into a JSX compatible format

{
  fontFamily: '"Noto Serif",serif',
  fontSize: '16px',
  fontWeight: '400',
  fontStyle: 'normal',
  textDecoration: 'none',
  textTransform: 'none',
  color: 'rgb(68, 68, 68)',
  backgroundColor: 'transparent',
  border: '',
  borderRadius: '',
  outline: '',
  textShadow: 'none',
}

and then removing the color and backgroundColor rules so they don't interfere with the background rendering as otherwise highlighting the menu background on selection doesn't work. I could retain the colour rules if I used indicators next to the text instead of behind it but that wouldn't match up with other select-lists in gutenberg.

I'd like to see if we can do a few more tweaks to it — the font sizes for the headings don't have to be identical to the ones actually in the document, we can relax those a bit

I would like to write the code that displays the formats so it will automatically adjust to any formats (as opposed to hard-coding styles for each "original" format). I could scale the sizes by finding the largest and smallest and then scaling everything so it fits within a range and everything is proportional. Would that work?

preformatted needs to match a font both in the freeform block and the dropdown to the font stack used by the separate preformatted block.

The stylesheet for the freeform block is probably wrong currently - I will look into it.

[W]e might also want to change the color of items in this dropdown.

Do you mean you want the colours of the items to match the styling on the page (in which case I'll have to change how selection is represented) or that you want different selection colours like in the old version you provided the screenshot from?

Can you clarify what bugs you the most about this? Is it the font size in the menus?

The vertical height used by it annoys me the most so scaling the font sizes might address it. The other thing that annoys me is that the drop-down list is now wider than the menu. The only alternative I could think of is keeping the menu options the normal size but rending a preview on hover next to the option.

@BoardJames
Copy link
Author

I realized I was missing styling from the heading block, preformatted block and editable.
freeform-block-format-selector-2

@BoardJames
Copy link
Author

I tweaked the line height so there wasn't so much whitespace around the larger items.
freeform-block-format-selector-3

@BoardJames
Copy link
Author

@jasmussen

Right now I'm pretty happy though, and I think if we can get a signoff from @youknowriad we might just want to merge this in and iterate.

Since I haven't heard back from you and I think everything is correct I'll merge it and then it can be iterated on.

@BoardJames BoardJames merged commit c650280 into master Jun 12, 2017
@BoardJames BoardJames deleted the update/972-Freeform-block-add-format-selector branch June 12, 2017 23:55
@BoardJames
Copy link
Author

The text selection issue seems to have been fixed on editable by #1104 so I have put in a pull request to fix it for the freeform block #1163 .

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.

6 participants