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.

In the previous installment of this series, we dynamically generated a gallery with the WordPress plugin Media Library Assistant and applied the JavaScript plugin Flickity to turn the gallery into a nice carousel. Today we’re going to tackle the real reason I wanted to use MLA for that carousel: to coordinate with a set of albums that can be easily navigated by the site visitor, and easily managed by the site owner. It’s remarkably difficult to find gallery plugins that mimic even the simplest of image-storing websites, with different albums that can be accessed from one page, especially if you want anything dynamically generated.

Edit: Since I have made so many additions to Twenty Fifteen, I thought it would be useful to assemble them into a single child theme. You can see the Fancy Fifteen code on GitHub, or look at all posts here tagged fancyfifteen.

As with the carousel, we’re going to put the albumization into Twenty Fifteen, and you can see its final form on my testing site — at least for the time being. The non-JS version is pictured to left.

The final version of the gallery is achieved in six steps, which we’ll split in half. Here’s today’s outline:

1. Use MLA to apply Att. Categories to images, where the categories are the albums. Subcategories are fine, though I’m not sure it’s good to go any deeper than one level down (and my code doesn’t support more than two levels in the hierarchy). We were thinking years for the main categories and individual events for the subcategories.
2. Use WordPress’s get_terms() function to generate a list of all categories, and within each, a list of all subcategories. Make each list a link that applies a query string to the URL when it is clicked.
3. Use the value in the query string to build the appropriate mla_gallery shortcode, and have a default for when the page is first loaded. We wanted the default to be the album for the current year, so even it is dynamic. Execute the shortcode with do_shortcode().

It’s the long half.

Step 1

In the Media -> Att. Categories page, I created Attachment Categories called 2015 Events and 2014 Events, and one or two subcategories for each. I uploaded a bunch of images using Media -> Add New, and then went to Media -> Assistant to assign them categories. Though this would not affect the mechanics of creating the gallery, no image has a parent category directly assigned to it; they each belong to one subcategory, an event.

Step 2

For Steps 2 and 3 I created a special page template that will be applied to a page called Gallery (so you have to make a page named that! If you want to name it something else you can rename page-gallery to page-[slug of your desired page name] and leave the rest alone). I’m going to show them in their entirety rather than parsing them out into the two steps.

Contents of page-gallery.php:

This is just a simplified version of page.php that calls content-gallery.php. I took out various extra bits that would potentially clutter the page.

Contents of content-gallery.php:

I believe I built this off content-page.php, but in the few hours since I did it I’ve already forgotten.

Step 2 is covered in lines 15-46. Here’s what’s going on:
Lines 20-24: Grab all Att. Categories without parents, in descending order (so most recent year will be first). If you have categories beginning with letters, you may wish to remove that attribute.
Lines 25-27: Awkwardly chunk pieces of the (sub)category list item/link HTML into variables.
Line 29: Start an unordered list.
Lines 30-43: Loop through the collection of parent categories.
– 31-32: Grab the parent’s slug and create its list item. If you don’t plan to AJAXify this you can delete the definition of $linkslug above and remove it and one of the $slugs from each list item construction.
– 33-34: Open a nested unordered list and start it with the “All” item. You don’t have to include this, but I thought it was a bit of useful redundancy, in case someone wanted to see the whole year and didn’t realize the year itself was a link.
– 35-40: Essentially repeat 20-24 and 31-32 (within a loop like 30-43) for each parent category. The only significant change is telling get_terms a different parent: the current parent category instead of “none”.
– 41-42 and into 44: Close up all the lists.

You’ll notice the page content appears after this menu. If you don’t intend to AJAXify it, you may wish to put it above the menu, perhaps even outside of .filtration-gallery.

Step 3

This is covered in lines 52-66. You only need #current-album-wrapper if you plan to use AJAX.
Lines 55-59: Is there a valid category slug in the URL, after ?album=? If so, extract the pretty name of that category and display it as a header, and then build an MLA gallery shortcode to display the photos in that category. Of course you can change the other mla_gallery options or add some.
Lines 60-62: Oh, there’s not a valid slug? Run a default MLA gallery shortcode. This is where you would make major changes to accommodate your particular album organization scheme.

Bonus Step

Just kidding, we’re not done yet.

I added this functionality to my Flickity child theme, but we’ll to make its own child theme here, plus style it. I already put headers on the preceding two files to match.

In a folder called albumized-twenty-fifteen, place the two files above, plus two more. I left their embed boxes short because this is already a really long post.

One called functions.php, which so far has no purpose other than enqueuing stylesheets:

And one called style.css, which is kind of long despite the fact that I haven’t tweaked it as thoroughly as I would for a client:

Hey, we made it! Next time we’ll make this quicker and more compact, and appropriately the post should also be shorter.

The post Gilding the Gallery 2: MLA + front-end filtration appeared first on rweber.net.

Edit: Since I have made so many additions to Twenty Fifteen, I thought it would be useful to assemble them into a single child theme. You can see the Fancy Fifteen code on GitHub, or look at all posts here tagged fancyfifteen.

The goal here: a front page carousel that could be easily updated, with just half a dozen or so selections from the most recent images added to the site. The pictures would be human-chosen. The carousel needed to be responsive and easy to navigate (for everyone; i.e., accessible), and ideally the whole shebang could coordinate with a filterable photo gallery to be created for the same site.

Enter Media Library Assistant. There are two functions of MLA that are important for this use: the addition of taxonomies to media library items directly, and the expansion of WordPress’s gallery shortcode into mla-gallery, with dynamic selection of media items by taxonomy, user-defined templates (as in direct control of the gallery’s HTML structure), and many other settings.

I figured I could apply a nice jQuery carousel to an MLA gallery of the correct form, and after looking around, Flickity seemed like the best candidate (with the implicit recommendation of CSS-Tricks). It is responsive, accessible, well-adapted to mouse/trackpad, keyboard, and touch, and styleable from the theme’s CSS file. After one significant (but easily remedied) hiccup we were in business!

Here’s how to set it up. There are some places where I made arbitrary decisions (such as downloading flickity.css but using a CDN for the .js file), but it should be easy to figure out how to make different ones.

For specificity, we’ll make a child theme to add this functionality to Twenty Fifteen. For now you can see this on my WordPress test site but there is no guarantee that will continue to be true indefinitely.

style.css:

Many themes set max-width: 100% on images for responsiveness purposes; it keeps them from exploding out of their housings when the browser gets smaller. However, you have to override it here or the images you can’t originally see may collapse to width 0. That was the hiccup I referred to – why is there blank white space when I click through the carousel?!? The last section highlights the gallery if you tab to it so you know you’ve tabbed to it; it’s straight off the Flickity website. I set a height of 200px; you can let it be determined by the images by removing that line of CSS and the line setGallerySize: false in carousel.js, below.

carousel.js:

functions.php:

Just put flickity.css, carousel.js, functions.php, and style.css (for your child theme) all into a folder called twenty-fifteen-flickity, zip it up, and upload it.

In Settings -> Media Library Assistant -> MLA Gallery (the middle tab), scroll to the bottom and create a template called carousel. Fill in the following boxes:
Open: <div id='carousel-gallery' class='carousel-no-js'>
Item: <div class='carousel-item'>
[+link+]
</div>
Close: </div>

In Media -> Assistant, tag all images for the slideshow with “featured” (or something else, and then change “featured” in the shortcode below).
Where you want the carousel, place the shortcode
[mla_gallery attachment_tag=featured mla_style="none" mla_markup="carousel" size=medium link=full]

Some notes:
– Most everything is adjustable from the CSS file, the MLA shortcode options, or the Flickity options.
– You’ll have to add appropriate styling for responsiveness, but no differently from usual.
– For graceful degradation the images start with the class carousel-no-js and carousel.js replaces that with carousel-js-on; I haven’t styled .carousel-no-js at all and wouldn’t count this as finished without doing so, but how to style it is a matter of taste.
– I threw a lightbox plugin onto the test site as well (Responsive Lightbox by dfactory) and it works without a squawk.

