• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 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.

Note: I expanded this from only being an IE problem related to verbatim to a general problem with any object wider than the browser window.

The current Dakar implementation of PatternSkin is not performing as well as it was in Cairo with respect to ensuring that menus and topic text is properly kept within the browser window. This issue is a major userability problem.


Dakar performs very badly with verbatim text in Internet Explorer and we have to do something about it.

In Cairo it worked very well so it can be done so it works in IE.

In Cairo - when you added verbatim text wider than the current window, the verbatim text would not wrap but run out of the right margin. To read it you had to scroll the entire browser window. That was OK and as expected. You do not want verbatim text to wrap.

In Cairo - the normal non-verbatim text, top bar, top and bottom menus would still stay nicely within the browser window. This worked well.

In Dakar is is all screwed up. The minute a page contains wide verbatim text everything gets wide. The top bar in which I have search and jump fields on the right gets expanded out of screen to the right. The edit/wysiwyg/attach/printable buttons are pushed out of the screen so you cannot see it unless you scroll to the side with the entire browser window.

The topic texts also gets expanded out of the window so you have to scroll the browser window from side to side to read the normal text.

The bottom menu will not wrap so the right bottoms cannot be seen if the window is narrow.

In summary - it is awful in IE. Both readability and userability is affected seriously.

In Firefox it works because of the new Dakar feature of showing a small horizontal scroll bar below each block of verbatim text. If this could work in IE that would be fine. If IE cannot do this feature then we need to find another solution. The way it worked in Cairo was acceptable. The way it works now is not acceptable.

You may now say - well it is rare that people paste in wide verbatim text. No it is not! It happens all the time when people report bugs and paste in error log messages. A large fraction of my Motion bug reports are screwed up now.

Quite a lot of the TWiki documentation has verbatim text. A significant part of the normal user TWiki documentation is now difficult to read in Internet Explorer. IE is still used by 99% of business users. And 60-80% of Internet users - so we cannot ignore IE.

A few examples of twiki docs that run outside the page (there are many more)

I have attached some screenshots from Cairo and from Dakar.

KJL

This problem is also when having graphics that are wider than normal.

In Cairo you would just have a wide picture and the rest was readable without having to sidescroll. Now menus and text is affected.

This is the most often heard complaints I have from my Motorola users since I upgraded 1 day ago.

We need a quick fix for this for 4.0.2. This is a serious issue.

KJL

I just extended the title a little.

This issue is even more severe than I thought.

Even attaching a picture which is larger than the browser window will make the whole page be as wide as the widest picture.

This is a serious problem. It is both menus and all the topic text that does not wrap correctly inside the browser window.

At Motorola many of our ISO9000 process documents have a few large flowcharts etc and it is impossible to read the documents now.

You can't even read these in Firefox.

I would really appreciate a fix to this problem urgently.

I just tested in Cairo. You could include huge images to a topic and the menus and the topic text still was wrapping nicely within the browser window.

KJL

My comment got lost.

If I could fix this easily, I would have done so. Any input is welcome as usual. I will have a further look tonight.

  • One earlier solution was to generate a scrollbar in the table. But that scrollbar will be hidden from view (its not a browser scrolbar), so is not useful.
  • One solution is to put the toolbar buttons outside of the table. The table will start below the toolbar, and also the web indicator in the leftbar will be outside the table. Then in any case the toolbar buttons are always in view. This is not just a tool bar issue. The main issue is that the topic text gets wider than the screen. Imagine reading what is equivalent to 30 printed pages where you have to scroll from side to side to read every line. We have 100s of such topics and it is a huge problem KJL
  • Another solution: back to pure css: div layout. But Win IE cannot have a floating left bar with a content div next to it. So I must use an absolute position for the content div. And that makes centering the page for instance impossible.
    • I sure hope we are not using table layout just to be able to make centered pages. Then instead make a skin for that. I suggest you go back to pure css ASAP and then work on alternatives afterwards. I am pretty desperate. My users are talking very badly about TWiki because of this problem. I am sure I am not the only TWiki admin with this problem KJL
AC

Using a layout table like it is now in the PatternSkin (and NatSkin) is the only solution that is stable across all browsers given a fluid layout (no fixed with). Divs and floats are implemented too differently. A solution is to assign a table-layout:fixed to the table that contains the content div and the sidebar div(s) and to have a overflow:auto in the content div. That will generate a horizontal scrollbar at the bottom of the content div if something gets too fat. The table-layout:fixed property is needed to build up enough "pressure" to constrain the inner stuff. The only problem with that approach is that you don't see the horizontal scrollbar til you scroll down to the bottom of the content div where it will appear if a picture or a table expands the content div. As a consequence any other text will be wider and truncated vertically also. It then isn't always obvious how to fix that as a topic author and what actually expanding the display. So you end up scrolling up and down adjusting the horizontal scrollbar. Next idea would be to render all tables and images inside an extra div that captures any overflow behavior locally like it is the case for verbatim environments already. But that would result in a change of the html markup being emitted by the TWiki engine and the TablePlugin.

MD

It all worked fine in Cairo. And in all browsers I ever tried.

Can we please revert back to the Cairo way until there is a solution.

People create topics with graphics. Graphics are often made so they fit a 1200x1024 screen. The minute someone reads the topic on a laptop with 1024x768 the graphics run out a little on the right. That is not a problem. You just scroll the entire browser window a little when you look at the figures.

The problem is that ALL the text in the topics now gets wider than the screen and the only way to read the topic is scroll left and right for each line of text. As you can imagine this is not possible in practical. My users are waiting for a solution and refuse to use TWiki until this is fixed. Almost all our ISO9000 procedures have flow charts so it is all the most important topics that are unredable.

