Make CKEditor's alignment + underline buttons available (but not enabled by default)

What are the reasons for not mapping the left/center/right/justify buttons to align-left/align-center/align-right/align-justify classes, and providing default styling for those in system.base.css?

Why not add an optional core module called, say, "CKEditor formatting" with a dependence on CKEditor? This module would provide the additional buttons and css for alignment and underline.

I think that this approach will also allow the gathering of statistics so that we can work out how many sites use both vs only using CKEditor.

($0.02)

I'm very curious what would be the result of this discussion... in fact I tend to agree with both "sides".
My personal opinion is that I agree a little bit more with quicksketch. Leaving these buttons as an optional feature would save a group of users a headache with looking on how to enable them.

I'd say that providing quite a small set of classes to enhance the list of available features is still a relatively cheap (?) price for saving thousands of users the time required to enable the functionality they need.
Note: the buttons for which the discussion is happening don't have to be enabled by default, they could just be available.

The default solution will never satisfy the needs of all users, so I guess sooner or later someone will create a "CKEditor full" module (the power of Drupal :)) which would provide color buttons, font combos and such (that can be used in Full HTML).
However, if we remove too many buttons, too many users might be downloading a 3rd party module, with "all the evil" to bring them back.

So one of the questions to answer is: is it better to have more users running Drupal core with more features, or more users using a contrib module / unsatisfied.

I'm fine with having classes like align-[position] and styles in a system CSS file; I have a couple Drupal sites that have been in existence since 4.7.x, and have used a variety of editors. There are some pieces of content with old/unused FCKEditor classes like 'rtecenter', which aren't supported by TinyMCE or Wysiwyg. I just added a class to my more modern theme after upgrading the site to D7 for rtecenter. Not a big deal at all.

I think having the buttons in core, enabled by default, is pretty common-sense. I use the center align for pictures quite often if I'm using a Wysiwyg, though I often hand-code still :)

I can't think of any visual text layout software from the past 20 years that doesn't have at least left/center/right align buttons in the toolbar. Heck, I even remember MacWrite having those buttons!

As a counter-point to #5. For most users, the editorial experience in Drupal is the only tool they get or understand, so to them, the other architectural tools won't be available. A common editor probably won't be able to modify panels for example, either by permissions or by knowledge. Regardless of if Drupal (or these other services mentioned) provide other tools, the editorial interface is by far the most accessible and direct method for formatting.

The amount of formatting being proposed here (alignment and underline) is not so drastic that it is beyond the control of the site builder or even the themer. Using classes for alignment provides no difficulty for mobile, but actually enhances the ability for themes to provide great looking display of images at all sizes. It's trivial for a theme to provide CSS that left/right aligns image when space is available and switch those aligned images to a 100%, full-width image when the available space becomes too narrow.

I updated the issue summary. Though I'm in the pro-alignment camp, I did my best to summarize the opposing viewpoint. If it's not adequately expressed, then please feel free to rephrase.

Unfortunately, we're missing the actual, major, technical aspects + consequences from the original issue in the issue summary.

We can also shorten the summary to some great extent, since this is not about pro/con, but about technical/architectural merits only. (Speaking of, it does not help at all to state that X or Y provides this feature.)

Unless someone beats me to it, I'll revamp it in the next ~24-48 hours.

Unless someone beats me to it, I'll revamp it in the next ~24-48 hours.

Could you elaborate on what approach you would take to a "revamp"? It's not clear where problems currently exist, other than the question of ckeditor.css. If system.base.css is acceptable, then we don't have a problem with the location of the CSS.

I already started rerolling before the CKEditor module patch was committed, so I already finished this before I saw @sun's offer. In any case it should be good fodder for discussion.

Differences from the original approach:

