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.

HTTP has some strange rules about using stale caches so usually you want to add must-revalidate to your cache-control header. That ensures that the browser must revalidate once the cache goes stale.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ca...

Personally I've opted for "stale only" caching, so everything is served with Cache-Control: max-age=0,must-revalidate and a Last-Modified header and the browser will always make corresponding If-Modified-Since requests. This means significantly more requests per page, even if the responses are mostly 304 Not Modified, but getting to avoid all forms of cache busting makes developing a lot nicer.

If we permit the fairly recent QOI format[0] we can produce a 1x1 transparent pixel in just 23 bytes (14 byte header, 1 byte for QOI_OP_INDEX, 8 byte end marker):

  71 6f 69 66 00 00 00 01 00 00 00 01 04 00 | 14 byte header
  00                                        | QOI_OP_INDEX 
  00 00 00 00 00 00 00 01                   | end marker

Similarly the 103 byte png in the article would be [EDIT] This is incorrect, see below

  71 6f 69 66 00 00 01 00 00 00 01 00 04 00 | 14 byte header
  fe b7 d0 d0                               | QOI_OP_RGB, RGB color, 
  fd fd fd fd c6                            | QOI_OP_RUN for 62+62+62+62+7
  00 00 00 00 00 00 00 01                   | end marker

[0]: https://qoiformat.org/qoi-specification.pdf

[EDIT] I realized that we actually run into one of QOI's drawbacks if we were to encode the 103 byte png in the article, as we actually need to repeat the pixel 65535 times, so we'd have floor(65535/62)=1057 QOI_OP_RUN bytes followed by another QOI_OP_RUN to repeat the last pixel. Here it's pretty clear that the QOI spec missed out on special handling of repeated QOI_OP_RUN operators, as long repetitions could have been handled in far fewer bytes.

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.

It's rather disappointing that websites can't request linear ("correct") alpha compositing in any way. I suppose it's a bit of fingerprinting, but browsers can already be fingerprinted by gamut support[0].

[0]: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/colo...

Valid or not several emoji domains have existed since 2001 https://en.wikipedia.org/wiki/Emoji_domain

There's two arguments I've heard against removing the User-Agent field:

"It helps us understand browser share" and "UA sniffing is faster than feature testing".

I believe both of these could be remedied quite easily with some minor work. Websites shouldn't have access to browser version, cpu architecture, model name etc by default. Websites with legitimate needs for this information can request access from the user and the user would be in charge of determining whether the website has earned the right to this information (useful for eg. sites that want to report "last login at [date] from [browser] on [platform]").

In terms of UA sniffing being faster than feature detection old browsers will continue to send their outdated User-Agent strings. Websites will simply have to opt to use feature detection in actively developed browsers.

In terms of the server determining whether it should serve a "lite" version of the site, there's potential in headers like "Save-Data: on". There's also research into headers that would send incredibly coarse information about the devices capabilities (eg memory available rounded down to nearest 1024^n bytes).

Is there a simple command you can use to read the contents of the script (pipe) before it's sent to sh? Something like:

    curl ... | less-and-maybe-cancel | sh

Semantic HTML sometimes creates layers of nesting that make it impossible to achieve certain css effects without either breaking the semantic markup or adding a lot of "pointless" divs.

In an ideal world HTML would be exclusively semantic content (eg, no div elements) and CSS would be exclusively styling (eg, no contents: property). display: contents; does allow us to get a little closer to that ideal.

I'd love to see PC devkits for this device. Something as simple as a USB 3 device you plug in and place under your monitor. Perhaps it will make its first "PC" appearance in a Google Chromebook?

I can see a lot of eccentric users figuring out interesting ways of integrate many of these gestures into their workflow. Perhaps for navigating in 3d space or switching between workspaces?

[edit] There used to be a developers page which showcased that devkits exists. http://web.archive.org/web/20181110202503/http://atap.google... Showcase video https://www.youtube.com/watch?v=H41A_IWZwZI

Looks like a fun project, all power too you for doing finding something that has kept you excited for an entire year!

How far have you gotten into bootstrapping Serenity OS? Is there a public "roadmap" for what feature you want to work on next?

For the people who are seeing the "Sorry, this content is not available in your region." message the article is available through the Internet Archive Wayback Machine (fetched today, Google's cache was giving me a 404) http://web.archive.org/web/20191004000016/https://ktla.com/2...

It's likely that the Chrome team has plans to eventually assume https by default, given that they've outlined their plans mark http as insecure on connect[0] (rather than on input).

The move would likely have to be coordinated among the browser vendors, but it wouldn't surprise me if Apple decides to lead the charge on this one. All iPhones being https by default would put a massive demand on crappy systems that assume they can mitm users.

0: http://www.chromium.org/Home/chromium-security/marking-http-...

YouTube could likely use Service Workers in modern browsers to determine what bundle to load. If so then our modern browsers could simply send [browser]/[major version] (eg. Google Chrome/78 or perhaps Blink/78) while old browsers continue to send their legacy mess.

An interesting issue is that it's currently impossible to pick the direction of the hue rotation, so if your start and end colors are one opposite sides of the hue circle this tool will go "the long way around". Great for rainbows, not so great if you want to go from orange to purple over red.

I think the scientific calculator could be an example of this principle on its own. It's often far more useful for a mathematician than struggling with the calculator app on a phone or booting up a clunky laptop.

Ultimately I think the principle is flawed. The amount of features isn't an issue but rather whether each and every feature works well and adds to the value of the product. Eg. a scientific calculator would be an awful fit for a todo list application.

It's incredibly unlikely that there's anything left that would let us deduce this man's lineage. Given what we know it's dramatically more likely that the aboriginals are related to him than any other group of people.

What I assume you're asking is if the aboriginals really have any right to claim the Mungo Man's remains. Regardless of family relations they disagree that these remains are "property of the scientific community". A lot of grave robbing has happened in the past in the name of archaeology and while these remains were on display at a museum that's not necessarily the most respectful way to treat these remains.

I know it doesn't help "the 99%", but you can set up your browser to block cookies by default and always block third party cookies.

What I've found is that a small subset of sites don't work without third party cookies (PlayStation store login being the only one I care about) and that a lot of sites don't expect localStorage access to ever fail (eg Codepen, I've had to fix some of my own sites that assumed localStorage access never throws).

The oddest issue I've come across was that LiveJournal would use JavaScript to immediately reload the site if a cookie wasn't detected so I had to disable JavaScript for all of LiveJournal to stop it from getting stuck in a reload loop.

Since USB device ID's cannot be trusted by themselves couldn't some 2FA (eg USB security key) be used to authorize a device for as long as it stays connected?

Once a USB security key has been authorized and is kept on your person rather than constantly attached to your machine it should be impossible to connect a new device and have it trusted by default - and re-connecting an already connected device would de-authorize it.