• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7700 for generic doc work for TWiki-6.0.2. Use View topic Item7703 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

Item4604: Must have clean fallback if JS is disabled in the browser

Item Form Data

AppliesTo: Component: Priority: CurrentState: WaitingFor: TargetRelease ReleasedIn
Extension TinyMCEPlugin Urgent Closed   n/a  

Edit Form Data

Summary:
Reported By:
Codebase:
Applies To:
Component:
Priority:
Current State:
Waiting For:
Target Release:
Released In:
 

Detail

TinyMCE appears to munge paragraphs together that were previously created as raw text.

TinyMCE appears to munge paragraphs together that were previously created as raw text. See Item3652 revision 75 vs 74 in particular. It might be useful to leave an HTML comment in topics when testing TinyMCE, so that we can tell which revisions were edited with which WYSIWYG editor (and maybe which version?)

See Item3652 revision 75 vs 74 in particular. It might be useful to leave an HTML comment in topics when testing TinyMCE, so that we can tell which revisions were edited with which WYSIWYG editor (and maybe which version?)

-- TWiki:Main/RichardDonkin - 10 Sep 2007

I can't work out from that diff where you think the problems are; it all looks fine to me :-/

Can you provide a testcase? A set of steps that reproduce the problem is what I really need.

Thanks, CC

CC Sorry, I don't have a test case, but it has happened multiple times on that page - see revision 73's changes, or rev 68's. In all cases what was originally formatted as multiple paragraphs separated by blank lines (e.g. signature after blank line ends up in same para) - here's the history output. The problem first occured in Steffen's Rev 68 of 05 Sep 2007 - you can see several cases where the munging happens - first is 'line 6 to 6' where Michael's signiature is changed from separate para to same para.

Something reformatted this into a single paragraph, which I suspect is TinyMCEPlugin - might be something else but this is probably about when TMCE was turned on by default. Sorry, I don't have a test case, but it has happened multiple times on that page - see revision 73's changes, or rev 68's. In all cases what was originally formatted as multiple paragraphs separated by blank lines (e.g. signature after blank line ends up in same para) - here's the history output. The problem first occured in Steffen's Rev 68 of 05 Sep 2007 - you can see several cases where the munging happens - first is 'line 6 to 6' where Michael's signiature is changed from separate para to same para. I realise this is not a very helpful bug report, but you could try copying the raw text of rev 74 into Sandbox and making an unrelated edit with TMCE to reproduce. An unrelated comment on TinyMCE - on editing this page with JavaScript turned off, I see the blank lines have all been replaced by <p> markup - not sure if that's normal but it looks ugly for non-WYSIWYG editing. Something reformatted this into a single paragraph, which I suspect is TinyMCEPlugin - might be something else but this is probably about when TMCE was turned on by default.

I realise this is not a very helpful bug report, but you could try copying the raw text of rev 74 into Sandbox and making an unrelated edit with TMCE to reproduce. An unrelated comment on TinyMCE - on editing this page with JavaScript turned off, I see the blank lines have all been replaced by <p> markup - not sure if that's normal but it looks ugly for non-WYSIWYG editing.

-- TWiki:Main.RichardDonkin - 11 Sep 2007

There's another case of this at Item4419 - on editing the topic (with JS disabled), I get the normal editor but all of topic blank lines now have P (paragraph) HTML markup. Result of making a small comment at end can be seen - everything is squished. My setup is: Firefox 2.0.0.6, Windows, using NoScript extension (just disable JS to replicate this).

My setup is: Firefox 2.0.0.6, Windows, using NoScript extension (just disable JS to replicate this).

-- TWiki:Main.RichardDonkin - 11 Sep 2007>

But.... it's a JS editor! If you disable JS in the browser, then you're going to see this problem. OK, so let's set TinyMCE as unavailable if NoScript is enabled :-/

OK, so let's set TinyMCE as unavailable if NoScript is enabled :-/

