Repository navigation
Will be there some element check support ? #2251
Description
Is the editor inline style could be applied to all elements, or there will be some elements that there are not supported ? In the last case, is there a function to check if a given element is supported?
I would like to apply ckeditor to classical DIV element, but also of other types. Here is a list of use cases of elements as root editable element (for all, allow text styles, as bold, italic, etc.):
- DIV: as actual
- Hn: insert BR on enter key, IMG (if it it allowed by html5 specification) and all allowed elements.
- P: insert BR on enter key if P is root (but no DIV), IMG, etc.
- UL/OL: insert LI on enter key and BR on shift+enter, etc.
- SPAN: insert BR on enter key, IMG, etc.
- A: could be around block elements (if I'm correct), so the content could be editable too like DIV (except we cannot insert other A elements)
Is there a list as of ckEditor 4 for editables elements, and maybe the rules according to their specifity? Is it the same?
$editable: {
address: 1, article: 1, aside: 1, blockquote: 1, body: 1, details: 1, div: 1, fieldset: 1,
figcaption: 1, footer: 1, form: 1, h1: 1, h2: 1, h3: 1, h4: 1, h5: 1, h6: 1, header: 1, hgroup: 1,
main: 1, nav: 1, p: 1, pre: 1, section: 1
},
Here, SPAN or A are not supported.
Thanks for your help
Activity
fredck commentedon Feb 14, 2017
That's a very interesting request. We should try to achieve such level of functionality, where the outer container defines features behavior. I'm not sure what's the status of it right now - maybe someone else can jump in and comment.
One thing to keep in mind is that we'll not have support for inline images (by design). Therefore, that's the only thing that goes out of your requirements, which in any case sounds to be an acceptable limitation (or feature, depending on the point of view).
oleq commentedon Feb 14, 2017
However good the overall concept might seem, I'm a little bit concerned about the whole BR thing in the context of Semantic Web approach, TBH.
I found some bits of information (1, 2, 3) on this subject (some dated) but from what I've seen,
<br>is rather considered a consequence of a poor design and unsemantic content in most cases.Exceptions:
<address>tag when you'd always expect the address to be spread across multiple lines,Using
<br>inside<hN>feels like a pure visual styling, and while it can make a sense in some particular web layout, the same content used in a different context (mobile app, RSS feed, some content excerpt, print etc.) will be the source of troubles.It raises the question: to what extent should CKEditor 5 remain semantic web–oriented in this matter? On one hand, we should encourage and support semantics. On the other hand – I understand that developers and environments they create have specific needs and we can't just let them down because we target a single trend, even if it's good. WDYT?
fredck commentedon Feb 14, 2017
I agree with your PoV @oleq. Many times we get excited about "features" that we don't think about the consequences of them. The usual approach of seeing the editor as an "HTML editor", not a "content creation tool".
@VincentClair, I would love to hear your comments about this.
mlewand commentedon Feb 14, 2017
Agreed with @oleq in terms that spamming
brs seems to reduce the semantic value.On top of that one might be tempted to use it in true inline fashion, and there might be still technical problems with using
contenteditablein inline elements. I've tested it some time ago: http://codepen.io/mlewand/pen/RGGxOjBasically it flows correctly with Chrome / Firefox, but it acts as
display: inline-blockon MS Edge.Chrome:
Edge:
VincentClair commentedon Feb 14, 2017
Thank you all for your replies.
As @oled said,
<br>inside<hN>feels is only a pure visual styling. It tends to be "poetry". I agreed to kept semantic way, or activate it by default. Ideally, if it could be deactivated and offers more possibilities from HTML could be great.Line break is only an exemple for some design presentation tool (something as InDesign in HTML). My main concern is just to apply content editable to span or other inline elements. I could imagine another use case: we could have a product page, with many editable informations as a volume, price, dimensions, description, etc. Description could use full ckeditor features, but price or volume is limited to just some text. The important thing for me is to kept the design of whole page and not use classical form inputs.
Reinmar commentedon Sep 5, 2019
I'd like to close this ticket as a dup of #762 which is more generic. We'll continue the work there. Also, check out #762 (comment) in which I summed up the developments and plans.