“Cross-browser compatibility” is a term for a reason; different browsers act differently in both styling and function. Starting out I had in my mind that Internet Explorer was the pain in the neck, but once you get to version 10 that’s not true. Here are a few things I’ve run across where one browser (or OS, in one case) does things differently – annoyingly so – from everyone else.

1. Firefox and ordered lists

We wanted numbered list elements with block-displayed links inside, as the Q of an FAQ. The calculation of 100% width for the block element in FF didn’t allow room for the item numbers – unlike in Safari, Chrome, and IE/Edge – so we had unwanted line breaks. There was no cross-browser-compatible way to reduce the width, say, and still get the clean look we wanted (with expansion carets aligned at the right end of each line). Ultimately we took off the built-in numbers and added our own to the links as pseudoelements. Silly.

2. iOS Safari and click handlers

This one I am surprised I did not learn about earlier. Anything that is not natively clickable (buttons and links) cannot be made clickable (tappable) in Safari on iOS without shenanigans. I read a number of things that talked about it being an event bubbling problem, but attaching the handler directly to the element involved didn’t fix anything; neither did setting cursor: pointer; in the CSS, another trick I read about. Ultimately I had to add onclick="void(0)" as an attribute to the elements I wanted clickable.

3. Windows and font height

This one’s not browser-based – you can use Chrome on different OSes and get different results. Windows and Mac don’t approach font height the same way, and unless the vertical metrics of your font cause the calculations to agree, vertical alignment across browsers may be impossible without JavaScript. The JavaScript in question is adding a class based on the User Agent:

var usrAgt = window.navigator.userAgent;
if (usrAgt.indexOf("Windows") > -1) {
// add a class to style on Windows differently from Mac, Android, iOS
}

Android and iOS seem to vertically align things in agreement with Mac. I was a sad panda to have to do OS sniffing, but boy was it ugly without.

4. Safari and animation trailers

Safari still has a nice CSS animation repainting bug that was supposedly fixed several versions ago – it may leave a little trail of the back edge of your moving element. Setting outline: 1px solid transparent; on the moving element will force repainting to happen on a broad-enough area to fix that.

5. Actually Safari, you’re kind of a pain

Positioning defaults for Safari are apparently different from other browsers; if you absolutely position an item you’d better explicitly relatively position its container. Inline-block items are not necessarily in line with their predecessors on the line, either – I had an inline-block element after a block element (that didn’t fill the width of the container), and the inline-block’s top was aligned to the block’s bottom until I set vertical-align: top; on it. No positioning or alignment changes were necessary to make things show up correctly in other browsers.

Photo by Luzap via Pizabay.

The post Playing odd-browser-out appeared first on rweber.net.

If you embed a Google map into your page via Google’s embed code, you can set a location marker and a zoom level (on the Google Maps side, before you click the “share” button), but other tweaks are reserved for users with API accounts. I was recently in a situation where we simply wanted to disable scroll-to-zoom, because it is super annoying – especially on mobile.

Somewhere online I found the idea to cover the map with a transparent div (you can see through it, but you can’t click through it or “scroll through” it) and add a line of JavaScript to remove that div if it is clicked on. It seemed hacky to me at first but the more I thought about it the more I liked it. We decided to use it and not even to worry about putting a “click to interact”-type note. If someone clicks once without effect they are going to click again, and then what they wanted to do will work.

If you are setting up your maps in a responsive iframe wrapper, the setup is very simple. Just tuck a second div in after the iframe (second so it will be on top), give it the same styling as the iframe, and add a line of JavaScript in the footer of your page.

Here’s the code for the embedded map above (view on pastebin):

The post Improving Embedded Google Maps appeared first on rweber.net.

How many ways are there to place a sidebar alongside the main content of the page, when it appears after the content in the HTML? I’m presuming here that you want a responsive design where the sidebar drops below the content at small sizes. Here are some ways to position content in a horizontal line. Possibilities 2 through 7 are illustrated on a demo page.

While working on this post I found a similar post by Karen Menezes that goes into more detail on certain points.

1. HTML tables. But don’t use these for large-scale layout. Why not? They exist separately on every page, making changing them a larger job, and responsiveness requires quashing the table’s natural (i.e. HTML) state of being. AND there are CSS tables (see below) that do the same thing more cleanly.

2. Absolute positioning. Easy to make responsive in and of itself – just don’t apply it until the screen is wide enough – but essentially impossible to get to play nicely with any elements underneath, unless either A) you use JavaScript, or B) the height of your content and sidebar is fixed, which is hard to imagine happening in a responsive context (and certainly not if you’re using this layout for multiple pages, as with a CMS). In the demo, I have pushed the footer below the content at 1000px-wide screens, which you will see leads to a gap at wider screens.

3. CSS columns. This is something of a faux answer. I really like these for columns of small elements – the widgetized area of this theme uses them – but they require your side-by-side regions be equal width (if you set a width on a div within a columnized wrapper it will be relative to one column), and they may break your content over two columns. It is unlikely this is what you want in the content-sidebar setting. They are good to know about, though I’ve learned they still need browser prefixes.

Edit 2/23: Since this writing I’ve learned about break-inside: avoid;, which you can set on the elements inside the columns to prevent them from breaking across columns (see CSS-Tricks for cross-browser syntax). On the other hand, I’ve also learned that the lovely slider function Flickity doesn’t work in CSS columns.

4. Inline-block display. If you set display: inline-block; on appropriate-width divs they will sit next to each other. By default they will be bottom-aligned, so you’ll probably want vertical-align: top; on both the sidebar and content divs. Note that display: inline; won’t work because width doesn’t apply to inline elements. Caveat: whitespace in markup translates to whitespace onscreen, so if you lack sufficient control over the HTML to eliminate whitespace your elements won’t touch onscreen (and hence can’t have widths summing to 100%). You can try it in the demo: go to your developer tools, turn off the sidebar and main content borders, and add 2% to the width of one of the pieces (currently widths and padding sum to 98%). The sidebar will pop down below the content.

5. Floats. This is a classic solution: float the content left and the sidebar right (or both left; the effect is different when the width sum is less than 100% but the idea is the same). This works well for just the content-sidebar setup, as long as you have a wrapper div with overflow: hidden; set on it to push your footer down. It does not lend itself well to more complicated layouts where taking elements out of the usual document flow introduces the need for a lot of clearfixes and other extra markup to maintain the layout.

6. CSS tables. This is the rule display: table; set on the wrapper and display: table-cell; set on the contents (there is also display: table-row; which could be put on an intermediate wrapper, but isn’t strictly necessary if you have only one row). It will line things up cleanly and is easily styled and made responsive. Every cell in a row will be made the same height and aligned together, which can be either overly rigid or just what you want. I think it makes the front page of this site look neater, and used it elsewhere to easily make a sidebar border into a full-height dividing line between content and sidebar. Caveats: if one side of your content is pushed down, the other will be also, unless you set vertical-align: top; on it – I’ve even seen an embedded Youtube video at the top of one side being interpreted as simply pushing the content down, and the other side pushing itself down to match (though not in all browsers). Also, if you want space between the borders of neighboring cells without space around the outside of the table, you’ll have to set a negative margin on the table wrapper.

7. Flexbox. If you don’t mind having to have a separate backup layout for (older if not all versions of) IE, flexbox is another option. [This simple layout should work in 10 and 11; more complex layouts may have issues even with those.] It will also make the divs equal height by default, though I believe you can change that. The two items will have to be in whole-integer proportions, but it doesn’t have to be that one is a multiple of the other. In the demo I commented out the widths of the divs, set the content to flex: 7; and the sidebar to flex: 3; with the wrapper set to display: flexbox;. I haven’t worked much with flexbox but this use-case has wonderfully simple syntax. CSS-Tricks has an article on mixing generations of flexbox syntax for strongest-possible browser support. I simply threw the most modern code into Autoprefixer and took what it gave me.

In the beautiful future we may also have a template layout module that looks really, really terrific.

The post Side by Side Divs appeared first on rweber.net.

The iframe is still state of the art for embedding content from a number of other webpages, but it is not a naturally responsive object. You can make it responsive, but it takes some effort. I’ve selected some Youtube videos to illustrate.

Doing nothing

Here is a video in standard Youtube syntax:

Since my theme gives iframes a max-width of 100%, it will narrow when you narrow the window, but it won’t change height, adding black bars above and below the content to maintain the aspect ratio of the video itself. This isn’t a big deal when the video is small, but gets more problematic when you want a larger display.

Doing something worse than nothing

Next we can remove the explicitly-set height and width, but that gives you this:

You have to enclose the iframe in a div that adapts its size, but even that takes some effort. Here is the video where the iframe has had its height and width replaced by the tag style="width: 100%;", and is enclosed in a div with style="width: 600px; max-width: 100%; position: relative;".

You can make it wider or narrower by changing the width style, but it won’t get any taller.

Doing enough

The answer is to play the aspect ratio trick and enclose the iframe in two divs. The outer div controls the width and placement; here it’s set with style="width: 100%; max-width: 700px;" (700 for dramatic effect). The inner div accommodates the changing height of the box with style="height: 0; padding-bottom: 56.25%; position:relative;", where the 56.25% comes from original height 315 divided by original width 560. The iframe has its height and width declarations replaced by style="position: absolute; width: 100%; height: 100%; top: 0; left: 0;". Absolute positioning allows it to take up the padding space of its container rather than just the content space (which of course is 0 because of the 0 height). The rest forces it to do so.

All of this styling is inline, so you can see it in the source of this page.

Frames photo by Michael Möller, via Wikimedia Commons.

The post As responsive as iframes get appeared first on rweber.net.

Assorted notes on recent experiences I’ve had with large amounts of blank space in websites. For smaller amounts you can check out my much earlier post on eliminating white space.

1.) On one site I set display: table on the content and sidebar so they would always be the same height. Later we made a page on which the page title was hidden and the first element in the content was an embedded video (wrapped in a couple of divs to allow responsiveness). In Chrome and Firefox that was fine; in Safari and IE the sidebar was pushed down. Safari’s developer tools showed it as padding, but far more than the pixel value listed. I realized the title of the first sidebar widget was lined up with the line of text under the video in all cases, from which I diagnosed that the browser was interpreting that line of text as the first thing in the cell. Setting vertical-align: top on the sidebar cured it. (In the reverse direction, when JavaScript is inactive the sidebar has a large top margin to accommodate the click-to-show menu being always visible, and the main content needs vertical-align: top to be positioned correctly.)

2.) I used CSS columns on a widgetized area on the footer of my page and ended up with a pile of whitespace after the end of the page content. The space wasn’t associated with any particular element. It turned out the order of rendering operations led to an absolutely positioned element being placed far down the page prior to the widgets being converted to columns and hence reducing their reach. The item was a bit of screen-reader-only text for the search widget and hence was a 1×1 pixel box, for all intents and purposes invisible. I found that exact problem on Stack Overflow, which gave me the diagnosis and the fix: set position: relative on the widgets.

3.) A different set of CSS columns had some whitespace above certain elements. This turned out to be another display: table problem rather than a column problem. This time, the display was set on the :before pseudoelement. Underscores uses a float clearing fix involving setting display: table on the :befores of a set of classes, and in this one case it was causing extra whitespace. Changing it to display: block for that particular page fixed it. It is possible there would be a vertical alignment fix for this as well, but its appearance was irregular and hence hard to test with.

The post Mysterious Extraneous Whitespace appeared first on rweber.net.

We’ve done some simple parallax on a couple of websites recently, using jQuery but no additional JavaScript libraries. It takes some hand-tweaking – and you have to know your items in advance – but is also much lighter weight than a plugin.

