Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
The Quickedit module has JavaScript which applies inline styles to the currently edited element.
This makes overriding the padding and positioning difficult.
In: FieldDecorationView.js the _pad and _unpad functions add positioning padding and margin and a fixed width which cannot be configured or easily disabled.
Steps to reproduce
On any page with Quickedit active, click an editable area, such as a block of text to edit. The div will now have inline styles added in addition to several classes.
Proposed resolution
1. Remove the javascript related to _pad and _unpad
This seems to predate the css border-box property since it includes code for setting padding independent of the width.
2. Replace the padding by toggling a css class so that it can be overridden by a theme or a class added by a loaded editor.
The padding should still be optional by the object returned from the getQuickEditUISettings function.
Remaining tasks
- Get agreement this code can be safely removed
- Remove the existing code and replace with a class toggle
- Add css for the new class to
quickedit.theme.css.
Issue fork drupal-3196689
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #3
zrpnrComment #4
wim leersI am 90% certain that this was done to be as portable/robust as possible — not every theme has a predictable set of selector specificity, and hence generic CSS could easily break, especially for common CSS properties such as
padding. Note that the inline CSS is also carefully reverted.AFAICT the proposed changes still suffer from that weakness?
Comment #5
wim leersComment #6
zrpnrBut in this case, isn't it desirable for a theme to be able to override the quickedit styles?
The inline style is the highest specificity (except for
!important) and means the px values on padding are too robust.Also, the js appears to have been written before CSS3 box-sizing property was in wider use, since the comments refer to how "padding changes affect width". The js sets a fixed width on the element as well as adding a top and left offset.
I had a tough time step-debugging where this happens- but the top and left values seem to be removed when CKEditor instantiates. In other editors it would cause a visible "jump" as the editable area position is offset. When the editable area is blurred that calculated offset remains and can compound.
Since the purpose of this js is apparently just to add padding, I'm confused as to why this wouldn't be better handled in css where it is more understandable, flexible and overridable.
Comment #7
wim leersFair point!
Back then, the rationale was that not every theme should need to bear the burden of Quick Edit-specific CSS just to support Quick Edit. This is how Quick Edit was able to avoid all the theme-specific CSS pains that Settings Tray has been seeing.
This I am less certain about, but I vaguely recall this being about Quick Edit working with all themes, regardless of what
box-sizingthe affected elements use in the currently active theme.Does that make sense? I could be completely wrong here :)
For the reason cited at the beginning of this comment 🤓
Comment #10
spokjeDue to Quickedit being moved out of Drupal Core and into a Contrib Module, moving this issue to the Contrib Module queue.