So by adding ,20% you scale the image down to 20% size, this is particularly handy for people who paste in “retina” screenshots end end up having double sized images. A quick ,50% will make the image look just right.
I do not think it will cause any issues, feel free to submit a PR for (and make sure there is a test) I would just add a \s* to the regex or something…
(This might actually be an alternative, bot not mutually exclusive, help for the @david’s issue too, if the default text would be there without a space)
I thought about this, I have mixed feelings about it. Maybe… @codinghorror what do you think?
We always wanted to allow people to “resize” using preview, this kind of unlocks that feature, but it is going to be a bit before markdown.it has proper source maps to support it.
No, I don’t think adding more noise to every image is a good idea. Ideally srcset would work transparently to the user. Manually resizing images is very advanced user scenario, I can’t even recall a time I needed to do that here in the last 6-12 months?
I believe those long, random filenames are a security measure since uploaded files are accessible by everyone who knows the filename. Those long names are quite hard to guess…
For the record, the 4970_1 was the original filename of the image I dragged/dropped, what is in parenthesizes is the filename GitHub created for storing the image.
I’s say, it worth to use term “random bit length” instead of “algorythm”, because any good hash function will be ok. Usually, 128 bits should be ok, but very big hostings (like “yandex photos”) switched to 512 bits. Also, timestamp can be used to reduce random part (see mongodb algorythm for ObjectID).
Another way to save ~25% is use of base58 encoding or similar (base64 is not url-friendly).
That is correct, base64 encoding of 128 bits GUID should produce 22 chars:
7v26IM9P2kmVepd7ZxuXyQ
You can do ASCII85 encoding to achieve 20 bytes but the characters used are no longer filesystem friendly and that does not seem worth the additonal pain:
So far, only @sam’s image://sha1.png sounds good to me. And I don’t feel any strong love for that. Why do you care how clean or ugly a filename a user doesn’t have to type in themselves is?
All the other ideas seem like more complexity for little gain. The whole idea of using a hash is that identical uploads can easily be optimized for disk space. Changing to some other ID doesn’t achieve that. You could store and save the SHA1 in the background and give out the same GUID for it, but there’s that complexity.
(And using MD5 is bad since there’s a non-zero chance someone will want to post deliberate collisions. But as easily forced SHA1 collisions will probably be upon us soon, too, maybe the complexity would be good?)
feature that allows you to quickly scale images down
)