daxterspeed · HackerTrans

daxterspeed

no profile record

コメント

2 年前議論

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.

4 年前議論

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.

4 年前議論

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.

4 年前議論

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.

4 年前議論

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.

4 年前議論

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.

5 年前議論

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 :/

6 年前議論

Linked tweet is from July 2nd 2019

6 年前議論

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.

6 年前議論

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.

6 年前議論

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

6 年前議論

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.

6 年前議論

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.

6 年前議論

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.

6 年前議論

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.

6 年前議論

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...

7 年前議論

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

7 年前議論

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).

7 年前議論

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

7 年前議論

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.