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

Fix small lineheight issue in editor style #10345

Merged
merged 2 commits into from Oct 4, 2018

Conversation

Projects
None yet
3 participants
@jasmussen
Contributor

jasmussen commented Oct 4, 2018

In the editor, the line-height for text is 1.8. This is assigned on the Rich Text component directly.

But when you apply a text style manipulation, then reset it, this lineheight disappears, for some reason I'm not fully understanding.

This PR fixes that by simply assigning the lineheight to the p in the editor style.

To your incoming question: why doesn't the P inherit the lineheight from the body? Well, because WordPress itself applies a 1.5 lineheight to the p tag directly, which our editor inherits

(ノ°Д°)ノ︵ ┻━┻

GIF of the bug:

the bug

GIF of the fix:

fix

Fix small lineheight issue in editor style
In the editor, the line-height for text is 1.8. This is assigned on the Rich Text component directly.

But when you apply a text style manipulation, then reset it, this lineheight disappears, for some reason I'm not fully understanding.

This PR fixes that by simply assigning the lineheight to the p in the editor style.

To your incoming question: why doesn't the P inherit the lineheight from the body? Well, because WordPress itself applies a 1.5 lineheight to the p tag directly, which our editor inherits

(ノ°Д°)ノ︵ ┻━┻

@jasmussen jasmussen added the [Type] Bug label Oct 4, 2018

@jasmussen jasmussen added this to the 4.1 milestone Oct 4, 2018

@jasmussen jasmussen self-assigned this Oct 4, 2018

@jasmussen jasmussen requested a review from WordPress/gutenberg-core Oct 4, 2018

@tofumatt

But when you apply a text style manipulation, then reset it, this lineheight disappears, for some reason I'm not fully understanding.

I would really like to understand why this is, because it sounds like a bug.

@chrisvanpatten

This comment has been minimized.

Show comment
Hide comment
@chrisvanpatten

chrisvanpatten Oct 4, 2018

Contributor

Oh man I noticed this too. No insight into why, but I'm glad I'm not the only one.

Contributor

chrisvanpatten commented Oct 4, 2018

Oh man I noticed this too. No insight into why, but I'm glad I'm not the only one.

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Oct 4, 2018

Contributor

Okay good feedback.

The editing canvas is subject to CSS bleed from WordPress. This is a little frustrating for folks styling the editor, they may have to override the lineheight for every element... at least the p element is styled by WordPress itself.

In 1a136e2, though, I moved the rule up a level, which solves the issue.

Specifically, the lineheight rule was previously assigned to .editor-rich-text__tinymce.mce-content-body, now it's simply assigned to .editor-rich-text__tinymce. The latter, for some reason, persists after you reset the text.

So maybe the bug that caused this is that .mce-content-body gets removed when resetting.

Contributor

jasmussen commented Oct 4, 2018

Okay good feedback.

The editing canvas is subject to CSS bleed from WordPress. This is a little frustrating for folks styling the editor, they may have to override the lineheight for every element... at least the p element is styled by WordPress itself.

In 1a136e2, though, I moved the rule up a level, which solves the issue.

Specifically, the lineheight rule was previously assigned to .editor-rich-text__tinymce.mce-content-body, now it's simply assigned to .editor-rich-text__tinymce. The latter, for some reason, persists after you reset the text.

So maybe the bug that caused this is that .mce-content-body gets removed when resetting.

@tofumatt

I tested this locally and it worked great! Worked for other blocks too like lists.

Thanks!

@tofumatt tofumatt modified the milestones: 4.1, 4.0 Oct 4, 2018

@tofumatt tofumatt merged commit a3e1058 into master Oct 4, 2018

2 checks passed

codecov/project 49.21% remains the same compared to 9c3e5f9
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@tofumatt tofumatt deleted the fix/lineheight-issue branch Oct 4, 2018

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