﻿
/*  ************************************************************************  *
 *                                  toc.css                                   *
 *  ************************************************************************  */

/*  This style sheet is for every Table of Contents (TOC) page. Include 
    after MASTER.CSS.  */

/*  The TOC is a nesting of unordered lists in the BODY. Scripts in TOC.JS 
    work closely with the position of list items and of their markers.  */

/*  ************************************************************************  */

/*  Start with something astonishing: the TOC page's scrolling is on a DIV. 
    The reason is that 3-4 years of several browsers make a complete mess of 
    whether scrolling is on the HTML or BODY. If these have height and 
    overflow, the affected browsers may present a working scrollbar but 
    leave both elements' scrollLeft and scrollTop unchanged by scrolling! 
    Apparently, there was confusion about which of the HTML and BODY should 
    be the scrolling element, and some cases slipped through in which 
    neither gets to be. 

    For all that Internet commentators disparage Internet Explorer, it is 
    not troubled. It's a Webkit bug, easily demonstrated on a simple test 
    page. Chromium has a report of it, with demonstration, as early as 
    October 2014: issue 423935. Reports are "still experiencing the issue" 
    as late as February 2017 and then in September it's bluntly dismissed as 
    "Fixed". Microsoft Edge has the bug at least until its version 44 from 
    the 1809 release of Windows 10 - yes, 4 years later. 

    The workaround here is that since scrolling evidently is unreliable on 
    the HTML or BODY elements, move it to a DIV beneath. The workaround 
    certainly is non-obvious, hence this extended note about its 
    importance. Do not think about changing it without days in reserve.  */

body {

    /*  Set a discreet colour gradient for the background, but specify a 
        plain colour to fall back to. 
      
        The linear-gradient is available in Internet Explorer 10 and higher. 
        Earlier versions, back to 5.5, have a non-standard property named 
        filter that does much the same (if the security option "Binary and 
        script behaviors" is not disabled). Keep it in for old browsers for 
        as long as it seems to do no harm. 

        While Expression Web is the word processor, be sure to have filter 
        before the background-image. Otherwise, Expression Web removes it - 
        and any comments that follow it - from the CSS on disk.  */

    background-color:#FFFFF7;
    filter:progid:DXImageTransform.Microsoft.Gradient (startColorStr="#FFFFFF", endColorStr="#FFFFF0", gradientType="0");
    background-image:linear-gradient(180deg, #FFFFFF, #FFFFF0);

    /*  Most text in the TOC is in links and shows in whatever style applies 
        to links, typically as blue. But some folders do not have links and 
        might never. There will be text that will show just as text - not 
        much in contrast with a document page, but some. It can usefully be 
        a little off-black. The present choice is a little darker than the 
        red used for headings in documents.  */

    color:#663333;
}  

/*  All sorts of things, including the background, especially with the 
    gradient, go wrong unless both the HTML and BODY fill the IFRAME that 
    we're loaded into.  */

html, body {
    height:100%;
    width:100%;
}

/*  In contrast to the banner, we don't want this content flush with the 
    frame. We don't want to push it very far, and we must remember that the 
    marker box for the root LI can extend further left than does this root's 
    margin. Do not be tempted, ever, to make this adjustment by styling a 
    margin or padding for the BODY. It complicates the placement of 
    scrollbars and the interpretation of the background. Style the #Root 
    instead. 

    Before we get to the #Root, we need a container for everything that may 
    need to look like it scrolls as the whole page. Keep it flush to the 
    frame's edges to avoid scrollbars that users will surely perceive as 
    unnecessary. Remember: the TOC's scrollbars are on this DIV! 

    Of course, we never get any workaround for free. Having any of width, 
    height or overflow induces Internet Explorer 7 to give us a text 
    cursor.  */

#Toc {
    border:0;
    cursor:default;
    height:100%;
    margin:0;
    overflow:auto;
    padding:0;
    width:100%;
}

/*  If only when the image in the marker roughly matches the font's height, 
    some sort of ideal is to have the list marker on the diagonal away from 
    the top left. The positioning strategy adopted here is that a uniform 
    margin of 0.5em adjusts to the font-size but an additional 7px places 
    the list marker horizontally.  */

#Root {
    margin:0.5em 14px;
    margin:0.5em calc(0.5em + 7px);
    *margin:0.5em 14px;
}

/*  ****  */
/*  List  */

/*  The TOC page supports a possibly large unordered list with multiple 
    levels. 
    
    List items are "folders" if they have a list beneath them. The HTML is 
    expected to distinguish these items by assigning them to a class named 
    Folder. This allows that folders show differently even when scripts 
    don't run.  */

li {
    list-style-image:url("../_images/page.gif");
}

li.Folder {
    list-style-image:url("../_images/folder.gif");
}

/*  Scripts that run on the TOC page assign each folder to one of two 
    classes, Expanded or Collapsed, according to whether any list beneath 
    them is meant to be visible. 

    It is very important that clearing display for collapsed folders comes 
    after all setting of display for others.  */

li.Expanded ul {
    display:block;
}

li.Collapsed ul {
    display:none;
}

li.Expanded {
    list-style-image:url("../_images/expanded.gif");
}

li.Collapsed {
    list-style-image:url("../_images/collapsed.gif");
}

/*  There we might leave it, with the understanding that Expanded and 
    Collapsed are just for the scripts, never for the HTML. This would miss 
    the opportunity to allow that the HTML can direct the scripts to show a 
    folder as expanded right from the start. What we wouldn't want is that 
    the HTML simply sets the Expanded class, for then the folder would show 
    with a suggestion of interactivity even if the scripts don't run. 

    The plan, should this ever get implemented, is that a folder is marked 
    for initial expansion if the HTML assigns it to both the Expanded and 
    Folder classes.  */

li.Expanded.Folder {
    list-style-image:url("../_images/folder.gif");
}

/*  The default indentation is much too large - surely for any purpose 
    that's imaginable yet practical, but who's to know. What we want is just 
    enough to mark the nesting of levels but also to fit a small image that 
    differentiates the list items. 

    For concreteness, begin with trivial layout and the Internet Explorer 
    default for the marker box's placement relative to the content box.  */

ul,
li {
    border:0;
    list-style-position:outside;
    margin:0;
    padding:0;
}

/*  List layout is highly variable between browsers. Let's start with 
    possibly reasonable certainties for all browsers. 

    For simplicity, leave list-style-position at its default, which is 
    outside. The implied layout for a first level is: 

        marker box, LI border, LI padding, LI content 

    Expect the next level to start immediately beneath the left of the 
    previous level's LI content. This level's layout should have 
    
        UL margin, UL border, UL padding, LI margin 

    running up to the LI border before which is to be placed this level's 
    marker box. We have an apparently standard relationship which may be 
    useful: 

        INDENTATION = UL margin + UL border + UL padding 
                        + LI margin + LI border + LI padding

    A pleasing arrangement would have vertical sight lines to help the user 
    assess nesting levels. Such lines can come only from the UL and LI 
    borders. Ideally, sight lines will appear to run through some key 
    feature in the chosen list-style-image. Also, they should be visible but 
    not disturbing: 1px is all that need be considered for width. 

    To put numbers to calculations, let X count the pixels in the marker box 
    to the right of where we want the border to line up. Alignment with the 
    LI  border requires: 

        X == LI padding + UL margin + UL border + UL padding + LI margin 

    Alignment with the UL border requires: 

        X == UL padding + LI margin

    Both work, but aligning with the LI border has two visual detractions. 
    First, there is no sight line for the top level. Second, the sight lines 
    extend along the text of each list item. There is also a practical issue 
    for the encoding: the border is better restricted to the Expanded and 
    Folder classes. Aligning with the UL border is both simpler and cleaner! 

    Observation of Internet Explorer in modern versions and of Microsoft 
    Edge suggests construction of the marker box as the image and then 8px 
    of space. Our list images, designed long ago, are 9x9 to line up through 
    the centre. For us, if only for these browsers, X is 12px. 

    Other browsers, of course, do things differently. Is the variability why 
    so few lists on the web have sight lines? Or is it that sight lines are 
    wanted so rarely that nobody cares about the difficulty? I may have 
    missed something. This user-interface convenience may need some 
    rethinking.  */

ul {
    border-left:1px #DDBBBB dotted;
}

li {
    margin-left:12px;
}

/*  The list looks better with a little leading and if items with long text 
    do not wrap to multiple lines.  */

li {
    line-height:1.29em;
    line-height:calc(9em / 7);
    *line-height:1.29em;
    white-space:nowrap
}

/*  *****  */
/*  Links  */

a {
    text-decoration:none;
}

a:link, 
a:visited {
    color:#0044CC;      /* was #0066CC, but low contrast against #FFFFFF */
}

a:hover {
    background-color:#88AACC;
    color:#FFFFFF;
}

/*  At any given time, one link in the TOC is current and is assigned to a 
    class to pick up a distinctive appearance.  */

a.Current:hover, 
a.Current:link, 
a.Current:visited {
    background-color:#224488;
    color:#FFFFFF;
}

/*  ******  */
/*  Footer  */

/*  Allow that the TOC can be followed by pretty much anything, which will 
    need to appear well-separated. This is presently used only for links to 
    other TOCs when scripts haven't built the intended viewer. For that, 
    though, it is very useful.  */

div.Footer {
    border-top:1px #663333 solid;
    width:100%;
}

/*  The same considerations that apply to positioning the #Root, above, 
    apply also to the first UL in the list of other TOCs. A complication is 
    that this list shows only if scripts don't run, including that they 
    decline to run. If this is because the browser is even older than 
    Internet Explorer 7, then the > combinator is unavailable for picking 
    out this OtherRoot. Better, then, is that each TOC.HTM gives this UL an 
    ID.  */

#OtherRoot {
    margin:0.5em 14px;
    margin:0.5em calc(0.5em + 7px);
    *margin:0.5em 14px;
}

/*  ***********  */
/*  Design Time  */

/*  A very similar consideration arises just for the author at design time 
    when writing the fragments that the full TOC is pieced together from.  */

body > ul {
    margin:0.5em 14px;
    margin:0.5em calc(0.5em + 7px);
    *margin:0.5em 14px;
}

/*  ************************************************************************  *
 *        Copyright © 2007-2021. Geoff Chappell. All rights reserved.         *
 *  ************************************************************************  */