The simplest version is elements scrolling independently of the page and each other, for decorative effect – so where they are when isn’t so crucial. Each needs to be fixed position and you’ll likely want some horizontal placement in the form of margins or left/right values.

In the JavaScript we’ll manipulate the CSS top value according to the amount we’ve scrolled the page.

Bind a function to the scroll event, then within that function calculate how far the page has been scrolled and use it to compute a new top value for each parallaxed element. In this case, starting 800px from the top, the element will scroll one quarter as fast as the page itself. The initial value for top in the CSS should also be 800px, or the element will jump when the page is first scrolled (if you are starting with very large – i.e. always offscreen – top values they probably don’t need to match, but there’s also no reason not to match them).

By changing the initial value and the multiplier to how much the page has been scrolled, you can get a variety of rates and entry points. Careful of your opacity – with abstract images, one showing through another can be lovely, but with representative images it may just be weird and distracting.

Multiple Items with Coordination

Since using that version of parallax I was called on to create a more complicated version. In this, we’re scrolling many items separately from the page, but certain subsets of them have to align at points along the way. This made tweaking just starting point and rate of scroll completely impractical – it would have taken forever. It also made screen height an important consideration.

Algebra to the rescue: All of the parallax in this post is linear; that is, the calculation of the CSS top value from the amount the page has been scrolled is the equation of a line. We can make our choice of linear equation more deliberate with two points on the line and the following equation:

In this case, x is the amount of scroll and y is the top value. What are the two points? I used the point where the element should touch the bottom of the screen and the point when all of a batch of elements should be in their proper relative positions. You can get some complicated arithmetic, but fortunately JavaScript knows how to do that. I ended up with a helper function:

Since I had a good number of elements calling this function I expected calculating screen height once and then passing it as a function input was more efficient than calling that jQuery function repeatedly. The function above takes the inputs x₁, y₁, x₂, y₂, x, and returns y.

There’s more algebra to determine what the appropriate ending top value should be, dependent of course on number and desired alignment of items. I wanted three rows of items, equally spaced, with margins of 48px above, between, and below. I also wanted them to align that way when the page had been scrolled 1.25 times the screen height – they were “page two” but I needed the breathing room of that extra quarter-screen for the parallax effect.

Why not 3/4 screen height on that third item? Because that gave it far too long to get to its final position, and as a result it took forever to disappear off the top of the screen – long enough to overlap with “page three,” the items lined up when we’d scrolled 2.5 times the screen height. With 7/8 screen height it still lingers, but gets out of the way in time.

The post Parallax without Plugins appeared first on rweber.net.

Just a quick note this week. The JavaScript add-on Flickity is fun, but I don’t always get what I want from it immediately. Here’s the key I’ve deduced: everything Flickity is applied to needs to have accurate size beforehand. I’ve encountered two situations where that was not the case.

The first, explained in my MLA + Flickity post, was when max-width: 100% set on images was causing anything not visible at the beginning of the slideshow to be blank – or, more accurately, zero width.

More recently, I was trying to create a slideshow in a page where most of the content accordion-folds up at mobile size. No applying Flickity with HTML there! If I did, I got one of two outcomes: if I set a height on my images, they all showed up stacked on top of each other. If not, the whole thing was the height of the combined top and bottom padding of the container. I needed to add a distinguishing class, and then set the accordioning code to check whether a panel it had just opened had that class. If so, apply Flickity from the JavaScript at that point. I’ve had no trouble with repeated opening and closing of the accordion.

Edit 9/30: In fact yet a third issue has arisen: Flickity not knowing the height of the slideshow because it’s being applied before the page content is fully loaded. $(document).ready wasn’t enough; I needed $(window).load(function () { /*call Flickity here*/ });
[Edit 12/12/16: .load was deprecated many versions of jQuery ago and finally removed in v3. Try $(window).on("load", function(){});]

