Tyler Cipriani: pages tagged design

Cross-Browser JavaScript Scrollbar Detection

Tyler Cipriani — Sat, 12 Jul 2014 00:00:00 +0000

I recently contributed a fix to the bootstrap framework that detects on-screen scrollbars to determine whether or not the body should be padded when a modal window is opened to prevent shifting of background contents. Detecting on-screen scrollbars turned out to be a bit more involved than I initially anticipated.

The tl;dr, semi-näive version:

var hasScrollbar = window.innerWidth > document.documentElement.clientWidth

This works for most browsers. Basically it checks to see if the width of the window element (read: including scrollbars) is greater than the width of the root element of the page (read: without scrollbars). If the width of the page with scrollbars is greater than the width of a page without scrollbars it would stand to reason that the extra width is a scrollbar.

This solution behaves correctly when IE10+ has @-ms-viewport { width: device-width; } set (as it is in the bootstrap framework), which seems to result in scrollbars being auto-hidden. This solution also works for Chrome on the Mac where the scrollbars are automagically hidden.

This certainly seems to function as expected for IE9+; however, IE8 is our newest anchor browser so IE8 should be addressed in any ostensibly “cross-browser” approaches.

window.innerWidth doesn’t exist on IE8. Any workarounds you see utilizing document.documentElement will not include scrollbars in the reported width, so document.docutmentElement will not be an adequate substitute in < IE9.

One thing to check is the scrollHeight. If the scrollHeight of the root element is greater than the clientHeight of the root element, then that root element is going to need to scroll to show the overflowing content:

var hasScrollbar

if (typeof window.innerWidth === 'number')
  hasScrollbar = window.innerWidth > document.documentElement.clientWidth

hasScrollbar = hasScrollbar ||
  document.documentElement.scrollHeight > document.documentElement.clientHeight

Again, this is an oversimplification. The overflow property of the root element can modify the appearance of scrollbars (to create on-screen faux llbars). Of course, once again, IE and modern browsers differ about how they’ve implemented the javascript api for accessing element styles. We can account for this difference and grab the overflow property like this:

var overflowStyle

if (typeof document.documentElement.currentStyle !== 'undefined')
  overflowStyle = document.documentElement.currentStyle.overflow

overflowStyle = overflowStyle || window.getComputedStyle(document.documentElement, '').overflow

The two values of the overflow or overflow-y properties that will create scrollbars are visible and auto provided that the scrollHeight is greater than the clientHeight. A value of scroll for the overflow or overflow-y properties will always cause a scrollbar.

This is, once again, a bit of a simplification.

In quirksmode in IE8 document.documentElement.clientHeight is 0. The root element is document.body. This won’t affect most people reading this, but just to be on the safe side let’s add it into our solution.

The final solution looks like this:

var hasScrollbar = function() {
  // The Modern solution
  if (typeof window.innerWidth === 'number')
    return window.innerWidth > document.documentElement.clientWidth

  // rootElem for quirksmode
  var rootElem = document.documentElement || document.body

  // Check overflow style property on body for fauxscrollbars
  var overflowStyle

  if (typeof rootElem.currentStyle !== 'undefined')
    overflowStyle = rootElem.currentStyle.overflow

  overflowStyle = overflowStyle || window.getComputedStyle(rootElem, '').overflow

    // Also need to check the Y axis overflow
  var overflowYStyle

  if (typeof rootElem.currentStyle !== 'undefined')
    overflowYStyle = rootElem.currentStyle.overflowY

  overflowYStyle = overflowYStyle || window.getComputedStyle(rootElem, '').overflowY

  var contentOverflows = rootElem.scrollHeight > rootElem.clientHeight
  var overflowShown    = /^(visible|auto)$/.test(overflowStyle) || /^(visible|auto)$/.test(overflowYStyle)
  var alwaysShowScroll = overflowStyle === 'scroll' || overflowYStyle === 'scroll'

  return (contentOverflows && overflowShown) || (alwaysShowScroll)
}

If I missed something, or if this solution is a bit of an oversimplification (le sigh), please let me know in the comments.

CSS display inline-block Extra Margin/Space