• New classes are in system.base.css
• system.base.css is added to iframe instances of CKEditor, which results in a small amount of unneeded CSS (such as autocomplete textfields and collapsed fieldset CSS). I don't find this offensive.
• In order to really make RTL alignment work, we need to use the same class for "opposite the normal direction". While we could do something like make a class for "align-opposite", I personally would prefer to keep the existing classes and flip their purpose when needed. This means that "align-right" really aligns left in RTL languages. I find this acceptable because end-users don't need to know the class names anyway. And considering the class names are written in English (as is all CSS in Drupal), I expect that RTL readers would not find this kind of reversed meaning unexpected.
• This patch includes classes for text alignment, underline, and indentation only. It does not include any of the image classes, since these wouldn't do anything anyway until the "drupalimage" plugin is restored to the CKEditor module (as it provides the ability to use classes for alignment on images).
• For the same reason caption CSS is not included, until the "drupalcaption" plugin is restored.

A few of the img alignment classes slipped into the last patch. Here we are with them removed.

Fixing remaining tests.

Issue #1879120: Use Drupal-specific image and link plugins — use core dialogs rather than CKEditor dialogs, containing alterable Drupal forms adds basic Drupal-native support for handling images and with it a "drupalimage" plugin that replaces CKEditor's bundled "image" plugin. In the event that the dialog patch goes in first, this issue should be updated to add alignment abilities to images as well as text by reverse applying the patch in comment #23 of that issue.

I think it is pointless to try and strive to support only clean markup (ie. reasons to not support aligning because that is "layouting"). Drupal core does not have layout capabilities on a sub-node scale and the way we place assets (eg. images) in text is we attach them and then edit them to the right place in the text (and yes, possibly align in the process). What Drupal 7 offered is the best avenue for crappy markup (since you needed to enter markup yourself). We already improve on that a great deal by trying to ensure the WYSIWYG buttons create as small and clean markup as possible.

As for the patch itself, I'm a bit puzzled by the RTL/LTR classing logic. My understanding is this would make the button that visually depicts left aligned text actually right-align things on RTL sites. I find it odd when I see a drawing of left alignment then the action is right alignment. Am I getting that wrong?

Looking at more "designed" editors — ones that don't just throw up the default buttons — like Unify and the Basecamp wysiwyg, and Barley, it's easy to notice a trend of reduction and simplicity.

I don't think that this is a level of manipulation we should encourage in Drupal or something we should stoop to meet, but I do think there are clients who do want this functionality. It feels like contrib space to me.

@LewisNyman

You don't want left, right and center align in a wysiwyg and point in to contrib (although that feature is used a LOT).
But on the other hand you want a mobile preview button that only has a sales aspect? #1741498: Add a responsive preview bar to Drupal core

Btw I use basecamp and thats a business tool not a tool to show "content" in a nice and prety way. So we shouldn't compare with those kinda tools.

Image alignment is handy, that's what floats were made for.

I'm happy to debate text alignment. Any typography resource will tell you that, for body copy, left alignment is the only choice, mobile or otherwise. It's potentially more damaging than allowing your client to select the text color. The only place you'd want centered text are in headers and it feels like we should be achieving that with semantics and CSS.

I think I'm just taking a design/front-end perspective on why I wouldn't want it enabled by default. I don't mind if it sits in core and contrib. I think it's a common feature but only because so many WYSIWYG ship with it by default, because they've just been copying Word.

@aspilicious

I think you misunderstood my comment on the mobile preview bar, I never took a stance either way. Here is not the place to discuss it.

I actually think a tool like base camp, which can display comments/posts in different contexts, is closer to Drupal than a full page editor like Google Docs. Business content is still content, I don't see why we shouldn't compare them.

Srry for the reference to the other issue.
Totally off topic.

@WimLeers I think your summary is completely accurate :) We should have this functionality in core, but not enabled in the standard profile.

I definitely think that Drupal's landscape is more in the realm, where one wants to control the typography. Having text-alignment enabled by default, stands outside that realm.

As for the patch itself, I'm a bit puzzled by the RTL/LTR classing logic. My understanding is this would make the button that visually depicts left aligned text actually right-align things on RTL sites. I find it odd when I see a drawing of left alignment then the action is right alignment. Am I getting that wrong?

So what happens in CKEditor is that when using an RTL language, CKEditor *does* flip the position of left and right align. So the button that used to left align now right aligns and vice-versa. But what CKEditor *also* does is that it (by default) gives content that is align-right (no matter what the current language is) a text-align or float "right". This means that when you switch to an opposite language, all the text gets flipped but the images stay in the alignment they had previously. If you're building an RTL/LTR dual website, you want everything to flip, not just some things. So the logic I introduced into handling RTL makes it so that if you say "left align" in an RTL language, it aligns left visually, just like you'd expect. But if you translate that content into an LTR language, the image is now aligned right (just like all the text) without any intervention on your part because the same class name flips its meaning between RTL and LTR (just like the rest of Drupal classes do).

If that's all confusing. Just try applying the patch and set up a site that has both English and Arabic, then try out the editor. Everything works the way you expect it to. The only thing that's strange is that the class "align-right" (which you don't see, it's only in the HTML source) visually aligns left when when using RTL.

Would it be acceptable to you to have a Justify.php CKEditor plugin, with none of its buttons enabled in any of the text formats in the Standard install profile, but with those buttons available to be enabled on the Text Editor configuration form?

That seems like a fine step in the right direction. I'd like to leave the discussion open on including them by default (I still think end users will have a strong preference for enabling it), but that discussion will be a lot easier if the technical problems are worked out first.

I don't see why this would need to be a separate plugin from the Internal plugins, but there's no difference if we make it a separate plugin. So if Justify.php is preferred for some reason we can take that route.

What should we do about the indentClasses reintroduced in #12? I know it would be preferable to many if the indent buttons didn't affect normal paragraphs and only worked on bullet lists. This isn't the case currently though. Indenting a paragraph right now adds a style="margin-left: 40px;" to the paragraph tag, which is the worst possible situation. Should we include those in the Internal plugin or remove them from the patch and try to ensure that they only work on bullet lists (working with the CKEditor team) before release?

Same patch as #12 without indent classes. I'm not terribly sad to see them go, though it leaves us with the current inline styles that MUST be removed before 8.0. Although #1936392: Configure CKEditor's "Advanced Content Filter" (ACF) to match Drupal's text filters settings will have an interesting effect that the inline margin styles won't be allowed, so indentation should be prevented on paragraphs. The behavior still won't be quite correct though, since the indent buttons shouldn't show in an active state and be clickable if they don't do anything.

As an aside on indent buttons: since we're only using them for bullet indentation, it would be optimal (IMO) if we could have the indent-with-tab behavior on item lists *without* the buttons. I personally *never* click these buttons. Anyone familiar with any word processor or WYSIWYG knows that tab/shift-tab handles indentation. So my preference would be to leave the indentation buttons out of the default configuration but keep their functionality. I don't think this is possible in the current version of CKEditor however.

This rerolls #12 but doesn't make a separate plugin for it. I couldn't see why we would treat alignment special compared to other built-in plugins. If we decide to break out all the default plugins into separate classes (not a bad idea really), we should do that in a dedicated issue and treat everything equally. This patch still adds system.base.css to all instances, since system.base.css is added to all pages on the front-end. Keeping with the goal of accurate WYSIWYG presentation, these classes should always affect content even if the individual buttons have been disabled. Users could potentially use the styles dropdown for the same purpose but disable the individual buttons for example. Or switching between text formats may result in residual alignment.

After poking around for information, I think this patch should be revised to simply use the <u> element for underline. Like <b> and <i>, the <u> tag is back in HTML5.

From the W3C HTML5 Spec:

The u element represents a span of text with an unarticulated, though explicitly rendered, non-textual annotation, such as labeling the text as being a proper name in Chinese text (a Chinese proper name mark), or labeling the text as being misspelt.

In most cases, another element is likely to be more appropriate: for marking stress emphasis, the em element should be used; for marking key words or phrases either the b element or the mark element should be used, depending on the context; for marking book titles, the cite element should be used; for labeling text with explicit textual annotations, the ruby element should be used; for labeling ship names in Western texts, the i element should be used.

So basically, <u> is back but you probably should be using something else in most situations. Therefor I propose we keep the button disabled by default like it is now, but directly use the <u> tag to avoid using span.underline (which is going to be worse in all situations).

EDIT: This reference provides the most extensive analysis that I've seen: http://html5doctor.com/u-element/

