Unable to create <p> inside <div> (the return)

[Carl Russell]

As previously reported in ticket #99 ​http://dev.fckeditor.net/ticket/99

Test step:

1. EnterMode='p' in config.js
2. have this content in "source" view: <div>abc</div>
3. in fckeditor view, put the cursor after 'ab', and press enter.
4. Check content in "source" view,

Result:

<div>ab</div>
<div>c</div>

There is NO <p> tag as expected.

So there is NO way to create a <p> tag in <div> tag, and there is no way to create a nested <div> tag.

Pressing enter seems to produce a 'div' or 'p' depending on the current format. Setting the EnterMode seems to have no affect.

[Frederico Caldeira Knabben]

We had some evolution on this after #99. The editor now is trying to guess...

If you past something like <div>abc</div> in the source, you are considering the <div> as a simple text block, not as a block elements holder.

If you instead paste <div><p>abc</p></div>, then you are correctly saying that your div is supposed to hold blocks. In this case, the editor will properly append new <p>s inside the <div>.

This situations seams to be reasonable, because if you paste <div>abc</div>, you should not expect to have <div><p>abc</p></div> as the final result.

Also, the current implementation also consider the other side of the coin, where people would like to have a <div> to behave just like a <p> or <h1>.

So, to conclude, it seams that it is just a matter of properly instructing your needs to the editor, and that seams to be the only reasonable able to satisfy all needs.

Am I wrong with it?

[Carl Russell]

In my view this is wrong. In fact the ability to create <p> tags inside a <div> using the editor (not pasting), is vital to most of my projects using your great editor.

If the EnterMode is set to 'p', it's only logical that pressing enter while in a <div> should create a paragraph, not another <div>.

If people want a <div> to behave like a <p> then this could be accommodated by setting the EnterMode to 'div' or applying it manually using the 'Format' dropdown menu.

Applying a styled <div> using the 'Style' dropdown, which can then be filled with paragraphs and headings is an incredibly powerful feature and should not be dropped from FCKeditor.

[Alfonso Martínez de Lizarrondo]

If EnterMode has been set to P then I don't understand why a Div should be splitted on pressing Enter.

Trying to force this kind of behavior will lead to lots of complains from people that have some template with some divs and now they are splitted instead of new paragraphs being created inside of them.

