Item9515: Help texts no longer visible with javascript off

Edit, attach or rename screens: if javascript is off, FW 1.0.9 shows the help text at the bottom of the page. In trunk this is no longer the case. The help text is written but with an inline style display:none, hiding the info.

-- ArthurClemens - 21 Aug 2010

Oops. As a result of fixing Item9422

-- PaulHarvey - 22 Aug 2010

If I turn it all upside down.

If the help text was visible always with JS off, I could as well have raised a bug reports saying that that in many UI cases the help texts are too intrusive and confusing for those that run without JS.

Most of the places where we hide help text behind a twisty, we do it because under normal use the help text adds so much information that the important controls drown. And in many cases the help text is 2-3 lines.

It is only few very geekly people that run with JS off, and with strikeone protection as default, we actually do not even allow people to save topics without JS.

I am not these help texts should be visible by default when JS is off. There may be a few places where it is important, but then let is discuss those.

What does others mean? This is raised as a release blocker, so it must be important.

-- KennethLavrsen - 22 Aug 2010

TwistyPlugin has a documented promise that no-JS users will be able to view the content (default expanded if no JS regardless of initial hidden state).

So, can't use JS to set hidden attribute on hidden twisties. Because jquery plugin does this on document.ready(); that's after the page is initially rendered, and gives us the jumping effect. So the content is hidden with a display: none; inline attribute. But then the no-JS users won't ever see the content. Can't put a <noscript> around some <style> tags either, that gives invalid XHTML, although it does work. It seems there's really no choice but to emit the content twice; once display:none, the other <noscript>

-- PaulHarvey - 22 Aug 2010

Well, the help texts have always showed with js off. I cannot see their removal/hiding as a feature.

-- ArthurClemens - 22 Aug 2010

You mean emit the content twice, just like it's always been?

Be careful that you generate proper content. I fixed a bug once because we include some page which had some div with ID in it. As we included them once for the JS, once for the noscript, we had duplicated IDs.

So Paul, what's the problem here? You don't like duplicating stuff? Then the only other alternative would be (I tried, and failed, but maybe with JQuery it's doable) to remove the content of the noscript thingy, and put it in a twisty, onload.

-- OlivierRaginel - 24 Aug 2010

What's the problem of having the content twice? These are not indexable pages.

-- ArthurClemens - 24 Aug 2010

On our site we hide some large swaths of pretty boring stuff under twisties. That's probably the wrong way to structure our documentation, but it happens.

I didn't want

1. Waste CPU time at the server
2. Bandwidth on the page views
3. Duplicating content can cause undesired side-effects; duplicate IDs, anchors, macro expressions that should only be included once, etc.

There is a bug where the new <script> tags are emitted for non-hidden content as well as hidden, I will fix that.

-- PaulHarvey - 25 Aug 2010

Olivier, we can't do anything with jQuery because this is not available while the jumping is happening unless {OptimizePageLayout} = 0

-- PaulHarvey - 25 Aug 2010

I think I've done everything I can on this. Set Arthur and Michael for feedback, hoping for some better ideas or maybe we can close this task.

-- PaulHarvey - 25 Aug 2010

Also, the initial work on Item9422 causes Item9534, but the work on this topic closes that. So if we're "happy" with closing this task, also close Item9534.

-- PaulHarvey - 25 Aug 2010

Basically, foswikiMakeHidden must not have a display:none style as well produced by perl. Instead, it is hidden using javascript ... or left visible in case javascript is not available. That's how it is supposed to work.

Inlineing script sections right after the twisty markup code is very bad as it slows down processing the overall page. A single $(".foswikiMakeHidden").hide() will be better. That's what we already have in jquery.foswiki.js. The actual error is that this piece is rendered bogus as the perl code already added a display:none.

In addition the js code processing foswikiMakeHidden, or better let's use twistyMakeHidden needs an extra touch to capture the height of the twisty before hiding it. I've been experimenting with this kind of code and haven't experienced flickering twisties yet (with an OptimizePageLayout disabled). So the js code does fine wrt init'ing the page quickly.

Capturing the natural height of a twisty before hiding it might be the solution to cure animated twisties flickering as proposed here.

-- MichaelDaum - 25 Aug 2010

But we can't use any jquery; that's the whole cause of "jumping twisties".

There is a delay from when the browser renders the initial markup (with twisty content "open", for the no-JS browsers), to jquery being ready and the twisties being hidden again. That delay causes the jumping.

Unless you want to set a style for foswikiHidden in the head, but then no-JS users can't see the twisty content - the whole point of this task.

So there are conflicting requirements here. I'd be fascinated to see a different way of satisfying them all (and immensely happy too, I really don't want Foswiki to emit so much inline <script>).

-- PaulHarvey - 25 Aug 2010

The code I've comitted could be re-worked so that all the .style.display = none JS is aggregated into one single script tag at the end.

The problem was I could not find a neat way to add to the body using addToZone

-- PaulHarvey - 25 Aug 2010

Changed the solution again. Add a class 'js' to the <html> element with some JS in the head that also defines the style html.js foswikiMakeHidde { display: none; }

-- PaulHarvey - 25 Aug 2010

Solution should be put in jquery.foswiki.js.

-- ArthurClemens - 28 Aug 2010

Please document new twisty defects here. Tasks waiting on Item9588:

Item9515, Item9576, Item9625

-- PaulHarvey - 05 Sep 2010

This is now ready to be fixed, Item9588 is mostly done.

-- PaulHarvey - 05 Sep 2010

I've started working on a solution for Foswiki, not just TwistyPlugin.

-- ArthurClemens - 07 Sep 2010

foswikiJs is now set to the html tag when Javascript is available.

-- ArthurClemens - 09 Sep 2010

NNNNNNNOOOOOOOOOOOOOO!!!!!!!!!!!

Somebody again committed the inclusion of the help template, twice. I had done hooks to avoid doing that, otherwise the HTML is invalid, as they both define the same anchors. Arthur, I think you put that back, and I have no idea why... So please fix it! I've removed an extra </div> that I think I had already removed...

-- OlivierRaginel - 10 Sep 2010

I didn't put things back - the solution was not there yet.

Now that I have worked on the issue for 2 evenings, I see that it is too much work to maintain happiness for the perhaps unexisting non-javascript user, and I will remove the double inclusion.

In fact, the help texts are now hidden for non-js users (so they do not have the annoying help block at the top each edit).

-- ArthurClemens - 12 Sep 2010

Commenting is disabled while not logged in