EnterParagraphs dangling section conflict with HTMLArea.getHTMLWrapper

Yermo · 2005-05-13 01:30:56

In the nightly example build clear out all the text and html. Type in the word test and press enter. Switch to source view and you will notice:

<p>test</p><p>
</p>

The second is being generated because, under FireFox, there is a blank text node to the right of the selection which is incorrectly being wrapped in tags in EnterParagraphs.prototype.processRng at the very bottom in the fragment:

roam = (pWrap || (cnt.nodeType == 11 && !cnt.firstChild)) ? editor._doc.createElement('p') : editor._doc.createDocumentFragment();
roam.appendChild(cnt);

Above this snippet is a section that creates a "fill" container that has a tag inserted if the range happens to be "content-less", per the comment. However, that section is completely ignored.

So, adding a simple if ahead of the code fragment above as in:

if ( fill )
  roam = fill;
else
  {
  roam = (pWrap || (cnt.nodeType == 11 && !cnt.firstChild)) ? editor._doc.createElement('p') :
      editor._doc.createDocumentFragment();
  roam.appendChild(cnt);
  }

Gets rid of the double tags on end condition (in this one case - there are unfortunately many more).

So now, at this point in the code when you repeat the test above, you have a document that looks like

ELEMENT_NODE - tag 'BODY' - 4 children
    ELEMENT_NODE - tag 'P' - 1 children
        TEXT_NODE contents 'test' - 0 children
    TEXT_NODE contents '' - 0 children
    TEXT_NODE contents ' ' - 0 children
    ELEMENT_NODE - tag 'BR' - 0 children 

(i.e. <p>test</p>(empty node)(empty node)<br>)

However, when you switch to source view the trailing is stripped out as a result of a long series of calls that eventually wind down to HTMLArea.getHTMLWrapper() where it does:

    case 1: // Node.ELEMENT_NODE
    case 11: // Node.DOCUMENT_FRAGMENT_NODE
    case 9: // Node.DOCUMENT_NODE
      {
      var closed;
      var i;
      var root_tag = (root.nodeType == 1) ? root.tagName.toLowerCase() : '';
      if (root_tag == 'br' && !root.nextSibling)
        break;
      ^^^^^^^^^^^^^^^^^^^^^^^^^
     ...

If you manually enter a and switch to WYSIWYG mode the element is not filtered out. It only happens when you switch from wysiwyg mode to text mode.

Is the ugly trailing the desired behavior? That seems unlikely since the tags have a tendency to stack up endlessly. (select the end of "test" and hit enter and repeat a few times then switch to text mode - but you can't select down into any of the subsequent tags so their use as a blank line in this case is somewhat limited)

I've seen another editor which keeps some trailing tags at the end of the document presumably to make it easier to "get out of" selections and the like but I can't remember what the tags were.

So the question is:

What's the "right" behavior?

Should EnterParagraphs do something different on empty right hand side node other than a (i.e. enter at the end of the document?)? (i.e. test )

Should it be something like test ?

Or just nothing (i.e. test)?

Any thoughts or insights would be greatly appreciated.

Thanks,

-- Yermo

gogo · 2005-05-13 01:56:29

would be the traditional way of inserting a "blank line" I think, at least around these parts, pretty sure this is what DW produces if you hit enter a bunch of times. I think that's what you are asking?

Yermo · 2005-05-13 02:12:46

gogo wrote:

would be the traditional way of inserting a "blank line" I think, at least around these parts, pretty sure this is what DW produces if you hit enter a bunch of times. I think that's what you are asking?

Actually, no. Do this, enter

test

on the first line of an empty document in the editor.

Press enter.

Now when you view the source you will see

test

That's clearly not correct as it should be:

test

In EnterParagraphs what looks like the original code would make it be:

test

but the is stripped out the getHTMLWrapper.

So the questions is what should the terminal tag in a document be? (i.e. in the case of entering test by itself in a window and pressing ENTER what should the resulting HTML look like? test? test ? something else? )

I saw one editor that always kept some tags at the very end of the document but I forget what they were .. seemed to be related to making it possible to get out of selections ...

willeffects · 2005-05-13 03:07:05

Doesnt IE and Mozilla handle trailing br tags differently? I dont have IE on this box but i thought a text in IE produced the double space while it did not in FF.

I put in the to get of out selections, but I only put it in where needed. I think it might make more sense to put in something like so that you can use something like php to remove them on submit. This is especially important when you have multiple editors that append the data into one submit (so now you can remove all instances without guessing where one submit started and ended).

my 2cents

Last edited by willeffects (2005-05-13 16:51:16)

Xinha Discussion Forum

Announcement

#1 2005-05-13 01:30:56

EnterParagraphs dangling section conflict with HTMLArea.getHTMLWrapper

#2 2005-05-13 01:56:29

Re: EnterParagraphs dangling section conflict with HTMLArea.getHTMLWrapper

#3 2005-05-13 02:12:46

Re: EnterParagraphs dangling section conflict with HTMLArea.getHTMLWrapper

#4 2005-05-13 03:07:05

Re: EnterParagraphs dangling section conflict with HTMLArea.getHTMLWrapper

Board footer