The following is being seen in Firefox 3. (since my understanding is this will vary by browser)

This module is great, but it doesn't insert code that is very standards compliant (or even very sensible). It's using <div> tags all over the place, which isn't proper for formatting text. (divs should be reserved for layout, not formatting)

Here's some examples:

  • When doing a single return, the next section of text is wrapped in a div tag. This really isn't proper, as it should be inserting a <p> tag to create a new paragraph.
  • When holding shift and hitting return, it's generally a WYSIWYG standard to insert a <br /> tag at that point, making a simple line break instead of a paragraph break.
  • When doing a double return, we're getting the ugliest code of all. It outputs an extra <div><br /><div> set of code between the already existing <div> tags.

I'm no coder, or I'd submit a patch...but from a themer/user experience standpoint, I really want to be able to use this module without it inserting a ton of unnecessary <div> tags into the content...especially when those should be simple text formatting tags.

Thoughts on this?

Comments

mfer’s picture

mfer commented

The div tags and other junk are to get it to present well in a WYSIWYG view. It makes it display right (hopefully). The way a WYSIWYG editor works is by inserting an iframe. That iframe needs to have full html to make it display and not just text so it can format things correctly.

When it goes to save the data is should be stripping all that stuff out so that what's saved is what you'd expect. It should have those div tags, p tags, or br tags. When it opens it up in the editor again it should add them back.

If you save something you enter into the editor is all that stuff being saved?

Poetro’s picture

Poetro commented

Something like this: 

      $(idoc).keypress(function(e) {
        if (e.keyCode) code = e.keyCode;
        else if (e.which) code = e.which;
        if (code === 13) {
          if (!$.browser.opera) {
            try {
              var el = glob_ha[d.id].getEventElement(iframe.contentWindow, e);
              if (el.nodeName == "BODY") {
                glob_ha[d.id].cmd("formatblock", "<p>");
              }
            }
            catch (exception) {}
          }
        }
      });

ATM i dont remember how it is implemented, but should be changed similarly to this.

frames’s picture

frames commented

I'm not sure I fully understand this issue, but if I save a comment (there's were I'm using HTMLBox), I don't get any extra divs.

Rob_Feature’s picture

Rob_Feature commented

If what mfer says is correct (that this only affects the WYSIWYG view and not the final output), then that makes the "html" button useless once you've added any formatting using the WYSIWYG. It would mean you're seeing a bunch of inaccurate code that won't really be displaying in the final result and if you start editing it in HTML mode...you're going to end up with a mess.

I'd suggest this is something that really needs to be changed to make this module usable. When clicking the HTML button, it should show you the actual code it's going to use...not the code that it's using to format the WYSIWYG display.