Enable CKEditor in the Standard install profile's "Full HTML" text format

What *is* the full list anyway?
Maybe it helps to build consensus around the absolute no-go's first.

Agreed with WimLeers his assumption there, I am also not sure about text color?

[ { "groups" : [ "mode",
        "document",
        "doctools"
      ],
    "items" : [ "Source",
        "-",
        "NewPage",
        "Preview",
        "Print",
        "-",
        "Templates"
      ],
    "name" : "document"
  },
  { "groups" : [ "clipboard",
        "undo"
      ],
    "items" : [ "Cut",
        "Copy",
        "Paste",
        "PasteText",
        "PasteFromWord",
        "-",
        "Undo",
        "Redo"
      ],
    "name" : "clipboard"
  },
  { "groups" : [ "find",
        "selection",
        "spellchecker"
      ],
    "items" : [ "Find",
        "Replace",
        "-",
        "SelectAll",
        "-",
        "Scayt"
      ],
    "name" : "editing"
  },
  "/",
  { "groups" : [ "basicstyles",
        "cleanup"
      ],
    "items" : [ "Bold",
        "Italic",
        "Underline",
        "Strike",
        "Subscript",
        "Superscript",
        "-",
        "RemoveFormat"
      ],
    "name" : "basicstyles"
  },
  { "groups" : [ "list",
        "indent",
        "blocks",
        "align"
      ],
    "items" : [ "NumberedList",
        "BulletedList",
        "-",
        "Outdent",
        "Indent",
        "-",
        "Blockquote",
        "-",
        "JustifyLeft",
        "JustifyCenter",
        "JustifyRight",
        "JustifyBlock"
      ],
    "name" : "paragraph"
  },
  { "items" : [ "Link",
        "Unlink",
        "Anchor"
      ],
    "name" : "links"
  },
  { "items" : [ "Image",
        "Table",
        "HorizontalRule",
        "SpecialChar",
      ],
    "name" : "insert"
  },
  "/",
  { "items" : [ "Styles",
        "Format",
      ],
    "name" : "styles"
  },
  { "items" : [ "Maximize",
        "ShowBlocks"
      ],
    "name" : "tools"
  },
  { "items" : [ "-" ],
    "name" : "others"
  },
  { "items" : [ "About" ],
    "name" : "about"
  }
]

What about this? I think we should avoid elements that introduce relatively random elements into the website. We want to avoid that "content managers" turn to all kinds of weird tools to get things done, rather than consult their developers. Tools that have a high potential for abuse, but also the things that are not a right fit for a CMS.

I'm going to add a bit different point of view, maybe someone else will agree. Sometimes Drupal is used by people that have very little knowledge about web standards. They still have a lot of things to learn, but in the meantime they'll be looking for various "uncool" features like e.g. TextColor / BGColor.

I'd say that when Drupal 8 comes out, the group of less advanced users may even enlarge, also because in general the whole installation process will be less complicated.

So to keep them happy, leaving these kind of buttons as an option in Full HTML might be the way to go, even if we all would not use these two buttons when creating a website. Not because I'm particular fan of them, but just because I'd say if it can save a part of users a headache with doing funny things like replacing CKEditor in order to get some buttons, then it might be worth of it.

It may be just a bit weird for a less advanced user that it is technically possible to enter anything in source mode, but there are no buttons to do it without messing up source code.

I agree, we shouldn't have any useless buttons :). I agree that this should really be two rows - the proposed button order for that seems fine.

I also had to add the "About" button to the list of buttons provided, that was simply forgotten in the previous issue and is not contentious.

Heh, here's quicksketch to be contentious. ;)

The about button doesn't have anything to do with Full HTML as it doesn't add any new tags (it just displays the CKEditor version). In the long run, my hope for the about button was that we would use the same approach as Github and Confluence and use the "about" button (really just the "?" icon) to bring up useful help such as the keyboard shortcuts for all of the available buttons. Although I'm not sure how to accomplish this piece, I'd also like to move the filter tips to the help dialog when CKEditor is enabled so we can reduce the cruft on the page below textareas. So basically I think at this point we shouldn't add the About button for two reasons: it doesn't add/require any tags and I'd like to use it for something more extensive in the future (and enable it in the default toolbar).

Hm hm. There are a lot of buttons here that actually don't have to do with HTML tags. copy/cut/paste (both normal and from word), undo/redo, symbols, remove formatting.

Some make sense (remove formatting) since you're more likely to need them if doing a lot of formatting. I'm not sure about adding other things that aren't related tags at all just to make the editor appear more powerful. But then you end up in a situation where you have a very uncomfortable number of buttons that don't really work on either 1 or 2 lines (it's like only 1.5 lines).

This might be too much psychological theorizing, but I'd like to avoid giving end-users multiple reasons to always use Full HTML over Basic HTML. If a user wants copy/paste or undo/redo buttons, we should try to encourage them to add the buttons they need to Basic HTML rather than simply granting Full HTML to all users.

I do really like removing auto-p and auto-a from Full HTML. Those have always been an inconvenience for my use of Full HTML (which is typically for small HTML snippets rather than actual content).

If we take this policy its full length and only add buttons that add tags to the Full HTML editor, then you end up with this:

Really "remove formatting" shouldn't be in there either for full compliance.

Looks good to me. Show invisibles is definitely more likely to be helpful on Full HTML since that's when invisibles are likely to occur. Why is Full Screen more helpful for Full HTML than Basic HTML? Should it be added in both places?

I think that nate's reduction in #16 was a little drastic, i think switching between basic html and full html should be a noticeable difference. However it seems WimLeers his proposal actually finds the right balance.

I would definitely defer adding "Full screen mode" to a followup. Basic HTML will be shown in many many places where adding even just one more button, adds significant clutter. Although its a good feature, I have rarely seen users actually using this (although this might be due to the usability test setting, where going into "zen" mode is not really part of the flow). However I think its usefulness is disputable on forms, where there is not one "centric body" and there are loads of textareas, in that case you would want to do better signalling of which field you went into zen mode for. So with all those considerations in mind, deferring it to a follow up would be a better strategy I think.

Lets do this!

I'm happy to see auto-p and auto-a removed from Full HTML. I'm still a bit skeptical because my particular usage of Full HTML rarely would require a WYSIWYG. However I think it's easier to remove settings (or add a new empty text format) than it is to set up an editor, and if I were a new user to Drupal I would expect "Full HTML" to be a WYSIWYG like "Basic HTML"... just more of it (like this patch adds). So +1 from me too.

Woohoo! :)

Committed and pushed to 8.x. Thanks!

This issue kind of heightens the importance of #1936392: Configure CKEditor's "Advanced Content Filter" (ACF) to match Drupal's text filters settings, since things like <script> and <style> are being stripped out on the Full HTML format. Any Full HTML existing content that uses these tags will immediately be mangled by CKEditor upon edit now.