Unwanted Changes to Bootstrap Clearfix Settings in the WYSIWYG Editor

Help / Discuss
1

When using Bootstrap’s clearfix utility to clear floated content within a container, you might include the following wiki syntax:

(% class="clearfix visible-md-block" %)((()))

However, after saving the page in the WYSIWYG editor, the syntax is modified as follows:

(% class="clearfix visible-md-block" %)
(((
 
)))

This change introduces extra space, which affects the layout of the floating content.

Is there a specific reason why the WYSIWYG editor alters the ((())) syntax? Any idea for a solution or a workaround?

2

The same happens for every other layout-relevant classes like (% class="page-break" %)((())) for PDF export settings, which results in unwanted free space in the page layout after saving in the WYSIWYG editor.

3

Hi,

CKEditor fills empty blocks, by default, with a non-breaking space to force them have a height. There is a configuration option that controls this: fillEmptyBlocks. See Class Config (CKEDITOR.config) | CKEditor 4 API docs . You can also use a JavaScript function as the value of this configuration option to decide in which case the filler should be avoided.

Hope this helps,
Marius

1 Like
4

That didn’t work in my test environment (local XWiki 16.10.5).

Interestingly, the editor itself applies the following CSS (from Flamingo/Sandstone), which seems to work within the editor but not in page view mode:

.visible-xs, .visible-sm, .visible-md, .visible-lg {
    display: none !important;
}
.visible-xs-block, .visible-xs-inline, .visible-xs-inline-block, .visible-sm-block, .visible-sm-inline, .visible-sm-inline-block, .visible-md-block, .visible-md-inline, .visible-md-inline-block, .visible-lg-block, .visible-lg-inline, .visible-lg-inline-block {
    display: none !important;
}

I additionally added an XWiki.StyleSheetExtension to hide <p>&nbsp;</p> inside <div class="clearfix …"><p>&nbsp;</p></div>, and that successfully fixed the issue:

.page-break p,
.clearfix p {
    display: none;
}
5

As a suggestion, instead of introducing this wiki syntax in a lot of places, you could create a custom wiki macro with this content that would also be easier to use in the WYSIWYG editor and that won’t suffer from this problem.

1 Like