The newly-introduced CSS “snap points” properties could make it a whole lot easier to create CSS-only scroll effects (once browser support catches up). This post from Sergey Gospodarets' blog includes demos of snappy scrolling for image galleries and full-page vertical scrolling.
Scroll snapping is used widely for a better separation of the provided content (vertical full height pages) or, for example, to emulate galleries behavior... Can you imagine how easy would be creating such effects using CSS only?
When we make a new component on a website, we’re effectively creating rectangles of different sizes, whether we realise it or not. But what happens if we want to experiment a little? How many different ways are there to make shapes?
In this post I want to roughly outline some of the most common ways to make circles, triangles, and polygons, as well jot down the advantages and disadvantages for these methods so we can experiment with those that might …
The latest episode from HTTP 203, a series of talks about front-end development with Paul Lewis and Jake Archibald, takes a look at progressively loading assets.
Jake makes the comparison between websites and the way that video games will let users download and play the first level instead of forcing them to wait for the all the assets to finish downloading. What does your level one website look like?
I guess the plan is to stop with the "element queries" and start thinking and referring to them as "container queries". We've been following this saga for a while. Element queries have a serious pitfall: infinite loops.
As Responsive Issues Community Group member Mat Marquis puts it:
Well, since the query no longer matches, the new width is no longer applied. Since that new width is never applied, the element query would match again, so the new width would be applied, so the query would no longer match, so the new width wouldn’t be applied—and so on unto infinity. We've achieved a TARDIS-caliber paradox with just a few lines of CSS, and there's no predictable way for the browser to handle it.
Infinite loops would freeze at the offending block. While infinite loops are much more likely to happen with element media queries, this issue has been around since :hover. Therefore, a clear specification would be doubly useful.
But alas, perhaps forcing the queries onto a parent element will help:
... we need to reframe the way we talk about a potential solution. Since a solution can't allow an element to restyle itself, we can build that constraint into the specification: queries attached to an element can only influence the styling of that element's child elements.
I don't think it totally solves the infinite loop problem, but makes it easier to handle somehow?
Ryan Albrecht digs into how efficient browser caching is on Facebook.com. They release code twice a day, breaking cache as they do, so they were curious if that was too often for browser cache to be efficient.
After collecting data, they are seeing 44.6% users getting an empty cache, which they determine effective:
The best practices tell us to use external styles and scripts, include Cache-Control and ETag headers, compress data on the wire, use URLs to expire cached resources, and separate frequently updated resources from long-lived ones. All of these techniques work together on any website, not just one at Facebook scale.
I'm not sure at what level they would be determined not useful though. Seems browser caching is an easy enough thing to implement that if 90% of users got an empty cache it would still be worth it, if just for the speed of that session alone.
I published a written post about this idea of the Server Side Mustard Cut. So if you're into reading and checking out code samples and stuff, that's the place for you. In this video I just walk through all that, explaining myself as we go.
I'll give the same caveat I have everywhere else I've introduced this: this may not be perfect for every site out there. In fact I think normal RWD stuff is generally better, up to …