Same patch as #29 with special handling for Underline removed.

Note that while testing this patch, I noticed that I was unable to use the alignment buttons.

Hmm, that's too bad. Glad to see the CKEditor bug has been fixed though. Here's a reroll without the duplicate CSS in system.base-rtl.css. Because the drupalimage in #1879120: Use Drupal-specific image and link plugins — use core dialogs rather than CKEditor dialogs, containing alterable Drupal forms is likely to depend on this patch for its alignment of images, it'd be nice to get this one out of the way so we don't have a patch dependency chain. But at the same time it's unfortunate that the buttons don't actually work.

0 byte patch. Hmm. Again.

I think this is a good compromise.

+++ b/core/modules/ckeditor/lib/Drupal/ckeditor/Plugin/ckeditor/plugin/Internal.phpundefined
@@ -43,10 +43,16 @@ public function getFile() {
+    // In order to allow CSS to fully flip alignment, RTL languages need to
+    // have the alignment buttons flip their class names.
+    $language_interface = language(LANGUAGE_TYPE_INTERFACE);
+    $rtl = $language_interface->direction == LANGUAGE_RTL;
...
+      'justifyClasses' => array($rtl ? 'align-right' : 'align-left', 'align-center', $rtl ? 'align-left' : 'align-right', 'align-justify'),

+++ b/core/modules/system/system.base.cssundefined
@@ -275,6 +275,22 @@ input {
+.align-left {
+  text-align: left; /* LTR */
+}
+.align-right {
+  text-align: right; /* LTR */
+}

Maybe we want to reconsider the class names to be something that indicates the native directional alignment versus the reverse directional flow. This could also be a followup discussion.

+++ b/core/modules/ckeditor/ckeditor.moduleundefined
@@ -85,6 +85,31 @@ function ckeditor_theme() {
+  $language_interface = language(LANGUAGE_TYPE_INTERFACE);
...
+  if ($language_interface->direction == LANGUAGE_RTL) {

@effulgentsia also pointed out that this should probably be the content language rather than the interface language.

Discussed with quicksketch and he plans on rerolling without all the RTL handling. Instead, align-left will always mean left, and align-right will always mean right. He'll open a follow up issue to make the content translation process easier (e.g., when translating a field from a LTR language to an RTL language or vice versa, to at that time str_replace() align-left and align-right to align-right and align-left).

The reason to do it this way is that we need to consider pages with mixed content languages. For example, a View of node teasers, some of which are in an LTR language and some of which are in an RTL language. We can't use an RTL stylesheet to do this, because we wouldn't want those styles applying to the LTR teasers. If browsers supported the :dir() pseudo class, we could use that to auto-reverse direction of only the RTL content, but that's still a draft spec. So for that reason as well as for clarity of what align-left and align-right mean, better to implement the swap at translation time rather than at display time.

I think this is the correct approach - left is still left even in a RTL world - the difference is that you might choose to use left in places where you would use right in a LTR text. This decision is embedded in the language in which it is placed and as such is correct in that context (and unlikely to be moved to a different context without translator intervention), so I think flipping this behind the scenes would only confuse authors.

Alignment buttons work great! Tested in RTL and LTR and everything works swimmingly.

Underline button can be added to the configuration and saved properly, but when creating content the underline button does not appear.

Other than that problem, this looks good!

Because filter setting syncing was broken, the <u> tag would not be allowed automatically when you enable the "Underline" button, and hence the button will disappear (because its functionality is disallowed by ACF).

Hahah, wow funny how fast we fall right back into the confusion that has plagued end-users for years. It'll be so nice to leave that behind.

So manually adding <u> to the allowed tag list fixes the problem. Buttons are working exactly like they should. We have a separate issue for fixing the syncing already. This is RTBC +1.

--- a/core/modules/ckeditor/css/ckeditor.admin-rtl.css
+++ b/core/modules/ckeditor/css/ckeditor.admin-rtl.css

Needs a reroll for #2015789: Remove language_css_alter() (RTL stylesheets) in favor of HTML 'dir' attribute.

Committed e4ef001 and pushed to 8.x. Thanks!