CSS Grid: Thoughts on when to use auto-fill

Sara Soueiden has an excellent CSS-Tricks post on Auto-Sizing Columns in CSS Grid: `auto-fill` vs `auto-fit` where she covers the difference between the two. At the end she asks the question of what the design case would be to use auto-fill as, generally, auto-fit seems to be a better solution. Thinking on it, I came up with one design situation where it actually would make sense to use `auto-fill.` As I commented on Sarah’s post:

auto-fill may make sense when building a layout template for dynamic content that is pulled in asynchronously and therefore may not appear in the view all at the same time. So basically when you have dynamic content getting loaded in and you don’t want your grid layout to “shift around” as this content comes in.

For most design situations, auto-fit is a better catch-all solution. But in cases where dynamic content is being loaded into your template asynchronously and where it’s important not for the grid layout to “shift” during this time while the content is being loaded in, auto-fill may be the better solution.

An interesting CSS flexbox issue with Apple’s iOS

I ran into an interesting issue recently with CSS Flexible Box Layout and Apple’s iOS Safari (latest version) – and the issue only occurs on iOS  Safari.

Let’s say you have a parent element with a display: flex;. And let’s say some children elements of this parent element also use display: flex;. These children elements also use vw/vh measurements for min/max width.

And iOS Safari seems to have issues with this – the layout, for some child elements, went bizarre and iOS Safari seemed to add extra margin to the right pushing the main content in.

So far the only workaround I got is to detect (via Modernizr) if it’s an iOS device and change my css from display: flex; to display: inline-block;. It’s not perfect, there’s some things I’d love to figure out better. But for now it does the job.

Addendum: Apparently this is a known (and as yet) unfixed bug: https://bugs.webkit.org/show_bug.cgi?id=136041

CSS classes based on page location

When styling SharePoint sites, it can be very useful to add specific styles to specific “pages” or views. Here’s a bit of jQuery/javascript code to make that possible. It works by grabbing the page location turning it into classes that are added to the body tag.

//use a javascript variable to hold the results of jQuery's "find the body tag" call
var $body = $('body');
//use a variable to capture and store the page url, also removing the 'http(s)://'
var url = window.location.href.replace(/http[s]?:\/\//, '');
//replace any .html, .asp(x), .php or .jsp file extensions
url = url.replace(/\.(htm[l]?|asp[x]?|php|jsp)$/,'');
//replace any '.' with '_' - ie. 'example.com' will become 'example_com'
url = url.replace(/[.]/g, "_");
//Wherever there is a '/', split url into a segment
var segments = url.split('/');
//Take these segments and add them as classes to the body
for (var i = 0; i < segments.length; i++) { $body.addClass(segments[i]); } });

For servers that prefer case sensitivity but allow either case to work (like SharePoint), and where that may cause unwanted headaches you can replace the line where we first define 'var url' with this:

var url = window.location.href.toLowerCase().replace(/http[s]?:\/\//, '');