WYSIWYG and in-place editing for structured content

Karen McGrane gave a great keynote at DrupalCon Portland on future-friendly content with Drupal. It's worth watching the video recording. I agree with Karen's vision for the future. With the proliferation of different devices, screen sizes and input devices, there is a growing need for structured content that can be reused in multiple channels.

From the early days, Drupal has been doing structured content and content reuse better than most competitors. Drupal's node system was introduced in Drupal 3 in 2001, and was ahead of its time compared to the "page tree"-model used by most competitors. With every release, Drupal has gotten better and better at structured content and content reuse, leading to things like CCK and Views in core. Still to date, Drupal is one of the leaders in modeling structured content and content reuse. It is is one of the primary reasons we've seen so much growth. It was great to see that recognized by Karen.

One of the biggest gaps in Drupal has been the authoring experience. Two of the most noticeable authoring experience improvements that we are adding to Drupal 8 core are WYSIWYG editing and in-place editing. Where I disagree with Karen is with her belief that in-place editing and WYSIWYG editing are bad. Sure, WYSIWYG and in-place editing definitely can be problematic when combined with structured content. However, I believe we’ve implemented them in a good way -- it can't be compared to Microsoft Word's blob-like approach. I wish that Karen better understood how we have implemented this functionality. It would have been helpful if she had offered concrete suggestions on what better solutions would look like. Until we know what better tools look like, I'm convinced that Drupal 8's approach to WYSIWYG and in-place editing are a big step forward. It makes for another intermediate step towards a bigger vision.

We've been talking about the advantages and disadvantages of WYSIWYG for more than 10 years now, and we still haven't figured out better approaches. The best we've been able to do is to evolve WYSIWYG editing and in-place editing to apply to individual chunks instead of the entire page, to generate clean markup and to better guide authors to make them aware that their input may end up in many forms of output.

While implementing Drupal 8's WYSIWYG and in-place editing functionality, a lot of attention was spent on ensuring that these features are compatible with structured content:

  • WYSIWYG editors used to generate bad markup. Drupal 8's WYSIWYG editor guarantees clean markup thanks to the new "Advanced Content Filter" feature in CKEditor.
  • Drupal applies WYSIWYG editors to individual form fields instead of the entire page. You are encouraged to break up your content in many fields. Similarly, in-place editing is triggered on the entity level, not the page level, which means the user declares his intent to edit a specific entity and can then edit a specific field within that entity. In-place editing is only designed for quick edits, it wants to delight the author for those small edits, rather than forcing him to go back to the potentially overwhelming back-end form every time. At no point are authors given the impression they are editing the entire page.

For a more detailed explanation, see Wim's article: “Drupal 8: best authoring experience for structured content?”.


Mike Hathaway (not verified):

What makes the Drupal community strong, and Drupalcon great is the acceptance of different viewpoints. Watching you (Dries) show the future of drupal and adding in place editing. Then listening to Karen get into the dangers of it was fantastic. Listing to our WYSIWYG is awesome and then WYSIWYG is evil will help everyone in using a light hand with its implementation. Being open to both is what will make great software and keep Drupal ahead of the curve.

phil (not verified):

If the backend of Drupal is setup right to begin with, the need for WYSIWYG editing should be very limited to a handful of "lazy" markups. I recently took on an existing D6 site where the previous developers used the body for all of the content generation, wrapped with a WYSIWYG. Needless to say, the customer who edits the pages, has a very difficult time with the edits.

WYSIWYG in D8 will no doutably be an awesome and welcome feature. I've stayed away from the D6 and D7 contributed methods because of the horrible markup so it will be nice to have a simple built in editor that does it the Drupal way :-)

Lee Hunter (not verified):

What's been missing from this discussion so far has been the need, in a number of use cases, for content types that can be self-validated using DTDs, in particular the DITA standard which has been widely adopted in technical communications and many other verticals (law, aerospace, pharmaceuticals etc.) A good DITA-compliant editor might provide a more elegant approach to maintaining structure than simply relying on fields which are not inherently a structural concept.

