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

Fixed background grey of the Shortcode block placeholder screen #14719

Merged
merged 3 commits into from
Apr 10, 2019

Conversation

mapk
Copy link
Contributor

@mapk mapk commented Mar 30, 2019

Description

Changed the background grey of the shortcode block to match all the other placeholder setup screens on other blocks. Fixes #14718

How has this been tested?

Tested locally.

Before

shortcode

After

Screen Shot 2019-03-29 at 8 34 52 PM

Types of changes

Changed the variable used for the background grey.

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.
  • I've included developer documentation if appropriate.

@mapk mapk self-assigned this Mar 30, 2019
@paulwilde
Copy link
Contributor

It would also make sense to add support for dark themes to be even more consistent with the placeholder component:

.is-dark-theme & {
    background: $light-opacity-light-200;
}

@mapk
Copy link
Contributor Author

mapk commented Apr 1, 2019

Here's how it looks now.

Screen Shot 2019-04-01 at 11 51 06 AM

@mapk
Copy link
Contributor Author

mapk commented Apr 1, 2019

Also, the dark mode work for the setup screen.

Screen Shot 2019-04-01 at 12 47 04 PM

There is a problem about the placeholder text being lost in the field, but this applies to multiple blocks which should be addressed in another PR.

@Soean Soean added the [Feature] Shortcodes Related to shortcode functionality label Apr 1, 2019
@mapk
Copy link
Contributor Author

mapk commented Apr 5, 2019

@gziolo Can you review this for me? I had made some changes, then noticed some conflicts with changes you had made earlier. I rebased and force pushed this bad boy, and want to make sure I did it all right. If we're good, can I get your approval?

Copy link
Member

@gziolo gziolo left a comment

Choose a reason for hiding this comment

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

Can you review this for me? I had made some changes, then noticed some conflicts with changes you had made earlier. I rebased and force pushed this bad boy, and want to make sure I did it all right. If we're good, can I get your approval?

All good 👍 There are more changes coming to all core blocks. We need those refactorings to validate all the assumptions made in RFC (#13693).

@gziolo gziolo requested a review from jasmussen April 8, 2019 07:30
@@ -10,8 +10,8 @@ const ShortcodeEdit = ( { attributes, setAttributes, instanceId } ) => {
const inputId = `blocks-shortcode-input-${ instanceId }`;

return (
<div className="wp-block-shortcode">
<label htmlFor={ inputId }>
<div className="wp-block-shortcode components-placeholder">
Copy link
Member

Choose a reason for hiding this comment

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

@jasmussen - can you advice how it could be coded differently? In general, we assume that class names are local to the component which define them. In this case, it's wp.components.Placeholder which uses components-placeholder. While it seems to be very convenient to use an existing class, it doesn't scale well as we learned down the road.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah this is an interesting question.

I would say there are two ways to go.

  1. Keep the shortcode block as its own thing. But then we remove the placeholder classes and duplicate the CSS rules necessary for them to look the same.
  2. Rewrite/potentially redesign the shortcode to actually use the placeholder component.

2 is a bigger task, and I have no strong opinions on which one is the right way to go. What do you think?

Copy link
Member

@gziolo gziolo Apr 8, 2019

Choose a reason for hiding this comment

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

Well, I'm seeing that components-placeholder* classes are used in several places for other core blocks as well :(

@youknowriad or @aduth - what would be the best way moving forward to tackle it? We definitely need to clean it up.

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 a placeholder component? What does it mean? Does it make sense as a separate component?

Copy link
Contributor

Choose a reason for hiding this comment

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

One of the main issues with duplicating the class like this is maintainability. If someone wants to refactor the placeholder styles, they'd generally expect only the <Placeholder> component to be affected, but in this case other components can be affected in an unexpected way.

What is a placeholder component?

In the context of a block, it seems like it's the UI that's displayed when the proper wysiwyg part of a block can't be shown. Outside of the context of a block, I'm not really sure. The word 'placeholder' generally implies a stopgap that will eventually be replaced, but I'm not sure how that applies to other user interfaces that @wordpress/components might be used in.

A couple of other options might be:

  1. Extend Placeholder to support other layouts, like the horizontal layout shown here
  2. Extract the container of the placeholder into a separate component (PlaceholderCard?) and use that.

Copy link
Member

@gziolo gziolo left a comment

Choose a reason for hiding this comment

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

Looks good.

We should open a follow-up issue where we cover the part about reusing class names from existing components.

@mapk mapk merged commit 17f8d86 into master Apr 10, 2019
@youknowriad youknowriad deleted the update/shortcode-grey branch April 11, 2019 07:18
@youknowriad youknowriad added this to the 5.5 (Gutenberg) milestone Apr 12, 2019
mchowning pushed a commit to mchowning/gutenberg that referenced this pull request Apr 15, 2019
…Press#14719)

* Changed the background grey of the shortcode block to match all the other placeholder setup screens on other blocks. Fixes WordPress#14718

* Restyled shortcode block to match placeholder block styling.

* Rebased and force pushed to catch up with changes made to this file since @gziolo made some changes.
This was referenced Apr 15, 2019
@youknowriad
Copy link
Contributor

I wonder if this is related to these changes here #15032

@aduth
Copy link
Member

aduth commented Apr 18, 2019

We should open a follow-up issue where we cover the part about reusing class names from existing components.

@youknowriad or @aduth - what would be the best way moving forward to tackle it? We definitely need to clean it up.

Sorry I missed this until now. I agree this shouldn't be done this way, and was part of the reason for #14556 in more strongly asserting that the class name should never be used outside its own component.

A component's class name should never be used outside its own folder (with rare exceptions such as _z-index.scss). If you need to inherit styles of another component in your own components, you should render an instance of that other component. At worst, you should duplicate the styles within your own component's stylesheet. This is intended to improve maintainability by treating individual components as the isolated abstract interface.

I would much rather have seen the styles duplicated, or to make some separate component which encompasses what it is we're trying to do with this padded gray container. But to me, the "padded gray container" is what the Placeholder component is trying to be. Whether it supports the desired use-case, it either (a) should be made to or (b) the desired use-case should be changed to align to what the Placeholder is meant to be used for.

Is it not enough to do something like:

<Placeholder
	icon="shortcode"
	label={ __( 'Shortcode' ) }
>
	<PlainText /* ... */ />
</Placeholder>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Shortcodes Related to shortcode functionality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Grey placeholder color is inconsistent in the Shortcode block
8 participants