-- TWiki:Main.CrawfordCurrie - 11 Sep 2007 No, that doesn;t make sense. The NoScript is only supposed to apply to embedded JS. There is no way on the server side to tell if JS is enabled in the browser or not :-(

No, that doesn;t make sense. The NoScript is only supposed to apply to embedded JS. There is no way on the server side to tell if JS is enabled in the browser or not :-(

-- TWiki:Main.CrawfordCurrie - 11 Sep 2007

TWiki really needs to work with JS disabled, i.e. to degrade gracefully just like good websites do - that's how I run most of the time, and I'm not going to re-enable JS for a public Internet wiki site, for security reasons (just too many JS holes are being discovered, and TWiki's a really nice place to host exploits IMO...) How about making the Edit button/link work as (1) ordinary link with JS off and (2) JavaScript link with JS on. In the 2nd case, you could set an additional variable in the GET URL, or a cookie, so that the server side knows to serve up a JS-enabled page. Without this, I don't think TMCE should be the default on public TWikis - otherwise those who disable JS are forced to insert HTML markup to get paragraphs to work - most un-Wiki like...

How about making the Edit button/link work as (1) ordinary link with JS off and (2) JavaScript link with JS on. In the 2nd case, you could set an additional variable in the GET URL, or a cookie, so that the server side knows to serve up a JS-enabled page. Without this, I don't think TMCE should be the default on public TWikis - otherwise those who disable JS are forced to insert HTML markup to get paragraphs to work - most un-Wiki like...

-- TWiki:Main.RichardDonkin - 11 Sep 2007 Some pointers on JavaScript graceful degradation:

* http://webtips.dan.info/graceful.html - see section on popups which talks about this dual mode button idea, and also part on menu rollovers and client vs server side forms.

* http://accessites.org/site/2007/02/graceful-degradation-progressive-enhancement/3/ - although TMCE is doing a lot more than form validation, from the POV of graceful degradation, the problem is similar - how to do one server-side action when hitting the Edit link with JS disabled, and another action when JS is enabled.Some pointers on JavaScript graceful degradation: Hope that helps. I'm sure other TMCE users must have had this problem too, but perhaps it's because in Wikis it's so easy to embed JS in pages that people like to have JS turned off.

  • http://accessites.org/site/2007/02/graceful-degradation-progressive-enhancement/3/ - although TMCE is doing a lot more than form validation, from the POV of graceful degradation, the problem is similar - how to do one server-side action when hitting the Edit link with JS disabled, and another action when JS is enabled.
  • Hope that helps. I'm sure other TMCE users must have had this problem too, but perhaps it's because in Wikis it's so easy to embed JS in pages that people like to have JS turned off.

    -- TWiki:Main.RichardDonkin - 12 Sep 2007

    I understand your points, but I'm not necessarily convinced by them. There are many. many sites on the internet where interaction is virtually impossible without JS, due to the rapid spread of AJAX and other JS-dependent tech. Yes, graceful degradation is important, but we have to trade off the value of graceful degradation versus the quality of the user experience.

    CC

    Isn't TMCE an upgrade from an existing raw-text editor mode that's used by all TWiki sites today? Surely if you are doing an upgrade you should make it easy to degrade from the WYSIWYG editor into the basic editor.

    Also, if there are ever bugs in TMCE, disabling JS is a very easy way for any user (who knows how to configure browsers but maybe not about the nowysiwyg URL param) to disable TMCE.

    I'm assuming here that the embedding in stored pages of HTML markup for paragraphs is not actually happening, i.e. the server is rendering things as HTML on assumption that TMCE is running.

    Even if you don't think people should disable JS when TMCE is enabled, some inevitably will (e.g. in response to latest browser security hole), so TWiki needs to deal with this elegantly.

    TWiki is not a fully AJAXian site (yet) and I don't think it is hard to do graceful degradation.

    BTW this page is now a mess due to this (the bullets above are 2/3 broken...) - do you really want this to happen? As a TWiki site admin this would make me turn off TMCE until it was fixed.

    -- TWiki:Main.RichardDonkin - 12 Sep 2007

    Here are the possible approaches to supporting graceful degradation that I have considered:

    1. Provide both the raw (unconverted) and converted (TML to HTML) content in the page.
    2. Serve the converted content from a REST handler only.
    3. Do the conversion from TML to HTML in JS.
    A REST handler (2) is the most generic solution, but requires an additional pass through the server which is slow and risky, as we saw with Kupu. Doing the conversion in JS increases the load on the client (and the server due to the volume of JS required) It also means TWiki variable expansions (e.g. image embeddings) have to be a lot less intelligent. Providing both the raw and the converted content on the page is also slow, as Sven discovered with his sectional edit stuff with Wikiwyg, as well as requiring significantly more JS to untangle.

    I need to think about this some more.

    CC

    Probably I don't understand some subtlety, but could we not refine option (1) as follows, in the view page:

    • If JS enabled, Edit link appears to user to work as now, but actually relies on JavaScript (use onClick to have some JS code set a hidden form attribute tmce_enabled to 1)
      • Server code works in the TMCE way, returning HTML
    • If JS disabled, Edit link just does HTML/HTTP form submit, with no JS of course, and the form attribute tmce_enabled, which defaults to 0, is sent as is.
      • Server code returns TML only, edited in the pre-TMCE editor.

    I don't see why this wouldn't work, it's just a simple switch between the basic editor and TMCE ways of doing things.

    -- TWiki:Main.RichardDonkin - 12 Sep 2007

    Ah, subtleties.... there are many. We don;t need to muck about with the links in any way at all. the only reason the fallback is a bit clumsy to do is that the server does the TML to HTML conversion before it passes the content on to the editor. If, instead, we use the REST handler in the Wysiwyg plugin to perform the translation, then we don't need to do that pre-translation - it is only done when the JS editor actually starts, which it won't if JS isn't available. The editor marks the HTMl with a special comment that flags to the WysiwygPlugin that the text requires post-translation back to TML. All around a neater solution.

    I changed the headline from "Paragraphs munged together by TinyMCE" to reflect the discussion

    CC

    OK, it ought to be happier now

    CC

    ItemTemplate
    Summary Must have clean fallback if JS is disabled in the browser
    ReportedBy TWiki:Main.RichardDonkin
    Codebase ~twiki4
    SVN Range TWiki-4.2.0, Sat, 08 Sep 2007, build 14780
    AppliesTo Extension
    Component TinyMCEPlugin
    Priority Urgent
    CurrentState Closed
    WaitingFor

    Checkins TWikirev:14833 TWikirev:14836 TWikirev:14837 TWikirev:14838 TWikirev:14848
    TargetRelease n/a
    ReleasedIn

    Edit | Attach | Watch | Print version | History: r21 < r20 < r19 < r18 < r17 | Backlinks | Raw View | Raw edit | More topic actions
    Topic revision: r21 - 2007-09-13 - CrawfordCurrie
     
    This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
    Ideas, requests, problems regarding TWiki? Send feedback