The post Gilding the Gallery: MLA + Flickity appeared first on rweber.net.

Horizontally there is no problem. Declare width: and left: as percentages, which will be relative to the screen size, and as it changes, they will change in tandem. Vertically there is a little more work to be done.

There is a well-established way to preserve aspect ratio via padding, which is calculated (when set as a percentage) relative to the width of the object rather than the width of the screen. The most complete tutorial I found on this was by Chris Wainwright, and I recommend it.

I had to make some changes, though. I didn’t have a wrapper div within which my padded div was 100% of the width; I set a percentage-of-screen width on my padded div directly. When I set padding according to my desired aspect ratio, the resulting div was enormously tall.

An example using numbers I have at hand: suppose the design has a segment that is 459 x 1358px, which has a 1:2.96 aspect ratio. Setting the padding to 296% produces an aspect ratio of 1:12.33. What is 12.33? Why, it’s 296/24, and 24% just happens to be the amount of screen width the segment was set to take up.

You can solve this with a tiny bit of algebra: if (actual padding) = (coded padding)/(width), then (coded padding) = (actual padding)*(width). In the latter equation you drop your desired aspect ratio into the “actual padding” slot. In this case, to get an aspect ratio of 1:2.96 on my 24% wide div, I have to set padding of 2.96*.24 = .7104 or 71.04%.

I reiterate that this is percent width relative to the container. For a single div you can avoid the arithmetic (and arguably make your code more readable, since the padding percentage will be the aspect ratio) by wrapping the padded div in a div of the desired width and letting the padded div have width 100%. This is, of course, how it’s done in the tutorials, but I haven’t seen one that explains why or warns against leaving the wrapper out.

However, if you have a vertically sliced background image to reconstitute I have found it’s actually better to set width on the padded divs directly, but with all padded divs inside a shared wrapper that they completely fill. The reason is that in this setting the padding on each individual div will be the aspect ratio of the entire unsliced image.

Here’s the algebra:
Assume the width of the whole image is 1, which makes the slice’s width X both raw and as a percentage. The slice and the entire image have height Y, so their aspect ratios are Y/X and Y/1. To get the coded padding we multiply the actual padding, Y/X by the percent width, which is X, resulting in Y (i.e., Y/1).

We can assume the unsliced width is 1 because to make it so is a unit of measurement conversion, which plays well with others. For example, if the actual width is 5000, and X and Y are raw measurements (X no longer serving as a percentage), the aspect ratio of the slice is still Y/X, the aspect ratio of the whole image is Y/5000, and the width of the image is X/5000. Multiplying actual padding (aspect ratio) by width then gives Y/X * X/5000 = Y/5000, the aspect ratio of the whole.

Anyway, algebra aside, this does save you some arithmetic, because the padding on the individual divs is all calculated with one division. The second part of this involves unraveling the quirks of percent margin, though this sentence should not be taken as a promise of its quick appearance.

The post Aspect Ratio appeared first on rweber.net.

All of the following require setting a position attribute. Fixed, relative, absolute – anything but the default static.

At a small screen width I just use percentages for width.

width: 60%;
left: 20%; // that is, half of 100-60

will center an image or the div containing it. If you apply it to the image and the image is smaller than 60% of the current screen width it will expand to fit. If you apply it to a containing div and leave the image unstyled, then the image will appear in its natural size, extending outside the div if necessary. Styling the image with width: 100%; makes it fill the div exactly, regardless of its natural size.

For larger screens width by percentage isn’t as useful for images. I do not remember where I found this trick, but you can center a smaller image or div on a wide page with percentages and negative margins.

top: 50%;
left: 50%;

will center the top left corner of the image or div. Suppose the element is 250px wide and 400px tall. Add margins to shift the element so its center is centered.

margin-top: -200px;
margin-left: -125px;

I used this technique to make sure the background image was centered regardless of browser window width, and, with appropriate margin adjustments, to stack a second div below the one in the center of the screen.

The post Images, centering, and responsiveness appeared first on rweber.net.