Add new logo

[tinykite]

What this does

Swaps a version of the LIL logo, with words "Harvard Law School Library Innovation Lab" into the footer.

Notes

I noticed that there was an explicit height set on the footer, which causes an additional scroll region to be added to the page for overflow at smaller viewport sizes. I removed it primarily for accessibility reasons — it felt like an unnecessarily hurdle for site visitors, to constrain the footer to a specific size and forcibly prevent the more natural reflow of the region on text resize — and one we can easily avoid.

That explicit height code does appear to have been required for some CSS math intended to make sure the footer is sticky regardless of the height of the content on the page. I quickly experimented to see if we can simply swap in an alternative approach, using the approach the MDN docs outline for a sticky footer . That added a truly surprising number of weird, unintended visual side effects to the homepage and other pages, so I didn't pursue it further.

It appears the only page that decision might affect is the 404 page (and possibly, if they exist, very very short blog posts?). The page still renders normally, just with a footer at the bottom of the page content rather than affixed to the bottom of the window. That feels like it might not at all be an issue — but want to make sure to note it here in case there might be objections.

Screenshots

Desktop screenshot comparisons: (new logo on the left, old logo on the right):

Tablet screenshot (old logo on the left, new logo on the right):

Mobile screenshot:

How To Test

I've discovered that the least-error prone way to check out a branch locally is to not follow the instructions github provides on each PR. It feels much more consistent to:

• Add a new remote for my fork of capstone-stone, named meaningfully (for example, named tinykite)
• Run git pull tinykite to make sure you have the latest remote branches
• Run git checkout swap-footer-logo to checkout this branch

[tinykite]

Note: this to maintain the required "L" space between the logo and the edge of the container

[rebeccacremona]

which causes an additional scroll region to be added to the page for overflow at smaller viewport sizes

Nice catch! That's subtle!

"No" is a perfectly fine answer: is it feasible to update the specified height to the correct/updated value to keep the sticky footer? I think the current scroll region on mobile is due to a bug (somebody updated the footer, maybe to add the accessibility link? but did not update the heights?). I think pre- your logo swap the margin and height on mobile are supposed to be 334px rather than 325px, and I think that takes care of it? I may be mistaken. And, I didn't try the code in this PR.

We should totally lose this dated approach for achieving a sticky footer during the top-to-bottom redesign! I love how much easier this is to achieve these days!!

I'm just wondering if we can hang onto this for now.

But again, "no" is a perfectly fine answer 🙂!!

[tinykite]

"No" is a perfectly fine answer: is it feasible to update the specified height to the correct/updated value to keep the sticky footer? I think the current scroll region on mobile is due to a bug (somebody updated the footer, maybe to add the accessibility link? but did not update the heights?). I think pre- your logo swap the margin and height on mobile are supposed to be 334px rather than 325px, and I think that takes care of it? I may be mistaken. And, I didn't try the code in this PR.

We should totally lose this dated approach for achieving a sticky footer during the top-to-bottom redesign! I love how much easier this is to achieve these days!!

I'm just wondering if we can hang onto this for now.

But again, "no" is a perfectly fine answer 🙂!!

Thank you for sharing this. In my testing on the develop branch, the fix did not appear to prevent an additional scroll region from being added at viewports ~450px wide or less or, in other cases, at zoom levels of 125% or higher. I understand the positive intent behind your approach — and I think we could try to increase the height of the footer beyond what you proposed to attempt to compensate for situations such as these. I would, however, prefer not to pursue a strategy like that — and instead recommend allowing the container to size itself intrinsically and reflow based on a user's specific needs.