The topic text must wrap inside the browser window no matter what size it is.

And the top menu bar should also stay within the browser area. But keeping the topic text inside is the most urgent.

KJL

Try this patch to the PatternSkin:

Index: pub/TWiki/PatternSkin/layout.css
===================================================================
--- pub/TWiki/PatternSkin/layout.css    (revision 8802)
+++ pub/TWiki/PatternSkin/layout.css    (working copy)
@@ -53,10 +53,16 @@
 #patternPage {
 }
 #patternColumnWrapper {
+       table-layout:fixed;
+       width:100%;
 }
 #patternMain {
        width:100%;
 }
+.patternMainContents {
+       overflow:auto;
+       padding:1px; /* fixes layout problems on FF and safari */
+}
 #patternLeftBar,
 .patternLeftBarContents {
        width:13em; /*C1*/
Index: templates/view.pattern.tmpl
===================================================================
--- templates/view.pattern.tmpl (revision 8802)
+++ templates/view.pattern.tmpl (working copy)
@@ -77,7 +77,7 @@



-%TMPL:DEF{"main"}%<table id="patternColumnWrapper" cellspacing="0" cellpadding="0"><tr><td colspan="2">%TMPL:P{"topbar"}%</td></tr><tr>
+%TMPL:DEF{"main"}%%TMPL:P{"topbar"}%<table id="patternColumnWrapper" cellspacing="0" cellpadding="0"><tr>
 %TMPL:P{"leftbar"}%
 <td id="patternMain" valign="top"><div class="patternMainContents">%BROADCASTMESSAGE%%TMPL:P{"toolbar"}%
 %TMPL:P{"content"}%

This works fine with the exception that IE-6 does not generate a horizontal scrollbar which it should. I didn't find a good workaround for that til now. At least the page does not expand in an unreadable way.

Besides Keneth, you should put all your large tables and images inside an extra div like

<div style="overflow:auto;width:100%;height:220px;">
     <img src="%ATTACHURLPATH%/some.gif" alt="some.gif" width='1089' height='197' />
</div>

That will give you good results even on IE.

MD

Here's another prove of concept patch to Attach.pm that will allow to add the right amount of overflow protection

--- Attach.pm   (revision 8802)
+++ Attach.pm   (working copy)
@@ -263,6 +263,7 @@
     my $prefs = $this->{session}->{prefs};
     my $store = $this->{session}->{store};

+    my ($nx, $ny);
     if( $attName =~ /\.(gif|jpg|jpeg|png)$/i ) {
         # inline image

@@ -273,7 +274,7 @@
         # the link checkbox, TWiki will generate the width and height
         # img parameters, speeding up the page rendering.
         my $stream =  $store->getAttachmentStream( $user, $web, $topic, $attName );
-        my( $nx, $ny ) = &_imgsize( $stream, $attName );
+        ( $nx, $ny ) = &_imgsize( $stream, $attName );
         my @attrs;

         if( $nx > 0 && $ny > 0 ) {
@@ -298,6 +299,10 @@
     $fileLink =~ s/\$name/$attName/g;
     $fileLink =~ s/\$comment/$fileComment/g;
     $fileLink =~ s/\$size/$imgSize/g;
+    $fileLink =~ s/\$width\+(\d+)/int($nx+$1)/ge;
+    $fileLink =~ s/\$width/$nx/g;
+    $fileLink =~ s/\$height\+(\d+)/int($ny+$1)/ge;
+    $fileLink =~ s/\$height/$ny/g;
     $fileLink =~ s/\\t/\t/go;
     $fileLink =~ s/\\n/\n/go;
     $fileLink =~ s/([^\n])$/$1\n/;

If you add the following to TWikiPreferences

   * Set ATTACHEDIMAGEFORMAT = <div style="overflow:auto;width:100%;height:$height+20px"><img src="%ATTACHURLPATH%/$name" alt="$name" width="$width" height="$height" /></div>
even IE will be happy.

MD.


I am working on a new css layout without tables. See my progress at http://visiblearea.com/devtwiki/bin/view/Sandbox/BigImage. Lots of rought edges, but both IE and Firefox keep the top nav inside the window.

And more: the text stays inside the window.

Centering the page is also possible, see http://visiblearea.com/devtwiki/bin/view/Sandbox/CenterPage.

All in all its a number of days work. Don't count that its ready in less than a week. But you can tell your users that TWiki developers are listening to you wink

AC

Closed with Item1672

Thanks Arthur.

KJL

Closed with the release of 4.0.2

KJL

ItemTemplate
Summary Pattern Skin in Dakar: verbatim text and large images makes everything wider than the screen.
ReportedBy TWiki:Main.KennethLavrsen
Codebase

SVN Range Thu, 02 Feb 2006 build 8675
AppliesTo Extension
Component PatternSkin
Priority Urgent
CurrentState Closed
WaitingFor

TargetRelease patch
Topic attachments
I Attachment History Action Size Date Who Comment
PNGpng cairo_ie_wide_verbatim.png r1 manage 45.6 K 2006-02-12 - 12:56 UnknownUser Wide verbatim text in Cairo
PNGpng dakar_ie_wide_verbatim.png r1 manage 65.4 K 2006-02-12 - 12:57 UnknownUser Wide verbatim text in Dakar
Edit | Attach | Watch | Print version | History: r17 < r16 < r15 < r14 < r13 | Backlinks | Raw View |  Raw edit | More topic actions
Topic revision: r17 - 2006-04-01 - KennethLavrsen
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback