All that we did to get this speedup is implement the Serialize trait using one line for the body of the serialize method!

But implementing the trait directly loses the possibility to serialize the structure with the #derive(Serialize) macro.

Instead, you should implement it on wrapper types that act like formatters.

Also for efficiency: format_args! doesn't allocate or even apply the formatting! It only returns Arguments which is a formatter that borrows its arguments.

We can now calculate the remainder rem() and the modulo mod in css.

We will have to wait a bit though for browser support: https://caniuse.com/?search=rem() and https://caniuse.com/?search=mod()

TL;DR nearly no website have valid HTML. We need validators and ways to integrate them in our development processes. It could allow us to tackle more serious challenges—like advancing accessibility—with collective vigor.

Maybe Cypress and test the different pages?
There is an NPM package dedicated to HTML checking https://www.npmjs.com/package/html-validate

because it is possible

A quick guide on makefiles

The author shares its point of view on Shuttle that needs little to nearly 0 configuration to get started.

Zerocal was the first project I deployed on Shuttle. The principle was very simple yet innovative: encode calendar data directly into a URL. [https://endler.dev/2022/zerocal/]

#project #idea improve the UI or make a custom one that calls the API
#project #idea use such API to generate other files. Contacts?

1. Consider mixing kebab-casing with camelCasing: --system-color-controlAccent: blue;
2. Using namespaces can help to avoid collision. In the upper example: system is a namespace.
3. Value typing hints to the use cases of the variable. In the upper example: color. It could be fontSize for example
4. Descriptive names can use 2 patterns: icyBlue which is value-based or accent which is usage-based.
5. Dark mode is simpler with usage-based variables

When to use between value- and usage-base?

Variables with value-based names can be useful for restricting the number of values in your interface. Using numbers can be useful, but sometimes overkill.

Usage-based tend to be useful to describe scopes of capability and utility within the project. The utility of a usage-based name comes in how it guides a developer or designer in its use.

There are often 3 levels of abstractions:

• defining the values
• different property for custom controls such as --color-accentColor
• the CSS variable of use in the component such as --button-color

the company announced today it’s not going ahead with the proposed API.

See the first question heading of https://android-developers.googleblog.com/2023/11/increasing-trust-for-embedded-media.html?m=1

The dedication, the urgency to reach your aims must come from within you.

Ok not bad at all. I still think Rust is not meant for prototyping, but let's give it a try.

Both Figma and Photoshop are for people who believe the web looks like an image.

Semantic HTML is a must. Because there is UX with HTML :D

Another thing our design tools really don’t give a shit about is accessibility. And to be honest, I think most of our industry doesn’t really care about accessibility as well.

Looks also valid to me.

The specialists who helped the architect in making sure it was certified did nothing else than ticking boxes. And this is exactly what most of us do when we think we make our sites accessible. We tick the WCAG boxes.

Use padding, relative line-height and a flow layout instead.

Pour 2023, l’IFN, véritable état des lieux de la forêt française, révèle des forêts de plus en plus affectées par le changement climatique, avec notamment une accélération de la mortalité des arbres, et une multiplication de crises entraînant un ralentissement du puits de carbone des forêts sur la dernière décennie.