Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#1290 closed Bug (wontfix)

unneeded <p> tags added to source

Reported by: kae Owned by:
Priority: Normal Milestone:
Component: General Version:
Keywords: Cc:


In the nightly build, open Source view and paste this in:

<p>some text</p>
<img alt="" src="" />
<p>some text</p>

then click Source again to view in WYSIWYG mode. click Source again to bring back to code view.

now, the <img> tag has surrounding <p> tags.

Change History (5)

comment:1 Changed 10 years ago by kae

a solution is to add img to the list of Block level elements in fcklistslib.js

this is possibly a matter of opinion. I notice as well that the <object> element is not mentioned as either block or inline. I'd recommend putting that in block.

I know that the XHTML 1.0 DTD says that img and object elements are inline, but I think that for FCKeditor, they should be marked as block level.

I could be wrong. Your mileacge may vary ;-)

comment:2 Changed 10 years ago by fredck

  • Resolution set to wontfix
  • Status changed from new to closed

Kae... we (the Internet developers world), are in a constant battle, giving our best to work on standards. With FCKeditor, we have already introduced many ways to go out of standards if one needs it, but we must ensure we can produce good HTML output with it.

Forcing inline elements to behave as block elements is certainly not the way to go. It is not really a FCKeditor bug here, but a situation that must be properly handled by the content producer, changing the mentality... after all, the same results can be produced under recommended standards.

comment:3 Changed 10 years ago by kae

forcing top-level Block elements is only correct if the FCKeditor content will be displayed directly in a <body>, <blockquote> or <noscript> element.

for example, the code I wrote above is correct if it is contained in a <div> element (the FCKeditor data is saved in a database, then displayed in a <div>).

what I mean is, I want to be able to tell FCKeditor to treat the top-level child nodes of the document as if they are contained in a Flow element.

would this maybe require a feature request?

comment:4 Changed 10 years ago by kae

to add more information to this:

the XHTML1.0 DTD specifies a <div> element as this: <!ELEMENT div %Flow;>

%Flow is defined as a mixture of block, inline and misc elements.

If I use FCKeditor to define HTML which I intend to place inside a <div> element, then I should be allowed to use inline elements as shown in the HTML above.

In other words, it would be nice to be able to define the mode of the FCKeditor root node - in this case, I would like it to be Flow, like a <div>, instead of Block like <body>, <noscript> or <blockquote>

comment:5 Changed 10 years ago by fredck

It is not a matter of pure DTD specifications. It is a matter of semantics. DIV elements "should" be used "exclusively" for elements "grouping". It doesn't mean that their contents can be semantically incorrect just because the DTD allows it. So, even if the contents of the editor are designed to be injected inside a DIV, it must still be structurally correct.

Just as an example, check out what the HTML5 has to say about that:

I'm sure you can find further reading about it on the net.

Note: See TracTickets for help on using tickets.
© 2003 – 2017 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy