htmlArea

A directory of browser-based WYSIWYG editors

  MAIN
INDEX
SEARCH
POSTS
WHO'S
ONLINE
LOG
IN

Home: htmlArea 3 (beta): htmlArea 2 & 3 archive (read only): htmlArea v3.0 - Discussion:
Mozilla: <br/> vs. <p> on Enter


The htmlArea 2 & 3 editors have been discontinued.

We've made these forums available as a read-only reference and knowledge-base for people using or developing editors based on htmlArea 2 or 3.

Anyone who is interested in taking over version 2 or 3 is free to do so. All we ask is that you choose a new name that doesn't have "htmlarea" in it to avoid confusion with this site. We'll even give you a link in the directory to make it easier for people to find you. If you are developing or hosting an htmlArea based-editor under a new name, please submit it to our directory.

First page Previous page 1 2 Next page Last page  View All


funthomas
New User

Mar 15, 2003, 12:46 PM

Post #1 of 26 (5180 views)
Shortcut
Mozilla: <br/> vs. <p> on Enter Can't Post

I found a "bug" under Mozilla: when I press ENTER, then it inserts <br/>, and not a new paragraph. Is it possible to change this behavior?


Benjamin
Staff


May 10, 2003, 3:54 PM

Post #2 of 26 (5085 views)
Shortcut
Re: [funthomas] Mozilla: <br/> vs. <p> on Enter [In reply to] Can't Post

I've been wondering about this myself... I'll keep you posted if I hear of anything.
Ben
interactivetools.com


funthomas
New User

May 10, 2003, 4:03 PM

Post #3 of 26 (5080 views)
Shortcut
Re: [Benjamin] Mozilla: <br/> vs. <p> on Enter [In reply to] Can't Post

I've tried to patch to insert </p><p> on enter (catch pressing enter, insert </p><p>), but not so easier to insert this two tag as I thought. Under IE it's working, but with Mozilla wanted to insert it as a valid HTML and not worked. I did it when I posted my message - it was a long time ago and I don't remember well.

My destiny is to get back a

<h1>header</h1>
<p>dhjahdjsa</p>
<p>dhjahdjsa</p>
<h1>djakjdsljdskaldsa</h1>
<p>dajshda</p>

style html file from the editor, I solved it under IE but I was unable to do it with Mozilla. Frown


Hipikat
User

Feb 3, 2004, 2:49 AM

Post #4 of 26 (4758 views)
Shortcut
Re: [funthomas] Mozilla: <br/> vs. <p> on Enter [In reply to] Can't Post

(I'll just duplicate what I wrote on a longer thread with the same topic at http://www.interactivetools.com/forum/gforum.cgi?post=23062#23062...)

Well, it's a lot of extra code, but I've finally done it :) For anyone desperate for Mozilla to perform proper behavior upon enter, behold my attachment. For anyone unfamiliar with the intricacies of running patch, there's a htmlarea.js also attached - but you'd better run it with a htmlArea directory from a similar era to today.

It involved a lot of DOM work. It's been fairly thoroughly tested. It's actually quite an interesting hack...

The patch is up against a htmlArea taken from the CVS about ten minutes ago.

Please, please please, if anyone finds any bugs with it, send them to me. On the other hand, it's about to be unleashed on my University, so I'll probably get enough local bug reports :P


(This post was edited by Hipikat on Feb 4, 2004, 7:55 PM)
Attachments: fixparas040203.diff (9.94 KB)
  htmlarea.js.fixpara01 (74.0 KB)


Sponge
Novice

Feb 4, 2004, 8:32 AM

Post #5 of 26 (4725 views)
Shortcut
Re: [Hipikat] Mozilla: <br/> vs. <p> on Enter [In reply to] Can't Post

I wonder if this could be used to do an <div>text</div> instead othe normal <p>text</p>. I wrote some semi working code in my topic (see first/second page on the topic list), but it's quite messy and not perfect.. ;). Ispent a lot on time on it, and it seems to be working quite fine, except for the lists


txia
New User

Feb 4, 2004, 8:06 PM

Post #6 of 26 (4710 views)
Shortcut
Re: [Hipikat] Mozilla: <br/> vs. <p> on Enter [In reply to] Can't Post

Smile Hello,

My 2 cents
Well I have completed it making it optional like languages.


Code
      if (_Pinsteadof_BR == "P") { 
if (!ev.shiftKey && this._iframe.contentWindow.getSelection) {

// Get the selection and solid references to what we're dealing with chopping
var sel = this._iframe.contentWindow.getSelection();

etc ...


Of course you have to set the _Pinsteadof_BR variable this way !

Code
<!-- load the main HTMLArea files --> 
<script type="text/javascript" >
_editor_url = "/htmlarea/"; // default path
_editor_lang = "fr"; // default language
_Pinsteadof_BR = "BR"; // replace BR by P or not, set BR if no replacement else set P
</script>


Not very original, just very like the lang variable.

Hope this will please you

Thank again for your good work !

Cy !

Txia
[@Lyfoung->http://www.lyfoung.com]


Hipikat
User

Feb 4, 2004, 8:12 PM

Post #7 of 26 (4710 views)
Shortcut
Re: [Sponge] Mozilla: <br/> vs. <p> on Enter [In reply to] Can't Post

Mmm! I imagine that it could easily be changed to work with <div/>s instead. There should be no real difference, to my mind. One would only need replace most of the occurrences of the letter 'p' with 'div', in the patch :)

I would be inclined to make the type of block to surround with on enter a configuration option, if I wasn't so philosophically rooted in the point that it should be a P =) For anyone who wants to see the long debate on the topic that never went anywhere, in the form of a mozilla bug report, see http://bugzilla.mozilla.org/show_bug.cgi?id=92686.


mishoo
User

Feb 5, 2004, 12:00 AM

Post #8 of 26 (4703 views)
Shortcut
Re: [Hipikat] Mozilla: <br/> vs. <p> on Enter [In reply to] Can't Post

Your work is very nice :)

Though, I still think that this problem should be fixed somewhere in Mozilla core and not in our code :(

Anyway, there already are lots of Mozilla versions and not anyone will use the latest one, so I was thinking: could we provide this as an external plugin? This way, people that don't need it will not be forced to load it (as you said, the code is pretty big). Do you think you need any API-s changed or improved in the editor in order to make it a plugin?
--
Mihai Bazon,
dynarch.com
Applied Web Standards


ReDefined
Novice

Feb 5, 2004, 1:11 AM

Post #9 of 26 (4697 views)
Shortcut
Re: [mishoo] Mozilla: <br/> vs. <p> on Enter [In reply to] Can't Post

Wow! Ben and Mishoo both posting in the same subject! Could this mean there will be a stable HTMLArea 3.0 release soon? Stay tuned boys and girls...


mishoo
User

Feb 5, 2004, 1:20 AM

Post #10 of 26 (4695 views)
Shortcut
Re: [ReDefined] Mozilla: <br/> vs. <p> on Enter [In reply to] Can't Post

LOL :-)

Yeah, I've been thinking about it for too long now. And there's plenty of new and wonderful code in the CVS. If the guys at Oktagone could only give me my shell back... :-\ I'm in the process of working this out with them.
--
Mihai Bazon,
dynarch.com
Applied Web Standards


Hipikat
User

Feb 9, 2004, 12:26 AM

Post #11 of 26 (4612 views)
Shortcut
Re: [mishoo] Mozilla: <br/> vs. <p> on Enter [In reply to] Can't Post

Voilą, voilą. EnterParagraphs as a plugin is attached.

One small change to the plugin API did need to be made - an onKeyPress event for plugins - as can be seen in the attached htmlarea.js.EnterParagraphs.diff

The only other change in that diff is to turn whitespace in otherwise empty elements into a nonbreakable space, as in http://www.interactivetools.com/forum/gforum.cgi?post=23119#23119. It would be a bit of a hack to let plugins mess around here, and (in my opinion) this should be in the core anyway.

I've been encountering one occasional crash in htmlArea that EnterParagraphs may be responsible for - it occurs when hitting left beyond the beginning of the document and hitting enter. But given that it seems to be having the right behavior before the crash, and given that it's a crash, rather than an error of any sort, it should be fixed in gecko, real soon now, I'm sure :P

Happy to be of service to open source =^.^=

[Oh no! I deleted enter-paragraphs.js from this post but couldn't upload a new one. Don't worry... just read down 4 posts]


(This post was edited by Hipikat on Feb 9, 2004, 3:11 AM)
Attachments: htmlarea.js.EnterParagraphs.diff (1.81 KB)


Sponge
Novice

Feb 9, 2004, 2:04 AM

Post #12 of 26 (4603 views)
Shortcut
Re: [Hipikat] Mozilla: <br/> vs. <p> on Enter [In reply to] Can't Post

Hmm, it looks nice :). Unfortunatly I can't get it to work converting enters to div (in IE) Unsure. I have to say, that code inside the .js file is pretty amazing Smile. I've been programming for HTMLArea for 5 months, and never wrote code that came even close to this :).

If someone could help me to get this wonderfull code to work to make <p>'s -> <div>'s, then that would be awesome! :) I've been tinkering on this for two weeks, and got some semi-working code working (here: http://www.interactivetools.com/forum/gforum.cgi?do=post_reply_write;quote=1;parent_post_id=23134;t=search_engine)

Thanks,
Sponge


Hipikat
User

Feb 9, 2004, 3:01 AM

Post #13 of 26 (4590 views)
Shortcut
Re: [Sponge] Mozilla: <br/> vs. <p> on Enter [In reply to] Can't Post

Thank you very much!

I actually just realized a case I'd missed and updated the .js file right before this post - if one had one's selection contained within one paragraph with an Id, that Id would be copied into both new paragraphs produced - which is illegal under html4.

Are there any other attributes whose values aren't allowed to be reproduced in a single document?

And yes, but sorry this isn't going to do anything for DIVs in IE. The wonderful thing about the whole patch is that IE already does the right thing, so I didn't have to worry about any whack compatibility (which is good, since the Windows laptop at work died last week...).


Sponge
Novice

Feb 9, 2004, 3:08 AM

Post #14 of 26 (4585 views)
Shortcut
Re: [Hipikat] Mozilla: <br/> vs. <p> on Enter [In reply to] Can't Post

True, but not for divs :). People convinced me actually why <div> is better than <p> and <br>, and they have been using it in their previous editor (using the DHTMLEdit component, in VB.. which had an event after all key-events.. which made replacing <p> -> <div> a piece of cake), and getting it to work in this version is quite important :).

Quite frustrating though, I've written 32k of code (not counting comments) for HTMLArea in the past months, but can't get this silly <p>-><div> to work for the fully 100% :), which might be less than 50 lines Shocked

Regards,
Sponge


Hipikat
User

Feb 9, 2004, 3:08 AM

Post #15 of 26 (4584 views)
Shortcut
Re: [Hipikat] Mozilla: <br/> vs. <p> on Enter [In reply to] Can't Post

Oh no! It looks like I couldn't attach that new file to the already posted post - although it let me delete it, and appeared to have worked.

So again, the enter-paragraphs.js htmlArea plugin is attached below. Also a patch to get from the old one to this one, if you'd prefer. It just looks like:


Code
*************** 
*** 112,118 ****
}
if ( this.isElem(endBlock,'p') ) {
for ( var i=0; i < endBlock.attributes.length; i++ ) {
! attrsRight[ endBlock.attributes.nodeName ] = endBlock.attributes.nodeValue;
}
}

--- 112,121 ----
}
if ( this.isElem(endBlock,'p') ) {
for ( var i=0; i < endBlock.attributes.length; i++ ) {
!
! // If we start and end within one paragraph, don't duplicate the 'id'
! if ( endBlock != startBlock || endBlock.attributes.nodeName.toLowerCase() != 'id' )
! attrsRight[ endBlock.attributes.nodeName ] = endBlock.attributes.nodeValue;
}
}

Attachments: enter-paragraphs.js (8.15 KB)
  fixMultiId.diff (1.46 KB)


mishoo
User

Feb 9, 2004, 3:58 AM

Post #16 of 26 (4576 views)
Shortcut
Re: [Hipikat] Mozilla: <br/> vs. <p> on Enter [In reply to] Can't Post

Hey..

Thanks for the code. Looks nice. I am looking through it now, also doing some "beautify" to make it look like the rest of HTMLArea.

At line ~136 in enter-paragraphs.js, there's code which creates a new paragraph and duplicates the properties of the left and right nodes (which are presumably the same node) from where ENTER was hit. Didn't DOM's "cloneNode(false)" work better? Perhaps you tried it and found some glitches I can't think about, that's why I thought I'd ask..

Anyhow, your code is great and it will make it into the next release; it's definitely needed since virtually all developers using HTMLArea are unhappy about this Gecko <-> IE difference.. Thanks for contributing it! 8-)
--
Mihai Bazon,
dynarch.com
Applied Web Standards


mishoo
User

Feb 9, 2004, 5:01 AM

Post #17 of 26 (4566 views)
Shortcut
Re: [Hipikat] Mozilla: <br/> vs. <p> on Enter [In reply to] Can't Post

OK, I committed the code. I also have done some small changes (couldn't help it :-p), I hope the functionality is intact. My changes were related to how you check if an element is inline.. shortened the code a bit by employing a RegExp to do the trick. I love RegExps.. ;-)

One serious problem, though, is inserting the &nbsp;. It's at best annoying. There has to be another way to keep the paragraphs. I did the same in tables, for instance, because if all cells were completely empty Mozilla didn't display the table at all. But later I have found a better trick: <br/> instead of &nbsp;. At least, the <br/> is both invisible and you can't walk the caret around it, if it's exactly at the end of some block element. Could we do that? I tried to hack the code but I hadn't fully understood it yet..
--
Mihai Bazon,
dynarch.com
Applied Web Standards


Hipikat
User

Feb 9, 2004, 5:59 AM

Post #18 of 26 (4561 views)
Shortcut
Re: [mishoo] Mozilla: <br/> vs. <p> on Enter [In reply to] Can't Post


Quote
there's code which creates a new paragraph and duplicates the properties of the left and right nodes (which are presumably the same node) from where ENTER was hit. Didn't DOM's "cloneNode(false)" work better?


Aaah, don't presume =) 90% of what made this little project so interesting is that people can have complicated selections throughout the document before they hit enter. For example, starting in a paragraph and ending in a different paragraph, starting in text that 'just in the body' and ending in a paragraph or going between different types of divs that have nothing to do with paragraphs...

EnterParagraphs will attempt to preserve the attributes of both the anchor and focus nodes as they're split again, and if paragraphs weren't involved, make new ones up to the borders of where the next 'display: block' elements are - but then that might only be necessary on one side or the other.

You could probably use cloneNode(), but then you'd have to fork the code into one stream of cloning it if the anchor/focus started/ended in a paragraph or creating a fresh one otherwise - which would probably be as many lines of code. And cloning the contents of those nodes isn't desired, as new partial ranges (only *outside* the selection (line 122-132)) are to be the final content of the paragraphs...

Boy, dancing around the DOM is tricky :P


Quote
changes were related to how you check if an element is inline.. shortened the code a bit by employing a RegExp to do the trick. I love RegExps.. ;-)


I'm open to changes in that department =^.^= The love of RegEx is mutual. If it was taught to students soon after reading and writing, the world would be a much more efficient place...


Quote
One serious problem, though, is inserting the &nbsp;. It's at best annoying.


I'll say =) I considered many models and options with a linguist friend who isn't a programmer, and this seemed to be the best compromise... At least without adding much more code, but then if much more code will fix it it's probably the best path to follow.

The problem isn't losing the paragraphs, it's that, at least under Gecko, they'll 'collapse' into each other - and hitting enter many times will just add <p /><p /><p /> to the DOM, without the perception of more space on the front end...

That's unacceptable, since when an end user hits enter lots of times, they want more lines to appear, damnit! Replacing neighboring <p />s with <br /><br /> is an option (one of those 'more code' options), but brings us back to the original point of this dilemma - that a paragraph is a block element and functions like formatblock work to change formatting on block elements. Thus changing a single paragraph with <br /><br /> after the first line into Heading 2 changes the whole thing to Heading 2... Bummer.

Even producing <p>foo</p><br /><br /><p>bar</p> isn't really a valid option, because then starting to type in between the breaks means you're suddenly writing on the document level instead of in a paragraph =P Argh! Although that wouldn't be *so* bad.

It's after all this frustration that I turned to see what the original (IE only) TTW WYSIWYG editor my CMS used, and found the &nbsp; solution. I'm not sure, but I suspect that might actually be how IE itself is doing it. Anyone who can come up with a solution that solves everyone's problems will really make my day =)


mishoo
User

Feb 9, 2004, 6:47 AM

Post #19 of 26 (4553 views)
Shortcut
Re: [Hipikat] Mozilla: <br/> vs. <p> on Enter [In reply to] Can't Post


Quote
and hitting enter many times will just add <p /><p /><p /> to the DOM, without the perception of more space on the front end


yeah, I noticed that..


Quote
Even producing <p>foo</p><br /><br /><p>bar</p> isn't really a valid option


I wasn't suggesting that... For instance, when pressing ENTER after ENTER, the current code produces:

<p>&nbsp;</p>
<p>&nbsp;</p>
...

I was suggesting this to become:

<p><br /></p>
<p><br /></p>

(if not empty paragraphs at all)
--
Mihai Bazon,
dynarch.com
Applied Web Standards


Hipikat
User

Feb 9, 2004, 7:08 AM

Post #20 of 26 (4549 views)
Shortcut
Re: [mishoo] Mozilla: <br/> vs. <p> on Enter [In reply to] Can't Post

Oh, right! =)

Yeah, brilliant... Hehe.. I've got one of those slap myself in the face feelings, after so much consideration and then I'm presented with such an obvious solution =)

It doesn't break formatting by having a random <br /> in the paragraph after the user starts filling it in, or do we deal with that later? In any case, yes, do what you will.


JSTijn
Novice

Feb 9, 2004, 7:24 AM

Post #21 of 26 (4548 views)
Shortcut
Re: [Hipikat] Mozilla: <br/> vs. <p> on Enter [In reply to] Can't Post

I tested your patch, and it works mostly. But if when you enter a lot and do like word editing stuff you get funny stuf. So after a <h1>header</h1> it goes like this <h1>header<p>&nbsp;</p></h1>. or sometimes like this: <p><h1>header</h1></p><p><h1>&nbsp;</h1></p>. And i can come up with more examples how it doesn't work like it should. But normal enters after another paragraph work great. but if you want to delete some paragraphs you keep the &nbsp;'s so they will be added to your row where you are deleting from.

The option with <p><br /></p> looks nice, but in the current situation it goes like this: <p><p>&nbsp;</p><p>&nbsp;</p><br /></p> after an enter. And i guess thats the problem mishoo is running into. I am currently using firefox 0.8, just downloaded from mozilla.org


mschering
Novice

Feb 11, 2004, 3:26 PM

