add ability to show drop cap setting in paragraph block by default #45994
Conversation
fabiankaegy
added
[Feature] Extensibility
|
Size Change: +43 B (0%) Total Size: 1.83 MB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
The enhancement works as expected 👍
Since the dropCap isn't a global typography feature, does it make sense to add this setting to its default controls?
@aaronrobertshaw, what do you think?
|
Thanks for putting this PR together @fabiankaegy and the ping @Mamaduka 👍 Given drop cap is a bespoke control, only relevant to the paragraph block, and generally is still infrequently used, I think it not being a default control is the right approach. I'm not against themes or plugins being able to elevate its prominence but toggling a non-block-support control via the block supports configuration doesn't seem like the right place to me. You can find some additional context and history in #36334 (comment). As part of that conversation it was floated that the drop cap setting might be moved outside of the typography panel eventually. @jasmussen might have better insight into where the drop cap control best fits now the block inspector sidebar is continuing to evolve. Ultimately, I think it would be best to avoid muddying the block supports configuration if we can avoid it. |
|
One of the challenges we have with the dropcap control, right now, is that it's a blunt boolean toggle. You cannot change size, font, style, margin, row-span, or anything like that. And ideally, you should be able to control all of those, so you can truly customize and have elaborate designs. In fact, I believe TwentyTwentyTwo disables the drop-cap by default, making it entirely inaccessible, mainly because there isn't a guarantee that the default drop cap values will look good across the various bundled style variations. In that light, the control itself is due for some design ideation: what would it look like if it wasn't just a toggle, but a toggle that offered various drop cap styles? A toggle that when enabled offered additional tools such as rowspan, font, style, and spacing options. What would that look like? And perhaps more importantly, what would that look like in theme.json definitions? Those options seem worth figuring out as a starting point. Once we have a clearer picture of that, it might also be clearer whether it's a control that is useful to surface by default, and where to surface it. |
|
Is there an issue opened for adding these drop cap style options? |
I'm not aware of one. |
|
Closing this PR as the approach isn't the right fit :) |
|
Noting that I just ran into a project where dropcap's were prominently utilized in the frontend design and having to get all editors/authors to make all the additional clicks to set this on a paragraph block was not the most graceful experience for anyone. While I totally agree that the dropcap setting should not be exposed as a default, at least having the ability in code to do so for a specific site need (e.g. frontend design uses it on intro paragraph on posts) makes for a dramatically better editor experience. Re-opening for consideration as this feels like a decent "paper cut" sort of simple improvement that may not impact the large majority but for those who do benefit its a much better experience than the current experience. |
|
Does this issue/mockup, #51481 created since this PR, change the calculus? |
|
@jasmussen while those updates to the dropcap functionality are helpful from a design perspective, that issue doesn't seem to note whether it also allows for the ability to expose the dropcap in the Typography section by default or not. If that is intended as part of that effort, then yes that would solve the issue we're currently seeing with some client work. |
|
The reason drop cap is not exposed that commonly, is because the lack of customizability in styles, global or otherwise, means the appearance is unpredictable depending on line height, fonts, etc. By actually adding those controls, the reason to not expose drop cap by default, would help here. |
|
In my, albeit limited, experience with dropcap usage on client work the theme generally has a singular styling option for it and doesn't usually have a need for editors having flexibility as shown in #51481. It's pretty much on or off and the styling of it is inflexible and set. |
Indeed, and that's the problem the mockup has tried to solve. Whether we need that for this PR to land, or not, I've personally no strong opinion on. I'm mentioning this because I've asked several theme developers and designers why they choose not to turn on the drop cap feature in their block themes. Consistently the response is: the cap may look good in the default style variation, but as soon as a user picks another style variation, it entirely falls apart visually. So they choose to not even offer the option. If style variations, each, could ensure the cap looked appropriate to the context, my understanding is they would turn it on. This is a more longer term problem to solve, surely, but the reason for why they choose not to, seems reasonable to me, and a blunt instrument to force it on from elsewhere, while well-meaning (and nothing I'd block) will not solve that problem. |
|
@jasmussen yeah I think this here is a classic case of different usecases of WordPress looking for different things. I can fully understand how the drop cap setting as it stands today has little to no value to DIY folks / theme designers that want to provide a flexible experience. On the other hand in tightly designed environments that is exactly what we are looking for. The ability to change the visual appearance of every single occurrence of the drop cap is very much not what we would want. Instead we need to be able to define one style of drop cap for the specific design system and then just allow editors to allow / disallow it on a per paragraph basis. And what this issue was about is that this setting currently is very burried and therefore we would love a way like with all the other controls to determine whether to show it by default or not. |
It sounds like I'm missing some nuance here, sorry about that. In a tightly designed environment, wouldn't you be able to just set |
|
@jasmussen yes the current setting as it exists is exactly what we need / want. We just ideally would want a way to have the toggle shown in the tools panel by default. Not hidden behind the tools panel dropdown option |
OH! That was the nuance I was missing. Apologies. These are crazy days. On my mind is that the current flow, even when drop dap is supported, requires you to first add the control, and then toggle it, which is a bit roundabout virtually counting as "two toggles". About the prominence: "should you or shouldn't you add a drop cap", I may lean towards the latter and keep a low prominence because it can quickly get out of hand. But that's also not a strongly held opinion. I know that @richtabor is currently very busy elsewhere, but I vaguely recall stumbling upon a mockup of his, that tackled specifically the drop cap control and its prominence in the toolspanel. Perhaps there's something in his design that threads the needle between prominence and direct-access? |
|
For me we should just ship this PR and establish |
@youknowriad there has been some work on block support stabilization lately. I recently merged a PR (#67018) that stabilized |
|
@aaronrobertshaw Thanks, yeah I had missed that. I don't know what's your thoughts ? I have a feeling that
|
I think if we are going to change it, now is the time. It was only just released in 19.8. The backport for this change hasn't landed yet as it was taking a little extra time combining the stabilization of typography and border supports along with these common experimental flags, and needed a different approach e.g. within the block type class rather than via a filter.
Agreed. This option was purely to signal that we wanted to skip the automatic serialization of block support classes and styles on the wrapper of a block. |
I'm curious about your opinion :P and everyone else :). Are there any technical issues for using a top level property? Does it make more or less sense? |
I don't think there are technical issues for using the top-level property. It might require a polyfill until the minimum supported WP version has server-side block definitions that include it. To me, the There might be some further questions to answer if moving to a top-level property. What does this property's shape look like? I'm assuming it would mirror the block supports e.g. I don't have strong opinions on this but I probably lean a touch towards the top-level property now. My only concern is to minimise the time between 19.8's release and any change we make. I'm happy to tackle it although I have some AFK in a few days that could delay things a little. |
|
I think this discussion shouldn't block this PR though. @fabiankaegy would you be able to refresh the PR to use what's currently available in trunk. I guess that's |
…default # Conflicts: # packages/block-library/src/paragraph/edit.js
|
@youknowriad Updated 👍 |
There was a problem hiding this comment.
Thanks for the patience and iteration here @fabiankaegy 👍
This tests as advertised for me.
✅ Tested updating paragraph/block.json
✅ Tested with a filter tweaking the setting I added to block.json
| Optional Control | Default Control |
|---|---|
 |
 |
As a side note, I've tried to pull together a proof of concept for moving the stable default controls config to a top-level block type property over in #67729.
If that PoC turns into something we want to land, I'll revisit the changes here and update as required in a follow up.
🚢
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
fabiankaegy
deleted the
feature/allow-drop-cap-setting-to-be-on-by-default
branch
…efault via defaultControls config (WordPress#45994) Co-authored-by: fabiankaegy <[email protected]> Co-authored-by: Mamaduka <[email protected]> Co-authored-by: youknowriad <[email protected]> Co-authored-by: aaronrobertshaw <[email protected]> Co-authored-by: jasmussen <[email protected]> Co-authored-by: carolinan <[email protected]> Co-authored-by: jeffpaul <[email protected]> Co-authored-by: jordesign <[email protected]>
What?
Add the ability for developers to modify whether the Drop Cap setting should be shown by default in the paragraph block.
Closing: #45755
Why?
If the Drop Cap style is a commonly used tool it is frustrating that with the recent change to the tools panel there now always is an additional click to achieve this design. This update allows developers to modify which default controls get shown. Same as they already can for all the other tool panels that get registered via the block supports system.
How?
Adding the
isShownByDefaultproperty to theToolsPanelItemcomponent.Testing Instructions
You can test this in two ways:
dropCapoption to the__experimentalDefaultControlsin theblock.jsonof the paragraph block