/* ============================================================================
   Responsive adjustments for phones and tablets.

   This app was built for a desktop browser at a fixed ~1000px and had no viewport
   meta tag, so a phone rendered the page at 980px CSS pixels and scaled the whole
   thing down -- everything legible only by pinch-zooming. header.php now declares
   the viewport, and this file adapts the layout to the widths that follow.

   DELIBERATELY ADDITIVE. Every rule here lives inside a max-width media query, so
   at desktop widths this file contributes nothing and the existing look is
   unchanged by construction rather than by inspection. It is also loaded with
   media="screen", so printed reports (print.css) are untouched.

   Two breakpoints:
     <= 900px  tablets and landscape phones -- unfix the fixed pixel widths, let
               the nav wrap, make wide data tables scroll inside themselves.
     <= 600px  phones -- stack form labels above their fields, enlarge tap
               targets, and stop iOS zooming on input focus.

   Nothing here changes a workflow: every page, field and table is still present
   and still does the same thing. Dense data tables scroll sideways rather than
   being re-flowed into cards, which would be a redesign rather than re-plumbing.
   ============================================================================ */

@media screen and (max-width: 900px) {

	/* Nothing should be able to push the page wider than the screen. */
	img { max-width: 100%; height: auto; }

	/* The masthead is a fixed 100px tall with the logo nudged half the page width
	   to the right, which on a narrow screen puts it off the edge entirely. */
	#header_bar { height: auto; min-height: 0; text-align: center; }
	#header_bar img { position: static; left: auto; top: auto; max-height: 44px; margin: 5px auto; display: block; }

	/* The top nav is a single 30px-tall bar of pipe-separated links. It has to be
	   allowed to wrap onto as many lines as it needs, or the links overlap the
	   content beneath them.
	
	   The link block and the tag-lookup icon are both taken out of float and set
	   inline so the whole nav reflows as one wrapped run. Left floated, the icon
	   dropped onto a line of its own and the bar cost ~40px more height than the
	   links actually need. */
	#topnav { height: auto; overflow: hidden; text-align: left; padding: 2px 8px; line-height: 1.4; }
	#topnav_links, #topnav_links_admin { float: none; margin-top: 0; display: inline; }
	#topnav a { display: inline-block; padding: 4px 3px; }
	a#taglookup { float: none; display: inline-block; vertical-align: middle; height: auto; width: auto; }
	#taglookup img { margin: 0 0 0 6px; }

	#maincontent { padding: 8px 10px; }

	/* Fixed pixel widths that are wider than a phone screen. */
	#mainpagenav { width: auto; max-width: 100%; }
	#mainpagenav ol { margin-left: 20px; }
	#loginform { width: auto; max-width: 100%; }
	.optionlist { width: auto; max-width: 100%; margin-left: 0; }

	/* Percentage indents waste most of a narrow screen. */
	.indent { margin-left: 0; }
	.styled table, #PrintReport table { margin-left: 0; }

	/* The loading overlay is positioned at left:25%/width:50%, which is a sliver
	   on a phone. */
	#isLoading { left: 5%; width: auto; right: 5%; padding: 15px; }

	/* Wide data tables scroll inside their own box instead of stretching the page.
	   nowrap is what forces the table past the container width so there is
	   something to scroll -- without it the columns compress into unreadable
	   slivers. The alternative, re-flowing rows into stacked cards, would change
	   how the reports read and is out of scope here. */
	#Data, .Data, .Summary, .entryTable, #UserListing,
	#PrintReport table, #searchResults table, #tagBox table {
		display: block;
		overflow-x: auto;
		width: 100%;
		max-width: 100%;
		-webkit-overflow-scrolling: touch;
	}
	#Data th, #Data td,
	.Data th, .Data td,
	.Summary th, .Summary td,
	.entryTable th, .entryTable td,
	#UserListing th, #UserListing td,
	#PrintReport table th, #PrintReport table td,
	#searchResults table th, #searchResults table td {
		white-space: nowrap;
	}

	/* The footer floats the login box left and the yard/year box right; side by
	   side they collide well before phone width. */
	#footer #loginInfo, #footer #yardYear {
		float: none;
		display: block;
		margin: 8px auto;
		max-width: 90%;
	}
}

@media screen and (max-width: 600px) {

	/* Labels are a fixed 200px, leaving almost nothing for the field itself on a
	   375px screen. Stack them instead. */
	.styled label,
	.styled fieldset li label {
		display: block;
		width: auto;
		margin-right: 0;
		margin-bottom: 2px;
	}
	.styled fieldset ol { text-align: left; }
	.styled fieldset li { padding: 6px 2px; }
	.styled .indent200 input { margin-left: 0; }
	#loginform label { width: auto; }

	/* Fields fill the line rather than sitting at a size= width chosen for a
	   desktop layout. Buttons and checkboxes keep their natural size. */
	.styled input[type="text"],
	.styled input[type="password"],
	.styled input[type="date"],
	.styled select,
	.styled textarea {
		width: 100%;
		max-width: 100%;
		box-sizing: border-box;
	}

	/* 16px is the threshold below which iOS Safari zooms the page in when a field
	   receives focus, which then leaves the user panned somewhere unexpected.
	   Entry fields inside a data table keep the table's own sizing, since those
	   scroll horizontally anyway. */
	input, select, textarea, button { font-size: 16px; }
	.entryTable input, .entryTable select { font-size: 14px; }

	/* Comfortable tap targets in the nav and on ordinary links in content. */
	#topnav a { padding: 6px 4px; }
	#mainpagenav ol { line-height: 32px; font-size: 18px; }

	h1 { font-size: 1.2em; }
	h2.section { margin-top: 15px; font-size: 1.2em; }
	.graybar { padding: 6px; }
}