[opencms-dev] Persuading FCKEditor to use default stylefor content

[Jonathan Woods]

Having done a bit of testing:

- you're right - a div is used at all only you select a style from the menu

- the default is to generate text without aadding a surrounding block-level
element at all; new lines generate <br /> markup

- the default style dropdown has 'Normal (DIV)' (which surrounds text with
<div>) and 'Normal' (which uses a <p> element)

- the 'Normal (DIV)' style generates <br/> for new lines

- the 'Normal' style generates new blocks of <p> </p> unless you hold down
Shift, in which case <br /> is inserted.  This is rather like Word's
behaviour.  The only trouble is that under some circumstances, shift-Enter
seems to produce <p><br/></p>, while other times just <br/>.

- I seem to remember reading that although <p> is a block level element, it
should not contain other block level elements.  Whether or not that's right,
FCKEditor will certainly permit (e.g.) <div>s nested inside <p>s.

Yuck.  I am now thirsting to get back to application architecture!

Jon

-----Original Message-----
From: opencms-dev-bounces at opencms.org
[mailto:opencms-dev-bounces at opencms.org] On Behalf Of Christian Steinert
Sent: 19 September 2006 11:33
To: The OpenCms mailing list
Subject: Re: [opencms-dev] Persuading FCKEditor to use default stylefor
content

Jonathan Woods schrieb:
> Christian -
>
> I wasn't being very clear, and in any case I've spotted an obvious 
> workaround.
>
> My concern was that the mark-up generated by FCKEditor isn't very 
> controllable.  I wanted to ensure that it did not generate class-less 
> <div>s, but instead generated <div>s which were always given an 
> explicit class (of which the default might be called 'Normal paragraph').
>   
I haven't tested this so much, but where would FCKEdit generate DIVs without
class attributes?
FCKEditor inserts all sorts of Tags, but DIVs should only be inserted when
you use the style selector and have configured some style entries to
generate DIVs, shouldn't they?
> Of course, I realise now that I can achieve the same end result by 
> making sure that all free-form content is contained in an outer <div> 
> generated by the template, and by defining a CSS rule which matches 
> content within that
> div:
>
> Template:
>
> 	<div>Template stuff preceding freeform content here</div>
> 	<div class="freeformContent">
> 		[include an FCKEditor-derived element from the
'body'/instance]
> 	</div>
> 	<div>template stuff following freeform content here</div>
>
> CSS matching at rendering time:
>
> 	/* Rule to match unclassified divs: */
> 	.freeformContent div {
> 		margin: 1em 0em 1em 0em;
> 	}
>
> CSS matching at editing time (cited by FCKEditor), in which context 
> the enclosing .freeformContent div is not present:
>
> 	div {
> 		margin: 1em 0em 1em 0em;
> 	}
>   
Yes, something like this was what I had on my mind...

christian