Cover: Add custom unit support for height controls #20888
Conversation
Size Change: +1.99 kB (0%) Total Size: 863 kB
|
Filename | Size | Change | |
---|---|---|---|
build/a11y/index.js |
998 B | 0 B | |
build/autop/index.js |
2.58 kB | 0 B | |
build/blob/index.js |
620 B | 0 B | |
build/block-directory/style-rtl.css |
760 B | 0 B | |
build/block-directory/style.css |
760 B | 0 B | |
build/block-library/editor-rtl.css |
7.21 kB | 0 B | |
build/block-library/editor.css |
7.21 kB | 0 B | |
build/block-library/style-rtl.css |
7.5 kB | 0 B | |
build/block-library/style.css |
7.51 kB | 0 B | |
build/block-library/theme-rtl.css |
669 B | 0 B | |
build/block-library/theme.css |
671 B | 0 B | |
build/block-serialization-spec-parser/index.js |
3.1 kB | 0 B | |
build/components/style-rtl.css |
15.8 kB | 0 B | |
build/components/style.css |
15.7 kB | 0 B | |
build/compose/index.js |
6.2 kB | 0 B | |
build/deprecated/index.js |
772 B | 0 B | |
build/dom-ready/index.js |
568 B | 0 B | |
build/dom/index.js |
3.06 kB | 0 B | |
build/edit-post/index.js |
92.3 kB | 0 B | |
build/edit-post/style-rtl.css |
8.35 kB | 0 B | |
build/edit-post/style.css |
8.34 kB | 0 B | |
build/edit-site/style-rtl.css |
3.44 kB | 0 B | |
build/edit-site/style.css |
3.44 kB | 0 B | |
build/edit-widgets/style-rtl.css |
2.57 kB | 0 B | |
build/edit-widgets/style.css |
2.57 kB | 0 B | |
build/editor/editor-styles-rtl.css |
423 B | 0 B | |
build/editor/editor-styles.css |
426 B | 0 B | |
build/editor/style-rtl.css |
3.38 kB | 0 B | |
build/editor/style.css |
3.38 kB | 0 B | |
build/escape-html/index.js |
733 B | 0 B | |
build/format-library/style-rtl.css |
502 B | 0 B | |
build/format-library/style.css |
502 B | 0 B | |
build/html-entities/index.js |
622 B | 0 B | |
build/list-reusable-blocks/index.js |
2.99 kB | 0 B | |
build/list-reusable-blocks/style-rtl.css |
226 B | 0 B | |
build/list-reusable-blocks/style.css |
226 B | 0 B | |
build/nux/style-rtl.css |
616 B | 0 B | |
build/nux/style.css |
613 B | 0 B | |
build/priority-queue/index.js |
781 B | 0 B | |
build/token-list/index.js |
1.28 kB | 0 B | |
build/viewport/index.js |
1.61 kB | 0 B | |
build/wordcount/index.js |
1.18 kB | 0 B |
Hi! I may have missed a detail, but was wondering: what are some intended use cases for allowing the customisation of the unit set beyond px, em, rem, vw, vh? |
* @return array Filtered editor settings. | ||
*/ | ||
function gutenberg_extend_settings_custom_units( $settings ) { | ||
$settings['__experimentalDisableCustomUnits'] = get_theme_support( 'disable-custom-units' ); |
mtias
Mar 16, 2020
Contributor
Should this support a second argument where the theme can say which should be the unit shown / used? Like get_theme_support( 'disable-custom-units', 'rem' )
would force rem to be used in all unit-based selectors.
Should this support a second argument where the theme can say which should be the unit shown / used? Like get_theme_support( 'disable-custom-units', 'rem' )
would force rem to be used in all unit-based selectors.
ItsJonQ
Mar 17, 2020
Author
Contributor
Good suggestion! Let me make that adjustment ✨
Good suggestion! Let me make that adjustment
@mcsf Haii!! There are many other units beyond the defaults I've set for the base Hope this makes sense |
@mtias I just pushed an update! This adds support for additional parameters for For example: // This will disable all custom units
add_theme_support( 'disable-custom-units' );
// This will enable only rem
add_theme_support( 'disable-custom-units', 'rem' );
// This will enable only rem and em
add_theme_support( 'disable-custom-units', 'rem', 'em' ); If, say, only Lemme know how this API feels for you :) In other news... There may be race conditions where a block (by default) expects a We have a bit of this in the case of Cover. To test...
|
This looks good. Yes, there will be several things to tweak to account for units being a "thing" now across blocks, but we'll get there. It might make sense to rename the theme support from |
@mtias Done |
I've left some notes, but other than that let's keep it moving! |
@@ -32,6 +32,9 @@ | |||
"minHeight": { | |||
"type": "number" | |||
}, | |||
"minHeightUnit": { | |||
"type": "string" |
mcsf
Mar 19, 2020
Contributor
I assume from this that it is preferred to let components like CoverHeightInput
decide based on an undefined value, correct? Otherwise we might add a default
value here.
I assume from this that it is preferred to let components like CoverHeightInput
decide based on an undefined value, correct? Otherwise we might add a default
value here.
style.minHeight = minHeight || undefined; | ||
style.minHeight = minHeightUnit | ||
? `${ minHeight }${ minHeightUnit }` | ||
: minHeight || undefined; |
mcsf
Mar 19, 2020
Contributor
I for one had to go check the operator precedence table for logical OR and ternary conditional to make sure I was reading this correctly. :) I recommend parentheses in this situations.
I for one had to go check the operator precedence table for logical OR and ternary conditional to make sure I was reading this correctly. :) I recommend parentheses in this situations.
export const BASE = { | ||
black: '#000', | ||
white: '#fff', | ||
}; | ||
|
||
export const G2 = { |
mcsf
Mar 19, 2020
Contributor
Maybe add TODO-type comment explaining what G2 means (succinctly, focused on why this object is separate from the other colors) and with a note on when it would be a good time to consolidate all of this. Otherwise other devs in a few months won't have a clue of what this means. :)
Maybe add TODO-type comment explaining what G2 means (succinctly, focused on why this object is separate from the other colors) and with a note on when it would be a good time to consolidate all of this. Otherwise other devs in a few months won't have a clue of what this means. :)
@mcsf Thank you so much for your feedback |
@mcsf Hmm! It looks like adding the default I'm not sure how to fix it. It looks like the fixture ( |
It also means you need a deprecated version for the block, otherwise, it's going to invalidate existing blocks. |
export const COLORS = { | ||
...BASE, | ||
darkGray: DARK_GRAY, | ||
darkGray: merge( DARK_GRAY, G2.darkGray ), |
aduth
Mar 20, 2020
Member
This is mutating DARK_GRAY
, such that every reference to DARK_GRAY
would subsequently contain properties of G2.darkGray
. I don't think that's the intention?
Suggested change
darkGray: merge( DARK_GRAY, G2.darkGray ),
darkGray: merge( {}, DARK_GRAY, G2.darkGray ),
A few other instances in this file as well.
This is mutating DARK_GRAY
, such that every reference to DARK_GRAY
would subsequently contain properties of G2.darkGray
. I don't think that's the intention?
darkGray: merge( DARK_GRAY, G2.darkGray ), | |
darkGray: merge( {}, DARK_GRAY, G2.darkGray ), |
A few other instances in this file as well.
ItsJonQ
Mar 20, 2020
Author
Contributor
Oh! I didn't know it mutates. Thank you! Will fix those up
Oh! I didn't know it mutates. Thank you! Will fix those up
Rebased with latest |
@youknowriad Haiii! I'm following up on this PR :). I'm not sure how to proceed with deprecation. For this particular change, would adding a new Thank you! |
The block-editor variant of UnitControl has add_theme_support built in
…ble-custom-units' )`
Yay! Looks like Travis green and happy! Excited for this one to land. Merging it up! |
|
||
const baseUnitLabelStyles = ( props ) => { | ||
return css` | ||
appearance: none; |
oandregal
Apr 13, 2020
Member
I'm testing this on Firefox 75 in a Linux OS and the input control in Firefox includes the stepper arrows buttons:
while in Chrome it doesn't:
For what is worth, I've tried with -moz-appearance: textfield
and, as far as my testing went, it worked as expected (arrow up/down with the keyboard still increases/decreases the number) and the steppers are not shown.
I'm testing this on Firefox 75 in a Linux OS and the input control in Firefox includes the stepper arrows buttons:
while in Chrome it doesn't:
For what is worth, I've tried with -moz-appearance: textfield
and, as far as my testing went, it worked as expected (arrow up/down with the keyboard still increases/decreases the number) and the steppers are not shown.
mcsf
Apr 13, 2020
Contributor
I'm testing this on Firefox 75 in a Linux OS
Firefox (76) on macOS is also affected.
I'm testing this on Firefox 75 in a Linux OS
Firefox (76) on macOS is also affected.
For people like me who don't know why this option is not available in the editor of cover block and find that PR, it's because the theme didn't enable custom units: add_theme_support( 'custom-units' ); // this allow the post author to select other CSS units than "px" |
ItsJonQ commentedMar 13, 2020
•
edited
Description
This update adds a new (experimental)
UnitControl
that enables values beyond pixels! For Cover block, this control unlocks the ability to setpx
,em
,rem
,vw
andvh
values.(Note: Although
%
is supported, it's omitted from the Cover block control as%
height does not render predictably).How has this been tested?
UnitControl
andNumberControl
were tested in Storybook and GutenbergUnitControl
x Cover block integration was developed and tested in local GutenbergScreenshots
The GIF above showcases the flow for changing values and unit values for the Cover block.
Types of changes
UnitControl (and NumberControl)
These new experimental components have been added to
@wordpress/components
. TheUnitControl
is the component that powers the input for setting the height for the Cover block.Shift Increment
One of the features with this new control is to jump values when holding down
shift
while pressingup
ordown
(default is by10
). This interaction is common for other Design applications like Figma, Sketch, Photoshop, etc...Note: This feature can be customized and even disabled in the base component.
Switching Units
The original behaviour defaults to a min-height of
50px
, but only if the user makes a change. This interaction is preserved in this update.To improve the canvas rendering of Cover, switching units would "reset" the Cover to predetermined values for each unit. This is to prevent the Cover block's height from unexpectedly jumping to
3000px
if they switch to avh
orvw
unit.Drag Resize Handling
Dragging to resize will "reset" the unit back to px. This interaction decision was made as it is very difficult to accurately translate pixel by pixel drag values to their respective
vh
orem
values.Simulated Height Rendering
Cover's canvas rendering is simulated as best as possible given the value and unit type. For example,
vh
andvw
can be accurately rendered. Whereas we have to take the best guess for units likeem
orrem
.Tests
These updates have been tested locally in Gutenberg. Unit tests need to be written for the new
UnitControl
andNumberControl
components.Checklist:
Resolves:
#20567 (comment)