Kristof Van Tomme, who has been working in the Drupal/DITA space for a while, and myself are currently exploring a proof-of-concept for this technology which might provide a useful framework for people working with content that requires a highly consistent structure. This will be especially useful where content must be treated as modular chunks that can be assembled into new deliverables. DITA is typically used for RFPs, legal documents, software manuals etc. but the concept of an editor that validates structure within the body field may have wider application in the Drupal community. It's certainly an approach that makes a lot of sense for the Drupal.org documentation which has a clear need for better structure, consistency and reuse of content.

Manuel Mejia (not verified):


My bigest takeaway from Karen's presentation was that "in place editing" contributes to the dominant (and aging) paradigm in content editing of "what you see is all there is", and that we need to encourage content editors to adopt a more holistic approach, like "what you see is only what you see, and there might be more". I agree with her, and that we need to keep this in mind as we evolve the content editing experience in Drupal.

The last sentence of your last bullet point kind of sums up the current sate and best focus (IMHO) for us in developing the content editing experience in Drupal.

"At no point are authors given the impression they are editing the entire [node]"

I hope that this "impression" can continue to be monitored and carefully crafted to facilitate a slow and steady shift to a new paradigm in content editing.

Thank you for sharing your opinion on this rather hot topic. Everything you've said is on point and important. I look forward to more discussions from all perspectives in our community.


mstrelan (not verified):

Maybe it's time to stop calling it WYSIWYG editing, since WYS is not always WYG, and that's the point. We're after structured content, not styled content. I much prefer Rich Text Editor or Structured Content Editor.

Maarten Stolte (not verified):

I agree with the last comment. People should think in terms of things like emphasis, heading, etc., like HTML5 tries to promote as well.
If the CSS is done correctly, this would also look right on the entity they are editing, resulting in a WYSIWYG experience, *but* if you hide the underlying meaning of the structure people will end up using a header in the middle of the text because it looks good, and your semantics are out of the window...

Check this post out for an editor that is more aimed at structure:


Karen McGrane (not verified):

I never said that in-place editing and WYSIWYG were "bad." I made a real point of saying that in-place editing can provide value to content creators, but in specific and limited scenarios. And I have zero problem with using a toolbar to apply semantic markup.

I do have a problem with focusing on specific interface features rather than on the underlying content structure, and the mental model formed by the content creator.

The "concrete suggestion" I offered to solve the problem is that Drupal developers must think like content strategists and UX designers. This problem doesn't get solved by a particular implementation in Drupal Core; my concern isn't based on understanding how you implemented this feature, but on the mental model it promotes.

You guys should be talking in depth about the scenarios under which it makes sense to give content creators in-line editing and WYSIWYG features, and when those tools should not be used. I fear that in-line editing could be presented as an "ease-of-use panacea" when, truly, it is not.


I remember you being more negative on stage, calling in-place editing a gimmick that marketing and sales dreamt up.

Karen McGrane (not verified):

I said "I can tell just by looking at it that inline editing was a feature ginned up by the marketing team to make Drupal seem easy to use. Which isn't the same as actually being easy to use."

I stand by that statement.


I can assure you that Drupal 8's in-place editing functionality wasn't ginned up by a marketing team. The current implementation of Drupal 8's in-place editing functionality has gone through multiple rounds of usability testing and tested really well.

Karen McGrane (not verified):

Lots of things test well in usability testing, but don't solve the problem they need to solve. The problem we need to solve on the web is helping content creators develop a new mental model for what it means to support multi-channel authoring. For the past 20 years, we've been treating the web like it's a glorified print document. Today, we have to help content creators imagine that their content can live in lots of different places. Inline editing doesn't do that. It does the opposite of that—it forces content creators to imagine that the only "real" version of their content is the front-end desktop experience.