Tyler Cipriani — Wed, 01 Aug 2012 00:00:00 +0000

TL;DR: The margin isn’t a margin—it’s a space. Try using display: block; float: left; instead.

ALSO: Checkout the amazing list of techniques to combat inline-block space-margins at CSS Tricks

I’ve made a weird discovery about using the inline-block display. I use inline-block elements on my homepage in the Recent Work section.

I noticed that the math for these block elements wasn’t quite adding up—the element width + padding + margin + border should’ve enabled three items on one line; however, the elements were wrapping.

Here’s an example of what I’m talking about:

Even though the margin of each element is set to zero there is seemingly, a margin, between each element.

This problem could be easily solved by removing the display property, floating each gallery item and using a clearfix on the parent:

That solution, however, ignores why that space is being added.

The inline-block display property treats block level elements (e.g. <div>) as an inline element (e.g. <span>), and, just like if you had a line break between two <span> elements, the line-break between the <div>s is creating a space between the <div>s. That extra margin is actually a space—not a margin.

Knowing what is creating an inline-block displayed <div>’s “margin” enables you to create a couple of different solutions.

First, the dumb and breakable solution, you could remove the spaces and line-breaks in your html
Second, directly address the space by setting a negative right margin or negative word-spacing for those elements
Or, Finally, just use display: block; float: left;

Here’s an example of what the second solution would look like:

Website Contrast Ratio in Practice

Tyler Cipriani — Fri, 27 Jul 2012 00:00:00 +0000

While perusing Hacker News I ran across a single-page site called Contrast Rebellion— which I understand has created a bit of controversy.

I think the point espoused by Contrast Rebellion is both well-made and well-taken (despite the host of straw-man style arguments to the contrary); however, I feel that—in most designs—contrast arises fairly organically. If I can’t read my font, or there isn’t enough contrast in my color palate, then I know that the people from whom I solicit opinions are going to mention that before saying anything else.

If only we were all so lucky. ☺

On the topic of color contrast the W3C defines Success Criterion 1.4.3 saying:

Contrast (Minimum): The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: (Level AA)

Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;

Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.

Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.

There is a formula for calculating the contrast of two colors available at the paciello group— they also have a Contrast Analyser that you can download for Mac and Windows.

Alternately, you could skip the download and the hand-cranking of numbers and enter your hex codes into the Luminosity Colour Contrast Ratio Analyser

edit—11/23/2012

My new favorite tool for contrast checking is Lea Verou’s constrast checker

Looking at popular websites contrast

The genesis of this exercise was to review websites I have built and to review some other popular sites so lets do that …

The contrast on this site

It’s pretty good right? The text you’re reading I mean— it’easy to read, contrast-wise anyway.

Text color: #444444
Background color: #f8f8f8
Contrast-ratio: 9.17:1
Analysis: Pretty amazing.

edit—11/23/2012

You’re looking at Text color: #8f8d80 which means that the contrast ratio here has dropped to 3.1:1—which meets the success cirterion for the current text-size of 24px! (which is, admittedly, very large, but whatever, I ain’t scared).

Apple’s nav bar

Apple’s nav bar is a gradient, so this analysis is for the color at the lightest point of the gradient versus the text

Text color: #FFFFFF
Background color (again, at the lightest part of the gradient): #727272
Contrast-ratio: 4.81:1
Analysis: Passed at Level AA for regular text, and pass at Level AAA for large text (18pt or 14pt bold)—Apple’s nav text is SVG (ostensibly for the new retina displays), but it seems to be about 13pt–14pt. A little low-contrast perhaps, but not too drastic.

Google’s account settings bar

Google’s account settings bar

The Google account settings bar has always seemed to be fairly low-contrast to me—let’s test a theory.

Text color: #666666
Background color: #F1F1F1
Contrast-ratio: 5.08:1
Analysis: Passed at Level AA for regular text, and pass at Level AAA for large text (18pt or 14pt bold)—better contrast than Apple; however, the text in this image above is 13px/27px Arial,sans-serif at the default font-weight which is close, but not quite ideal.

Out of curiousity I decided to see what these recommendations would look like for Google in practice—answer: more readable, arguably less aesthetically appealing (see below).