Posts tagged “code”, page 2

Adrian Roselli:

What we know is that native and custom calendar controls are often a problem for users and applied where they are not needed. Before dropping the code on a screen as a matter of habit, consider if it genuinely helps the user or just your workflow.

An open-source community effort to map support for web accessibility features across different Assistive Technologies. It’s still early days, but I hope this flourishes — accessibility interop is a complex topic in dire need of de-mystification.

Heydon Pickering and Andy Bell have created a terrific resource for CSS layout patterns following algorithmic design principles.

We make many of our biggest mistakes as visual designers for the web by insisting on hard coding designs. We break browsers’ layout algorithms by applying fixed positions and dimensions to our content.

Instead, we should be deferential to the underlying algorithms that power CSS, and we should think in terms of algorithms as we extrapolate layouts based on these foundations. We need to be leveraging selector logic, harnessing flow and wrapping behavior, and using calculations to adapt layout to context.

This approach is precisely what I’ve been striving for ever since Jen Simmons’s Intrinsic Web Design talk from last year.

Brent Simmons on SwiftUI:

The future of app-making looks more and more like web development. Declarative. Semantic. Dynamic — adapting to context (interaction styles, accessibility settings, screen size, etc.). Runtime-editable.

Brad Frost:

I was just talking with Dave about the accessibility of moving images on the web, and he said:

hm… I wonder if you could use picture + prefers-reduced-motion?

He then sends the following code:

<picture>
  <source srcset="no-motion.jpg" media="(prefers-reduced-motion: reduce)"></source> 
  <img srcset="animated.gif alt="brick wall"/>
</picture>

Whoa! This is a revelation.

Adrian Roselli:

Once major browsers started supporting <details> & <summary> developers immediately started to play with them to see what sorts of patterns they could enhance or replace. This is a good thing. Experimentation pushes boundaries, improves understanding.

However, we need to be careful of christening this new-to-us interaction as the solution to all our coding struggles.

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.

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.

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.

Philipp Ranzhin:

I was mad that, while I spent my nights learning F#, my daughter started calling everyone around “fathers”. And this guy, instead of getting better at his job, went home to his children. And I wanted to punish him.

Because I do code review for self-identification. I don’t give a toss about the project or the code. I’m simply a madman who’s allowed to hurt people. I’m a psychopath with a licence to kill. An alpha male with a huge stick.

When I realized that, I felt ashamed of myself.

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.

A deep dive into figure accessibility from Scott O’Hara:

A figcaption is meant to provide a caption or summary to a figure, relating it back to the document the figure is contained within, or conveying additional information that may not be directly apparent from reviewing the figure itself.

If an image is given an empty alt, then the figcaption is in effect describing nothing. And that doesn’t make much sense, does it?

Vincent De Oliveira:

Line-height and vertical-align are simple CSS properties. So simple that most of us are convinced to fully understand how they work and how to use them. But it’s not. They really are complex, maybe the hardest ones, as they have a major role in the creation of one of the less-known feature of CSS: inline formatting context.

No kidding, this stuff is complex.

Fighting words from Rachel Andrew, defending the ease of learning HTML and CSS from scratch:

Whether front or backend, many of us without a computer science background are here because of the ease of starting to write HTML and CSS. The magic of seeing our code do stuff on a real live webpage!

Yes! The instantaneous feedback when editing HTML or CSS on a live webpage is, to me, one of the most important characteristics of the web as a medium. Having no layers of abstraction between creative input and final output is one of the web’s miracles.

I might be the “old guard” but if you think I’m incapable of learning React, or another framework, and am defending my way of working because of this, please get over yourself. However, 22 year old me would have looked at those things and run away. If we make it so that you have to understand programming to even start, then we take something open and enabling, and place it back in the hands of those who are already privileged. I have plenty of fight left in me to stand up against that.

I couldn’t agree more. It really was the ease of getting started that got me into web development, and kept me away from native app development. Easy to learn, hard to master is a wonderful trait that the web should fight to keep.

David Heinemeier Hansson thinks that web design quality is at risk of regressing now that it’s increasingly difficult for designers to work directly with code:

The towering demands inherent in certain ways of working with JavaScript are rightfully scaring some designers off from implementing their ideas at all. That’s a travesty.