of breadcrumbs; gives slightly tighter linespacing than standard. */
body.dark div#navBtn_target, body.dark div#navBtn_target p { color: #afa6a4; }
/* Light grayish color for all non-link text in navbtn mot area. For dark-background pgs like 'Contact San' and 'Thank You'.
º LINKSKEY (Key to Site Links):
`````````````````````````````````````````````````````````````````
These are for the area in some pages' graybars that start "Key to Site Links" and are created by the BBinclude file "KeyToSiteLinks.incl".
1. These "examples of my links" styles are not coded as actual links. This pseudo-links approach was done to simplify and shorten the code and avoid weird browser-dependent problems in trying to get example links not to behave like real links (go somewhere, switch to visited linkcolor, hover red or green, etc.)
BTW, if I change the colors of the link styles I have to remember to change the colors of these example styles as well.
2. There are still a few _real_ links in the graybars, which use the same darker blue and purple (see comments below) as these pseudo-links do. */
/* div#linksKeyOuter { width: 120px; } */
div#linksKey { width: 120px; line-height: 1.2em;}
div#linksKey p { font: 11px/13px arial, geneva, helvetica, sans-serif; margin:0; padding: 0; }
/* div#linksKey is needed to make the overall construction just wide enough so that WinIE5.0 and Safari don't wrap the pw icon (after the text "Blue with popup icon") to another line. I don't know why it wraps in those browsers but not in FF; the text width measures exactly the same. "min-width" would be better than "width" for this purpose, but WinIE5.0 doesn't understand it; and "nobr" (nobreak) doesn't validate.
BTW, note that the PARENT of this div (defined differently in various html pages) must also be almost 120px wide for this to render well; perhaps this div will force them out where needed. WHY DOES IT NEED A PARENT? WHY CAN'T IT JUST HAVE HANGLEFT DIRECTLY? IT'S A DIV!
Note that the pseudo-links that get underdots must be within a span, because applying underdots directly to the enclosing P will cause the dots to fill the entire column width beyond the text itself, destroying the illusion of a "link". The padding-bottom: 1px (see rules below) gives a little air between the link-text and the underdots; IE5.0 doesn't see it, but the more modern browsers do.
Also note that in the "About San" pages the linksKey gets additional positioning from AboutSan.css. */
/* Link eXample: */
div#linksKey p#lx-L { margin: 0 0 9px 0; padding: 0; } /* Link eXample Lede — i.e., "Key to Site Links:" text */
div#linksKey p#lx-1, div#linksKey p#vlx-1 { margin: 0 0 3px 0; line-height: 1em; color: #002699; }
/* Link Underline Dark Blue Dot is slightly darker than "real" link because it's in the graybar. */
p#lx-1 span{ background-image: url(/msg/widgets/ludbd.gif); background-repeat: repeat-x; background-position: 0px 100%; padding-bottom: 1px; }
div#linksKey p#lx-2, div#linksKey p#vlx-2 { margin: 4px 0 8px 0; }
/* Visited Link eXample uses "lupd" gif (Link Underline Purple Dot): */
div#linksKey p#vlx-1 { color: #5e1c5e; }
/* Purple slightly darker than "real" link because it's in the graybar. */
#vlx-1 span{ background-image: url(/msg/widgets/lupd.gif); background-repeat: repeat-x; background-position: 18px 100%; padding-bottom: 1px; }
/* POPUP WINDOW (pw) Link eXamples:
The two PW examples have same colors as regular link examples, but no underdots.
The "v" refers to the "visited" (purple text) version.
The icon "pwsid" (Popup Window Static Icon Dark gif) is a special dark version for use in the graybar.*/
div#linksKey p#pw-lx-1, div#linksKey p#pw-vlx-1 { margin: 0; line-height: 1em; color: #002699; }
/* For now, to accomodate WinIE5.0, I'll apply the popup icon to its own span, as in the actual pw links (higher up). The stupid "height: 1em" is to add hasLayout so WinIE5 will see the padding (IE6 doesn't need it). WinIE5.0 also needs different vertical position ("bottom") from all other browsers; the commented bullet hides the second (normal/real) rule from it (the hack itself is just an empty comment; the bullet prevents my A.S. optimizer from deleting the comment). */
/* The following "height:1em" (to add IE "hasLayout") affects browsers like this:
WinIE5.0: critical to see the 14px padding; otherwise pw icons tucked under text
MacIE5.2: helpful; pw icons base-align better
WinIE5.5, Firefox: mostly don't care
WinIE6.0: harmful; screws up pw icon baseline in some contexts
WinIE7: need to test
So we use a parsing hack to make the style visible to WinIE5.0 & MacIE5 only: */
*+html>body #pw-lx-1 span, *+html>body #pw-vlx-1 span { height: 1em; }
p#pw-lx-1 span, p#pw-vlx-1 span { padding-right: 14px; background: url(/msg/widgets/pwsid.gif); background-repeat: no-repeat; background-position: right bottom; background-position/*•*/: right 10%;}
div#linksKey p#pw-vlx-1 { color: #5e1c5e; }
div#linksKey p#pw-lx-2, div#linksKey p#pw-vlx-2 { margin: 2px 0 8px 0; }
/* Jump Link eXample: */
div#linksKey p#j-lx-1 { margin: 0 0 3px 0; line-height: 1em; color: #611515; }
#j-lx-1 span{ background-image: url(/msg/widgets/lubrd.gif); background-repeat: repeat-x; background-position: 18px 100%; padding-bottom: 1px; }
div#linksKey p#j-lx-2 { margin: 2px 0 8px 0; }
/* Most straightforward version of LINK EXAMPLES code NG in WinIE5.0, would be fine elsewhere: */
/* #pwlx { color: #002699; text-decoration: none; padding-right: 16px; background: url(/msg/widgets/pwsid.gif) right top; background-repeat: no-repeat; }
#pwvlex { color: #5e1c5e; text-decoration: none; padding-right: 16px; background: url(/msg/widgets/PopupWindow_StaticIconDark.gif) right top; background-repeat: no-repeat; } */
/* Note that the pwsid hollow-pw-doohickey is also used lower down in the roundBox styles section. */
/*º HangLeft/Right, navTop, navBottom styles:
`````````````````````````````````````````````````````````````````````````````````````````` */
.hangLeft, div#navTop, div.navTop, div#navBottom, div.navBottom { position: absolute; left: 0; margin: 0; padding: 0; }
/* hangLeft is a child of textCol, but since textCol isn't positioned, its positioning parent is its grandparent, divOuter.
navTop & navBottom are children of, and positioned relative to, divOuter.
See also the z-index code for these absolute elements, in the FTS code near the bottom of this page. */
div#navBottomR, div.navBottomR { position: absolute; bottom: 30px; right: 0; margin: 0; padding: 0; }
/*navBottomR is a rarely used construction, similar to navBottom but on the lower right. The bottom: 30px position matches that applied to the regular (leftside) navBottom a little further down, although this is likely to be overridden in the html page. */
div#navBottomR div.thumbWrap, div.navBottomR div.thumbWrap { position: relative; }
div#navTop, div.navTop { top: 20px; width: 120px; }
/* The top position is in addition to any logo top margin (which is useful as a minimum on pages that don't use the divOuter architecture). The 120px is wider than the 88px navBtn width, originally to accomodate the wider MOT messages, but now with the addition of the still-wider site thumbnails, this width "limitation" may be irrelevant. */
/* ----- W A R N I N G ! -----
My BB include will wipe out the "linksKeyNEW" id I temporarily put in that section on the BID MC page. Need to replace "linksKeyNEW" with "linksKey" here in c2, but of course that may break most pages on sites until I roll out new approach everywhere. ALSO: SEARCH for "NEW" (case-sensitive) in c2, j2, and BID MC page when wrapping up this stage of the project. */
/* NEW CONSTRUCTIONS FOR SIDE-COLUMN ELEMENTS to replace "img-parent" and "sidebarParent" etc. No positioning containers needed around images and sidebars! "Top" must _not_ be set here or anywhere, so it retains the default of "auto" (i.e. static with respect to text-flow vertically down textCol); tweak vertical position in html doc with margin-top. By default, hangRight's right position is to the right of (overlaps) the right edge of divOuter, because it looks better in mid-sized windows; this may be tweaked (typically, reduced to right:0) by j3.js for either smallish or largeish windows. */
.hangRight { position: absolute; right: -45px; } /* The “right: -45px” is only intended for situations where JS is disabled. j3.js will override this.
See also the z-index code for these absolute elements, in the FTS code near the bottom of this page. */
/* Sometimes we apply the "hangRight" class to a container div that encloses both an image and a caption div (e.g., see Santh MIT-ASD page, or Mad Journey Through Titles essay). Unfortunately, with the same specs, IE & FF put the caption a slightly different distance below the image. Zeroing out font-size, line-height, etc., did nothing. This reduces the disparity from 2px to 1px: */
div.hangRight img, div.hangLeft img { display: block; background-repeat: no-repeat; }
/* The no-repeat is not really needed, since no-repeat is the default & typically in these cases there's no room to see the repeat anyway; I'm just being careful: */
div#navBottom, div.navBottom { bottom: 30px; width: 164px; }
/* The bottom-left block that contains bbinclude w "Go to top of page" link & © line, and sometimes other legal stuff.
164px is the same width as the site thumbnails. Although navBottom’s “natural width” (to prevent the standard copyright line from wrapping) is more like 140px, it looks better when centered under a site-thumb which may be visible above it. Previously I was using “max-width: 164px” to prevent FF from extending div#navBottom across the entire bottom width of the page, which (despite div#navBottom being transparent) blocked the clickability of the next/prev bottom links. IE6 doesn’t understand max-width, but it didn’t need this anyway; for some reason it doesn’t extend short-line divs that way. Unfortunately, Safari 1 didn’t understand max-width either, and it _did_ need a width limitation - it was blocking the prev/next links. So I gave up & am using a fixed width: 164. However, this means that on any pages which don’t have any thumbnails in the left column (that is, where the left col require only about 120px width), I’ll have to redefine the width of navBottom manually (probably to 140px) in the page’s head CSS (as in the site maps).
Update Jan 2013: In Santh pg (Gordon Gribley story) the div#navBottom (empirically) is forcing the left col width out from about 166px to 199px. Not sure what's happening here.
One of the following two selectors is used in older layouts to hold copyright info in the bottom left. In some pages (like the sitemaps), use of expansion triggers will create havoc as the JS layout-adjustment routines (which were never meant for table pages) pick up “navBottom”; so we use “navBottomCell” on those pages. OTOH, on pages like the About San pages, the opposite is true: we have to use “navBottom” or the layout gets snafu’d. (And those pages have no expansion triggers.) The older (table-based) About Story pages seek okay either way. Just have to test any table-based pages to see which of the following works better. */
td#navBottom, td#navBottomCell, td.navBottom, td.navBottomCell { vertical-align: bottom; padding-bottom: 18px; }
/*º Copyrights: */
p.copyright, div#textCol div.graybarCol p.copyright, div.textCol div.graybarCol p.copyright, div.hangLeft#navBottom p.copyright, div.hangLeft.navBottom p.copyright, div.hangRight#navBottom p.copyright, div.hangRight.navBottom p.copyright, td p.copyright { font: 10.5px/11px arial, geneva, helvetica, sans-serif; color: #666; margin: 1em 0 0 0; }
/* WARNING! If browser's prefs have “Minimum Font Size” set larger than 9px (e.g., to 10px), the copyright may butt up against the right margin or wrap. */
/* Re font sizes for regmark: Typically this style would also include “font-size: 85%”, and if I use it in my typical 13px (or 14px?) fontsize context, I should experiment with that.
However, when I use the span.regmark ® inside a block of text with class “copyright”, which is only 9px arial, I have the opposite problem — the ® is illegible. A © is legible, but could be larger too. The next rule fixes that problem, but only looks right if the ® is in the first line of the paragraph, because it adds a little space before that line. This is almost unnoticeable if it’s the first line, but slightly annoying if the extra linespace occurs in the middle of a paragraph — but it is only legal small type, after all. */
p.copyright span.mark { font-size: 130%; position: relative; top: 1px; }
/*º topJump: */
p#topJumpP, p.topJumpP { margin: 2em 0 2em 0; }
/* This is the selector for the parent paragraph of the “Go to top of page” link. The font face & size should more or less match the a.jump series of selectors, defined higher up; but the actual font/size/color is defined with the other "Bottom-Left Nav Block" styles slightly lower down. The link itself has an ID of topJumpA, which so far is only used by j3.js. */
/* · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
º BOTTOM-LEFT NAV BLOCK:
[ Some of these styles are almost certainly unused and can be deleted.]
` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` `
div.leftBlock and div.rightBlock are designed to be grandchildren of divOuter, which provides the relative-positioned ancestor. The top: positioning (where needed) will have to be added in each html instance. */
div.leftBlock, div.rightBlock { position: absolute; width: 120px; padding: 0; z-index: 99999; color: #333333; font: 11px/15px arial, geneva, helvetica, sans-serif;}
div.leftBlock { left: 35px; }
/* Indents the entire leftblock (including the logo, navButtons, & mot area — or, in a separate div with the same leftBlock class, the copyright/top-of-page-linkblock near the bottom) relative to the left edge of divOuter. OBSOLESCENT; should be replaced by the new classes associated with the j2 layout-adjustment scripts. */
div.rightBlock {right: -45px; }
.top0 {top: 0px;}
.top10 {top: 10px;}
.top20 {top: 20px;}
.bottom0 {bottom:0px}
.bottom10 {bottom:10px}
.bottom20 {bottom:20px}
.bottom30 {bottom:30px}
.bottom40 {bottom:40px}
.bottom50 {bottom:50px}
.bottom60 {bottom:60px}
/* Most logical way of placing bottom-left nav block at bottom of text column (assuming it's extruded from just under last regular paragraph). Parsing bug hides style from MacIE5 which screws up "bottom" positioning. Unfortunately it also hides it from WinIE5.0 which doesn't screw up bottom positioning.
div#leftBlock is an ALTERNATIVE to div#bottomNavblock, aka "nav block from hell".
leftBlock is left-aligning relative to its grandparent divOuter since its parent textCol isn't relative positioned.
It can be used for anything in the left graybar (or, in Santh, taupebar) column; not just navigation. You just put it between the paragraphs in the main text column that you want it to appear to the left of. For the bottom nav block, place it right after the last regular paragraph in the main text column.
A high z-index is required for it to be clickable in Firefox and in Mac NS7. It's probably not clickable in NS6 anyway, but I don't care.
The sidebar styles for the About San pages are in a separate "aboutSan.css" stylesheet in msc.
Classnames "graybarCol", "graybarColTight", & "graybarCell" are used in both Sanstu & Santh.
The word "graybar" is used in comments, but probably never as a classname, even though
there's a selector for it below.
I suspect "taupebar" (for Santh) is only used in comments, not as actual classname.
Some of these are type styles, some box styles; should the box styles be split off
and placed up top with the other box styles?
1. Typically for 125-pixel-wide, medium-gray(rgb153; hex99) leftside graybar,
or for 55-pixel wide, light-gray rightside graybar (currently only in About San pages).
If nav btns and text&link blocks are placed in the same div, NS4 tends to freak out,
so mostly wrap graybar divs tightly around text&link blocks only.
2. I put the "td" items in there because it wasn't automatically inheriting into
table cells the way it was into paragraphs.
3. See also Links section for special treatment of some link colors in graybar columns.
The selectors that put the .graybarCol stuff inside a #textCol selector are for pure CSS pages where the graybar contents are absolutely positioned from _inside_ the main textCol. You can see this in the Link Color Examples in the right column of TechNotes_List.html, for example; it doesn't happen in table-based pages like About San. To work, these selectors have to be highly specific.
LATER NOTE: I had added a div#divOuter selector because I'm now putting some of the left-column nav stuff directly into divOuter, but it caused problems in other pages (like Mad Journey pgs 2ff), so I tightened the selector to div.roundBox_body and overrode the gray color (with brown) in santh.css. Perhaps I should move the #333 color to sanstu.css, which would be more logical, but I'd have to repeat all the selectors. */
/* DELETE the id-rules as soon as I’ve replaced them w the class in all html pages: */
div.roundBox_body, div.graybarCol, div.graybarCol td, div#textCol div.graybarCol p, div.textCol div.graybarCol p, div.graybarColTight, div.graybarColTight td, div#textCol div.graybarColTight p, div#navBottom.hangLeft p, p#topJumpP,
div.textCol div.graybarColTight p, div.navBottom.hangLeft p, p.topJumpP
{ font: 12px/14px arial, geneva, helvetica, sans-serif; color: #444; }
td div.graybarCol { margin: 0 18px; }
/* Note there's 18px space both left and right. See About San for use. */
td div.storyList { width: 90px; margin: 0 0 0 2px; padding: 0; }
/* Used as 'additional class' (along with div.graybarCol) in CxStoriesClickableList.incl.
Designed so that the list appears no wider than the 88px navButtons above it.
The 2px left margin is for optical alignment. MacIE5 requires the "td" contextual
ancestor or it won't see _any_ margins here, even though it will see _other_
styles here without the td ancestor! And it sees margins in div.graybarCol without
the ancestor too! */
div.graybarColTight, div#textCol div.graybarColTight, div.textCol div.graybarColTight { margin: 0; }
/* In this v. there's no extra space anywhere. Used in tables w tightly-bound text
& spacer columns. */
/* The 'graybarCol' div itself provides the left and right margin, but vertical spacing
is left up to the individual elements' padding and margins. The div also provides
the core font definitions, since I never want serif over a gray background. But
should the font SIZE be in the div or in that div's contextual basic p (below)? */
p.graybar, .graybarCol p, .graybarColTight p, div#textCol div.graybarCol p, div#textCol div.graybarColTight p, div.textCol div.graybarCol p, div.textCol div.graybarColTight p { margin-top: 0px; margin-bottom: 8px; }
/* When not simply defined contextually by their position in a graybar column, the p's
can be classed simply 'graybar' since it makes no difference whether they're in a
padded or tight column (the column definition handles the horizontal space, the p
handles the vertical space). */
/* FOR OLDER TABLE LAYOUTS ONLY?? ITALICIZED STORY TITLE styles for left navbar (between logo & navbtns) in cx stories, and perhaps in other series.
Note that now the Illustrations & Sketches have the title as a caption beneath the main image; and in Santh the title is normally at the top of the text column… so for now this only seems relevant in the Cx stories. PERHAPS this should therefore be transferred to sanstu.css: */
.leftNav h1, #leftNav h1.tite {
margin: -10px 0 15px 0;
padding: 0;
color: #464559;
font-family: arial, geneva, helvetica, sans-serif;
font-size: 12px;
line-height: 14px;
font-style: italic;
font-weight: normal;
}
/* FOR OLDER TABLE LAYOUTS ONLY?? The title “Psychology Can’t Help” is too long to fit on one line (in the left nav column), but too short to look good on two. So I created the following style: */
.leftNav h1.loose {
margin-left: 6px;
letter-spacing: .1em;
word-spacing: .15em;
}
/* FOR OLDER TABLE LAYOUTS ONLY The Radnor Wentworth titles are too long to fit easily even on two lines, so I created this style so they would. I haven’t yet tested the negative margin-right on browsers (other than Mac FF); it’s designed so the second line of the title will encroach slightly into the spacer cell between the nav column and the main panel cell: */
.leftNav h1.tite { /* don’t use the identifier “tight” as it conflicts with another style */
font-size: 11px;
line-height: 13px;
margin-right: -10px !important;
}
/*
EXPERIMENT FOR NEW LAYOUT Why is the newer "Sketch/Cx" layout using an ID instead of a class?
BTW, I could find no way to wrap the h1 (below the logo in a cx story) to a certain width using css; I ended up using an html
.
*/
#leftNav h1.tite {
font-size: 12.5px;
line-height: 1.3;
/*color: #444; */
display: block; margin: -20px 0 25px 0;
}
/*White "heads" for graybars - but need to convert to standard h1 h2 etc. for Google */
.graybarCol p.head, .graybarColTight p.head { color: white; font-weight: bold; }
/* for very short viewports, kill the mot area: */
@media screen and (max-height: 480px) {
.motMessage { display: none; }
p.copyright { z-index: 9999; margin-bottom: -10px; bottom: 0; } /* doesn't accomplish much */
}
/* · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
º IMG-PARENT:
` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` `
MOSTLY REPLACED BY HANGLEFT & HANGRIGHT:
The html code for these images typically goes within textCol, although they’re positioned in such a way as to appear completely outside textCol, in the right ‘column’ (which, like the left ‘column’, does not actually have its own div). The ability to have images placed in outer columns but positioned relative to specific points in the central textCol was a major reason to switch to a pure-CSS model for the text-centric pages. (With table layout I was doing this by splitting the column into TDs - a pain. However, it turns out this newer ‘hang’ positioning method works with table-based layouts too! See, for example, right-column sketches in About San Personal.)
The specific positioning location for the images needs to be set in the individual pages. Typically the img-parent lives in textCol and moves along in the natural text flow; its child image is shoved out from there into the right column; its vertical & horizontal positions are tweaked in the html doc’s head css.
For right-column images that don’t need to be tied to specific text in the main column, their html can go below the textCol html block (directly into divOuter) and be absolutely positioned relative to divOuter.
See extensive notes on CSS positioning experiments & strategy for these images in:
/Goya/Documents/San_Creative/San_Cartoon_Stories_Devel/_RW_Strip_Devel_f/RW-Happiness_Devel_f/RW_Happiness_Devel_Misc_f/About-RW-Happiness_DevelLog.txt
*/
.img-parent { position: relative; height: 0px; }
.img-parent img, .img-parent div { position: absolute; margin:0; padding:0}
.img-parent .caption { margin-top: 5px; }
.img-parent div img { position: static; }
/* About the child rules:
It's tempting to set 'div.img-parent img' and 'div.img-parent div' to position: relative, as this would simplify the positioning of captions under images. (Instead of having to calculate the caption's top position each time — as the height of its sibling image + the desired margin between the image and caption — we could just assign a standard top-margin to the caption in c3.css and not specify its top position at all, just as we often don't need to specify its left position now.) This would work in Firefox, but IE (6.0, anyway) reserves space for the image when it's positioned relatively even when it doesn't need any space (for example, if it's shoved out into a side column). IE may actually be more "correct" than FF in this behavior. In any event, we need to keep the img-parent's children absolutely positioned.
About the last two selectors:
'div.img-parent div' is often used to hold a caption under an image (for example, div.img-parent div.caption medCaption in AboutSan Personal); and it's also used, along with 'div.img-parent div img', for the special case of the 3-col RW Shiny/Pitted WITHIN the textCol in About RW Happiness, requiring an extra layer of divs to keep the captions with the images.
/* · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
º SIDEBOX sidebar boxes
` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` `
These rules could use better organization. Also some sidebox styles may be in santh.css (and maybe sanstu.css?) because specific rules like "fill" will vary depending on that site's design. Yet I suspect many of those rules should be moved here.
Note you can omit the p tag if there's only one content block in the sidebox, but the bottom margin will be a little too tight unless you manually add padding to the div, which is harder than just putting a
around the block. I experimented extensively; there's no practical way around this, I think. */
div.sidebox {
/* position: absolute; */
/* Must be absolute _if hung_ but this code line isn't needed. Where is it inheriting from? */
width: 137px;
/* Traditional method: refers to the width of the text-area only, i.e. as
though the padding were zero, & ignores the border thickness. The actual
box width (including padding and borders) used to be defined as 167px.
The more modern "border-box" method is more intuitive & width is correct; problem
is that it shifts my hung sidebars horizontally. I'd have to analyze & redo my complex
JS layout-adjustment routines to use this newer method. Which I may have to do
anyway to accommodate phones… box-sizing: border-box; width: 168px; */
border: 1px solid; /* the border & font colors should come from sanstu.css & santh.css */
border-radius: 12px;
z-index: 120; /* Added 7.10.17 because we want hover to “light up” the box, so need to bring in front of fts. Note that creating a “lower” z-index for the sidebox contents (like p's, etc) won”t help because the css3 transform that lights up the sidebox creates its own stacking context. The only way to protect the contents might be some weird shield inside the sideBox… maybe… */
}
/* · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
º ZOOM elements when hovered (typically sidebars or pix):
` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` */
.zoomable:hover { transform: scale(1.6); transition: 0.2s; transform-origin: center center; z-index: 999; }
.zoomable { z-index: 999; } /* Needed to pull zoomable item in front of fts shield. See, for example, a "San Word Tales" logo in upper right of those pages. However, this means most zoomable images must be image shields, not actual graphic! */
/* The direction we want it to zoom in will vary depending on the layout;
this is just a generic default but will often have to be overridden locally.
Absolute-positioned elms may not be able to use a transform-origin
like "center" at all, may have to be specified in pixels.
The z-index is to (1) pull it in front of fts so it responds to hover, and
(2) pull it in front of anything above it (e.g., the pageTools box above
the top thumbnail) so it doesn't "slide under" it when zooming.. */
/* SIDEBOX MAIN TYPE STYLES:
BTW, the body text within a sidebox cannot be “naked” -- it must be containerized in one or more p, div (or UL?) tag(s) to get the vert spacing right. I reseached & experimented _extensively_ in an attempt to properly style naked text, to no avail; it’s simply not worth trying to get around this! */
.sidebox, .sidebox p, .sidebox li, .sidebox li a.jump {
/* IE9 & IE10 don’t support rem in font shorthand, so we have to expand it: */
font-family: verdana,arial,geneva,helvetica,sans-serif;
font-size: .7rem;
line-height: 0.87rem;
}
.sidebox h4 {
font-family: verdana, arial, geneva, helvetica, sans-serif;
text-align: center; margin-bottom: .6em;
/* Font size: inherits .7rem from root .sidebox style; roughly 11px */
}
.sidebox.smallType h4 { font-size: 0.6rem; }
/* The h4 above looks bigger than the p type, even though it’s set “smaller”, because the cascade sets the h4 as Verdana bold whereas the p is in Arial regular. */
.sidebox.smallType p { font-size: 0.65rem; line-height: 0.75rem; }
/*SIDEBOX LIST ITEMS: */
/* Most of the time we won't want a bullet for an unordered list item, so this is the unclassed default. Note that IE9 or earlier mistakenly set this on the li, not on the parent ul, so we set the li as well: */
div.sidebox ul, div.sidebox li { list-style-type: none; }
/* List Items: override part of above rule: */
.sidebox li, .sidebox li a {
line-height: 0.95em; /* Only intended to affect internal linespacing _within_ a single li in the rare instance where it wraps to more than one line, but unfortunately it affects the space between li's too… */
margin-bottom: 0.8em; /* Restores the space between list items, to compensate for above line-height rule. Note the last li is also affected by the "last-child" rule a little higher up. */
}
/* The sidebox "light up when hovered" css is mostly set here, but the actual fill color has to be set separately in santh.css & sanstu.css.
Sidebox glow (hover-fill); we make the default transparent (so it "unglows" gradually on mouseout), and only add a fill when the class is added to that box's markup, or when a user hovers a non-filled box. The actual bg color is set separately
in santh.css and sanstu.css because the fill color is different. */
.sidebox { background-color: transparent; transition: 0.3s; }
.sidebox.fill, .sidebox:hover { transition: 0.3s; }
/* SIDEBAR INTERNAL IMAGES (incl. LEFT-ARROWHEADS):
The left-arrowhead is the most typical image used with sidebars, so we make it the default (i.e. we don’t specify in the html which image is desired).
The left-arrowhead is just outside the sidebar on the top-left side -- basically a pointer to some text or graphic in the main column) where needed. The “img” itself is actually a cleardot specified in the HTML, typically called “l”; the position of the “background-image” doesn’t matter since it’s exactly the same size as the img it “fills”. The filepath/filename looks the same in both sanstu & santh, but is actually a different file w a different colored fill, and there's no way to differentiate between the two different "sg" directories from here in c3.css… so the url part of the rule ("background:…") is set separately in sanstu.css and santh.css. The negative z-index is so the arrowhead tucks under the parent box's border, rather than having little gaps between the image (which should have been transparent, but I guess isn't) and the border: */
/*SEE MAD JOURNEY… many of these "arrowhead" specs will be overridden for other sideBox graphics. */
/* Any NON-ARROWHEAD image associated with the sidebox must be brought to the front, such as the wrench in the Page Tools box (see Gordon Gribley). This is especially true if it's a filled box, but is true regardless. So we set an image-class rule here: DO I STILL NEED THIS? */
div.sidebox img.toFront { z-index: 150; }
/*The tiny external “left arrowhead” is perhaps the most typical image we use with sideBoxes. The class 'sbla' (SideBox Left Arrowhead) requests it …*/
/*.sidebox img.sbla { width: 11px; height: 21px; position: absolute; left: -11px; right: 10px; top: 30px; z-index: -9999; }*/
.sidebox img.sbla {
background: transparent url(/msg/arrows/SideBox_LeftArrow.png) no-repeat;
width: 12px; height: 23px; position: absolute; left: -12px; top: 40%;
}
/* SIDEBAR INTERNAL VERTICAL SPACING:
Current sidebox construction doesn’t _require_ any headline. The vert spacing issues within the box are complicated… */
/* Padding here is for the box itself, not its contents as subsequent styles are. Also, if I apply a test-color to this, it doesn't work unless I make the selector more specific (prepend div#divOuter). */
div.sidebox { padding: 9px 12px 0 18px; }
/* RESET all vert space for sidebox direct contents (typically P, DIV, LI) : */
.sidebox * { padding: 0; margin: 0; }
/* Problem is the above rule is too powerful; for example, it prevents the link underdots spacing (much higher up) from working. */
.sidebox p a, .sidebox p a:hover, .sidebox p a:visited, .sidebox li a, .sidebox li a:hover, .sidebox li a:visited { padding-bottom: .1em; }
/* The only purpose of this if for boxes that don’t start w an h4 — i.e. the body content is the only thing in the box. This pushes that content down slightly, but shouldn’t affect boxes that do have an h4 at the top because this top-margin overlaps the h4’s bottom margin:: */
.sidebox p, .sidebox div { margin-top: 0.4em; }
.sidebox div, .sidebox p {
/* The inner “p” or “div” are, for most practical purposes, identical. */
margin-bottom: .65em;
/* The purpose of the margin-bottom rule is that, visually, we want less space between paragraphs than under the final paragraph (cf. following “last-child” rule). This should only affect body-type blocks that are followed by another body-type block; the later rule (for last-child) should override this in most cases. */
}
/* The last text (near the box bottom) can use a little more space under it; unfortunately this won’t work in boxes with a caption, since that’s technically the last child even though it appears below the box; but it doesn’t hurt either. Another limitation: I tried to add still more space under the last-child li if it’s an “a” since the underdots could use more space under them (visually eat into the bottom margin) but couldn’t get that to work right. */
.sidebox p:last-child, .sidebox div:last-child, .sidebox li:last-child { margin-bottom: 1.4em; }
/*º • • • PAGE TOOLS sidebar styles: • • •
(May override some sidebox rules above): */
/* HTML created from pageToolsScripts.php; main styles are here in c3.css; behavior comes from j3.js. */
div#pageTools {
top: 200px; /* likely to be overidden by local pgs, based on height of titleblock or masthead, etc. */
/* Reduce distraction from real pg content, until they hover the pageTools sidebar: */
transform: scale(0.9); opacity: 0.6;
box-shadow: inset 0 0 10px #8c8381;
/* In rare cases where only two links initially appear (like in the About San Pro pages), this prevents the Page Tools bottom-padding from looking too tight, without screwing up the sidebox once an additional link is added: */
min-height: 78px;
}
div#pageTools:hover { /* When they mouse over the Page Tools… */
/* Restore full size & opacity: */
transform: scale(1.0); opacity: 1.0;
box-shadow: inset 0 0 10px #685d5a; /* make it a little more 3-D looking */
}
/* … and “light up” the sidebar’s background. On Santh it's a bright
tan light; Page Tools aren't used much in Sanstu (see About San
pages) but when it's there, it lights up a pale bluish-gray: */
body.santh div#pageTools:hover { background-color: #ddd0c9; }
body.sanstu div#pageTools:hover { background-color: #dde; }
/* NOT WORKING: This is my attempt to make the page tools box reachable through the fts shield even after the initial click on the "Zoom in page" link, even if the fts code is _below_ (i.e. outside) the div#outer, where the fts works better. Unfortunately this doesn't help for some reason: */
div#pageTools, div#pageTools:hover { position: absolute !important; z-index: 99999 !important; }
div#pageTools img#wrench, div.pageTools img.wrench {
/*BORDER: 10PX DASHED ORANGE;*/
background-image: url(/msg/widgets/Wrench_forPageTools.png);
position: absolute;
width: 54px;
height: 90px;
top: -12px;
/* Horizontal Position: You’d think that a simple “right:” declaration here would override the “left:” declaration higher up in the div.sideBox rule (which is meant for the typical arrowhead image). However, it seems that (at least on an absolutely positioned element like this) a position-left overrides position-right, even if the latter is lower down, is marked “!important”, & has greater specificity -- i.e. no matter what! (BTW position-top always overrides position-bottom as well.) The left:auto below returns the left position to the default, which allows the right position to take effect: */
left: auto;
right: -10px; /* Has same effect as “left: 73%” but is more direct -- not dependent on the parent box’s width */
}
div#pageTools h3 { font-size: 0.79rem; margin: 0 0 .7rem 25px; }
/* PAGE TOOLS LINKS:
We set the finger pointer here so we don't have to bother putting my "link" class into each a tag.
Also, santh.css sets sidebar link colors to a brown, overriding the usual navy set lower down here; but we don't want Page Tools links that subtle, so we restore them to the c3.css conventional link color: */
/*div#pageTools li a { cursor: pointer; color: navy; }*/
/*EXPERIMENT: */
div#pageTools li {
/* Somewhat bigger type & smaller line-height than usual, because of 'resize' links & need for consistency: */
font-size: 0.8rem; line-height: 0.5rem;
/* There are actually no A tags, but we make them look somewhat like links: */
cursor: pointer; color: navy;
/* Add underdots. See true 'A' tag rules higher up for more comments: */
background: url(/msg/widgets/lubld.gif) repeat-x 0px 100%; padding-bottom: .4em;
/* Limit underdots to actual width of text, not the whole box. BTW additional (temporarily hidden) links will also be set to inline-block by j3.js… */
display: inline-block;
}
div#pageTools ul li#aboutDrawings, div#pageTools ul li#showhideDrawings { margin-top: 2px; }
/* Override slightly-too-large bottom margin inherited from gen'l sideBox rules higher up. */
div#pageTools li:last-child { margin-bottom: 16px; }
div#pageTools li:hover { background: url(/msg/widgets/lugad.gif) repeat-x 0px 100%; }
div#pageTools li.jmw_link {
/* Put JMW/popup-window anim icon to right of (faux) link.
Adapted from “Links to JMWs…” much higher up; see there for relevant notes, but note changes here. */
margin-top: -2px;
background-image: url(/msg/widgets/pwsid.gif);
background-repeat: no-repeat;
background-position: right -1px;
padding-right: 18px; /* Leave room so the icon doesn't overlap the link text */
}
div#pageTools li.jmw_link:hover { background-image: url(/msg/widgets/pwai.gif) }
/* SERIESBOX (a kind of sidebox) SERIES/NAV LIST:
This is a particular form of sidebox with li’s inside (styled just above this) — a list with short links to navigate within a series of related pages. See my NCRI business writing pgs (Consulting_DecisionPoint.html, etc) for examples.
The "top" position here may be typical but will have to be tweaked in some pages. */
/* TOO HIGH if we're putting a PageTools box above it! What pages use #seriesBox? */
#seriesBox { top: 116px; }
#seriesBox h4, #seriesBox li { text-align: left; margin-left: .6em; }
/* The space between a sidebar's h4 and the first li under it would normally be 2px less (19 vs. 21) than if the h4 were followed by an ordinary p of text. This is a function of the line-heights involved, not the margins per se. I don’t know any way to detect via CSS “an h4 followed by a UL” etc (although I could create a new class for an “h4+ul sidebox” I guess), so I just manually add a little space here to the normal .sidebox h4 margin-bottom: 0.6em, although the difference is almost trivial: */
#seriesBox h4 { margin-bottom: 0.7em }
/* CAPTION (optional): code stays inside the sidebox-div code for simpler overall positioning & JS tweaks, yet displays outside (below) the bordered box. “Absolute” gets it out of the bordered area, but we can’t use conventional absolute positions “top” or “bottom” since (regardless of how arranged) they require advance knowledge of box and caption heights. Using “absolute” + “margin-top” solves this. Note p.caption must be last block within div.sidebox… */
div.sidebox p.caption { position: absolute; width: 169px; margin: 1.6em 0 0 -19px; text-align: center; /* OUTLINE: 1PX DASHED CYAN; */ }
/* To compensate for the left-padding, and still have a caption (of any length) look visually centered to the entire box, we use a -19px negative left-margin (approx. equal to the left-padding within the box) coupled with a forced width of the entire box. We could probably get rid of the left-margin and width crap if we converted from the traditional (default) of “box-sizing:content-box” to the newer, more intuitive “box-sizing:border-box” for all the sidebar stuff. Unfortunately that screws up my existing JavaScript layout-adjustment calculations so we'd have to tweak that too… */
/*NEW CLASS only for sidebox’s (or other divs?) that get the “swap” option via j3.js elmSwap() */
.swap > * { display: none; }
/* Above means: hide all _immediate_ children of any div classed as “.swap”. Typically that would mean “Hide any divs or p’s directly within the div.swap parent, but don’t hide the headline and break tags inside those divs or p’s”… */
/* By comparison, the following _doesn’t_ work; all the h4’s and tags. Meyer says “no-repeat” is the bg default but that’s not what my experiments in FF indicate; the 3px height should prevent repeats anyway but I put in the instruction just to be safe. Initial margins defined below may be suitable for some mid-column purposes, but will usually have to be overridden: */
.horizRule280, .horizRule382, .horizRule387, .bottomRule { display: block; background-repeat: no-repeat; margin: 22px auto 22px auto; height: 3px; }
/* Standard width of textCol (382px): */
.horizRule382 { width: 382px; background-image: url(/msg/widgets/horizRule382.gif); }
/* Shorter rule designed to be horizontally centered within textCol. Mechanical centering would be 51px left margin, but visually it needs to be a little left of there to look centered for a typical text rag: */
.horizRule280 { width: 280px; margin-left: 45px; background-image: url(/msg/widgets/horizRule280.gif); }
/* Standard width of textCol (382px) + a smidgen for a leftside outreach: */
.horizRule387 { width: 387px; margin-left: -5px; background-image: url(/msg/widgets/horizRule387.gif); }
/* “.bottomRule” is used above the “previous/sectionName/next” links at most page bottoms - its 400px width gives a pleasing overhang beyond the text column on both sides. (But be careful: some pages (e.g. MassSAVE_ad) will screw up in IE with a rule this wide.) The negative margins position the rule horizontally, but they also do more: they’re especially needed by IE6 — added to the 400px rule they equal textCol’s official 382px “content width” ( 400 minus 7, minus 11, = 382). You actually only need a negative margin on one side to position the rule, but if the width+ negative margins add up to more than 382, an IE bug will expand the overall width of textCol. */
.bottomRule { width: 400px; height: 3px; background-image: url(/msg/widgets/horizRule400.gif); margin: 38px -7px 6px -11px; }
/* ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` `
º AUTOMATIC PAGE NUMBERS
(e.g., for navigating graphic stories; generated by PHP or JS)
TO DO: 1. MOVE THIS TO SERIES.CSS (Dupe at first?) There's already styles in this ballpark there. See what breaks if I move it & comment it out here…
2. it seems like I must have used JS to vary the page numbers size & spacing depending on how much room we have… need to track that down… WHERE IS THAT CODE?
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · */
#pageNumbers, #pageNumbers p, #pageNumbers a:link, #pageNumbers a:visited {
font: 12px/1em arial, geneva, helvetica, sans-serif;
margin: 0; padding: 0;
text-decoration: none;
}
/*
- Above font size overridden in series.css, for (I think/hope) the same pages that use graphicSeriesScripts.js …
- See also similar rule re-implementing the above with more specific “multipageNav” selector in santh.css
- DELETE the id-rules as soon as I’ve replaced them w the class in all html pages: */
#pageNumbers a, #pageNumbers a:link, #pageNumbers a:visited,
.pageNumbers a, .pageNumbers a:link, .pageNumbers a:visited { color: #666; }
/* Since I started using faux-links (pure JS links) for the illus pages, all the "a:link"-type selectors above are ignored, because without hrefs they're not seen as "links" (just as A tags). So I prefixed the simple "#pageNumbers a" selector to the ruleset. BTW all the other elements in that kind of div (e.g. vertical divider lines, current-page number, arrowheads) tend to be styled separately. Also, this color will be overridden in many pages by head css anyway. */
/* The images affected are the _graphic_ arrowheads on the two ends of the line of page numerals. (Also the pipe/dividers?)
Weird code, but LOOKS GOOD in Win & Mac browsers. This shouldn't be relevant to the unicode pointer
characters (January 2014 change) that are replacing the graphic arrowheads, at least in the illus section… */
#pageNumbers img, .pageNumbers img {margin-top: -1px !important; vertical-align: -1px !important; }
/* The 'margin-top' part is to maintain alignment in WinIE (the other browsers ignore it); the 'vertical-align' is to maintain alignment in Firefox and Safari. */
/* The second and third selectors below are for Firefox to cascade-override the previous rule (right above this). IE doesn't need these selectors; it considers that "a:hover" will always override other link rules. Note that W3C sees these selectors as valid, but WDG thinks they're errors. The hover color (#00cc00) is moderately bright green, and can be overridden with a darker green (#009900) or brighter green (#00ff00) depending on page backgrounds, etc. */
#pageNumbers a:hover, #pageNumbers a:link:hover, #pageNumbers a:visited:hover, .pageNumbers a:hover, .pageNumbers a:link:hover, .pageNumbers a:visited:hover { color: #00cc00; font-weight: bolder; }
/* Note that some of the above “pageNumbers” rules may be overridden in series.css, sanstu.css, santh.css */
#cp, .cp { font-weight: bold; color: #444; }
/* default style for "current page" numeral, although this will often be overridden */
/*
VERTICAL DIVIDERS (between page numbers in series pages):
The vertical dividers are actually formed from a 1x1px transparent dot (called, for this purpose, ’l’ formerly 'd.gif' but actually identical to 'cleardot.gif'). The dividers' apparent color (set by 'background-color') can be set individually in the head css for each illus page, depending on what looks good on that page's background color. Previously I was also customizing the horizontal margins around the vert. dividers on some pages (the default here is 4px), but I stopped doing this because the horizontal shifting of the next/previous arrowheads (which can be disconcerting to a user hovering over the arrowhead) wasn't worth the minor aesthetic tweaking.
Also note that the arrowheads are always 11px high, and the dividers (while they can be made any height) generally look best at 11px as well.
VERTICAL-ALIGNMENT NIGHTMARE:
Getting the vertical alignment of the page numerals, vertical dividers, and arrowheads all looking good across browsers was _extremely_ difficult and time-consuming. The combination of the "#pgnumbers img" rules higher up and just below use the cascade to make various browsers happy. Don't mess with these settings lightly!
Style the vertical dividers that are between the page numbers.
The background-color, and/or the horizontal margins, will be overridden in many pages by head css.
Modern browsers ignore the vertical-align and margin-top here, because the contradictory instructions higher up have "!important" which overrides this; but WinIE5.0 obeys this because it doesn't know what "!important" means. This convoluted use of the cascade is, in effect, a form of browser detection hack. It works and it still validates perfectly, so leave it. */
#pageNumbers img, .pageNumbers img { vertical-align: middle; border:none; width: 1px; height: 11px; background-color: #777; margin: 0 4px 0 4px;}
/* The two arrowheads have a fixed size. This rule overrides the previous rule,
and overrides the background-color set in the html doc head css, since
technically the arrowheads, like the dividers, are '#pageNumbers img' */
.pn_arrow { width: 9px !important; height: 11px !important; background-color: transparent !important; margin: 0 2px 0 2px !important; }
/* BTW, the vertical position of the pageNumbers block within its TD or DIV cannot be set here, because that varies with different kinds of series layouts (cx, illus, sketch, etc.). */
/* · · · · · · · · · · · · · · · · · · · · end Page Numbers section · · · · · · · · · · · · · · · · · · · · · · · */
/*º TEENY STUFF: */
.tight, p.tight, span.tight { margin: 0 !important; padding: 0 !important; }
.micro, p.micro, span.micro { margin: 0px !important; padding: 0 !important; font-size: 0 !important; line-height: 0px !important; }
/* 'micro' is typically used to prevent browser from increasing the linespacing
on an invisible 'typographic' element if the user has entered an unusually large
type size in their defaults (which affects linespacing as well as fontsize). For
example, it might be used to class the container of an nbsp placeholder within
an empty table cell, or to class a break tag. WARNING: SAFARI (1.3.2, anyway) IGNORES THIS TAG! */
/* For Copyright styles, see "Side-Column & Graybar Styles" section higher up. */
/* ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` */
/*º LISTS (UNORDERED or ORDERED):
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
See also:
'Prev/Next bottom links' under 'Link Styles' higher up.
(The prev/next links are organized as a special UL with horizontal styling.)
'p.preList' under "Body Text Styles' higher up.
ul, ol { font-size:12px; line-height:15px; margin:0 0 14px 0; padding:0; }
The font-size/line-height definition was causing a problem in Safari (only) in Santh Bsns Writing Abt-2:Financial in the main column bullet section. Taking out the font definitions and letting inheritance handle it solved that and doesn't seem to bother anything else; in the rare cases where I want a list different than its parent, I spec it locally anyway. */
ul, ol { margin: 0 0 14px 0; padding:0; }
li { margin:0 0 3px 2px; padding:0; vertical-align: middle; }
/* The 'vertical-align: middle' helps standard bullets look vertically centered, rather than too low, in IE; it has no effect in FF or Safari, which know how to center bullets properly anyway. This gets overridden higher up for the prev/next custom bullets, which need 'baseline' alignment in IE. */
li.lede { font-style:italic; color:#7f7f60; padding:4px 0; }
ul { list-style-type: none; margin:0; }
/* Killing the bullets re Edward Tufte's 'chart junk' concepts. The only effect of the margin:0 that I can see is to kill what looks like padding at the bottom of the ul block as a whole (i.e. under the last li.) */
/* ul.smTitle li, ul.smTitle li a, ol.smTitle li, ol.smTitle li a { font-size: 14px; line-height: 1em; margin-bottom: 8px; } */ /* "sm" refers to sitemap; sometimes there are titles there in a list form and they need to be bigger than standard list items. However this style was somehow involved in a weird problem in IE. */
ul.bulletList { list-style-type: disc; }
/* Moved into here from Santh.css, since I use this in both Santh bsns writings (for example, Abt Financial) and in the Sanstu sitemap (by coincidence, in the expansion listing for Santh):
Custom bullets done in the 'official' way are badly aligned vertically in IE — a problem that's been discussed often (without resolution) online. The following method overcomes that problem, although the author doesn't mention IE or its problems at all. From MacWorld "CSS Tricks for Custom Bullets" by David Sawyer McFarland; saved in my WinFF Scrapbook as "CSS Custom Bullets" */
ul.diamond {
list-style-type: none;
padding-left: 0;
margin-left: 0;
}
/* Currently, the "#textCol" (below) is for Santh (e.g. Abt Financial); the "td.mainCol" is for the Sanstu sitemap (e.g. Santh-listing expansion trigger). Generalizing it to just "ul.diamond li" screws up one or the other; I didn't bother to track down why. There are also "diamond" styles in Santh.css. */
#textCol ul.diamond li, .textCol ul.diamond li, td.mainCol ul.diamond li {
background: url(/msg/widgets/HollowBrownDiamondBullet.gif) left 6px no-repeat;
padding-left: 17px;
margin-bottom: 6px;
}
/* · · · · · · · · · · · · · end List styles · · · · · · · · · · · · · · · · · · · · · · ·
Typically, when I use a background-image, I don't want it to repeat. Meyer says the "initial value" is no-repeat, but in my experience that isn't the browsers' default, so we make it so: */
background-image { background-repeat: no-repeat; }
/* Note this makes some of the tags higher up redundant; perhaps I should prune them. Also be careful this doesn't create problems for my link underdots. */
/*º JS-ENHANCED TOOLTIPS STYLES:
These are just the CSS styles; the main code is in j3.js. For originals and semi-originals see my folder: Tooltips_Enhanced_by_JS+CSS_f*/
#tooltip {
position:absolute;
background:#444; /* dark gray */
color: yellow;
padding:8px;
z-index:999;
font-family: arial, helvetica, tahoma, verdana, "sans-serif";
font-size: .75rem;
letter-spacing: 1.3px;
line-height: 1.3;
padding: .6rem .6rem .8rem 1.0rem;
width: 15rem; /* Sometimes too wide. Script this? */
text-align: center;
border: 3px ridge #666; /* light gray*/
border-radius: 20px;
opacity: .7; /* any less & they're hard to read over other type */
}
/*º - - - - - - - - - - S E C U R I T Y C O D E - - - - - - - - - - - -*/
/*º FTS SECURITY CODE:
This is part of my Full Text Shield system that has HTML, CSS, and JS components.
For discussion of below code, see my techdoc: file://localhost/Volumes/Goya/Documents/San_Creative/DEVEL_of_San_Websites/Security_Webdev/Securing_MainText.txt
I keep the security code (here and in the main JS file) turned off during most of the devel process; it should be turned on right before optimizing the file for upload. Note that my AppleScripts to enable/disable/toggle the FTS are for the individual HTML docs (and the script is broken!); the scripts don't toggle it here, have to do that manually.
NO LONGER WORKING RIGHT (MacFF & Chrome); if window wide, FTS is not wide enough to shield entire page/body. (It only shields the central portion covered by div#divOuter). Once you get an insertion or selection in the unprotected part of a sidebar, you can just "select all" to get everything on the page.
EXPERIMENT: See "Window Shade" essay -- I moved FTS div down just _below_ the end of divOuter; seems to work better (covers the entire window width). We'll see… UNFORTUNATELY, this also seems to make the Page Tools (and all the other links etc) unreachable after using its "Zoom in page"…
Also some pages (like my new PHP-based gx story pages) don't even _have_ a div#outer…
Also just doing "Select All" command (⌘A) would normally still select everything, even without a prior insertion point, except this is fixed by the other method I used (see next paragraph).
This whole fts system may be somewhat redundant to (and is generally less effective than) my other security method, "anti-highlighting security code" (yes, it's CSS not JS!) just a little way down below this.
*/
#fts {
/* BORDER: 8px DASHED RED; */
position: absolute;
top: 0;
bottom: 0;
left: 0;
right: 0;
width: 100%;
height: 100%;
background-image: url(/msg/l);
background-repeat: repeat;
z-index: 100;
background-position: 0 0;
}
/* Make links work despite fts page shield:
Certain elements need to be brought in front of the page shield, more in some browsers than others, in order to contain clickable links. This line of code should replace my previous “toFront” class that had to be applied to individual elements (clunky). This doesn't have to be toggled on & off with the rest of the security code (I can just leave it on): */
a, a img, div#pageTools li , .hovernote
/* Also make links work on phone-screen layouts despite fts page shield:
NOPE, doesn't work, phone arrowheads still not clickable
and regular layout title shoved over all the way to right!
.graphicSeriesPage #infoBlock h1#captionBlock,
.graphicSeriesPage #infoBlock h1#captionBlock.longTitle,
p#phoneLogoBlock, a#logoForPhoneScreen img */
{ position: relative; z-index: 120; }
/* For phone (small) screens, see code in series.css immediately after comment “FTS FIX: Make phone-screen arrowheds clickable despite fts being enabled” */
/* FOR EXPERIMENTING: */
p#phoneLogoBlock, a#logoForPhoneScreen img {
/* background-color: RED;*/
}
/* Note that in some cases an ’a’ or ’a img’ needs to be something other than position:relative in order for its layout positioning to work. But z-index will only work with positioned elements (i.e. not static) which is why we have to add _some_ kind of non-static positioning to the z-index instruction above. What all this means is that in a few cases I’ll have to override this position:relative in the html doc’s head styles. For example, in the sitemaps, I had to add a rule that the bigBrown buttons “a” tags are position:static; otherwise they’d appear in the wrong place. But they remain clickable in front of the shield anyway… because those ’a’ tag’s children are img's with position:absolute and z-index:120; so I guess it’s actually the child that’s clickable, not the ’a’ itself. Very confusing. Update: pay attention to Stacking Context! E.g. 'opacity', 'transform', etc create new stacking contexts; everything inside a context can only be vertically repositioned within its own stacking context, kind of like scope in JS… */
/* See Window Shade essay for issue: the elm has to be at least relative for .toFront to work, but I can't just put that here because it might be absolute… what to do? */
div#navTop, div#navBottom, div#navBottomR, div#bottomBar div,
div.navTop, div.navBottom, div.navBottomR, div.bottomBar div,
div.thumbWrap, .toFront { z-index: 120; }
/*º ANTI-HIGHLIGHTING SECURITY CODE:
I normally don't bother w vendor prefixes anymore, but this is NOT on standards track & they're still needed, even for FF (March 2019). Either the "webkit" or "khtml" works in Safari 5.1. This works in most browsers (except IE & Opera). Note I also have equivalent code in j3.js [I do? It's not working. Where?]; either this CSS or that JS alone are sufficient to trigger these attributes. Luckily this doesn't seem to affect form text, rollovers, etc. You can also supposedly override this for particular elements with “.force-select”. See tech notes in Securing_MainText.txt (full path is a little higher up). See also https://drafts.csswg.org/css-ui-4/#content-selection
Could also use other selectors: body, div#divOuter, div's & p's, etc.)
Not sure which vendor prefixes still needed, but many may be (like Moz) because this code isn't on a standards track AFAIK. Not sure what all the prefixes are for, but possibly: webkit & khtml: safari; moz: firefox; ms: IE 10+ (none of this works in IE9); o: opera? ; no-prefix: for possible future browsers.
*/
/* MOSTLY WORKS. Toggle code off for devel & on for going live: */
/*
HTML {
-webkit-user-select: none; -khtml-user-select: none; -moz-user-select: none; -ms-user-select: none; -o-user-select: none; user-select: none; }
*/
tags are wiped out & never return when we click through the series:
.swap * { display: none; } */
/* Now we partially override the above, but just for specific kinds of child elms:
- the initial text block (probably DIV or P);
- any headline (h4) that's _directly_ inside the outer ".swap" parent; note
this does _not_ include headlines within the swappable sub-elements;
- the caption underneath the main box (which contains the swap-trigger link): */
.swap .initialDisplay, .swap .initialDisplay *, .swap > h4, .swap .caption { display: block }
/* Initially I also had “ .swap .caption * ” (with a wildcard child) in the above rule, to make it more flexible, but that screwed up A tags (links) */
/* Darken link colors within roundBox. Without the .div its priority gets overridden: */
div.sidebox a, div.sidebox a:link, div.sidebox a:visited { color: navy; }
/* Apparently “navy” is #000080 (?) */
/* · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
º SIDEBARS ("sidebox"), sidebarParent, & thumbWrap:
` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` `` ` ` ` ` ` ` ` ` ` ` ` `
See my devel documentation in: Boxed_Asides.techdoc.rtfd
Horizontally position sidebars: */
.sidebox {
position: absolute; /* Prevents vertical gaps in main text when roundbox is slid into right col from main col.
BTW, sidebox's position is relative to sidebarParent, if that's used as a container; or else to its grandparent divOuter. (Both are relative-positioned.) Position of sidebox is _not_ directly relative to div#textCol, which is normally not positioned, although the text flow within textCol does affect the sidebox vertical position. */
/* Slide boxes horizontally into right column, up against right edge of divOuter: */
/* right: 0; */
right: -30px /* Adjustment for "JS disabled" situations. This gets overridden in j3.js
layout-adjustment code. This could cause trouble if i ever put a sidebar in the left column,
for example in the Window Shade essay, or in some table-based layouts. */
}
/* Vertically position sidebars:
Unfortunately, if we want to vertically position the sidebar relative to some text in the main column (using sidebarParent), then we can't horizontally position it relative to something else (i.e. divOuter). So we have to horizontally position it relative to sidebarParent as well. (Actually sidebarParent isn’t used much.) BTW, this horizontal-positioning override to the above rule was calculated for sanstu; may be different for santh?: */
div.sidebarParent div.sidebox { left: 494px; } /* NOT ADEQUATELY TESTED W CURRENT CODE; was: 479px */
/* Small type used in some sidebars. Unfortunately there’s no way to set max-size of a font in CSS, not even in CSS3… */
.smallType, .smallType * { font-family: arial, verdana, geneva, helvetica, sans-serif; font-size: 10px; }
/* To explain the use of the following, see notes in RoundCorneredBoxes-TechDoc.rtf: */
div.sidebarParent { position: relative; height: 0px; width: 0px; }
/* Wrapper used when vertical positioning is tied to particular text in main column.
In that case, to position horizontally use "left: 479px" (or whatever) rather than
"right:0" to position sidebar horizontally against divOuter. */
div.sidebox a {
/* This enables any sidebox link (including a caption link) to work
w my fts security, without having to add a "toFront" class: */
position: relative; z-index: 120;
}
div.sidebox p.caption, div.sidebox div.caption, div.sidebox .caption a {
/*COLOR: YELLOW; */
font-family: arial, helvetica, sans-serif;
}
/* THUMBWRAP for _rectangular_ thumbnail images of site pages, which can go in either side column. Similar idea to "img-parent", but code works slightly different. Typically used in conjunction with the hangLeft or hangRight classes. Note that, typically, only the rectangular "recessed" thumbs (in both sites) are 164px wide (they come from the same Ph master file). The "flat" thumbs are usually narrower, and the silh thumbs (like the page-spreads for the NCRI quals page) could be any width.
Standard left-column element is 120px wide; 164-120 = 44px. The margin will have to be OVERRIDDEN for hangRight or main-col thumbs. */
div.thumbWrap, div.thumbWrap img { width: 164px; border: none; }
div.thumbWrap a, div.thumbWrap img a { background-image: none; } /*prevent underdots*/
/* See also more styles for thumbWrap much higher up, where I define the A tag underdots. */
/*The ’display:inline’ (below) reduces a caption-spacing bug in IE8 (only!) — but unfortunately in reducing the excessive space that IE8 puts above the caption, it unfortunately _adds_ a touch of extra space above the FF caption, which seems too far from the pix now. Still this seems like a decent compromise for now. It has no effect on Safari or Chrome, where the caption is too tight to the pix either way. */
div.thumbWrap img { display: inline; }
div.thumbWrap .caption { margin: 6px 0 0 5px; } /* Top margin was previously set to 4px. Compare to div#TFFcaption, which was designed for use w img-parent and for some reason doesn't affect anything with thumbWrap.
THUMBWRAP CAPTIONS SCREWED UP IN IE8 (only!); space between pix & caption much too great. But right in all other browsers including IE7! The debugger indicates something about div.hangRight img displaying as block.
- - - - - - - - - - - - - - - - end of "Side-Column Elements" section - - - - - - - - - - - - -
---------------------------------------------------------------------------------
º MISCELLANEOUS STYLES:
---------------------------------------------------------------------------------
º IMAGES:
````````````````````````
I usually don’t want borders on images, and I don’t think I’ve ever used a repeating background image. (Meyer says “no-repeat” is the bg default but that’s not what my experiments in FF indicate.) The following “image reset” styles are duplicated, probably unnecessarily, by the individual styles for some element types above and/or in the html pages, so perhaps I can purge some. Here are the overall “image reset” styles: */
img, a img { border: none; outline: none; background-repeat: no-repeat; }
/*º EXPANDABLE TEXT SECTIONS styles:
````````````````````````````````````````````````````````````````````````````````
They're styled from here (and also from sanstu.css or santh.css) but actuated from j3.js.
See (obsolete) devel log: file://localhost/Volumes/Goya/Documents/San_Creative/DEVEL_of_San_Websites/Dev_Logs_for_San_Websites/Expansion_(Show-Hide_Text).txt
CAN I GET RID OF THE DAMNED !IMPORTANT BELOW? */
div.expandable { display: none; } /* styles initial display only */
p.triggerContainer, p.triggerContainer a { margin: -4px 0 4px 0 /*!important*/; padding:0; color: #605d6f; } /* link color is a light bluish-gray */
p.triggerContainer a:hover, p.triggerContainer a:link:hover { color: #009900; text-decoration: none; }
div.sidebox p.triggerContainer, div.sidebox p.triggerContainer a { margin-bottom: 1.2em; }
/* DO NOT try to combine, alter, or even understand the following code! It has to appear exactly like this. I have no idea why: */
p.triggerContainer a, p.triggerContainer a:link, p.triggerContainer a:hover, p.triggerContainer a:link:hover { padding: 0; }
p.triggerContainer a { padding-right: 14px !important; }
/* The padding-right provides the space for the down_gray_arrowhead background image to appear.
WARNING WARNING WARNING WARNING WARNING WARNING:
In the next two rules, do NOT delete the space between the close parens and the words ‘right bottom’ or IE (all versions) won’t see the arrowheads and will put underdots under the link. (My CSS cruncher script shouldn’t delete an ordinary space following a close paren.) Currently (June 2011) IE6 screws up because it doesn’t seem to see the positioning & no-repeat instructions, even if I add !important; I don’t know why.
Define down-pointing grayish arrowheads to the right of most 'expand this paragraph' links: */
p.triggerContainer a, p.triggerContainer a:link, p.triggerContainer a:visited { background:url(/msg/arrows/down_gray_arrowhead.gif) right /*bottom*/ 5px no-repeat; }
/* Show the _green_ arrowhead on hover: */
p.triggerContainer a:hover, p.triggerContainer a:link:hover { background:url(/msg/arrows/down_green_arrowhead.gif) right bottom no-repeat; }
/* BTW, the preload for the down green arrowhead is handled by j3.js, using a root-relative URL. */
/* · · · · · · · · · · · · · · · · · · · end of Styles for Expandable Text Sections · · · · · · · · · · · · · · · · · · · */
/* Used for 'body' styles at present; could be used for almost anything: */
.gray9 { background-color: #999999; }
/* #999 is Medium Gray, or RGB 153 — the typical Sanstudio bg color. */
/* Note the Santh homepage background color comes from santh.css. */
.hideMe {display: none}
.showBlock {display: block}
/* An item set to display: none takes up no space in the layout.
If you want the item to retain its space, use visibility: hidden. */
/*º THUMBNAILS:
Purpose: Thumbnail images of pages (“thumbs”) are generally used to ‘advertise’ those pages.
Structure: There’s typically a parent div classed as “img-parent” which may also have an ID. It has zero (or 1px) height, is relatively positioned, moves along with the text in the main column, and contains the thumb img as a child. It may also contain a caption child. Its children are absolutely positioned and usually shifted horizontally (and often vertically) to position them in the adjacent sidebar column. Their positional shifts are defined in the individual html page CSS, or in aboutSan.css or similar sectional CSS.
Image location: Thumb graphics are stored in various places — for example, the Contact San thumb is stored in msg/infographics (because it’s the same for Sanstu & Santh), and the TFF and Sitemap thumbnail graphics are stored in the individual sites’ general “sg” (site graphics) directories. Would it make more sense to store the images in the directories they advertise? (E.g., in the sites’ “infographics” dirs?)
Often, the local html pages specify a path to a “shield”; the real image is applied as a background to that. Generally the specs for those background-image filenames and dimensions will be in santh.css or sanstu.css; and their positions will be in the individual page heads (or perhaps in specialized files like aboutSan.css). But if the thumbnail uses the same graphic in both sites — such as the Contact San thumb — then its filename and dimensions should be stored here. However, its positions would still be stored more locally.
TELLFRIEND THUMBNAILS:
Since the image differs for sanstu & santh, we don’t define it here. However, both versions have the same dimensions, and use the same caption text, so the specs for their captions are the same (except the text color). So we define most of the caption specs here: */
div#TFFcaption { top: 118px; left: 5px; width: 154px; }
/* For the above to be useful, you have to put the caption code _inside_ the same img-parent div as the thumbnail image itself, so that the caption is positioned relative to that parent div (even though the caption is “absolutely” positioned). Just be careful that if you apply vertical positioning to the parent div (which is “relative”), there isn’t an empty space opened up in IE.
CONTACT SAN THUMBNAILS:
Flat version (no recessed frame built-in to the image itself) is basically the same in both sites. I did create an inherently recessed version of the graphic specifically for white or off-white backgrounds but it doesn’t look that good. (Too much shading; border too thick to match other recessed thumbs; etc.) We still want a recessed look, sort of , but here we construct it in HTML. The standard “ridge” style looks too much like the picture-frame ridge I use for my sketch or illus. thumbs. The standard “inset” style looks awful and is lit from wrong side (in FF, anyway). So we do the whole frame manually: */
div#CSthumb img { width: 159px; height: 238px; background-image: url(/msg/infographics/ContactSanThumb_flat.gif);
border: 5px solid #ccc;
/* border-color: #999 #ccc white white; */
}
div#contactSanCaption { top: 250px; left: 6px; width: 153px; }
/* Version with built-in recessing for white or offwhite bkground could be used on either site; but the recessed effect isn't very effective on white backgrounds: */
div#CSthumb_whiteR img { width: 164px; height: 235px; background-image: url(/msg/infographics/ContactSanThumb_whiteR.jpg); border: none; }
div#contactSanRecessed_Caption { top: 240px; left: 6px; width: 153px; }
/* Contact San thumbs with gray or taupe indented frames are defined in sanstu.css or santh.css. */
/*º HORIZONTAL SPACERS:
This could also be referred to as “white space control” or “validatible word breaks”.
In the first two rules below, the line-height: 0 is needed to prevent Mac Firefox (and maybe other browsers; I didn’t test) from inserting extra linespace for some reason when the minute horizontal space [in a span] is inserted. */
.nano { font-size: 1px; line-height: 0; }
/* Comments on above rule:
My “nano” class can be used for a couple of purposes.
It can create a validatable optional wordbreak. It’s 1px because some browsers will refuse to make type “0” in size.
It would normally be used in a span containing a single space, following an ellipsis or hyphen (instead of the nonstandard/non-validatable which is now deprecated. Current tags, and , normally have same presentation (browsers typically default to "line-through") but are semantically different. In short, means “no longer current or appropriate” while indicates an actual edit. I’ll use (formerly I used a custom span.crossedOut class but that’s verbose)
However BBEdit 9 flags as an error, but not , so if I get tired enough of the errors I might revert to . OTOH BBEdit's preview still works correctly (I think it actually uses Safari's rendering engine).
We use css3 ’opacity’ rather than a specific color to lighten crossed-out text, because of all the different colors of backgrounds & text. */
s { text-decoration: line-through; opacity: 0.6; }
/*º VERTICAL SPACERS:
Not sure it’s as reliable as cleardot spacers, but code is more compact. These were previously coded using p’s rather than divs, but that introduced uncertainties about linespacing, font size, etc; and the truth is they have nothing to do with p’s or type, they’re pure box-model spacers. */
div.vert16 { height: 16px; padding:0;margin:0}
/* Typical HTML:
because it's not consistent between browsers.*/
/* Pseudo-HR for Sanstudio graybars - CURRENTLY only used in "Illus_vs_Cx_Styles.html": */
.grayHR {border-top: 1px solid #7f7f7f; border-bottom: 1px solid #afafaf; height: 1px; margin: 9px 0 6px 0; padding:0; font-size: 0px !important; line-height: 0px !important;}
/* Used like this: