Seems to be Opera Mini at 1.1%, and IE adding up to around 0.6%, so no feature ever gets more than 98%. Also, the browsers that never support anything seem to be mostly desktop ones.
It's because of safari. Same problem used to be with IE where computers/OS were stuck with a specific version. Now the world has moved onto evergreen browsers which are no pinned to OS versions (except for Apple).
Safari is the new IE. From one point of view it's good that Apple still develops his browser and didn't choose to use Chromium like all the others (except Firefox), but from another to this day keeping up with all new web features and standard is not a simple thing. Safari usually is the last to implement modern web features.
> From one point of view it's good that Apple still develops his browser and didn't choose to use Chromium like all the others (except Firefox)
Technically, sure, and I'm all for browser diversity... but i'm kind of tired of this comment because Apple barely put any work or money into webkit while being excessively profitable (and there are good "business" reasons for them not doing this). At this point it's just not excusable for Apple... The way to support browser diversity would be for Apple to fund webkit properly rather than keep it on life support, locking their OS to safari is not the healthy solution for the web, it's the healthy solution for the App store's bottom line.
This is a valid concern but it comes with the caveat that you have to measure actual user-base. For example, in this case that’s the stragglers using IE11 years after it being out of support. That might not be something you care about at all if you don’t support that for other reasons such as security, and if there’s a functional polyfill you might use that so the cost is shifted to the people who don’t upgrade.
Above all, I’d check your own site data: Can I Use has to use public, global data for obvious reasons but you can see fairly different numbers based on what type of site you’re running.
That's pretty common. The "browserslist" tool allows you to specify which features you want to support in terms of the browsers that support them, and the default is "> 0.5%, last 2 versions, Firefox ESR, not dead", supports all browser versions for which at least one of the following is true:
* Have more than 0.5% market share
* Is one of the last two released versions of that browser type
* Is the Firefox LTS release, which presumably doesn't fit the previous two rows but is deemed useful and modern enough to support.
In addition, all "dead" browsers (any version of IE, and a handful of obsolete mobile browsers) are explicitly not supported.
Of course, the browserslist string can be configured as needed, so if you know all users will be using a certain browser (say in a corporate environment) you can configure that fairly easily, and you can even use your own stats for things like the >2% queries.
This string can be translated into a list of browsers, and then that list of browsers can be translated into a set of supported features, which you can use to warn developers if they use unsupported elements, or pass to the bundler so that only the relevant polyfills get included. There are also more advanced techniques (like building a modern and a legacy bundle which can be loaded as needed depending on the browser).
Although a bit off topic, I think it is really interesting to see that a lot of firefox users are on an old version. Firefox supporting <dialog> has around 2.4% users, while firefox not supporting <dialog> because it is old, has around 0.7%
I'm working on a photo-sharing service for groups to replace shared Google Drive folders. Even if a Google Drive is publicly editable uploads count against the uploader's quota unless they select all, right click, change owner to the folder owner which is a bridge too far.
By default anyone can upload to a gallery but they are identified by hard-to-guess UUIDs. This makes passing galleries around SMS or any chat platform very easy but one thing I did not expect is groups forming long-lived persistent galleries. Once you have more than one or two of these they become hard to keep track of.
I am currently working on an app with optional accounts for end users to (1) keep track of multiple galleries (2) allow iPhone live photo uploading (no way to do that within Safari) and (3) allow iPhones to upload pictures with metadata which Apple strips from all Safari uploads.
Ooo, this is really interesting. It sounds like it might scratch an itch I have.
I've wanted a way to say "Hey if you took photos while visiting our makerspace, would you share them back with us somehow?"
Because a visitor's eye is sure to catch things differently than folks who're always around. And many visitors are here during interesting events when there's lots of fun stuff to photograph. If we could get even a fraction of those photos back under a creative commons license, it'd be a great resource for next time we need to make brochures or give talks or whatever.
But I don't know how to make this happen, either from a tech side or from a social side. It needs to be as low-friction as possible, and I'd like to support both folks who shoot on their mobile phones, and those who tote around DSLRs and process when they get home.
I imagine I could hang a poster on the wall that says something like "TAKE A PICTURE OF THIS POSTER and check it out when you get home. Hey, yeah, would you share the photos you took? Go to some.website.example/i3detroit and follow the prompts, eh?", possibly with a QR code that does the typing for them, but I haven't found good software to run behind it.
Nobody Listens to Paula Poundstone (the comedy podcast) had scientist Ralph Harvey on to talk about collecting meteorites in Antarctica in episode 208. He made the point that any rock you find out there lying on top of the ice is probably a meteorite and there are scientists out searching for meteorites that have collected in water channels formed from melting ice in the warmer seasons.
I bet there's a way to reassemble the entire book from it, though. For example "Show me the first paragraph of chapter 4." returns—what seems to be—the actual requested value.
A photo sharing website for high-trust groups. Only the album creator needs an account, then they can share a hard-to-guess link with the group members allowing them to upload photos. Anyone with the link can upload and download. Before this the best solution my groups had found was a shared Google Drive folder.
A band rehearsal recording management website. Uses much of the same code as the previous. Suggests the canonical names for songs based on the file names. Songs can be searched by name, date, or tag (any arbitrary value). This replaces a shared google drive folder with subfolders by recording date (great to find the most recent run through a of songs, bad to find the best run through of any given song)
