WYMeditor doesn't load at all in IE6. No more info.

http://www.456bereastreet.com/archive/200612/forget_wysiwyg_editors_use_wysiwym_instead/#comment35

It is possible to size tables by dragging handles. Doing so is reflected in the markup. That needs to be filtered out at some stage before saving the page to the database.

To futher improve the semantic and accessibility aspects of the anchor element I think support for the ''rel'' attribute is nessecary.

If I'm not wrong there left two words, which are not translated: "Containers" and "Classes".
It would be nice to have localized this words.

I think support for '''' and '''' with at least the ''title'' attribute should be implemented (editable) in WYMeditor. This would improve the semantics and accessibility of what the editor will output.

New Catalan translation and Spanish language update.

Mustache.js is an easy to use template engine for, amongst other languages, JavaScript.

It seems to me this would help the project focus more on the other parts of the system and help with a more flexible skinning system.

What are your thoughts on this?

When choosing Paragraph/Heading/... in the list at the right side the background color is set to #F2F2F2, but no font color is set. On a site with a light link color this will not work.

Patch to the default screen.css file:

change:
.wym_skin_default .wym_section a { padding: 0 3px; display: block; text-decoration: none; }

to:
.wym_skin_default .wym_section a { padding: 0 3px; display: block; text-decoration: none; color: #000000;}

When you press enter after 'WYMeditor instance', that creates a new paragraph.
If you type some text, and if the cursor is at the end of the new paragraph, you get 'endNode is not defined', line 610, when you click on the link button.

New patch containing Spanish translation.

I was able to fix the tag issue by making param an inline tag rather than a block tag.

rogerhu@3cf8fe0

This is my first take on the WymClassSafari.

It prevents the default behavior and preserves the selection for further processing (as suggested on the development wiki).

The class handles Apple-style-span elements and sets the correct tag for them.

Unsupported commands can be implemented using a simple name convention like:

{{{
WymClassSafari.prototype.InsertOrderedList = function(param) {
// InsertOrderedList implementation
}
}}}

This can lead to hackish code which might not be worth the effort, as new safari update with better execCommand support seem to be coming http://webkit.org/blog/?p=65

It also implements a commented version (as requested by Jean-Francois) of the duplicated tag removal procedure I added to WymClassMozilla #26 plus introduces some improvements and bug fixes.

There is a small annoyance when toggling into HTML mode. You need to click the textarea in order to see the html code. It seems like a CSS problem. Perhaps calling to focus() if the textarea is visible might help here.

Class and Container handler is not implemented yet.

There is no way to add elements and attributes (th, caption, scope, etc) needed for accessibility to data tables.

The 'Preview' button is missing.

Not all WYM features are available in all browsers (safari lacks most of them) so there should be a way to detect/define which functionality is available in order to avoid showing no-working buttons.

1. When I click "enter" to create new paragraph at the end of it tag "br" is inserted. When I click "enter" once again this tag will move to the end of new paragraph.
   I'm attaching screenshot where you can see what I mean.
2. Put the cursor at the end of last list item in list (ul or ol). Click "enter" once - new list item is created, click once more... and there should be new paragraph created. In IE this works good. In FF there is no new paragraph but the cursor is pointed outside the list block. New paragraph appear not till when you enter some text. I'm attaching screenshot where I've marked the cursor position.

Both issues noticed on Firefox 2.0.0.3 on Windows. On IE7 this works fine.

Copy all tickets from http://trac.wymeditor.org/trac/report/3 and set Trac to read-only.

Here you go.

Documentation must be improved before releasing 0.3 stable.

When editing the first box of the advanced.html file, if COMMAND + A is pressed for selecting all this contents

{{{

WYMeditor instance 0 with some text.

• One
• Two
• Three

}}}

is converted into this

{{{

WYMeditor instance 0 with some text.

• One

• Two

• Three

}}}

as you can see it encloses each list item into a paragraph block.

This is caused by the keyup reformatting so undoing using COMMAND + Z doesn't even work.

When undoing the editor should not perform any sanitizing or formatting as this might lead to data/format loss.

After a little bit of testing I've found that other blocks like "pre" are also converted into paragraphs.

This might happen in other browsers/OS

when entering the caracter " (double quotes) as part of the title attribute of an image, it causes problems.

Testing the 0.3 version on the demo page with IE7 under Windows XP. When I start entering text, I get the result shown in the first attached image: the text appears but there is no white box to indicate a paragraph.

If I press Enter and type more text, I get the second attached image: the new text appears above the old text, instead of below it. The white paragraph boxes appear, the new text is still above both of them, and the second box stays empty.

Here is a Swedish translation of WYMeditor.

There is no way to add elements and attributes (th, caption, scope, etc) needed for accessibility to data tables.

To further the semantic nature of Wymeditor, I think we need to add support for the address element. This is pretty minor but I think it would be a nice feature to have.

When you create nested lists, the current list element is closed before the next level ul or ol is inserted.

This patch came up when trying to fix issue #22.

I found that Mozilla designMode does insert tags even if they are repeated. This leads to situations where generated code looks like this (emphasis can not be removed on wysiwm mode)

{{{

Welcome to MetaDesign.

}}}

when it should be just

{{{

Welcome to MetaDesign.

}}}

As you can see it takes the outermost tag.

This might also needed on other browsers and it can be easily moved to jquery.wymeditor.js

Proposal for browser detection

var d=document;
var moz=(d.designMode&&!d.uniqueID); //op9+ and gecko
var ie=(d.uniqueID&&!d.childNodes); //ie and !ie4

When selecting all content of the editor (command + a / ctrl + a), all formatting like h1, table etc., is removed in favour of p-elements.

This happens in FF on both mac and pc.

While integrating WYM into Drupal, I met this problem : if WYM is embedded into a hidden container (collapsed fieldset, hidden div...), it will fail on load (exception : can't set designmode).

This is a known Gecko bug and the fix consists in[[BR]]

• catching the exception when setting designMode[[BR]]
• Resetting designMode when WYM's body gets focus

Attached are a test file and a patch against jquery.wymeditor.mozilla.js (Latest SVN).
Might need some work.

When you click on e.g. the Link button, cursorToStart is called (for debugging purposes), and the iframe looses the focus, so the cursor disappears.

Testing with Firefox on MacOS X, using the 0.3 version of WYMeditor on the demo page, I can't use the Ctrl+B/Ctrl+I key combinations to toggle bold and italic text. The same keys do work under IE7 on Windows XP.

IMHO, the buttons representing indent/outdent actions suggest that they create nested lists instead of blockquote. Besides I would appreciate such a "nested list" functionality.

I would love to help to enhance the code legibility but I cannot find anything about a coding standard.

Are there currently any efforts to create a coding standard? As I'm not familiar with the defaults of the jQuery community I'm not really sure if my style is too deviant from what people are used to...

I'd be willing to start working on a draft if required.

The default path should be automatically guessed by WYM, allowing users to overwrite it if desired.

This patch computes the base path by analyzing the '''src''' attribute in
{{{

}}}

It would be very useful to be able to set a ''root path for the wymeditor-folder''. At the moment I'm building a CMS system and WYMEditor as a plugin. This could be done in one of the constants.

sWYM_PATH = "/cms/plugins/orlokwymeditor/wymeditor/";

I can of course change the paths by replacing strings in the affected variables (for example in sIframeHtml and sDialogHtml). And maybe that's the idea altogether. But I figured I'd post a ticket just in case.

== Example ==

My WYMeditor-folder is places in a plugin-folder, as such:

{{{
/cms/plugins/orlokwymeditor/wymeditor/jquery.wymeditor.js
}}}

I include this script, and others, from:

{{{
/cms/admin/index.php?page=pageform
}}}

This, however, makes the paths in the script wrong (in the ''sIframeHtml'' variable):
{{{
/cms/admin/wymeditor/wymiframe.html
}}}

This also appears in the WYMeditor-generated dialogs (in sDialogHtml variable):
{{{
/cms/admin/jquery/jquery.js
/cms/admin/wymeditor/jquery.wymeditor.js
}}}

I am unable to edit existing links in Firefox.

When I put the cursor on a link and click the Link-button the window pops up as normal with the correct values in the textboxes. But when I click Submit, the window closes but no changes are made on the link.

I tested the same thing on the same page in IE7, and that worked fine.

Regards
David

Reference : [http://forum.wymeditor.org/forum/viewtopic.php?t=80]
In Mozilla, when switching a container, focus is lost, so you must click on the container to give the focus back to it.

This piece of (hacky) code might do the trick :

{{{
function setFocusToNode(node) {
if (moz) {
r=document.createRange();
r.selectNode(node);
sel=iframe().contentWindow.getSelection();
sel.addRange(r);
sel.collapse(node,0);
iframe().contentWindow.focus();
}
}
}}}

Attached is a modified 'wym.js' file, implementing the function above (for WYMeditor '''0.2.2'''), in case someone wants to see this function in action.

I have run into a real-world situation where one of the users of SkyBlueCanvas with Wymeditor needs to be able to insert html special characters without editing the raw HTML (¨ » etc.). I think this is going to be a necessity in a fully developed version of Wymeditor.

The 'Paste from Word' button is missing.

HTML entities are case sensitive see http://www.w3.org/TR/html401/sgml/entities.html

On the IE class all the entities are lowercased. So Á (Á) is converted to á (á)

I couldn't test this on IE but looking to the code made me aware of this. Please confirm this issue if you have IE at hand.

In order to acomplish Safari integration and adding support for semantic tags like

As jf.hovinne suggested at #12 insertAtCaret should be implemented in the core.

Other useful methods to implement might include

• hasContentSelected
• getSelectedContent
• replaceSelectedContent
• insertAtCaret
• deleteSelection
• moveCaretTo
• getCaretPosition

If this sounds OK, I will start adding this features at the [https://trac.wymeditor.org/trac/browser/branches/new_parser New parser] branch.

When you double-click at the end of a paragraph, it is selected, but startNode and endNode return the BODY element.

As of 0.3 you can make changes in the HTML textarea and they are immediately reflected it the WYMeditor portion below, but why doesn't it work the other way around? You have to click the HTML button to close the HTML pane and then click again to reopen and see the latest HTML.

If you paste directly into the window from MS Word (in FF), you still get a big mess in WYM Editor

... and if I click the "paste from word button" with an entirely empty main textarea, nothing pastes at all.

Microsoft's contentEditable sometimes generates duplicate ID's.

Steps to reproduce :[[BR]]

• edit "advanced.html"[[BR]]
• in the 'wym.html' call, add some html containing 'strong' and 'em' tags :
  {{{

  Bold, Italics

  }}}
• open "advanced.html"[[BR]]
• try to remove bold or italics

The same problem occurs with WYMeditor 0.2.2 when dynamically inserting the html content (see the issue on drupal.org : [http://drupal.org/node/134278] ).

The workaround is to convert 'strong' and 'em' tags to 'b' and 'i', ''before'' inserting the content. To test this, I used the following quick fix :

{{{
Wymeditor.prototype.html = function(sHtml) {
if(sHtml) {
sHtml=sHtml.replace(//g,'').replace(/</strong>/g,'');
sHtml=sHtml.replace(//g,'').replace(/</em>/g,'');
$j(this._doc.body).html(sHtml);
}
else return($j(this._doc.body).html());
};
}}}

The strict DTD requires that blockquotes only contain block level elements.

Polish translation for WYMeditor. Lang file in attach