I am sure it tested well in certain scenarios. I'm sure faster horses would have tested well too.

Gordon Henriksen (not verified):

I had a few thoughts after Christine asked me to watching Karen's keynote from Drupalcon.

• There are valid use cases when what you see is all there is. Responsive CSS is expensive; responsive applications which truly adapt behavior are more expensive. Don't make people jump through too many mental hurdles when it has no value. So: hooray for in-place WYSIWYG editing!

• It's very hard for people to build an abstract mental model and predict the impacts of their changes. This is the appeal of WYSIWYG. What if you can help people visualize how their changes to structured content impact other use cases for the content? This could take the onus off of the author to avoid unintended consequences. Instead, the tool proactively alerts her to the true scope of her changes. Done right, this could permit her to not only become sensitive to other channels, but give her the tools she needs to take responsibility for maintaining them.

• Within WYSIWYG editors, hybridizing to visualize markup could be helpful. e.g., present mini [em][/em] glyphs around emphasized text. This way, an author can visually distinguish between [em][/em] and mere [i][/i]. (Even with markup visualization, she may not understand [or have a reason to care!] about the impact of proper markup, though. This is where enforcement of a style guide through DTD validation helps.)

Michael Miles (not verified):

The message I took away from Karen's keynote (and something she reiterates in a comment above) is that WYSIWYG editors need to be used in limited and specific places. Not to be treated the end all be all solution when it comes to content creation.

With the ever expanding world of devices that can be used to view our content, the re-usability of content should be at the forefront of our minds (form should follow function).

Jeff Eaton some comments similar to Karens about WYSIWYG in his drupalcon session Building for a Post Mobile World. Jeff said that the issues with WYSIWYG editors is that the "You" is the content editor and not everyone looking at the content. The content editor is going to keep adjusting the content in the WYSIWYG until they see it laid out how they expect it to, but from only the machine they are working on.

Because of this I think WYSIWYG break the re-usability of content and limits it to the single viewing context of the content editor. To combat these issues we should be limiting the amount of control a WYSIWYG editor has to simple styling markup (strong, em, hrefs, quotes, ect..), as to make sure it does not they allow the editor to insert structured markup that break the contents output in other viewing contexts (mobile, tablets, apps,etc...)

Hearing that the WYSIWYG editor in Drupal 8 generates cleaner markup is great news and a step in the right direction however, until we have a solution that is WYSIWEG (What You See Is What Everyone Gets) we need to be more thoughtful and informative on how we allow content editors to use them.

Tom Durocher (not verified):

This is what I also took to be Karen's gripe with WYSIWYG. If markup is mixed with content, it is much more difficult to reuse that content elsewhere. One difference in viewpoint here is that Drupal really isn't architected to reuse content. I can't (in core anyway) reuse the body content of a node anywhere else. Nor can I create content outside of a node or block. If we did have content as loose chunks, what we could then have is a page builder where that bit of content (not called "body" obviously) can be included into some region of a page. Other chunks of content could also be included. THERE is where we'd want the WYSIWYG and markup, I think. It does sound like D8 is moving somewhat in this direction but just a bit, as far as I understand it.

Mark123 (not verified):
  • One thing Drupal 8 could do to implement support for an NPR cope - type strategy of multiple versions of content is to enhance the already existing 'long text and summary' field. The site designer could specify an unlimited number of text variants along with their title, for example: 'full text', 'shortened text', 'teaser', 'mini teaser'.
  • More of a brainstorming comment: as far as a new 'mental model' or metaphor, an obvious candidate is something like 'electronic screen' (that appears in different shapes), since, well, that's where this stuff gets displayed, whether a monitor, pad, phone or college e-kiosk. Two items that could help with this are 1) easy to toggle, or display side-by-side, previews of the current text 'chunk' in context in different 'devices' and 2) graphic frames of different devices (for ex. see responsinator.com).