Bug 600433 - iframe on left of docs.fedoraproject.org cannot be resized
iframe on left of docs.fedoraproject.org cannot be resized
Status: CLOSED WONTFIX
Product: Publican
Classification: Community
Component: publican (Show other bugs)
1.6
All Linux
low Severity medium
: ---
: ---
Assigned To: Jeff Fearn
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-04 13:20 EDT by Garrett Holmstrom
Modified: 2010-11-23 23:18 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-22 03:02:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Garrett Holmstrom 2010-06-04 13:20:42 EDT
Description of problem:
The navigation/search/etc iframe on the left of http://docs.fedoraproject.org/ takes up an awful lot of screen real estate.  This wouldn't be such a problem if it was possible to either resize it or hide it.


How reproducible:
Go to http://docs.fedoraproject.org/ with a browser window of size 1024x768 or less
Comment 1 Ruediger Landmann 2010-06-04 18:16:05 EDT
Thanks Garrett -- the current layout is provided by our publishing toolchain, Publican -- I'm re-assigning this bug there.
Comment 2 Jeff Fearn 2010-06-08 21:55:14 EDT
I took a shot at this but couldn't get the iframe to be full height and get the remaining body content to float relative to the iframe, it seems you can have one or the other :(

I'll try a few other approaches, but it's not looking good atm :(
Comment 3 Garrett Holmstrom 2010-06-12 00:04:12 EDT
If resizing isn't an option, perhaps a "Hide" button would work instead.
Comment 4 Jeff Fearn 2010-06-16 02:46:44 EDT
(In reply to comment #3)
> If resizing isn't an option, perhaps a "Hide" button would work instead.    

Hiding and resizing is effectively the same in CSS, if you can do one you can do the other.

Another thing is that the body layout currently restricts the body width to 55em, which there are apparently good reasons to do related to readability, and in my testing at 1024x768 there was a border on the right hand side indicating that you wouldn't get any more content per line anyway .. at 800x600 the body content had no right margin and is wrapped more tightly.

FWIW I'm still trying to solve this as it would certainly help anyone using a hand held devise to surf the sites, say like if your computer was having a fit and you needed to read the docs urgently.
Comment 5 Ruediger Landmann 2010-06-22 03:02:13 EDT
As Jeff says, the amount of screen real estate available for the document is not determined by the presence or absence of the iframe, but by the hard, 55-em limit on the width of the content.

Anyone with a hand-held device is going to need to zoom in and out to navigate a document like this anyway, and such devices may contain little optimizations to make this easier. For example, double-tapping on the content itself makes the main frame fit an iPhone screen, with the navigation iframe hidden off to the left.

Since interactivity between iframes and main frames is limited for security reasons, the only practical way of implementing this suggestion would be to switch to using frames, with the various drawbacks inherent in that approach.

Sorry, Garrett, I'm closing this WONTFIX. However, if you're aware of another site that implements such a solution well, please point us to it!
Comment 6 Garrett Holmstrom 2010-06-22 10:09:44 EDT
(In reply to comment #5)
> Since interactivity between iframes and main frames is limited for security
> reasons, the only practical way of implementing this suggestion would be to
> switch to using frames, with the various drawbacks inherent in that approach.

Is interactivity between them really necessary?  The parent frame can hide the TOC frame entirely by simply changing its CSS display attribute.  For instance, calling

    function toggleIframe(id) {
        var ifr = document.getElementById(id);
        ifr.style.display = (ifr.style.display == 'block') ? 'none' : 'block';
    }

on 'tocframe' seems to work for me, though I must admit I'm not much of a web designer.
Comment 7 Jeff Fearn 2010-06-22 21:28:26 EDT
(In reply to comment #6)
> (In reply to comment #5)
> > Since interactivity between iframes and main frames is limited for security
> > reasons, the only practical way of implementing this suggestion would be to
> > switch to using frames, with the various drawbacks inherent in that approach.
> 
> Is interactivity between them really necessary?  The parent frame can hide the
> TOC frame entirely by simply changing its CSS display attribute.  For instance,
> calling
> 
>     function toggleIframe(id) {
>         var ifr = document.getElementById(id);
>         ifr.style.display = (ifr.style.display == 'block') ? 'none' : 'block';
>     }
> 
> on 'tocframe' seems to work for me, though I must admit I'm not much of a web
> designer.    

The problem with controlling this from the content page, instead of the toc, is that when you want to change/fix the behaviour you need to regenerate every book on the site, so the penalty for change scales with the size of your site. What's more you have to pay this penalty for every change, whereas moving to a frameset would be a one off penalty.

This is mainly because the site is static, which was required to meet some design constraints for off-line use of the entire site. However the rationale of that has been rendered rather pointless by some recent decisions.

Given how close we are to 2.0 shipping I'd be reluctant to make changes to these kinds of things as they will definitely delay 2.0. But if there is enough need then we will just have to delay.
Comment 8 Garrett Holmstrom 2010-06-22 22:03:17 EDT
That makes sense; thanks for explaining it.

Note You need to log in before you can comment on or make changes to this bug.