Edit 2/23/16: I don’t know the reason for the conflict as of this writing, but I’ve since discovered that Flickity does not get along with CSS columns. With overflow: hidden; set on .flickity-viewport no images show, and with it removed, some images show outside of the viewport.

I hope this helps someone!

You Must Be This Tall to Ride from Eric Mesa via Flickr.

The post Troubleshooting Flickity: one note appeared first on rweber.net.

Ever since I found it probably close to a year ago, I’ve been a big fan of the simple auto-playing slideshow on CSS-Tricks (though perhaps surprisingly I have yet to apply it to a Media Library Assistant-generated WordPress gallery). I’ve tweaked it multiple times to serve different purposes, and thought I’d share two.

The first tweak is more of a wrapper than a modification. It has two features: it loads the slideshow content via AJAX, and it has a small change to the CSS to smooth the beginning of the slideshow.

I wanted to load the slideshow dynamically so I could turn it off entirely on mobile, without a Very Helpful Browser loading the images in case they were used later, slowing down the site. The page itself had the slideshow as a banner header, and it was collapsed at small sizes, so I used its height as the test in the JavaScript. There was a #slideshow div which had a background image set in CSS (via a class JavaScript removed) in case someone’s JavaScript was disabled, and the slideshow images were in a separate file as naked HTML (though the file was .php for no particular reason) to be pulled in with jQuery.load().

As for the CSS, I found that trying to hide all but one image via CSS and have the JavaScript take over from there gave me a herky-jerky first transition. Instead, I hid everything in the CSS and used JavaScript to show the first image just as soon as the images were loaded up.

AJAXified slideshow JavaScript:

This and the JavaScript below need to be wrapped in a $(document).ready(function () { … }); to operate most smoothly.

CSS:

The second tweak makes it a double slideshow: question and answer. In situ it uses WordPress text widgets, the title for the question and the content for its answer, but you can do it with any paired elements. The code below assumes a div with both class and id slideshow-wrapper, holding divs with class slideshow-item, each holding a pair of divs: .question and .answer. There are two different timeframes. The loop moves from pair to pair, and within it the question appears first, then the answer, they stay put for a while for reading, and then both fade away.

The other change to this one is that there’s a lone single animation outside the setInterval loop. Your choices without this separate bit are to have both the question and the answer in view immediately upon loading the page, or to wait with blank space for the entire first interval.

Q&A slideshow JavaScript:

CSS:

Slide projector image by Jean-Jacques Milan via Wikimedia Commons

The post Tweaking the simple auto-playing slideshow appeared first on rweber.net.

Here, at great length, is the sequel to my post on aspect ratio, about vertical positioning. Again, horizontally, everything is easy – declare width: and left: as percentages, and as the screen size changes, they will change in tandem.

For vertical positioning originally (i.e., almost a year ago – but then again, only almost a year ago) I thought it would be easiest to have a div above the one in question that always pushes it down by the correct amount, but you either have to do the aspect ratio business on it or slice your images so the aspect ratio is taken care of that way (hence my post on white space). However, and I’m sure I read this when I was reading about padding but had it fly out of my brain for a while, not only is percent padding calculated from the width of the object, percent margin is too. Setting margin-top to the appropriate percentage will keep your objects in the correct vertical alignment upon resizing.

Just as with padding, though, in practice I didn’t get the predicted margin from my numbers.

If you know the percentage of the padded div’s width that your margin should be, and your padded div is not 100% of its container, you make the same calculation as for padding: (coded margin) = (desired margin)*(width). I have discovered that there is one situation where a div that is not 100% of its container is great: giving some element the same margin to the left and top edges of the screen. Suppose I want a margin that is 5% of the screen width, on an element that is 20% of the screen width. I can do left: 5%; and then calculate a margin-top. If the 20%-wide element is sitting immediately within a container that is the full width of the screen, the calculation simplifies nicely: 5% of the screen is 5% * 100% / 20% of the element (desired margin), but then you have to make the adjustment of multiplying by the width, 20%. You get (coded margin) = 5% * 100% / 20% * 20% = 5%, or (coded margin) = (desired margin).

