You are not logged in.
Pages: 1
hello. a client of ours is having problems forming content. i am trying to help him and I can't get it to work correctly either. it has to do with spacing. he is trying to space things, and can't get the regular returns causing <P> tags to get spacing like he wants so he is shift+returning to get <BR />. Now for some reason some of these tags dissapear. the editor seems to remove them automatically.
for instance there is some code in the editor that looks like this:
employee claims a suspicious on-the-job injury.</em><em>We aren't the guys you call for a round of golf on Sunday. We'll already be out there
we want to put 2 <BR /> tags b/w the em tags. I shift return twice and it looks right. then i click the <> for code view and low and behold only 1 BR tag. i shift back to wysywig mode and then immediately back to code view and I have no BR tags.
I am thinking this might have something to do with nexting <P> and <BR /> tags or something? Can anyone help... this is extremely frustrating as the client is trying to update content and it isn't working.
Offline
so I might have made a bit of headway. it appears that if i delete the </em> and <em> tags (that is where I am applying the line breaks) then the line breaks do not dissapear. But they do dissapear if those tags are in there. weird. I am not quite sure how I am going to explain this one to the user who doesn't understand HTML.
Offline
It also appears that if I have </B><p> tags in the place I am trying to add line breaks that will not work either. how do you guys do this? because <P> tags really just not always give the desired effects.
Offline
I can confirm this problem, quite a few of our clients have commented on problems of spacing lines. They are visible in the editor, but if you switch back and forth in HTML mode they will vanish, or if you dont swith editing mode and just press "submit" the served code will be different than its viewed.
I havnt had time to look into this, why its happening and where, but its happening thats for sure. The problem is also in htmlarea, so if we are lucky and find a way to reproduse the problem maby some nice people in here can fix the problem.
Offline
I can confirm this problem, quite a few of our clients have commented on problems of spacing lines. They are visible in the editor, but if you switch back and forth in HTML mode they will vanish, or if you dont swith editing mode and just press "submit" the served code will be different than its viewed.
I havnt had time to look into this, why its happening and where, but its happening thats for sure. The problem is also in htmlarea, so if we are lucky and find a way to reproduse the problem maby some nice people in here can fix the problem.
Check HTMLArea.getHTMLWrapper(). It's stripping out <br>'s there in the section:
case 1: // Node.ELEMENT_NODE
case 11: // Node.DOCUMENT_FRAGMENT_NODE
case 9: // Node.DOCUMENT_NODE
...
Every time you switch between source and wysiwyg view it goes through getHTMLWrapper and mucks with the html causing all kinds of headaches. (this is one of the things that messes up EnterParagraphs).
-----------------------------------------------------------------------------------------
Content Management with Business Intelligence [url]http://www.formvista.com[/url]
Offline
Okay I have figured out a bit more about this behavior
I am using IE6. if you paste this into xinha in code mode (<>)
<em>We're the guys.<br /><br /></em><em>We aren't the guys</em>
when you toggle back to WYSYWIG (<>) and then back to code one of the <br /> tags will be gone. if you toggle again, the other one will be gone.
This appears to be happening ONLY if the <br /> tags are before the closing </em> tag. If you manually put the <br />'s either inbetween the
</em><br /><br /><em>
tags the <br /> will not be removed one by one. Also if you place them after the opening em tag
</em><em><br /><br />
everything will remain in tact.
the problem is if you have it like this
<br /><br /></em><em>
or something like this
<br /><br /></p><p>
this appears to be where IE puts the tags when you insert them in WYSYWIG mode. I tried this in firefox, and if i put the <br />s in manually before a closing tag i get the same problem, however firefox appears to be inserting the <br />'s after the OPENING <em> tag thus not causing a problem.
this is about as specific as i can get. i have tried looking in the javascript files but i really don't know where i'd start, and i'm not overly comfortable at javascript to begin with.
Last edited by KingMoore (2005-05-18 12:58:09)
Offline
any further thoughts on this? Anyone care to show me where to try to fix this stuff?
Offline
i have this problem too, we NEED a solution for this!
as yermo pointed out i will take a look at getHTMLWrapper....
but the problem is imho more that IE adds the <br> bevore the </em> (as kingmoore said)
a solutions would be probably to add the <br> after the </em> .... but how ???
Niko
Offline
i am a bit confused about how much of this is actually controlled by xinha and how much is just the way browsers handle the textarea thing. (my knowledge of this is vague).
i am willing to work to try to get a fix though. thanks niko.
Offline
Offline
sweet.
so how does this work? will that go into the next release or what?
Offline
actually xinha hasn't released anything yet
so just use the latest nightly
Niko
Offline
the last nightly i tried no longer works with my setup for some reason . and seemed much slower when i did get it partly working... ah well. have to spend some more dev time when i get it.
Offline
I have the same problem, but I thought it had to do with the way MSWord copies junk all around. My client cuts and pastes content from Word into Xinha using IExplorer and BRs and Ps are giving us quite a headache. I'd like to thank those who are working on the problem and wish I could contribute more... as it is, all I can do is hack a couple of plugins to run with our database...
Offline
If anyone still has the problem because they are using an old version of htmlarea or Xinha, here is one workaround that we tell our customers for this bug. Place a single space on any blank line and the blank line will be preserved.
Last edited by Chris Allison (2005-06-10 20:02:53)
Offline
Pages: 1