Enable user-specified CSS classes via Inspector field #1889
Conversation
aduth
added
the
General Interface
| @@ -34,8 +35,7 @@ const BlockInspector = ( { selectedBlock } ) => { | |||
| export default connect( | |||
| ( state ) => { | |||
| return { | |||
| selectedBlock: getSelectedBlock( state ), | |||
| hasSelectedBlock: !! getSelectedBlock( state ), | |||
There was a problem hiding this comment.
I was going to include the block name somewhere in the UI.
There was a problem hiding this comment.
I was going to include the block name somewhere in the UI.
Can always change it back with your changes 😉
| return <span className="editor-block-inspector__no-blocks">{ __( 'No block selected.' ) }</span>; | ||
| } | ||
|
|
||
| return ( | ||
| <Panel> | ||
| <PanelBody> | ||
| <BlockInspectorClassName /> |
There was a problem hiding this comment.
This should be rendered after the slot, and probably include a separator (hr).
Dispatch only auto-bound when object argument, not function returning object. See also: bindActionCreators
aduth
force-pushed
the
add/inspector-class-name
branch
from
3d17c86 to
3f84d6c
Compare
|
@mtias is something similar planned for allowing inline css style? Would be useful for Headers and elsewhere. |
|
@lkraav nothing planned for it. The point being you would add the class and style separately. What was the use case you had in mind? Inline styles would make further modifications more difficult, make theme switches potentially harder, and affect context like feeds, readers, email in ways the user cannot anticipate. |
Use case is mainly landing/sales pages. One can template (aka try to generalize how content should look) all one wants, but when copywriting across products is going to be different length, different concepts presented, etc, adjusting specific things quickly per-page/product via inline styling is the fastest and most productive workflow. It doesn't necessarily have to be in core, if we are really looking to save people from shooting themselves in the foot and are thinking that not making some basic html/css level tools available would help it. As long as there's an interface for a plugin to hook in and provide this ability, that would probably work for people handling "Advanced" cases. |
Related: #887
This pull request seeks to add an "Additional CSS Class" field to the Block Inspector for all blocks which do not explicitly opt out from the
classNameblock type field. If the user provides a value fro this field, it is automatically applied to the serialized content for that block.Testing instructions:
Verify that the "Additional CSS Class" field shows in the Block Inspector for all applicable block types, and that the value is included in the serialized content.
classNamefield (e.g. text block), the "Additional CSS Class" field is not shownCaveats:
The behavior of block description is such that the "Additional CSS Class" field is shown before the description in the inspector. Per feedback at #1555 (comment), I'd like to separately explore refactoring description to be a property of the block type itself.