daxterspeed

The issue is that QR's alphanumeric segments are uppercase only, and while browsers will automatically lowercase the protocol and domain name, you'll have to either have all your paths be uppercase or automatically lowercase paths. On top of that when someone scans the code it will likely be presented with an uppercase URL (if it doesn't automatically open in a browser) and that should alert anyone that doesn't already know that uppercase domains are equivalent to lowercase domains.

Ideally QR codes would have had a segment to encode URIs more efficiently (73-82 characters depending on how the implementation decided to handle the "unreserved marks"), but that ship has long sailed.

A significant downside to the <picture> element, and alternative image formats in general, is that when most users wanna download the image they expect an image format they already know how to work with. To most users an .avif or .webp are an annoyance because they reasonable expect most of their tools to be unable to open these.

It's disappointing that browser vendors haven't picked up on this and offered a "Save as PNG/JPEG/GIF" option when downloading images, but for now if it seems reasonable that if any user would want to download an image you're displaying then you should probably stick to the legacy formats.

It's definitely worth mentioning JSONP - which worked by setting up a function in the global scope and using JavaScript inserting a new script tag that would hopefully call that function with the data. It was the ultimate trust exercise, as your target data vendor could execute any JavaScript it desired. Despite the name, JSONP could of course contain non-json data, like functions or class definitions.

It's definitely cheap to execute, the problem lies in the network overhead. With sub-resources (css, js, images) you can go from 1 request per page to 10 or 100 which is still negligible for fast connections (10 mbps+, http2) and servers with low request overhead - but the worst case scenario is high latency http1 connections where each request really matters.

However if you are serving clients with highly restricted bandwidth you're probably going to want extremely cacheable resources (public, immutable) and perhaps even a completely different site architecture.

The whole brands aspect has really confused me. If you search for "nature" on unsplash right now the first result is a picture of a person prominently holding a product in the most blatant product placement way possible. So far they're basically working as banner ads, no sensible user would ever want to use a sponsored photo for their work.

I'm more afraid of how they'll modify their existing products to manipulate users into paying for "Premium" Getty stock photos over the free Unsplash ones :/

Linked tweet is from July 2nd 2019

I think the parent argued that both serve a purpose. When you're dealing with a large selection of fonts a small pangram is more useful to help you narrow the list down - until it becomes small enough that you can switch to one of these font proofs to evaluate the final few fonts.

Websites like Google Fonts should absolutely use one of these font proofs for the dedicated font pages - or when simply comparing two fonts, but use a shorter pangram when comparing several fonts at once.

These visualization are very satisfying and provide some wonderful insight.

A few minor bugs: - The gray area is always too small, so there's plenty of area of the canvas that never gets cleared. - Perhaps this is intended, or maybe it's caused by by the demo running at 144Hz, but the drone is always swept away by the wind for me. It doesn't even stand a chance to fight it.

I'm really hoping another company is able to pick up the Cliqz search index. Having an option to Google and Bing is important.

Everything only searching file names might seem like a dealbreaker to some people but it actually provides a great incentive to give your files useful descriptive names.

I got Everything in a hotkey so it also doubles as an application launcher. It really is quite elegant.

These tests could be on a website of their own. I'd love to see how the results change with time and how competing implementations compare in terms of behavior (not necessarily performance), V8 especially has changed a lot but it wouldn't surprise me if it still ran into issues.

It seems to me like VR could get some great usage of vector assets. Having icons and especially text render perfectly regardless of how close you get seems ideal.

I'm not a huge fan of template e-mails, if you're just gonna do an automatic response then make that obvious from the start.

However I do see how these can be useful as a reference point, I especially like the templates/examples that have a little story behind them. Saying no "like a pro" isn't about the exact phrasing, but knowing that you can and often should say no.