One advantage to this method, aside from the lack of reassembled background slices, is that if you don’t have something from which to calculate a good margin or padding percentage it’s easy to tweak them and see how they look. I find myself occasionally mocking up pages without the final graphics in hand, so there’s a limit to how much arithmetic I want to do to fit everything together perfectly.

One final note: The reason this got put on the back burner originally is that I had unwittingly swapped out top and margin-top, so my test page was not working as expected. While left and margin-left are interchangeable for absolutely positioned elements, top and margin-top are not at all. Left, right, top, and bottom percentages refer to the height or width of the containing box according to whether they are height or width measurements; margin percentages are always according to the width of the containing box. Hence you will need margin for relative vertical positioning, though you may then need to set top: 0; to make sure your element is positioned relative to the top of the window.

3D pantograph rendering by Joseph Lertola, via Wikimedia Commons.

The post Relative Position appeared first on rweber.net.

So suppose you want to fix the sidebar on a Twenty Fifteen WordPress site, because most of the time it’s going to be short enough to fit entirely on the screen. Maybe it’s not always going to be, or maybe it’s just a little too long so you want to have it scrollable but not tied to the scrolling of the rest of the page. You can do that. Actually, it’s pretty easy if you aren’t concerned with aesthetics: position:fixed; height:100%; overflow:scroll; on the sidebar should cover you. However, Internet Explorer (even 11) will put a nice wide scrollbar down the edge of your sidebar whether or not scrolling is happening or even possible. Here we’ll talk about making that not happen.

The key is a lightweight jQuery plugin called jQuery-slimScroll. It adds a lovely and styleable scrollbar only as necessary, and allows you to avoid overflow:scroll entirely (which is the source of the IE scrollbar).

In your wp-content/themes/fancyfifteen folder you’ll need 4 files: functions.php, style.css, aqa-pretty-scrolling.js, and header.php (the scrolling requires adding a wrapper to the sidebar content, which in Twenty Fifteen is in the header file).

As will now be standard, you can get the code for all of my Twenty Fifteen modifications in one big (but separable) Twenty Fifteen child theme on GitHub.

header.php:

The only thing in header.php that is different is the div with id “pretty-scroll”, just inside the div with id “sidebar”. Everything else is exactly as in Twenty Fifteen, which is why I haven’t bothered making this very large.

functions.php:

This is also very standard: enqueue your parent and child stylesheets, then enqueue jQuery-slimScroll and our JavaScript program that makes use of it. These enqueuings could be combined.

style.css:

This is simple but getting more interesting. The sidebar isn’t along the side until the screen gets sufficiently large, hence the media query. If a visitor has JavaScript turned off, they will get a fixed sidebar with overflow: scroll, trading an ugly scrollbar for a usable sidebar. Otherwise, the code will tack on the hide-scroll class, erasing the scrollbar. The rest of the styles bring the widgets closer together; if you are not accordion-folding them you may not want them closer, but then again if you’re not accordioning them what are the odds you have few enough to want to fix your sidebar?

aqa-pretty-scrolling.js:

Finally, we have the little bit of code that sets everything up and activates jQuery-slimScroll. If the sidebar is fixed (this seemed an easier indicator to use than sizes), the sidebar and pretty-scroll div get overflow:hidden on them, and then slimScroll scrolls pretty-scroll within sidebar. If you have trouble with bits of your sidebar not scrolling with the rest, uncomment the line that sets position: relative on pretty-scroll. For a quick and easy style match, set the scrollbar color to one of your site’s main colors. It will be translucent, so a darker one will likely look better.

There you have it. It took a little while for me to get this set up so there was no scrollbar visible on IE, but now that I have a template I’ll be using this whenever I have a piece of a page that scrolls independently of the rest of the page.

Complicated scroll from Pixabay

The post Conquering scrollbars appeared first on rweber.net.