Post #22 of 26 (4485 views)
Shortcut
Re: [mishoo] Mozilla: <br/> vs. <p> on Enter [In reply to] Can't Post

I just added this in the onsubit function and it works for the empty lines:

var replacement = '<p><br /></p>';
editor._textArea.value = editor._textArea.value.replace(/<P[^>]*\/>/gi, replacement);

Seems easy.

Regards,

merijn


havardw
Novice

Feb 17, 2004, 6:09 AM

Post #23 of 26 (4338 views)
Shortcut
Re: [Hipikat] Mozilla: <br/> vs. <p> on Enter, and other block level elements [In reply to] Can't Post

Hipikat,

thank you for your great work in taming Mozilla.

The current implementation in CVS will insert two <p> elements even if the cursor is positioned inside another toplevel element such as <h1>, resulting in HTML code like this: <h1><p>...</p><p>---</p></h1>

Is this the desired behaviour, or would it be possible to change the code to split the element instead, to get <h1>...</h1></h1>---</h1>?


Hipikat
User

Feb 17, 2004, 7:40 PM

Post #24 of 26 (4312 views)
Shortcut
Re: [havardw] Mozilla: <br/> vs. <p> on Enter, and other block level elements [In reply to] Can't Post

Good question... I'm aware of the current behavior, and it is what i knowingly programmed in. I knew IE surrounded some things with <p />s, but I wasn't sure about others and yeah, getting back to windows and looking at IE's behavior now, clearly it does just split <h* />s themselves, not to mention <div />s and other block display elements...

But I don't know what to do, because I'm sure it can't just be applied to all block display elements without thinking - <code /> for example, IE splits to:

Good question... I'm aware of the current behavior, and it is what i knowingly programmed in. I knew IE surrounded some things with <p />s, but I wasn't sure about others and yeah, getting back to windows and looking at IE's behavior now, clearly it does just split <h* />s themselves, not to mention <div />s and other block display elements...

But I don't know what to do, because I'm sure it can't just be applied to all block display elements without thinking - <code /> for example, IE splits to:


Code
<P><CODE>blapppi</CODE></P> 
<P><CODE>ty blah</CODE></P>


So evidently, some tags are in and some are out. Hopefully it's that simple and there aren't other strange exceptions which require special attention :) But in either case it's certainly more work, more code, and I don't have time right now to work out a list or do it.

It's on the wishlist, but the behavior I've got now is sufficient, and sadly I'm not doing this for the pleasure of it - although oddly, I would be, if only I had a little more spare time...


havardw
Novice

Feb 18, 2004, 1:38 AM

Post #25 of 26 (4309 views)
Shortcut
Re: [Hipikat] Mozilla: <br/> vs. <p> on Enter, and other block level elements [In reply to] Can't Post


In Reply To
Good question... I'm aware of the current behavior, and it is what i knowingly programmed in. I knew IE surrounded some things with <p />s, but I wasn't sure about others and yeah, getting back to windows and looking at IE's behavior now, clearly it does just split <h* />s themselves, not to mention <div />s and other block display elements...

But I don't know what to do, because I'm sure it can't just be applied to all block display elements without thinking - <code /> for example, IE splits to:


Code
<P><CODE>blapppi</CODE></P> 
<P><CODE>ty blah</CODE></P>


That's probably because <code> is an inline element Wink
The list of block level elements are for this purpose headings, <p>, <div>, <blockquote> and <address>.


In Reply To
So evidently, some tags are in and some are out. Hopefully it's that simple and there aren't other strange exceptions which require special attention :) But in either case it's certainly more work, more code, and I don't have time right now to work out a list or do it.

It's on the wishlist, but the behavior I've got now is sufficient, and sadly I'm not doing this for the pleasure of it - although oddly, I would be, if only I had a little more spare time...

Then I hope you don't mind if I try to come up with a patch? I'll probably take a stab at it sometime near the end of the week.

First page Previous page 1 2 Next page Last page  View All
 
 


Search for (options)