Unfortunately your HTML is completely out of order, and the images aren’t set to resize fluidly. In fact, it’s likely impossible to achieve more desirable gallery behavior without rewriting your HTML.
The reason your images appear the way the do is because they’re not wrapped in any container that’s interacting manageably with the other elements present on the page. In particular, your
#front-page has an
absolute position that’s giving the visual illusion that that it’s at the top of the document. It’s that same rule that’s forcing the images to ignore the
#front-page. Unsetting it will make your design “break,” but it’s a necessary first step toward achieving what you want.
Here’s a working example of what (I assume) you’re going after. I suspect more complex media queries would yield a better result, but this is a starting point for a more maintainable document:
<img> tag that I was too lazy to add, but the behavior should remain the same for any 1:1 dimensioned image. As an added benefit, setting the
padding of the
<img> instead of the
height will allow you to maintain consistent aspect ratios for images that aren’t 1:1.
Keep it simple. By default elements are
static-ly positioned in the document, and most layout elements are
display: block, meaning they stack on top of one another. This is good. Converting them to
relative has very few drawbacks, and often enhances default behavior (enabling
z-indexing, among other things). If you notice, of the four elements that are direct children of
<footer>), they’re all either
relative. You don’t have to keep those class names, but I recommend keeping almost all elements either
relative, with very few, specific exceptions. Certainly you should keep layout containers
position: absolute or
fixed takes them out of the flow of the document, and this has very unintuitive consequences.
You’ll also notice that where there’s content (the
.mock-image elements), that content is wrapped in containers (
.gallery, respectively). Those containers are there to decrease complexity. Instead of having eight images butting up against the
.splash, we only have one
.gallery. It’s far more manageable to deal with two interacting elements than nine, and this is a simple case. Complexity will only grow from here. Additionally, they’re both set to
width: 100%, meaning as long as they’re positioned
static, they’ll always stack on top of each other, which is exactly the kind of predictable behavior you want.
An added benefit of setting the containers to
width: 100% is that it scales with the window, meaning all percentage-based children (in this case your images) will scale with the window too. Typically you do want it to max out at some point (hence the
.wrap with a
max-width: 1000px), but up until that point, especially for galleries, this is the behavior you want. The
@media query is a bonus: since 12.5% of a mobile screen is tiny (on an iPhone it would be only 40px by 40px), on smaller screen dimensions the media query sets images to 25% instead of 12.5%, resulting in an 80px by 80px image.
Since your thumbnails will only ever be at most 162.5px by 162.5px in this case, you also, as another poster said, want to crop them in an image editing program before you use them, otherwise you’re wasting crazy bandwidth.