What an awful idea. How is a web developer supposed to test the website when he and user might have different browser behaviour? It looks like someone read about deployment at Facebook and wanted to implement the same thing without any valid reason. Firefox is not a server-side software and this style of deployment doesn't make much sense.
So that is always going to be the case with a change like this, simply because people use older versions, use different browsers, etc.
If this change breaks popular-site.com then it will continue work fine for 95% of people, and it breaks for "only" 5%, one of whom will (hopefully) report it. This allows the Firefox people to test the waters to make sure it's not going to horrible break things and break things for too many people.
How about devs evaluate a change by doing some testing, instead of using users as guinea pigs?
I agree with parent, this is an awful approach.
This is not new either. Many such changes have been reverted after discovering that they broke more things than expected. One example is the Object.groupBy static method, which was initially Array.prototype.group.
That sounds like a pretty lame excuse.
So if a self-driving car manufacturer does testing, they are not testing the car, they are testing the environment? Sounds like a pretty neat trick, maybe marketing should adopt this attitude.
Presumably they have done as much of that evaluation as is reasonable already.
It feels to me like usability testing and quality assurance have both joined security and accessibility on the back burner now.
"Who would pay for it ?" Sincerely, Microsoft™
The change has been shipping in Firefox Nightly for a year. I have analyzed impact of affected pages in the HTTP Archive dataset (about 12,000,000 pages), twice:
https://github.com/whatwg/html/issues/7867#issuecomment-1977... https://github.com/whatwg/html/issues/7867#issuecomment-2595...
The next step is either rollout or ship directly.
That is kind of part of the bargain when you download a version of the browser explicitly labeled as a beta.
Yes, but in this case asking the user to update to the latest version won't fix the problem either. I agree it's a terrible idea.
> The plan is to roll out to 5% of users on the Firefox 138 stable release, ramp up to 50% of users, then ship on all platforms in Firefox 140.
How would they report it? "Hey, your website looks weird. Yeah I'm running Firefox 138 stable and I'm in the 5% experimental group who received the default h1 styling change"?
What is more likely to happen is: A website might get a report, the dev goes to reproduce it, and they're in the control group, so they can't; and because it was only one or two reports, it gets closed.
I understand that a rollout makes reproduction harder, and not everyone will be aware of the change. It's a tradeoff when deciding whether to do a rollout or ride the trains normally.
This is totally possible. Many changes to the web platform we abandoned or changed significantly because a couple of websites look a little wonky.
Just like any web page should work perfectly with JavaScript disabled, it should work perfectly with a user-supplied style sheet.
If you’re making a web page that has this problem, what you’re making should not be a web page, and you should feel bad about the choices that led you to that point in your life.
It will take a while to fix this problem in our industry since we’ve waited so long on it, but the best time to start is now.
And the problem is neither of those things are true in reality. So in real life a change like this can cost the economy millions of dollars.
Firefox isn't doing so well on market share, and appearing to be broken isn't going to help.
Changing the latter costs money - time from people’s lives.
Why?
You’ve given no argument that this actually is “abuse”
However, you run the risk of the user re-submitting the form anyway. Since this is involving orders and money, you may want the order confirmation / submit page to have a nonce or temporary ID representing the checkout session in the URL such that, upon revisiting that page, you can lookup the order status on the backend and redirect them to the order success page again.
The original task was to do this without JS, so my first guess would be: Instruct the browser to re-load the page upon navigating back (cacheability headers), identify the order using an ID in the URL, then when reloading detect its already-submitted state on the server.
And how would one do that without using JS?
Re-loading the page on navigating back would be done using cacheability headers. This is the most shaky part, and I'm not sure if it is possible today. If this does indeed not work, then this would be one of the "things that Javascript has solved that the non-JS web is still stuck with" I meantioned in my other post, i.e. one of the reasons that JS is more popular than non-JS pages today.
Identifying the order using an ID in the URL is standard practice everywhere.
When the order page gets requested, the server would take that ID, look the order up in the database and see that it is already submitted, responding with a page that has its submit button disabled.
I specifically called out the issue of re-submitting certain forms and proposed the above solution. I don't think relying on cache headers is going to be sufficiently reliable.
But even with a nonce and a re-submission check, the cache headers are essential to make sure that when the user presses the back button, they'll see a greyed-out submit button. If the browser does not reload that page, the button will still be clickable. It won't work correctly because the re-submission check will fail, but a clickable and guaranteed non-functional button is very bad UI.
The latter is one of the main reasons that we have so much JS/SPAs. Sure, you can build an application without it that is somewhat functional, but the UI will be low-quality -- even if this particular example might be fixable with cacheability headers.
The web is explicitly and intentionally a software distribution platform. JavaScript is a web standard and is no less “part of the web” than HTML and CSS. You’re f
I actually work at Qt and many of our new products are web apps
The result is always a better product with happier users. If you don’t want to invest in that, you should at minimum be willing to admit to yourself that you’re OK with giving your users something subpar because it’s to your advantage to do so.
It might be true that applications actually are web pages now (e.g. Slack, WebEx), but I almost never encounter web pages that are actually applications.
For work other than some very industry specific high performance software most businesses software is web based, and users ( those paying the bills anyways ) want them to be web based because it is much more portable and easy to deploy.
It worked perfectly fine until browser companies decided they wanted more than to be renders for hypertext documents.
We lost this battle by 1999. And again when we started to deliver full web applications instead of documents.
I wish we had a second protocol that was more document and information focused. Something that gave zero control over programming or layout to providers.
I just want to exchange information P2P in a dense swarm approximating modern social media. I want to use my own client configured how I like it to choose what to ingest and how to flag it and present it.
Without layout or programming (functionality)...is that not just json??
And if you consider "structure" to be "layout"...then...a txt file?
Unf I don't see the point here. You're basically just describing an api endpoint and a custom client.
Hyper scale businesses captured most of the internet's value and humans and turned tech into a series of walled gardens for eyeball attention doom scroll maximization. Retweeting the for you page is what some committee of product managers decided was best for us all. Who are we to question the architectures of power?
It almost sounds like a perverse weird utopia to imagine a world where we controlled all of the information flows ourselves. I can't think why we should have all the power.
Not sure how we could expect users to switch between whatever font they want, and things not breaking.
Different fonts both appear and have different sizes, so what might look perfect with one font (a button where the text is aligned in the center vertically/horizontally), can look massively different with another (say the font's characters are wider, so now the text either overflows or breaks into two parts, making the button "broken").
When you are changing the very fabric of the whole web, rolling things out in a gradual, controlled way is paramount. Not just because people can find and report issues before roll-out reaches 100%, but also because browsers collect telemetry on features and how they work in the wild that can be used to gauge the effect.
> To test in Firefox with the new behavior, set layout.css.h1-in-section-ua-styles.enabled to false in about:config.
Gbd article doesn't specify how to test in Chrome (probably something in chrome://flags), but you can read the deprecation warnings dumped into your console. You may need to enable them in your default log level. If so, there may be a lot of other behaviour that you'll probably want to fix.
Although I agree with codedokode insofar as I don't see how the phased rollout in stable could possibly help. Hopefully they've thought of something I haven't otherwise it is silly.
There are [to] many ways to set the font size. I don't even know which on is the correct choice, if there is such a thing.
Maybe not trying to control it is the best approach? How can one tell?
The problem isn’t you per say, it’s the 5000 people that mis-follow some YouTube video because it looks cool without it actually understanding what they’re changing , how to undo it, or what the implications are.
I would like to remind that some time ago browsers allowed to change the default font size; it never worked well so Opera started to scale the whole page instead. Other browsers followed it.
Android browsers seem to repeat the same mistake by the way: they override developer's styles when the user changes font size in OS accessibility settings.
Any web developer that would have an issue with this is already overriding the default styling.
https://developer.chrome.com/docs/web-platform/chrome-finch
This is a list of variations:
>To test in Firefox with the new behavior, set layout.css.h1-in-section-ua-styles.enabled to false in about:config.
Rolling out potentially risky changes in this way is not new, and is also a strategy that other browsers employ. It allows for course-correcting if necessary and is less disruptive than shipping to 100% of users directly.
2. Anyone that cares a lot how h1 looks is going to set the style themselves, rather than relying on whatever the browser default happens to be.
3. Bad browser defaults have (not inaccurately) been blamed for people excessively crapping out CSS.
The fix for this is to define your own H1 margin and font size and then to test that the site looks correct with those values. Your test is should be that your styling works, not that Firefox's styling works. That'd be like testing a dependency. You shouldn't be doing that.
For example, I tested something in my own private Azure Subscription, but the feature was simply missing in the customer subscription.
Microsoft was enabling features randomly without even documenting this or showing any kind of user-visible indicator of what feature set was available or not.
> Since Firefox 136, developers will see a console warning for h1s in article/aside/nav/section without author-defined font-size or margins
Seems like it should be fairly obvious for any dev that tries to look into it even if they're not part of the cohort with the new behavoir.
Sure, it’s a lot cheaper but also, you’re supposed to ship things that actually work.
How does safe velocity not apply to client apps? We've been doing this for decades.
I get studies and exp. But that's different than rolling out a default behavior to all users, which still requires safe velocity guardrails so you don't Crowdstrike yourself.
If only there was like a Developer version, perhaps one version ahead of stable: https://www.mozilla.org/en-US/firefox/developer/
What are they?