Not gone, but that's the direction we're heading (hopefully).
> it may currently still be best to use a framework or library to present these, or to use a custom input of your own. Another option is to use separate date and time inputs, each of which is more widely supported than datetime-local
I literally waited years for this. This year I opted to change a backend date input from datetime-local to date and time input input fields, after waiting too long for browser support. The datetime-local field got added 2014, "browsers will support it soon"...
Which browser does not support it (if we can exclude IE 11)? And if some obscure browser does not support, it will just fallback to input[type=text], so no big deal. I'm really looking forward to get rid of all these JS implementations which can't properly handle keyboard / touch / screenreader / whatever comes.
That's because by design <input> does not let you configure a timezone (EDIT: nor a datetime format), and it's always somehow badly detected/misconfigured on a small subset of your users. Later you find out the user thought they were entering a DD/MM/YYYY date, while the browser decided it's getting MM/DD/YYYY, and hijinks ensue. It's easy to ensure the correct timezone on js pickers.
According to MDN[0], timezones are not supported. But easy to add on top of the native datetime-local field. So it looks like that timezone detection of yours is all you need: let it fill a hidden field, instead of replacing everyting with your self-built thing (which probably lacks aria controls, keyboard controls, breaks tabbing, looks terrible on dark-mode and so on).
> ...the date/time and time zone values would be submitted to the server as separate data points, and then you'd need to store them appropriately in the database on the server-side.
Which, IMO is the correct way, also for a datetime-picker, anyway.
I'd much rather use the provided <input> types, like a normal UI program. That's less Kb sent, and hopefully better integration. I tried this, it's just that locale autodetection simply wasn't reliable enough.
For example, one customer had all their computers default to MM/DD/YYYY despite locale using DD/MM/YYYY (and all other non-browser programs using the right format). So I ended up switching to js pickers thanks to the bad experiences.
>instead of replacing everyting with your self-built thing
There are about a million different js datetime pickers which provide the entire thing in a package, rather than me writing it all by hand.
> I tried this, it's just locale autodetection simply wasn't reliable enough.
Which was one reason they removed it from the spec. And why datetime-local does not have it.
And why adding a simple <input type=hidden name=tz value=""/> can be filled by your JavaScript that detects the timezone. Or, if you need, a <select> or something else.
This helps with the timezone, but doesn't solve the format problem. If the browser decides 1/2/XXXX is 2nd Jan and not 1st Feb because locale detection went haywire, I can't know what the user really meant.
Besides, once I need to write js it's just as easy to pull a datetime picker and use that...
I'd like to use <input>, but they need to make it work and also allow a reasonable way of overriding the autodetection.
Did you even look at the spec for "datetime-local"?
> One thing to note is that the displayed date and time formats differ from the actual value; the displayed date and time are formatted according to the user's locale as reported by their operating system, whereas the date/time value is always formatted YYYY-MM-DDThh:mm. When the above value submitted to the server, for example, it will look like partydate=2017-06-01T08:30.
I know how it's transmitted, and that's totally fine.
The problem is on the other end: The guarantee ("formatted according to the user's locale") too often doesn't work, the displayed date and time format somehow may not match the locale as reported by the OS.
In the previous example, users in EU countries can get a MM/dd/YYYY input despite the locale being set right. The user can enter a date thinking it's DD/MM/YYYY (some users preferred fast input with the keyboard), so what they send to the server is really YYYY-DD-MM despite the "guarantee" because the browser somehow doesn't understand how the date should be formatted on the client.
Otherwise it was just extremely annoying to the users and to me, so it was the last straw for using <input> that way. I could hack it, but what's the point of maintaining a hack when there are many packages out there just implementing a picker?
How is that different from most or any JS frameworks with regards to DD/MM/YYY formatting?
How can a user filling in a date, confuse "12 juni 2018" (juni Dutch locale for "June") with the 06-12-2018? And if so, how does any JS based datepicker solve this instead?
It's my fault. I mentioned timezones but the even bigger problem is client side formatting, so when I described that it was confusing two things.
Imagine your screenshot instead of '12 - 06 - 2018' had displayed '06 - 12 - 2018'. For the same date (12th June 2018). Because locale detection failed it fellback to the US locale**. And it set up the input so that '06-13-2018' is legal but '13-06-2018' is not. Does my example make sense now?
In a JS datepicker, I could force DD/MM/YYYY (or whatever according to the user record) and that's it. Timezones are also a problem, but that's indeed easier to work around. The issue is that the specification by design does not allow forcing a format, despite me knowing exactly what the user wants.
It may sound fantastical that locale detection can fail that badly, but it did, and nothing simple I did could fix that - I don't exactly have access to set up the client machines, but I could reproduce on one of mine. Note that matheusmoreira here in this thread also has this problem, so it's apparently not impossibly rare.
Old Edge for example, seemed to prefer autodetection via the keyboard locale*** over the region date settings, and that was a product by the OS maker! (Also, their date picker was trash by modern standards).
** I guess all browser makers are American companies so US is default? Or perhaps it went to the US locale by keyboard like old Edge, since just about everyone here uses the English (US) locale for English.
*** Setting up English (UK) fixed the date display. Except that comes with other downsides.
We must be miscommunicating again or I'm being dimmer than usual, because when I read the spec and the MDN page I don't see any way of forcing the display format (pattern attribute exists only for browsers which do not understand the picker).
I see 'browser will autodetect the right display format for the locale and give back YYYY-MM-DD' in so many words, which would be nice if it worked. The problem being it not actually working and not allowing me any good way to override it when it doesn't work.
To be sure I wasn't imagining things, I decided to test again, with the simplest example I could find on the net (I forget w3schools still exists).
Note the date format on the picker. I can assure the test system used had LANG, LC_TIME, LC_ALL, timezone, etc. all set to a non-American locale. I used Chromium to make sure this is on a typical(ish) browser. Still the MM/dd/YYYY format is used.
> the user thought they were entering a DD/MM/YYYY date, while the browser decided it's getting MM/DD/YYYY
Happens to me every week. Sometimes nearly every day. It is infuriating. Why can't they use YYYY-MM-DD? When are we humans gonna stop having these problems?
It is anecdotal but we had a JPEG at ~115KB and after encoding to AVIF the quality remained the same but the file size dropped to ~15KB.
Having looked at caniuse.com it seems that Chrome, Opera and (only just now by default) Firefox support it. With Edge, Safari, and the majority of mobile browsers still to catch up.
What's extra sad about that is WebKit supports AVIF images, but Safari doesn't because it hands image decoding off to the OS where it isn't supported. Works in Gnome's WebKitGTK though.
I did a small trial of AVIF (using the AVIF plugin for pillow) with high quality photographs and got much worse results than WEBP. (Much bigger file that looked much worse.)
It could be my encoder sucks, could be I didn’t pick the right settings (command line opts look like the engineer’s console on the original 747). Most of the demos I have seen online with AVIF images are highly compressed images that look awful on close inspection. Maybe you can accept that for video but I can’t for my photographs.
I have experienced the same, though I’ve done less visual comparisons. Comparing % quality like-for-like between webp and avif, on average avif files are slightly larger than webp counterparts.
Things didn’t materially improve when using high compression (slow) encoding settings. Could have been a bad encoder (libavif iirc)— there might be an explanation but on the face of it I saw worse performance than webp.
Worth noting that Waterfox was acquired by System1, an advertising company. While I've seen no evidence that this has affected the browser itself yet, I'd be a bit concerned about the incentives this creates.
Yeah. Also I don't think most Firefox forks take security seriously. Jumping like this is like jumping into a house on fire because your finger got burned.
Have you tried containers? I used to rely heavily on profiles, but containers are like having several profiles open at once, or several degrees of private browsing.
There are definite advantages to this over containers in some cases, and definite advantages of containers over this in others. Containers are always hard to manage with multiple Google accounts if you want one to be default, for example, because of the way they do accounts and how they redirects everything work. Any time I'm in "workspace" type window, I want Google to just load in that container, so a profile would be great.
For other things, I really want containers. For example, if I'm prompted to load my banking side from a google email, why yes, I do want to open this tab in my baanking container, thanak you for asking, Firefox. Oh, this is a link to social media? Please cordon that off to a separate container as well.
Profiles are good, containers are good, they both serve slightly different use cases and can be used well by the same person, so both should be first class.
In FF, I have an email window with different tabs for each email account. It would be a nightmare to switch through multiple windows to see all of my email.
Not op but I also stopped using Firefox due to profiles. I have one monitored/controlled profile for work and another for my personal stuff and I really need the complete separation so I don't do the wrong thing in the wrong place. I use different themes for both of them so it's obvious which one I'm on.
I also have multiple google accounts because of it which are super simple to use in Chrome, the containers might cover that for me.
But if you know about it, it makes no sense as a reason for you to stop using firefox. It only takes a few seconds to set up and you can do the same thing with themes.
> Also have you ever tried migrating profiles before Sync?
I have. You move the folder from one computer to another and the profile is migrated.
Unlike chrome, where that triggers some kind of "malware has altered the profile!" mode and it resets things. How do you migrate a chrome profile without sync?
Optimal would be to separate work time from leisure, but I realize that may not be realistic for everyone. I use separate OS accounts, or with some customers, separate computers to never mix work and private stuff.
I don't work for $bigcorp and 60% of the apps/things I need to log into to do my work (like my github) are on other profiles that I wind up adding to each profile. I mostly need multiple AWS/Google logins and things of that nature. It's not because I'm bored and want to complicate my life.
I work on various OSS projects for $smallcorp mostly.
Only as long as there is a "no profile" option that will still save history and cookies. You know, like a browser before all the crap came along.
It appears to me that Google Chrome only has the option of "fully logged in with GSuite account where we track every damn thing you do" and "Guest" which is just private browsing, won't save any state, making it inconvenient.
I would trade all these things, in a heartbeat, for the ability to keep other tabs/windows working when one tab is in a hard loop. That one facility is the thing that means I can't let go of Chrome, even though Firefox is prefereable in so many other way.
That was exactly my issue with Firefox. They mostly fixed it in 2016 [1], though I still found a few issues. These days, it seems mostly to be a thing of the past.
Lots to see but still no ipv6 support in the adresse bar. What I mean is that you can write http://192.168.1.1 to access some page but you can't type some ipv6 adresse format
I'll check Firefox again when they get rid of the leeching managing team going from blunder to blunder, and from unrelated to a web browser pursuit to another...
My favorite thing about Firefox is containers. It also has a more generous addon policy, for instance the Bypass Paywalls Clean extension which Google won't allow on the Chrome store.
Hillarious that they said it was an opt in feature, then when I checked my settings all these boxes were checked already. Who opted in for me, mozilla?
It seems like it is opt-in. Just that the opt-in happens with the pop-up described in the link you mentioned [0]. I recall both seeing the pop-up and opt-ing in now that I see the pop-up.
v.93 I don't even see Firefox Suggest in those settings.
Linux distro removed it? Or Firefox know apple, windows people will just put up with anything but linux people probably won't?
edit: Don't see it on an v.93 on an old mac laptop either.
checkboxes for browsing history, bookmarks, open tabs, shortcuts, search engines only. I wanna yell fake news out of FF loyalty boosterism but I do actually believe you so I wonder what's going on?
I'm actually on V. 92.0.1 on Mac OS, in the US if that helps. Maybe they are AB testing this and gauging fallout. Here's a paste of what I have in my settings > privacy and security menu under address bar:
Address Bar — Firefox Suggest
Choose the type of suggestions that appear in the address bar:
Browsing history
Bookmarks
Open tabs
Shortcuts
Search engines
Contextual suggestions (this was checked when i became aware of these settings and went to look)
Learn more
Include occasional sponsored suggestions (this was also checked)
Well anyone who agrees to what microsoft forces on you by running windows is hardly going to object to anything firefox does. Firefox isn't spyware, windows clearly is nowadays.
And it's not like they need to sell ads to make money.
This can only generate bad PR without getting anything in return. Whoever authorized this change is essentially working against Firefox.
Yes they do. Practically all revenue is from Google being a middle-man for selling ads in Firefox. Getting some of those adsales away from the middleman is a big deal for they financial independence.
It's a difference without a distinction. They're paying to be the default search engine so that they can show Firefox users ads in their search results. Either way, they're a middle man selling ads and giving a small percentage of their profits to Mozilla when Mozilla helps them show more ads (mainly to avoid anti trust, mind you ).
I've often thought this myself. As I'm reluctant to donate money to Mozilla knowing they have a record of firing developers and splurging on executive salaries.
What if a fork was funded in a kickstarter like way, enough ideally to pay the salaries of the development team.
I'd happily pay ~$20 per month knowing that the money was going where it should.
Realistic, maybe not. But if we skip the whole funding part, fork out from v92, skip all new features and cherry-pick security patches and nothing but, then I'm in!
They deluded themselves into thinking they could somehow obtain Chrome's market share by making Firefox more like Chrome. They threw the ten percent of users who loved what Firefox was under the bus in order to chase the 40 percent they will never, ever sway.
Remember when you could make Firefox look and behave exactly like you wanted it to? Because I sure as hell do.
No they don't. The way Mozilla is currently setup they need to sell ads, but there are other ways to manage firefox (note that separation between Mozilla and firefox!).
Former Mozilla employee here... I'm not sure you're correct unless you are talking about turning Firefox into a non-commercial open source project supported by volunteers.
Tl;Dr: Mozilla gets no less than $400 million yearly from Google just by keeping it as default search engine.
I was happy to donate to Mozilla in the past, and would do again even knowing about the agreement with Google; I want to support them.
But I'm donating to support development and promotion, not to make some rich execs even more richer. If that's the case, then I'll use my wallet elsewhere.
Didn’t Mozilla recently lay off a bunch of good engineers? Seems like the organization thinks it needs money, although you could debate whether they are spending it the right way.
It's even worse then I thought - every website you visit and every search query will be sent to them! They can basically create a whole shadow profile of you based on your browsing data (like Google already does when you enable search suggestion):
> To help you find information faster, Firefox Suggest uses a service provided by us to offer relevant suggestions for what you’re typing. When you opt-in to improve Contextual suggestions, Mozilla receives your search queries. When you see or click on a Firefox Suggest result, Mozilla collects and sends your search queries and the result you click on to our partners through a Mozilla-owned proxy service.
Not just every search query: apparently location data too.
>When contextual suggestions are enabled, the feature uses your city location and search keywords to make contextual suggestions from Firefox and our partners, while keeping your privacy in mind.
Wow, that last bit. Would have been easier to swallow if Mozilla did the ad brokering and promised to not store them, but no, they do actually ship off the queries to partners.
I was opted in without permission on macOS, so not just a linux thing.
Who the hell at Mozilla thinks that:
1) this is a good idea?
2) that they can sneak this by all of Firefox's tech-savvy users?
I mean, it just seems like such a low risk:reward ratio, what's the point? There's no way that this makes them enough money that it could be worthwhile.
Obviously a lot of HN people would probably prefer it not exist at all, but if you accept that the train has left the station on all this tracking on the Internet being here to stay, then explicit opt-in is still a massive improvement to the current status quo.
For now, it's possible to use Firefox ESR version (Firefox 91 with security patches) and avoid this 'feature'. A year from now, when ESR loses support, I'll have to see whether FF will still be worth using.
I'd be surprised if the US didn't have the largest amount of firefox users, even if it isn't the majority of all users worldwide. I couldn't find any data to back that up, though, since the public site[0] has no per-country statistics.
Talk about a clickbait title. Two hyper-technical features and support for an obscure image format.
To be honest, as a faithful Firefox user, I'm very hesitant to update my browser. A few months ago FF rolled out an abysmal UI update out of the blue, and I had to rely on third-party "fix" [0] to this problem. I really don't want to lose the "fix" due to update, the low contrast of default theme makes Firefox just unusable to me.
I wish there was a no-bullshit fork of Firefox with no Pocket, no Suggestions and Photon UI.
I already know that's going to be an ongoing project getting sites correctly whitelisted, plus its all moot when I take my laptop outside my home. Ublock origin just works.
the only sites I've had to whitelist are the shopping links in Google.
I maintain my pihole outside the house with an always on wireguard tunnel. Granted, this is more work than installing an extension but my phone uses it too.
The biggest thing I miss is ad blocking on youtube.
broke all my banking websites and probably half the rest of the web when i tried it out unfortunately. the world is reliant on javascript for better or worse.
And I did, then some other critical website would come up that would be broken, then another, and another, and eventually I just got sick of dealing with the internet in a broken state and always having to mess with a config. At least with ublock origin I can block trackers and ads and still use websites that rely on js, which is the vast majority of them these days, and it works without me having to do hardly any fiddling at all.
Why not just turn off "Contextual suggestions"? Using unpatched version of browser is very risky these days. Or at least use Firefox ESR, that receives security patches, but lags on features.
Right. I just wanted to check what's my current version first. I went Hamburger -> Help -> About Firefox, which prompted the browser to automatically download and install version 93.
Did I ever mention I fucking hate automatic updates?
Pretty much unequivocal good if you want state-of-the-art compression and live in a country that enforce patents. The Wikipedia page for AV1 explains it well I think: https://en.wikipedia.org/wiki/AV1#Purpose
> The SHA-256 algorithm is now supported for HTTP Authentication using digests. This allows much more secure authentication than previously available using the MD5 algorithm.
Lol wat?
For reference - in a password hashing context, you generally don't care about about collisions. Its not really a relavent attack.
What you do care is speed and memory hardness. Generally you want a slow hash, like bcrypt or argon2, so that in an offline attack the attacker can't bruteforce very quickly.
I've been out of frontend web dev for a while... does this mean the days of trying to find/create your own (good) datetime picker component are gone?