JAWW (beta)

The ward is a factory for the Combine

I’m using Rich Text Editor and I have problems!

FAQ no longer [since 2006/Jun/07] blames Safari:

Using Safari you cannot see the toolbar editors – either the Rich Text Editor or the basic one. This is not the fault of WordPress.com. It is a fault in Safari in that it uses a non-standard way of rendering the necessary code.

it should be said that wp.com Rich Text Editor (TinyMCE) uses a specific extensions (quirks) of Microsoft® Internet Explorer (since v5.5; in this case even proprietary) and Mozilla Foundation (since v1.3; or to be exact a Gecko) based family browsers.

and, currently, THERE IS NO SUCH A ’standard way of rendering the necessary code.

therefore, plain truth is so called ’Rich Text Editor’ which describes itself as a cross platform* is available to users of only two mainstream browser family TMCE supports.

oh, and yes, of course: “We have no plans to support Markdown or Textile at present“. apparently, Markdown or Textile users don’t belong wp.com target audience which is probably supposed to be a crowd of a complete dummies who can only push a fancy WYSIWYG buttons, which alas does not even work with a Safari browser.

*) WTF, why the hell browser is platform??? or, even better, why MSIE & Mozilla are the platform and others ain’t one?

6 responses to “I’m using Rich Text Editor and I have problems!

  1. berk June 1, 2006 at 13:12

    Use Camino if you want the rich text editor on a Mac. I can’t recommend Firefox on Mac because it’s too slow. I also don’t recommend Safari because it doesn’t play well on some sites.

    This might be a repeat of what you read, but here’s some info on the WP FAQ.

    ---

  2. drmike June 1, 2006 at 15:34

    Actually the issue with TinyMCE is that Safari doesn’t support WYSIWYG. We have the same problem with TinyMCE in phpBB, phpNuke, and other platforms. The issue exists elsewhere as well.

  3. podz June 6, 2006 at 10:20

    As far back as January 2004 when I started with WordPress, mac users complained that they could not see the quicktags. Nothing to do with TinyMCE. Quicktags = javascript. If IE, Netscape, Mozilla and Opera could make it work, and Safari could not it suggests that the problem lies with how Safari handles javascript. There may be no ‘standard’ but if one product cannot and several products can then it’s fair to say that the one product is getting it wrong is it not?

    My wording in the FAQ may be slightly wrong but the meaning is the same – the fault lies with Safari.

  4. options June 6, 2006 at 15:36

    hello folks!

    thank you all for your comments to this post and sorry for delay with my reply to them.

    first of all, I think I need to reiterate myself a bit to (hopefully) make the point of this post more clear:

    * it’s not that I’d be fond of Apple Safari browser, or have something against of TinyMCE, but at the same time, I don’t think it’s good idea when a pot (script of several dozens lines length) calls a kettle (very large codebase written on the Objective-C) black.

    * I also believe that instead of misleading statements in the WP FAQ pages and Support forums which blames Safari (or other browsers) for the lack of nonexistent (in this moment) standards support, there should be put just a simple list of browsers TMCE currently has support for and reliably work with.

     

    berk:

    thanks for your suggestion of using a ‘Camino’ browser on Mac — indeed, since Camino uses a Gecko (see a link in the post) rendering engine, it is naturally that TMCE works pretty good with it due to enough efforts has been put into the TMCE to support this another major browser family.

     

    drmike:

    Actually the issue with TinyMCE is that Safari doesn’t support WYSIWYG.

    Safari (WebKit) not only DOES SUPPORT WYSIWYG (in-page Rich Text Editing), but it is used by the standard Mac OS Tiger Mail.app and some third-party browser based WYSIWYG HTML editors as well (see a ‘TTW (“Through the Web”)’ WYSIWYG Web Editors List and a ‘WYSIWYG Editors directory’ at htmlArea.com for instance).

    and, yes, as absolutely any software it has bugs/flaws which are WebKit devs are working on, also, they are “welcome any WinIE-compatible patches that improve editing support to match WinIE“.

    so, actually the issue with TinyMCE is that it doesn’t support Safari as much as it does MSIE and Mozilla, while Safari doesn’t yet mimics MSIE behavior as much as Mozilla does ;-)

     

    podz:

    Quicktags = javascript. If IE, Netscape, Mozilla and Opera could make it work, and Safari could not it suggests that the problem lies with how Safari handles javascript.

    alas, it’s not just Javascript, I have to disappoint you once again, but AlexKing’s QuickTags script uses MS DHTML quirk .createTextRange() (“There is no public standard that applies to this method“) and Netscape/Mozilla DOM 0 .getSelection() (“Specification: Not part of specification“) methods which are exposed to browsers’ Javascript engines. you can also see a .getSelection() browsers incompatibility chart at the http://www.quirksmode.org

    I know you don’t code, but this code snippet comments do speak for themselves:

    // JS QuickTags version 1.2
    //
    // Copyright (c) 2002-2005 Alex King
    // 
    //
    // This JavaScript will insert the tags below at the cursor position in IE
    // and Gecko-based browsers (Mozilla, Camino, Firefox, Netscape).
    //
    // For browsers that do not support inserting at the cursor position 
    // (Safari, OmniWeb) it appends the tags to the end of the content.
    
    
    function edInsertContent(myField, myValue) {
    
            // IE support
            if (document.selection) {
                    myField.focus();
                    sel = document.selection.createRange();
                    sel.text = myValue;
                    myField.focus();
            }
    
            // MOZILLA/NETSCAPE support
            else if (myField.selectionStart || myField.selectionStart == '0') {
                    var startPos = myField.selectionStart;
                    var endPos = myField.selectionEnd;
                    var scrollTop = myField.scrollTop;
                    myField.value = myField.value.substring(0, startPos)
                                  + myValue 
                          + myField.value.substring(endPos, myField.value.length);
                    myField.focus();
                    myField.selectionStart = startPos + myValue.length;
                    myField.selectionEnd = startPos + myValue.length;
                    myField.scrollTop = scrollTop;
            } else {
                    myField.value += myValue;
                    myField.focus();
            }
    }
    

    [WTF!?! why `PRE` tags are stripped down from comments? now you can see how hard it to read w/o indents?]

     

    There may be no ‘standard’ but if one product cannot and several products can then it’s fair to say that the one product is getting it wrong is it not?

    following this logic, one can say: “There may be no ‘standard’ for customizing templates for public bloghosts, but if several products can do this by the secure way (having enough programming skills and guts: LJ, as you know, allows even external CSS) and one cannot, it’s fair to say that this one product is getting it wrong, isn’t it?” ;-)

    If you would like to make your web pages usable by everyone, it is important that you emphasize standards compliance. By complying with existing standards, rather than relying upon browser specific extensions and hacks, you can make sure that the web sites you design will be readable by all browsers supporting those standards, not just the ones you have time to test it on, and that your page designs won’t break when new browsers and versions come into existence.” (AnyBrowser.org)

     

    My wording in the FAQ may be slightly wrong but the meaning is the same – the fault lies with Safari

    I can’t see the reason of putting blame on any particular browser on the official pages, instead of putting a simple list of browsers TMCE really has support for and works with. and, besides, as I’ve tried to show, this is not a correct statement [ — the actual fault lies much deeper than in the browsers’ quirks usage by the tiny script in question and even deeper than in attempts to implement specific features by a particular browser without well established standards, but that’s a topic for another post or two].

    Browser makers are no longer the problem. The problem lies with designers and developers chained to the browser–quirk–oriented markup of the 1990s” (WebStandards.org)

    I thought alots about in-browser WYSIWYG editors — there’s actually a big cross-browser compatibility problem — it’s gonna be persisting until so called WYSIWYG Rich Text Editing becomes a real standard. I think I’ll blog about this and its possible working remedy in some future.

  5. podz June 6, 2006 at 22:52

    I’ll certainly change the FAQ to reflect the above… not quite sure of the wording so that Safari people don’t start throwing rocks at TinyMCE ..

  6. drmike June 22, 2006 at 22:54

    Heck, I throw rocks at the TinyMCE people. Why not let the Safari people have some fun? :)

%d bloggers like this: