I’m passionate about image performance optimisation and making images load fast on the web. One of the most interesting areas of exploration is placeholders: what to show when the image hasn’t loaded yet.
During the last days I have come across some loading techniques that use SVG, and I would like to describe them in this post.
I think this is a good example of the is-ought problem in philosophy, transplanted into the world of software development:
A/B testing is a great way of finding out what happens when you introduce a change. But it can’t tell you why.
I used the site earlier in the year, and actually felt my heart rate increase. Never again.
— Paul Robert Lloyd (@paulrobertlloyd) October 24, 2017The problem is that, in a data-driven environment, decisions ultimately come down to whether something works or not. But just because something works, doesn’t mean it’s a good thing.
If I were trying to convince you to buy a product, or use a service, one way I could accomplish that would be to literally put a gun to your head. It would work. Except it’s not exactly a good solution, is it? But if we were to judge by the numbers (100% of people threatened with a gun did what we wanted), it would appear to be the right solution.
console.logis no debugger. It’s great for figuring out what your JavaScript app is up to, but it’s limited to spitting out a minimal amount of information. If your code is complex, you’ll need a proper debugger. That’s why we’ve added a new section to the Firefox Devtools Playground that’s all about debugging. We’ve built four basic lessons that use the Firefox Debugger to examine and repair a simple JavaScript to-do app.
Need a quick way to generate the necessary icons for your site, from the lowly favicon.ico to high resolution icons? I found this really helpful:
No hard decision
With so many platforms and icons, it’s hard to know exactly what you should do. What are the dimensions of favicon.ico? How many Touch icons do I need? RealFaviconGenerator did the reseach and testing for you.
Done in 5 minutes
You spent hours on design, colors, graphics… How much time left for the favicon? Probably not much. But no worries, you only need a few minutes to tackle this task.
Compelling design, a platform at a time
Each platform comes with its own design requirements. You can’t just use the same picture everywhere. RealFaviconGenerator knows this and lets you craft your icons platform per platform.
Instant feedback
How will Android display my icon? How will iOS round my Touch icon? No more guesswork. RealFaviconGenerator instantly shows you how your icons will look like.
Do you want a deep and nerdy dive into the web browser rendering and how the upcoming WebRender rendering engine for Firefox will use the GPU more like games currently do?
[T]here’s another big piece of Servo technology that’s not in Firefox Quantum quite yet, though it’s coming soon. That’s WebRender, which is being added to Firefox as part of the Quantum Render project.
Web forms are complex beasts. There are a lot of field types to remember, each with dozens of attributes. It’s hard to know which is the right way to go, especially when presented with a choice between two seemingly similar options for disallowing a field to be edited:
disabledandreadonly.TL;DR: If you really need it, which you probably don’t,
readonlyis what you want.[…]
The Key Difference
So why do we have two attributes that do the same thing? Unfortunately this is where developers often get confused: the user experience is the same, but the mechanics are quite different.
Fields marked as
readonlyare collected along with all of the normal field values in a form submission (“successful controls” in the spec). The only difference between areadonlyfield and a regular field is the user experience.Fields marked as
disabledare ignored when collecting values from the form. In a traditional form submission, the action page would never receive values for adisabledfield, regardless of whether it has anameattribute.
