Skip to content

Don't hardcode CSS units #32482

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.

Sign up for GitHub

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

Merged
aristath merged 6 commits into from
Jun 10, 2021
Merged

Don't hardcode CSS units #32482

Changes from 1 commit
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
0f770aa
letter-spacing
aristath Jun 7, 2021
8eafae5
expose ALL_CSS_UNITS
aristath Jun 7, 2021
c36f3ba
border
aristath Jun 7, 2021
f169091
Add defaults to letter-spacing
aristath Jun 7, 2021
afdf29d
expose parseUnit instead of ALL_CSS_UNITS
aristath Jun 10, 2021
2a5af57
rename parseUnit to __experimentalParseUnit
aristath Jun 10, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Add defaults to letter-spacing
  • Loading branch information
@aristath
aristath committed Jun 10, 2021
commit f1690919730016b33d83d4a544a6e94a12a33de9
1 change: 1 addition & 0 deletions packages/block-editor/src/components/letter-spacing-control/index.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -23,6 +23,7 @@ import useSetting from '../../components/use-setting';
export default function LetterSpacingControl( { value, onChange } ) {
const units = useCustomUnits( {
availableUnits: useSetting( 'layout.units' ) || [ 'px', 'em', 'rem' ],
Copy link
Contributor

@youknowriad youknowriad Jun 10, 2021

Choose a reason for hiding this comment

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

in which situation the fallback is necessary?

Copy link
Member Author

@aristath aristath Jun 10, 2021

Choose a reason for hiding this comment

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

If for some reason value can't be retrieved from a theme.json file then the fallback will be used. It's a "better safe than sorry" fallback to make sure nothing breaks.

Copy link
Contributor

@youknowriad youknowriad Jun 10, 2021

Choose a reason for hiding this comment

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

It feels we should have a system that provide defaults in the block-editor package for all settings instead of repeating the same code over and over in all places.

Copy link
Contributor

@youknowriad youknowriad Jun 10, 2021

Choose a reason for hiding this comment

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

@nosolosw @jorgefilipecosta how defauts for the block-editor are provided now? (I mean in the frontend without the core theme.json)

Copy link
Member

@oandregal oandregal Jun 10, 2021

Choose a reason for hiding this comment

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

To make sure I follow: do you mean what happens in the editor when a theme doesn't provide a theme.json? In the specific case of layout.units we don't provide a fallback. We do for some things like spacing.units. We pre-populate the block editor store with defaults, but we also don't do that for __experimentalFeatures.

Adding the fallback in the useSetting hook sounds like something we should explore.

Copy link
Contributor

@youknowriad youknowriad Jun 10, 2021

Choose a reason for hiding this comment

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

I'm fine if the defaults are duplicated between client and server, if there's a valid reason for it. The endpoint for settings is good to get the settings that are not "defaults" but for the defaults, I don't see the issue for mobile.

Copy link
Member

@oandregal oandregal Jun 10, 2021

Choose a reason for hiding this comment

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

How do you feel passing defaults as initialization to the block editor?

The fact that we have them in multiple places (client defaults for the store, useSetting, server, etc) has been problematic in the past and this issue is also a good demonstration of that.

Copy link
Contributor

@youknowriad youknowriad Jun 10, 2021

Choose a reason for hiding this comment

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

How do you feel passing defaults as initialization to the block editor?

I think the editor should have defaults bundled, and not require passing settings to work properly.

Copy link
Contributor

@youknowriad youknowriad Jun 10, 2021

Choose a reason for hiding this comment

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

the reason is simple, the block-editor package is independent and it's really not great to force its users to pass a complex settings object to get sane defaults.

Copy link
Member

@oandregal oandregal Jun 15, 2021

Choose a reason for hiding this comment

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

I've prepared #32702 that adds a default value for __experimentalFeatures in the @wordpress/block-editor package. It ports the existing defaults set by the core theme.json.

defaultValues: { px: '2', em: '.2', rem: '.2' },
} );
return (
<UnitControl
Expand Down