I'd say it starts with dialing back the "new feature/change fetish" that a lot of web developers have. Yes, I know some things simply can't be done without a JS webapp, but not all and probably not even a majority, so if HTML and CSS will do the job fine, then so be it; and even if it needs to use JS, it likely doesn't need to be latest-browser-only JS either.
The constant "X is bad, use Y; no, Y is bad, use Z; no, Z is bad, use..." churn and that "push the web forward" trendchasing seems to be so entrenched in "modern" (there's another buzzword) web dev culture that I wonder if Google/Chrome is responsible for cultivating and propagating it, because it's not quite as endemic in other areas of software and also helps Chrome keep its monopoly, since it keeps the target moving and beckons at others to "catch up".
I think web developers need to adopt a more "do what you can with what you have"/demoscene-ish (for lack of a better term) attitude and not the silly "I could do it with just X, but I'll use Y because it's newer/better-but-I-can't-explain-why-and-everyone-else-is" that really just assists Google's monopoly. In other words: Writing a webapp that could work over 20 years of browsers may not be as hard as it sounds (I've done it --- and I'm not even a web developer --- which might be the reason why...), and you will definitely help browser diversity that way.
Multi select in particular feels like it's stuck in the 90's.
Also select's lack of consistent search capabilities is painful.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...
https://bradleytaunt.com/dynamic-checkboxes/
Sticking to HTML and CSS won't necessarily get rid of this - new stuff is being added to CSS all the time, in particular. And browser support is just as patchy.
All browsers seem to have bugs with it. I also don't understand how it's essential.
CSS unfortunately doesn’t work that way, so apart from graceful degradation you’re out of luck.
I wonder whether this phenomenon is driven by HTML, CSS, and JavaScript being such lacklustre tools for building applications?
Many things that are completely reasonable to deal with in any “native” stack (animations, local storage, offline access, hardware access, accessibility just to name a few), while usually possible with a web stack, are often unnecessarily difficult or awkward.
Things are improving fairly rapidly because of the insistence that everything should be web based these days, and I could totally see that driving people to the bleeding edge.
I mean hell, I do it myself. I’m a web developer, and when reading about shiny new features I’m often eager to start using them ASAP — especially when it would replace a bunch of kludgy JavaScript I’d been relying on previously.
Most web pages will not need any JavaScripts, although some might need it. And in some other cases, optional JavaScript might help, such as to auto-fill or validate a form, in which case the form will still work with JavaScript disabled. (Also note that, for example, Lynx does not implement JavaScript.)
For some of that, my idea of a <widget> element might help a bit. It would improve performance, allow better user customizations, allow enabling some functions that would previously require JavaScript even though JavaScript is disabled, and is compatible even with browsers that do not implement <widget>.
CSS is also overused, although even if you use it, you should try to also allow working without CSS in cases where such a thing makes sense (which it often does, although not always). (CSS styles often just make stuff worse in my opinion anyways; that is why I put in my own CSS codes for stuff.)
I think, the end user need to have enough ropes to hang yourself and also a few more just in case. The entire control of the interface should be controlled by the end user.
Also, these web pages and HTTP(S) are rather overused anyways. There are other protocols, such as Gopher and Telnet and SSH and NNTP and IRC, which are better for some things (and worse for some things, too, I suppose). (But multiple protocols and multiple interfaces can be offered if wanted, anyways, I suppose.)
Only for certain things. A lot of web browsing is still pure information-consumption. The "native apps" are also turning into effective webapps, thanks to Electron and the like.
Even this site, which is interactive, doesn't require JS to use (it provides some enhancements, but the site is still quite usable without.)
[0]: https://www.reddit.com/r/programming/comments/ar1qj1/_/egl52...
You can watch IO talks from Android, Chrome, Flutter where the presenter eventually throws some jabs at other competing stacks as if they aren't from the same employer.
Where I work, departments bill each other. Sometimes, two departments develop competing tools that are third department could make use of. Instead the third department use an off the shelf tool because the "license" for the internal tools is too expensive.
At these scales, companies are almost like states. A group of entities with shared services but otherwise working independently.
No it isn't. Competition with native apps is the completely wrong way to think of it. The web should complement native apps.
Drop those apostrophes - a web developer is a completely valid, skilled profession.
Web apps unequivocally compete with native apps, that is a fact. I prefer the Slack web client to the native version. I use Google Docs instead of Microsoft Word. I use Google Drive, iCloud, Google Photos etc. instead of my own harddrive.
To think that web apps don't compete with native apps is simply untrue.
Slack doesn't have a native version, does it? They have a desktop client, but that's just the web version wrapped inside Electron.
A web developer, doing what they know what to do on the web, is a legitimate developer.
A web "developer" that only knows webdev, doesn't have the skill or will to learn anything else but webdev, insists on splurging web crap as "apps" outside of the web—that's, to me, is not legitimate, and "dev" worthy.
But modern frontend stack - with the whole pile of transpilers, uglifiers, and what not - is almost unusable with Firefox, because source maps don't work with Webpack.
https://github.com/webpack/webpack/issues/1194
This put me in a position where I had to choose between switching to Chrome for development or not using Webpack that comes nicely integrated into the web framework of my choice.
I went with ditching Webpack, but it's hard.
https://stackoverflow.com/questions/55669725/require-module-...
Developers will not use Firefox if FF dev tools are inferior to Chrome.
Some comments from devs:
> Can we please fix this? I don't want to choose Chrome as the browser only coz of this issue.
Mozzila took notice of the issue after 4 years...
Also a full-time Firefox user. This is fascinating because I quite literally cannot remember a website for which I had to switch browser so it would start working.
What kind of websites are these? Have you noticed any pattern about them? Perhaps it's a certain type of site that I usually avoid.
With Safari or Chrome, I can select the dropdown (by clicking it or navigating there using the keyboard) and then enter the letter or number on the keyboard.
With Firefox, I have to click on the dropdown, scroll down looking for the right letter/number and then select it with the mouse. It takes at least 10 times as long as with other browsers. So I'm not using Firefox for that site.
Of all the interactive sites I use regularly about 10% have some sort of bug when visited with Firefox. And this is getting worse at an alarming rate.
I think many mainstream sites not created by actual tech companies have simply stopped testing with Firefox.
(I don't use ad blockers, just browser default settings)
My current bank (Smile) works in Firefox on linux, so that's fine. If it didn't, they'll be losing my custom.
I do not understand. It boggles my mind, in the most curious way.
Also, I have actually tried to communicate with that bank about a far more important issue. It was frustrating and pointless, starting with the fact that they don't have a customer support email address.
<option value="&nbsp;c"> c</option>
This is quite strange, because it could mean that the anti-keylogger feature only works as intended with Firefox but not with Chrome.
Only they seem to have forgotten to test whether it actually does block keyloggers, and it only does so in Firefox.
So my grand example for a website not working well in Firefox may be just the opposite - Firefox saving my money from getting siphoned off by thiefs. Very bad choice of example on my part! :-)
Here's what the HTML 5 spec says on the <option> element's text content:
The text IDL attribute, on getting, must return the result of stripping and collapsing ASCII whitespace from the concatenation of data of all the Text node descendants of the option element, in tree order, excluding any that are descendants of descendants of the option element that are themselves script or SVG script elements.
https://html.spec.whatwg.org/multipage/form-elements.html#th...
nbsp is not ASCII whitespace and so it should not be stripped. I can't seem to find anything specific on the autocomplete behaviour in this case, but arguably autocomplete should use the text content without further normalisation. Perhaps this is where Chrome and Safari devs would disagree.
In any event, this raises a bigger question. What if a site is actually broken in Firefox, but it's not Firefox's fault? Should Firefox then be changed to non-conforming behaviour, aping any Chrome bugs? That would put a huge question mark on all the work they put into making their own rendering engine instead of just using Blink.
I can remember one case of such a thing happening before: css box-sizing.
Before the attribute existed, the spec said content-box was correct, and all browsers except IE implemented it that way. IE implemented border-box, going against spec, but it turned out to make so much more sense it was eventually added to CSS, and nowadays is the recommended way to go (but still not the default value).
In all that time, I don't think I've ever seen a Firefox-specific bug or layout issue.
I saw them on IE all the time (obviously), sometimes in Edge, rarely in Chrome, and never in Firefox.
People hold on to this belief that Google is infallible because they're rich and they put together a marketing campaign some years back to convince people that only smart people work there. I believe the truth is exactly the opposite.
Another bug that I believe is actually Firefox doing the right thing: if you make an event handler function but give it no parameters, Firefox will have no local named event. Chrome will create an event variable for you. Caused several "Firefox bugs" in our app.
[0]: https://developer.mozilla.org/en-US/docs/Web/API/Window/even...
The other issue is that it does not use Windows ca store for certificates. When company uses internal certificate authority for internal websites this requires users to manually update the browser cert store. Chrome and Edge will use windows ca store on windows. My it dept will not automate this but will manage the windows ca store.
By default. But can be configured to use the cert store [0].
> Apparently the content type is wrong in downloaded file so ff will not associate an application with the file
If it is consistent that shouldn't be a real problem.
I do see quite a few sites that apparently never have been tested with ublock or privacy badger, but they break on all browsers where those are enabled.
I know for example I can use FF everywhere but specific Google apps (new sites) don't work well in FF, though that's improved lately as well.
As an aside, immediately upon seeing the website, I had a split-second thought of the content reminding me of Don't Starve. Amusingly, the website turns out to be about Oxygen Not Included, another Klei game. :-)
And then I have to redo all the ordering process on Chromium.
It for long failed on Visa 3D secure (so not website dependant) until I found why with Badger blocking it.
But often when the payment system is included in the website it fails (and that’s really annoying)
As it turns out in recent news, credit card companies sell weakly anonymized information about cardholder purchases so ¯\_(ツ)_/¯
Every damn time.
I also have a big issue with their handling of webm/webp. There was one single guy at Mozilla killing that for years - may still be - despite heavy demand for support.
Both were really disheartening because it showed that Mozilla had lost its fight and had become so complacent that it didn’t even feel the need to match its competitors much less try to lead.
On the flip side Chrome has now become so comfortable with their position that their users are more of an annoyance, which lets them do very unpopular things like pinching off all of the ad blockers. This is where Mozilla could make a comeback because I think a lot of people (myself included) would take another look at Firefox if that is what it took to keep ublock and ghostery functioning.
I've had bugs where the site doesn't work in Firefox but works in Chrome, but as far as I can tell, those were always caused by the aggressive privacy settings I use in Firefox (whereas the Chrome profile is mostly default).
I'm not particularly concerned with the article's complaint about onboarding. The problem is that Firefox is simply slightly worse (less polished, often slower) in many, many aspects.
On Desktop, Firefox is quite usable, even if it is a bit less polished than Chrome.
On Mobile, it's another story. The only thing saving it is the fact that Chrome doesn't let you install extensions, so you have the choice between an ad-filled web on a browser that runs well, with the ads slowing you down (with Chrome), and a clean web in a slow browser with an unpolished UX and infuriating bugs that don't get fixed (with Firefox). So far, I'd say the two experiences are comparably annoying.
You can report sites broken in Firefox (or other browsers) at https://webcompat.com/. Mozilla web developers will debug the broken site and either file a Firefox bug report or try to reach out to the site developer.
Mozilla even has a convenient Firefox extension to make reporting broken sites quick and easy:
https://addons.mozilla.org/en-US/firefox/addon/webcompatcom-...
I don't know if meeting online counts: I'm bothered by Mozilla having a partnership with Google. I'm bothered by the fact that Mozilla maintains an official Facebook container but the Google equivalent is left to the community, I can't help but think that the reason why there isn't an official Google container by Mozilla is that Mozilla and Google have a commercial partnership which apparently provides most of Mozilla's income (as per link provided in the article).
They do already a great job with documentation, but they could and should improve on the dev-tools.
Chrome dev tools are now in a state, that I only use them for developing and debugging. Built in code editor with autocomplete. And I can debug ... and change code while debugging. And it works great (mostly).
Firefox dev tools on the other hand barely work for me to do some debugging and it is no joy. So no wonder more and more developers skip it alltogether, given the low market share of firefox.
This is a game of reducing friction incrementally, not big ticket bothered by it
Web developers can help by using and endorsing Firefox in their coding tutorials/videos/screenshots.
And guess what? Sites that appear to have bugs in FireFox, when I switch the user agent, suddenly render just fine.
Example: Before FB rolled out the FB Live feature to everyone, it was "Chrome only" until I figured out that a simple UA switch made it work.
No, I won't trust you to say "It doesn't work in FireFox" because one of the biggest companies on this planet said the same thing and it was an outright LIE. If you're actually coding to real standards, and not the crap Google dictates, your shit will work right down to Lynx (because you'll also be following best practice for the disabled.)
Good job demonstrating that you don't really know how to make a web page.
As a full-time firefox user, I commonly find that sites have bugs, and when I boot it up in Chrome just to check my hunch, they don't manifest. It's pretty easy to figure out what happened: The developer wrote his code, tested it on chrome alone, and then called it a day. No one booted it up in another browser and even smoke-tested to see if basic use-cases work as intended.
If developers are genuinely concerned with browser diversity and not handing the Web over to Google and whatever they deem to be the next IE6, it starts with having a test plan for other browsers. Testing on only one platform is tantamount to having official support for one platform because you only guarantee your product to work on that platform in so many words. Officially supporting one platform is pressuring your users into a vendor-lock.
They - even the tech savvy ones - can't even begin to make vendor choices when the products they use accidentally lock them out left and right.