Skip to content

Fix icon size regression.#10987

Merged
jasmussen merged 2 commits intomasterfrom
fix/icon-sizes
Oct 24, 2018
Merged

Fix icon size regression.#10987
jasmussen merged 2 commits intomasterfrom
fix/icon-sizes

Conversation

@jasmussen
Copy link
Copy Markdown
Contributor

This is an alternative to #10938 which for whatever reason I can't rebase. The purpose is the same:

This PR fixes an icon size regression that was introduced in #9828. Basically SVG icons are between 20 and 24px.

If an SVG has an explicit width, it uses that width, within the boundaries of those extremes. But unfortunately it also means if the SVG doesn't have an explicit width or height, it collapses to the min-width and min-height.

This PR updates documentation, and adds explicit dimensions for all block icons used.

Before:

screen shot 2018-10-23 at 11 34 25

After:

screen shot 2018-10-23 at 11 39 07

This is an alternative to #10938 which for whatever reason I can't rebase. The purpose is the same:

This PR fixes an icon size regression that was introduced in #9828. Basically SVG icons are _between 20 and 24px_.

If an SVG has an explicit width, it uses that width, within the boundaries of those extremes. But unfortunately it also means if the SVG _doesn't_ have an explicit width or height, it collapses to the min-width and min-height.

This PR updates documentation, and adds explicit dimensions for all block icons used.

Before:

![screen shot 2018-10-23 at 11 34 25](https://user-images.githubusercontent.com/1204802/47352448-32d6d000-d6ba-11e8-8ab8-c83fea8e8b07.png)

After:

![screen shot 2018-10-23 at 11 39 07](https://user-images.githubusercontent.com/1204802/47352456-35392a00-d6ba-11e8-832e-a45f3772389c.png)
@jasmussen jasmussen added the [Type] Enhancement A suggestion for improvement. label Oct 24, 2018
@jasmussen jasmussen added this to the 4.2 milestone Oct 24, 2018
@jasmussen jasmussen self-assigned this Oct 24, 2018
@jasmussen jasmussen requested review from a team, chrisvanpatten and gziolo October 24, 2018 08:30

return icon();
} else if ( icon && icon.type === 'svg' ) {
} else if ( isSVGIcon( icon ) ) {
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I wanted to write this way simpler, like this:

	} else if ( icon && icon.type === 'svg' || icon && icon.type.name === 'SVG' ) {
		const appliedProps = {
			...icon.props,
			width: icon.props.width || 24,
			height: icon.props.height || 24,
		};
		return <SVG { ...appliedProps } />;
	}

But for whatever reason, this did not pass linting tests. I'm not sure why, as this implementation seems far more complex.

function isSVGIcon( icon ) {
if ( icon && icon.type === 'svg' ) {
return true;
} else if ( icon && icon.type.name === 'SVG' ) {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

You can check also refactor it as:

return icon && ( icon.type === 'svg' || icon.type === SVG );

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

You mean

return icon && ( icon.type === 'svg' || icon.type.name === SVG );

right?

If so, YAY, that's what I wanted! Thank you. Will update.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

screen shot 2018-10-24 at 11 40 22

Nope, my code is correct. .name is less reliable.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Oh really, will that work? Let me give it a shot! Thanks again.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

it's the same thing as with <svg - type is the name of the component that was used to create an actual element - in first case it's svg (string for html tag has special handling), in the second it's the SVG component.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Okay, pushed 1f4a19b — is that kosher? I don't like creating an entirely new function if we don't have to.

Copy link
Copy Markdown
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.

LGTM 👍

@chrisvanpatten
Copy link
Copy Markdown
Contributor

🚢

@jasmussen jasmussen merged commit 2a94b94 into master Oct 24, 2018
@jasmussen jasmussen deleted the fix/icon-sizes branch October 24, 2018 10:05
antpb pushed a commit to antpb/gutenberg that referenced this pull request Oct 26, 2018
* Fix icon size regression.

This is an alternative to WordPress#10938 which for whatever reason I can't rebase. The purpose is the same:

This PR fixes an icon size regression that was introduced in WordPress#9828. Basically SVG icons are _between 20 and 24px_.

If an SVG has an explicit width, it uses that width, within the boundaries of those extremes. But unfortunately it also means if the SVG _doesn't_ have an explicit width or height, it collapses to the min-width and min-height.

This PR updates documentation, and adds explicit dimensions for all block icons used.

Before:

![screen shot 2018-10-23 at 11 34 25](https://user-images.githubusercontent.com/1204802/47352448-32d6d000-d6ba-11e8-8ab8-c83fea8e8b07.png)

After:

![screen shot 2018-10-23 at 11 39 07](https://user-images.githubusercontent.com/1204802/47352456-35392a00-d6ba-11e8-832e-a45f3772389c.png)

* Pretty up the code a bit.
@mtias mtias added [Type] Bug An existing feature does not function as intended [Type] Regression Related to a regression in the latest release labels Oct 30, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

[Type] Bug An existing feature does not function as intended [Type] Enhancement A suggestion for improvement. [Type] Regression Related to a regression in the latest release

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants