From a7f6cbb6fb01d759459e35ef67494c5cbba8fc77 Mon Sep 17 00:00:00 2001 From: Karl Hobley Date: Mon, 18 Nov 2019 13:37:59 +0000 Subject: [PATCH] Outline RFC for single-block rich text fields --- text/000-simple-rich-text.md | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 text/000-simple-rich-text.md diff --git a/text/000-simple-rich-text.md b/text/000-simple-rich-text.md new file mode 100644 index 00000000..f1bcf3f0 --- /dev/null +++ b/text/000-simple-rich-text.md @@ -0,0 +1,24 @@ +# Outline RFC : Rich text segment blocks + +* RFC: +* Authors: Karl Hobley +* Created: 2019-11-18 +* Last Modified: 2019-11-18 + +## Abstract + +This is an outline proposal for a new field and block type in Wagtail. This field/block type would behave like a ``RichTextField``/``RichTextBlock`` but only allows a single segment of text. + +Inline elements such as formatting and hyperlinks may be allowed. But block elements like paragraphs, images and bullet points will not. The HTML segment in the database will not be enclosed in a `
` or even a `

` tag giving developers more flexibility in how it is used. + +I think this will be very useful for: + - Introductions/summaries which can usually only be one paragraph but use rich text fields as they may need inline formatting. For example, the sentence above "Tom Dyson" in: https://wagtail.io/blog/wagtail-2-7/. + - Image captions + - Inline styling in titles. For example: https://torchbox.com/digital-products/ + - Forcing editors to use separate rich text blocks in streamfields + +I think it would also be very useful to have an internal ``RichTextSegment`` type to represent the values of these fields. Having a separate type would be useful separate type because some logic, such as diffing and translating, would be different to ``RichText`` values. + +## Specification + +I don't think this would be a very technically challenging change to make, but I'm leaving this bit out since I'm only looking to get feedback on the general idea for now.