/*  ************************************************************************  *
 *                                 tree.css                                   *
 *  ************************************************************************  */

/*  This stylesheet is for document pages that present an interactive tree. 
    Load after MASTER.CSS and DOCUMENT.CSS - in that order. Familiarity with 
    both, and their comments, is assumed.

    The interactive tree is originally a reduction of the similar nested 
    lists that make the Table Of Contents (TOC). There is some long-term 
    plan to bring the two together somehow. Meanwhile, familiary with TOC.JS 
    may help, since it was the model.  */
    
/*  ************************************************************************  */

/*  The tree is an unordered list, modelled on those that are styled by 
    TOC.CSS, but intended for document pages. A key difference is that a 
    document page can have any number of trees. Each tree is a DIV that has 
    Tree as its class. Beneath it is a nesting of UL and LI nodes.  */
    
div.Tree {
    padding-left:7px;
}

/*  A branch is an LI that has at least one UL beneath it (preferably with 
    at least one LI beneath the UL). Any other LI is just a leaf. 
    Historically, branches and leaves are folders and pages in a TOC, and 
    this still names the images that are to show in list-item marker boxes 
    for the tree's branches and leaves. 
    
    Though CSS rules can select a node according to whether it has some 
    pattern of ancestors (or earlier siblings), they do not (yet?) extend to 
    selecting a node according to whether it has some pattern of 
    descendants. So that branches and leaves are correctly distinguished 
    even when scripts don't run (and the presentation then depends entirely 
    on CSS), the HTML author must assign each branch to the Branch class. 
    Failure on this point is an error of authoring, and needs correction in 
    the HTML, even if scripts correct it for most users in practice.  */

div.Tree li {
    list-style-image:url("../_images/page.gif");
}

div.Tree li.Branch {
    list-style-image:url("../_images/folder.gif");
}

/*  Branches can be expanded or collapsed interactively by clicking in their 
    LI nodes' marker boxes. Scripts in TREE.JS assign each branch to either 
    the Expanded or Collapsed class according to whether the list beneath 
    should show or not. 

    See that the Expanded and Collapsed classes matter only if scripts run. 
    These classes in the HTML then specify an initial expansion state. It is 
    strongly recommended that the HTML author sets either Expanded or 
    Collapsed for every top-level branch and for every branch whose parent 
    is Expanded. Complete omission of this has the side-effect that the tree 
    is shown briefly as fully expanded (just as if scripts hadn't run) until 
    the scripts apply defaults (which presently means to expand only at the 
    top level). The visual effect as the page loads may be substantial: the 
    tree is seen to collapse and everything below the tree shifts upwards.  */

html.Scripted div.Tree li.Expanded {
    list-style-image:url("../_images/expanded.gif");
}

html.Scripted div.Tree li.Collapsed {
    list-style-image:url("../_images/collapsed.gif");
}

html.Scripted div.Tree li.Expanded ol, 
html.Scripted div.Tree li.Expanded ul {
    display:block;
}

html.Scripted div.Tree li.Collapsed ol, 
html.Scripted div.Tree li.Collapsed ul {
    display:none;
}

/*  ======  */
/*  Layout  */
/*  ======  */

/*  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.  */

div.Tree ol, 
div.Tree ul {
    border:0;
    margin:0;
    padding:0;
}

div.Tree 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.  */

div.Tree ol, 
div.Tree ul {
    border-left:1px #DDBBBB dotted;
}

div.Tree li {
    margin-left:12px;
}

/*  ====  */
/*  Text  */
/*  ====  */

/*  The list looks better with a little leading and if items with long text 
    do not wrap to multiple lines.  */

div.Tree li {
    line-height:1.29;
    line-height:calc(9em / 7);
    *line-height:1.29;
    white-space:nowrap;
}

/*  ********************************  */
/*  Readability Limit on Line Length  */

/*  On document pages, list items ordinarily have their width limited for 
    readability. See DOCUMENT.CSS. 

    This creates trouble for nested lists. The marker box for an LI that 
    itself contains a list is misplaced very badly by Internet Explorer 7 if 
    the LI has a max-width. No less bizarre, and only a little less 
    unsatisfactory, is that if the containing DIV or UL has a max-width, 
    then the cursor over the whole list is an I-beam as if for text.  */

#DocFrame div.Tree, 
#DocFrame div.Tree li, 
#DocFrame div.Tree ol, 
#DocFrame div.Tree ul {
    max-width:none;
}

/*  ************************************************************************  *
 *        Copyright © 2020-2022. Geoff Chappell. All rights reserved.         *
 *  ************************************************************************  */