Posts tagged “web”, page 4

Tobias Ahlin:

On the surface it seems fairly easy to create a masonry layout with flexbox; all you need to do is set flex-flow to column wrap` and voilà, you have a masonry layout. Sort of. The problem with this approach is that it produces a grid with a seemingly shuffled and obscure order. Items will be (unbeknownst to the user) rendered from top to bottom and someone parsing the grid from left to right will read the boxes in a somewhat arbitrary order, for example 1, 3, 6, 2, 4, 7, 8, 5, and so on so forth.

Flexbox has no easy way of rendering items with a column layout while using a row order, but we can build a masonry layout with CSS only—no JavaScript needed—by using :nth-child() and the order property.

This is very clever — an actually helpful use of order that helps visual order more accurately follow source order.

But there’s a catch: it requires a fixed height for the container — and it needs to be a magic number that’s taller than the tallest column. That unfortunately makes it not super resilient to content changes, limiting its usefulness.

Richard Rutter:

There is more to setting hyphenation than just turning on the hyphens. The CSS Text Module Level 4 has introduced the same kind of hyphenation controls provided in layout software (eg. InDesign) and some word processors (including Word). These controls provide different ways to define how much hyphenation occurs through your text.

This is great news. I’ve always avoided CSS hyphenation because of how aggressive the algorithms are. Using these new properties in concert with @supports we can get well-controlled hyphenation as a progressive enhancement while avoiding the half-baked hyper-hyphenated middle ground we’ve had so far.

Mat Marquis:

It could seem like an enticing option for our users, at first glance: an enhanced, fully-featured website, on the one hand, a fully accessible alternative experience on the other. That unravels with even the slightest examination, though: if the fully-featured website isn’t accessible, the accessible website won’t be fully featured. By choosing to have the “accessible experience” deviate from the “real website,” we end up drawing a sharper line between those two definitions, and we nudge the “accessible experience” closer to an afterthought—limited and frustratingly out-of-sync with the “real” website, like so many dedicated mobile sites quickly became.

Jeremy Keith:

Where it gets interesting is when a technology that’s designed for developer convenience is made out of the very materials being delivered to users. For example, a CSS framework like Bootstrap is made of CSS. That’s different to a tool like Sass which outputs CSS. Whether or not a developer chooses to use Sass is irrelevant to the user—the final output will be CSS either way. But if a developer chooses to use a CSS framework, that decision has a direct impact on the user experience. The user must download the framework in order for the developer to get the benefit.

So whereas Sass sits at the back of the front end—where I don’t care what you use—Bootstrap sits at the front of the front end. For tools like that, I don’t think saying “use whatever works for you” is good enough. It’s got to be weighed against the cost to the user.

An interesting comparison from Danny Moerkerke:

Remember when document.querySelector first got wide browser support and started to end jQuery’s ubiquity? It finally gave us a way to do natively what jQuery had been providing for years: easy selection of DOM elements. I believe the same is about to happen to frontend frameworks like Angular and React.

Andy Bell:

The majority of the web community are probably building—y’know—modest websites. There’s a reason why WordPress powers 33.5% of the web: because most of the web isn’t big applications or design systems—it’s straight-up websites. We would all do well to remember that.

Kevin Marks:

There’s a widespread movement in design circles to reduce the contrast between text and background, making type harder to read. Apple is guilty. Google is, too. So is Twitter.

My plea to designers and software engineers: Ignore the fads and go back to the typographic principles of print — keep your type black, and vary weight and font instead of grayness. You’ll be making things better for people who read on smaller, dimmer screens, even if their eyes aren’t aging like mine. It may not be trendy, but it’s time to consider who is being left out by the web’s aesthetic.

Dave Rupert thinks version number bumps would be a good move for HTML and CSS, marketing-wise. I agree!

A single number bump replaces a mountain of marketing. Every discerning technologist knows it only makes sense to invest in technologies that are moving forward. To invest in a stagnant technology would be a dereliction of duty.

I think this has effected web technologies deeply. HTML5 was released in 2008 and its handful of new elements and APIs was a boom for the language. Even Steve Jobs advocated for it over Flash. Web Standards had won, Firefox and Webkit were our champions. “We need to upgrade to HTML5” was a blanket excuse for auditing your website and cleaning up your codebase.

Jeremy Wagner:

It’s easy to slap something up on a web server, but it’s quite another to be a steward of it in a way that makes the web a better place. That starts with redefining our productivity with the goal of serving the interests of others instead of our own.

Casper Beyer:

Research has shown that modals that cannot be closed have the highest conversion rates.

Putting this on Medium: *chef’s kiss*

Great writing on this well-researched story, by Jason Hoffman:

At first glance, the bug appeared to be fairly routine, most likely a small problem somewhere in the website’s code or a strange coincidence. After just a few hours though, it became clear that the stakes for this one particular bug were far graver than anyone could have anticipated. If Firefox were to release this version of their browser as-is, they risked breaking an unknown, but still predictably rather large number of websites, all at once. Why that is has everything to do with the way MooTools was built, where it drew influence from, and the moment in time it was released. So to really understand the problem, we’ll have to go all the way back to the beginning.

Jeremy Keith:

It’s relatively easy to write and speak about new technologies. You’re excited about them, and there’s probably an eager audience who can learn from what you have to say.

It’s trickier to write something insightful about a tried and trusted (perhaps even boring) technology that’s been around for a while. You could maybe write little tips and tricks, but I bet your inner critic would tell you that nobody’s interested in hearing about that old tech. It’s boring.

The result is that what’s being written about is not a reflection of what’s being widely used.

Bridget Stewart:

How many features are built-in to a framework or library that your app doesn’t need yet (and may never need)? How much can you hold back from the package you send to the web? How dependent are these modules and bits of code on one another? To me, that sounds like a lot of analysis up front to pick apart a tool before I even write a single line of code to be truly productive. It is also the antithesis of Progressive Enhancement, which strives to start with the bare minimum necessary to make it work and build up from there.

Prompted by an excellent Kurzgesagt video on the subject, Jason Kottke reflects on what to do with old blog posts that don’t quite pass muster anymore:

But so anyway, I don’t know what to do about those old problematic posts. Tim Berners-Lee’s idea that cool URIs don’t change is almost part of my DNA at this point, so deleting them seems wrong. Approximately no one ever reads any post on this site that’s more than a few years old, but is that an argument for or against deleting them? (If a tree falls in the woods, etc…) Should I delete but leave a note they were deleted? Should I leave the original posts but append updates citing my current displeasure? Or like Mister Rogers used to do, should I rewrite the posts to bring them more into line with my current thinking? Is the kottke.org archive trapped in amber, a record of what I’ve written when I wrote it, or is it a living, breathing thing that thrives on activity? Is it more like a book or a performance?

This is an issue I struggle with, too. I no longer agree with some of my older film reviews, and some even contain mistakes. Should I delete them? Do I need to rewatch the films and write new reviews?

I might implement something I’ve seen in other blogs: a notice on old posts saying something to the effect of “this post is old, I might not agree with it anymore.”

Tyler Sticka:

When everyone finished translating articles to semantic, accessible HTML, I let them in on a secret: This was still design. While we hadn’t yet incorporated color, typography or composition, we had made decisions about prioritization, hierarchy, information architecture and user experience. And those decisions would be the most resilient… accessible to virtually any visitor, not just those blessed few with perfect vision, hearing and mobility. The web was the only medium that offered designers the chance to craft one work for such a varied landscape with so few gatekeepers.

Andy Bell suggests using CSS Custom Properties together with Heydon Pickering’s lobotomized owl selector to manage vertical spacing. It’s an elegant solution that works well with the cascade:

.flow {
  --flow-space: 1em;
}  

.flow > * + * { 
  margin-top: var(--flow-space);
}

I’ve been experimenting with old-school margin collapsing for vertical rhythm this past year, in Cobalt. I’m a proponent of spacing being an inherent property that exists by default instead of something that has to be explicitly added. But margin collapsing doesn’t really play well with Grid layout (until we get something like margin-trim), so I might give this method a try.