From my point of view, the only reason why people want to use <div> instead of <p> to create paragraphs is that they don't don't how to simply remove the default margin from <p>s (mostly like those that don't want <p> and want <br> all the way). So forcing the current behavior is wrong in my point of view.

If we are going to force anything, then the first step that I would take it would be to remove the <div> EnterMode. Writing texts using divs is wrong from a semantical point of view.

[Randall Severy]

I just ran into this bug working with the new 2.6 beta release and I have to agree 100% with designstack and alfonsoml. Users expect the Enter key to work the same way everywhere in a web page, and most of the time don't even know whether they are in the middle of a div or outside of a div. Having a different behavior depending on where you are on the page is a recipe for major confusion. I could only see what was really going on with the new ShowBlocks feature enabled, without that I was just as confused as the users are. Has a decision been made on how to deal with this issue?

[Alfonso Martínez de Lizarrondo]

removing the pending keyword so it doesn't get closed by accident

[Frederico Caldeira Knabben]

Replying to designstack:

If people want a <div> to behave like a <p> then this could be accommodated by setting the EnterMode to 'div' or applying it manually using the 'Format' dropdown menu.

This is the key to understand the current behavior. Right now, the only way to produce <div>abc</div> with the editor is by using the Format combo. By doing that the user is saying that that <div> is a "paragraph", and that s/he wants it to behave like that, which currently means duplicating itself on ENTER.

Another thing to consider is the definition of <div> in the HTML5. A <div> as a container cannot contain text or inline elements. It can only contain block elements. So, we are assuming that <div>abc</div> is not a container, and the assumption is correct.

Now, the only way to make users confused is by inputting code not produced with FCKeditor. Alfonso exemplified it with templates. In this case, the template itself is wrong. It must not contain an <div>Type here</div> tag to indicate that you want a container there. It must instead have <div><p>Type here</p></div>, so the template designer intention is clear.

To create container divs instead, we just came out with the Div Container Tool. So, if you want a <p> inside a <div>, then just use that tool over your p and you will have it done. I'm closing this ticket as we already have a way to do that.

We can still open a discussion over the <div> support for V3, but this ticket is not the right place for that. I would suggest going to the ​ODE Forum for it.

[Randall Severy]

Replying to fredck:

Now, the only way to make users confused is by inputting code not produced with FCKeditor. Alfonso exemplified it with templates. In this case, the template itself is wrong. It must not contain an <div>Type here</div> tag to indicate that you want a container there. It must instead have <div><p>Type here</p></div>, so the template designer intention is clear.

Frederico,

<sigh> I had fervently hoped that you would avoid falling into the trap that every other WYSIWYG editor developer seems to fall into eventually, by assuming that content is *only* created in your editor. While FCKeditor is wonderful and all that, there is far more content out on the net that is *not* created in FCKeditor. You can not ignore that reality and basically say we only support content that was entirely created in FCKeditor, which is basically what you are saying above. I'm sure I'm not alone in using FCKeditor in a CMS that is designed to edit existing content that was created long before the CMS was installed on the site. It's not content that is created by templates in the editor, it's content that was created by other editors or even Notepad.

And most existing content on web sites is not created to follow the HTML5 standard, you're lucky if they even coded to the HTML4 standards. So you're saying that FCKeditor will only support HTML5-coded web sites? From my experience, most of the <div> tags on web sites on the Internet *do* contain text or inline elements. And you're basically saying that all of the web sites can not be edited in FCKeditor without the behavior acting very strangely to the user, who doesn't know anything about HTML5 requirements or the arcane details of div rules, but simply expects the Enter key to put in a <P> tag.

So is it really that hard to add a configuration setting to allow this behavior to work the way users would expect on a non-HTML5 web sites? If a developer is using FCKeditor on a web site where all of the content is created in the editor, leaving it as the current default may be fine. But for the rest of the world, where we have to edit the content that already exists, in whatever form it may be, we really, really need to be able to configure FCKeditor to work the way the user would expect it to work. Don't you agree?

[Randall Severy]

Replying to fredck:

Another thing to consider is the definition of <div> in the HTML5. A <div> as a container cannot contain text or inline elements. It can only contain block elements. So, we are assuming that <div>abc</div> is not a container, and the assumption is correct.

Frederico,

Since you mentioned a misunderstanding about your reference to HTML5, I've been doing some research on this area to learn more about it. As best as I can tell, HTML5 allows *either* text or inline elements inside a <div>, but not both, but not just block elements. But it is also clear that HTML4 explicitly allows both text *and* inline elements inside a <div>, and I have worked with many web pages built that way that validate perfectly in the W3C validator. And I don't think it's much of a stretch to say that 99% of the web pages currently on the Internet that would be edited in FCKeditor that use a DOCTYPE are set to one of the HTML4 variants. If you are dead set against a config flag to switch the div-enter behavior, you could base it on the DOCTYPE. If the DOCTYPE is HTML5, use the current behavior, as that conforms to the HTML5 standard. But if the DOCTYPE is HTML4, you should allow behavior that is consistent with that standard, in which inline elements inside divs are perfectly acceptable. Users should not have to rewrite *existing* web pages to be edited properly within FCKeditor when the pages are valid HTML4 pages, and this bug would require that be done. That would cause major headaches (and already is) with most of the users of the editor.

[Frederico Caldeira Knabben]

Before continuing, let me highlight that I'm not here to push my personal point of view. I prefer taking decisions over tangible arguments, not only based on personal assumptions.

Replying to severy:

I had fervently hoped that you would avoid falling into the trap that every other WYSIWYG editor developer seems to fall into eventually, by assuming that content is *only* created in your editor. (...) You can not ignore that reality and basically say we only support content that was entirely created in FCKeditor, which is basically what you are saying above.

Please don't put words in my mouth. I've only explained how things are done in the editor and the reasons for it. I've also explained the way we handle content not produced with the editor, also explaining the reasons for it.

So you're saying that FCKeditor will only support HTML5-coded web sites?

Again, I've never told that. I've pointed to HTML5 because that standard gives us some better understanding of <div>, while HTML4 is limited to its syntax only. The HTML4 standards is quite limited in the semantics point of view.

most of the <div> tags on web sites on the Internet *do* contain text or inline elements

Ok, and most of them are not there to hold block elements, but text and inline elements. There is no magic here... there must be some rules to understand which div is for inline content, and which one is for blocks.

And you're basically saying that all of the web sites can not be edited in FCKeditor without the behavior acting very strangely to the user, who doesn't know anything about HTML5 requirements or the arcane details of div rules, but simply expects the Enter key to put in a <P> tag.

we really, really need to be able to configure FCKeditor to work the way the user would expect

Again, more words put on my mouth...

Well... here, you are really reading users' minds. You can't just say what users want it in this way. Because this is not always true. And the same user who says that s/he needs it, will later say that it should be other way "also".

Here again. Put yourself in the editor shoes... is the following div intended to hold inline stuff or blocks: <div>by Bruce Lee</div>. What should we have on enter at the end of it?

<div>by Bruce Lee</div>
<p></p>

... or:

<div>
  <p>by Bruce Lee</p>
  <p></p>
</div>

... or even:

<div>by Bruce Lee</div>
<div></div>

There is no way to know what the user expects here. There is nothing there saying that it should hold blocks. As it has text only, all we can do is assume it has to be inline.

Then, at the same time, we can have mixed situations, like the following:

<div class="title">About Bruce Lee</div>
<div class="body">Bruce Lee was an American-born martial artist...</div>

Here, users (the rest of the world) will tell you that they want the editor to magically understand that the first div is not supposed to contain blocks, while the second should have them. What to do in this case? Start crying? No! We must instead explain things well, making it clear that they will be facing such issues because of technical problems introduced with content produced previously. Then, explain them how to fix it. As things get fixed, they will just have a better editing experience, making their content better at the same time.

Since you mentioned a misunderstanding about your reference to HTML5, I've been doing some research on this area to learn more about it.

It was not intended to say that you have limited HTML5 knowledge. I was saying that you have misunderstood the way I've referenced to it in my comment, as I'm not saying that our content is targeted to HTML5. Sorry for another misunderstanding.

---

Now two notes.

One thing that can be definitely considered instead is a way to make sure that <p> will be produced when pressing ENTER and EnterMode="p". Ticket #2403 should address this issue.

Please do not reopen this ticket just to add further comments. It has been closed because there is currently a way to create <p> inside <div>. Other things should be discussed in the proper place, as explained in my previous comment.