Thanks Garrett -- the current layout is provided by our publishing toolchain, Publican -- I'm re-assigning this bug there.

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 :(

If resizing isn't an option, perhaps a "Hide" button would work instead.

(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.

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!

(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.

(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.

That makes sense; thanks for explaining it.