(EDIT: this is the relevant quote, but worth reading the whole article)
"Well, we have met the enemy, and he is us.* In the currently shipping version, Firefox ships with many options that will render the browser unusable to most people, right in the main settings ui."
The solutions offered? Kill it all with fire. I'm paraphrasing, of course.
Problem: People today change some feature then have a "broken" browser (basically, they forgot to turn it back to the default, or they didn't realize they changed it in the first place).
Solution: reset button, also notification to the user that "this page might not work correctly", some sort of an extension of how Chrome shows you that a popup and/or a cookie was blocked, based on your settings. Don't treat your users like idiots, just provide information that clears up certain odd states by explicitly informing them of something like:
"The webpage you are viewing may not work correctly because the following options differ from their default values:
1. Enable automatic loading of images.
These features of Firefox are essential for most webpages to run properly. If the webpage you are trying to access is behaving strangely or appears to be working incorrectly, <click here> to load the page with the default browser configuration."
Done, and done. No removing useful features from the browser, no treating users like morons, but now I have a new, useful, awesome, self-debugging feature which is user friendly, and doesn't require a pesky IT guru's assistance navigating the sea of 10 trillion options.
You are absolutely right that configurability is a sign of laziness, the opposite of hard work. But removing configurability is _not_ the sign of hard work. Hard work means addressing the interests of all parties, and Mozilla did not do that.
Assuming you're correct (which I'm not convinced you are), when you then continue, "I have a checkbox that will make it so they don't track you, but it will also break those sites. Is that ok?" They will also respond "hello no".
Right, because you can easily say that a non-user-triggered window.open() is almost always unwanted. I can't think of any other cases where it's so clear-cut and related to JS, or that disabling a particular facet of JS always would be a net win.
If you're going to claim that there's something like that, provide examples. How do you know people at Mozilla haven't already thought hard about this problem and decided there isn't much more they can do? I bet they have.
> "I have a checkbox that will make it so they don't track you, but it will also break those sites. Is that ok?" They will also respond "hello no".
This overstates the case most of the time because doing this generally breaks relatively little for those domains listed, and to the extent it doesn't, making that decision on a domain-by-domain basis seems to work pretty well (ask any Noscript user)
Perhaps, but Mozilla should do it anyways.
Make no mistake: advertisers believe that they have a right to know what links you click and sites you visit across the whole web, and even a right to enlist your browser to aid in informing them. And Mozilla is complicit!
(And why not? Recall who pays Mozilla’s bills.)
As far as blowing off your leg, sometimes you just really hate tennis elbow, you know?
At this point, with your reply taken into consideration, I'm confused. Feel free to elaborate.
> If ... you are doing Internet wrong
Well, my first sentence was actually asking you, since I wasn't sure.
JS has more features than it deserves for learning about and (critically) sharing information about the host platform. Yes, you can still learn some things as a website operator by watching what browsers load/don't load, and what they put in their requests.
Edit: I should hasten to add that there are other concerns beyond privacy, like accessibility and the fact that a web page has no bloody business deciding that I'm likely running an iPad and therefor I shouldn't have access to X or Y. This is dumb, and contrary to the idea of the open internet. It's the same thing that's wrong with this EME nonsense.
I can get behind most of what you say - as long as we are talking about simple, presentation based websites.
Where I think there's a breakdown in this view is when you consider complex web applications, including games. At that point, I believe some level of inspection capabilities are required, if we desire to have complex web apps delivered through the internet. I'm by no means sold that on-demand web delivered code is necessarily a good thing though. There's far too large a surface area to adequately secure while still making it useful, IMHO.
If we follow this thinking too far, we end up with a closed console like device, or Gnome 4 as parodied last April .
Surely there is a case for progressive revealing/enabling of advanced functions?
In the UK, the Blackberry phones are very popular with teenagers because of BBM. This desire to access BBM even extends to students carrying two phones, one an old blackberry handset on wifi and the other an iPhone or whatever. You will find small groups in corners at lunchtime exploring the features of the handsets. Experts will coach those who know less. If I could get that level of peer tutoring going in Maths, I'd have my OBE in the bag quite soon! Users can increase their knowledge provided the unfolding of extra features is managed.
The downside of progressive functions in the base install is that the core Firefox team would have to support all the functions.
To be most intuitive to use, computers should converse like a human. Humans have LOTS of options, and everyone understands that. E.g. if I ask a human to make a sandwich, I can specify all the ingredients I want, how and when I want it, and so on.
Far future of course, but that is the most intuitive end goal of computers: you ask them what you want in natural language, they understand and provide it.
For now, because the above does not yet work, please provide options. Fortunately Firefox provides many options for those who need them: about:config. I find it really awesome if you can adjust an application to your needs at such fine grained level.
Adding more in the way you prescribe isn't just adding more, but officially supporting more at the code level and user level.
Depends who you ask. My mate and a few close friends would know to make me a sandwich without bread, but hardly anyone else would get that right.
Why would scared people even open the settings dialog?
And now your browser is broken.
Though most casual users I know avoid GUI configuration all the same, so I don't really see the issue here.
you assume that users actually read dialogs presented by the software. This is unfortunately not a correct assumption.
Attempt #3: make that dialog less intrusive; do not require acknowledgment. Result: users get trained to overlook it; users who accidentally enable the mode will never figure out what happened to their browser.
Attempt #4: a whitelist of allowed scripts. Problem: users will disagree about what should make it into the whitelist.
Attempt #5: the JSBlock extension. This may have merit. So, if you want this feature, download it, or write it if it doesn't exist yet. If the API does not allow writing it, bicker Mozilla.
The webpage you are viewing may
not work correctly because the following
options differ from their default values:
1. Enable automatic loading of images.
These features of Firefox are essential
for most webpages to run properly. If the
webpage you are trying to access is behaving
strangely or appears to be working incorrectly,
<a href="">click here</a> to load the page
with the default browser configuration.
Also: how is that not a dialog? It presents a message to the user, and waits for a reply.
The author of that article says: "Is it really worth having a preference panel that benefits fewer than 2% of users overall? — obvious spoiler alert: The answer is no."
The answer is yes. If 2% of users have a purpose for it, perhaps it wouldn't have been high up on the priority list to implement as a new feature, but it's already there, and removing it requires extra work. Is it really worth removing features from an application to deal with some hypothetical problem that's been posited under the assumption that most users are idiots?
If there really is a problem, it may be worthwhile to move it to an "advanced settings" panel, but removing it entirely is a terrible idea.
The assertion is that 'configuration creep' is overwhelming for the unsophisticated user in the first place, adding even more notes and explanations to all the configuration options is not going to help.
Really? I would think that sign would help everyone who knew how to read, bothered to read, and wanted their car to run. A sign with a simple message like that was enough to fix one national timeclock system that I worked on. "Do not do X before 12:00 Noon unless Y." in English, Spanish, and Polish.
For the people who still messed it up that we found by using heuristics on all of the punch data, we sent reports to their managers that said that they had probably done something wrong. After 3 or 4 cycles of this, the failure rate went from 15-20% to 1-2%.
Unsophisticated users remain unsophisticated users if you systematically remove configuration until the application only does one thing one way, badly.
But, yes, clearly, the goal is removing configuration until the app does one thing well, not badly.
If you know your car runs on gasoline, and you don't know the difference between gasoline and diesel, then you see a sign that says "diesel is not gasoline," you know that diesel is not what you're looking for - even though you still don't know the difference.
Is this not the equivalent of 'about:config'? In reality it is the advanced settings panel, just without the pretty dialog to go with it.
1. As the blog post has said, many web sites will fail in mysterious and unexpected ways. Some web apps may be rendered completely useless. In fact, you might as well just say goodbye to the modern web if you're gonna totally disable JS.
Rather than demonstrating careful attention to what features are useful and important enough to ship, they become dumping grounds for "something someone asked for once".
Imagine if Excel employed this philosophy. It wouldn't be useful to anyone.
Same for scatter plot, import csv files delimited with % marks, and the ipmt() function?
Is this different in Office 2010 or any of the newer versions of Office? I mostly use LibreOffice and even there it has the same "all GUI" functionality.
And in any case, for those that want it, it's in about:config ... I doubt anyone who should be disabling JS would be looking around for it in a config frame, and not do a quick google search. I've generally adjusted most of my settings via about:config, mostly cache related for me, but if I'm playing with js settings etc.. it's easier to keep a tab open with about:config than a modal.
And all of this actually is equivalent to the "uncommon" VBA coding that you hear of. I wouldn't be surprised if all of the VBA code / spreadsheets you hear about evolved from one of these massive GUI created spreadsheets. Why? Anecdote time:
Those VBA sheets tend to come into existence when a non-programmer decides to learn about macros, updates one of these sheets to be simpler (less data entry), and it actually works. One of my friends was one such employee and she ended up converting a few of the inefficient spreadsheets into a single faster (though still slow) one. Due to cutting down the amount of manual data entry and processing time, it made what used to take a few days of work into a single day of work (mostly to have the sheet run calculations). If this creation gets useful enough, it can take a life of its own in the company and eventually some manager might make it the responsibility of an "IT" guy to update the code. Usually because the original employee got promoted (or left for a better job) due to killing their performance reviews. My friend was one such employee who left and actually did this at more than 1 company leading to a pretty damn well paying job at a young age. Last she heard, her original spreadsheet was still being used and semi-maintained by IT. And this it how I believe a lot of those VBA coding projects come into existence.
This meant that he freed up plenty of time for the entire team he was on. Unfortunately, this meant that they now had surplus staff, and as the newest arrival, he was the first to let go.
Yeah, incredibly backwards internal politics, but I swear it's true.
Obviously anything on the 'Advanced...' dialog makes an easy target.
Right. That's what they should be.
Software exists to provide utility for users, not to instantiate designers' aesthetic visions.
And the most important point here: This feature really is broken as of today. Nobody can persuade me that they use it on their main browsers. I don't believe them.
Certain lyrics sites disable right-click to prevent "theft".
Certain sites disable right-click for aesthetics or to prevent me from seeing the page source.
This news just makes me glad I'm on chrome.
Of course not. Mozilla's agenda is determined by its main sponsor, Google, which has a vital interest for JS to be enabled. Any spin on this being somehow "for the user" is bullshit.
Anyone interested in psychology should do phone support for a few weeks...
My guess is that they dismiss error boxes too quickly, or work ahead of you and are afraid that you'll figure it out if they tell you what their error box actually says, and they'll get an F on the test and will have to go to summer school.
The problem is that once trained, people start doing it instinctively, even with the people that can actualy help.
There are plenty options that can bug your browser or leave you unable to surf, why remove this particular one?
If you think users aren't that stupid, you're wrong, they are that stupid. If you think people should not use the Internet if they don't understand that much, then you're suggesting kicking a large chunk of the population off the Internet. If you work in IT, kicking a lot of people off the Internet is a surefire way to reduce your industry's size.
Not if someone borrowing your computer for 5 minutes disables it.
Knight turned the machine off and on.
The machine worked.
In many cases, I suppose the developer doesn't know about the cookie dependency (because of a framework or some other dependency). In other cases, I guess they don't care. Rarely does the page actually tell you that cookies are required.
The point is that it is relatively trivial for the developer to add automated checks for per-requisites and display warnings for the ones that are missing. It is a lot harder for each user to manually run down through the list of all the things that could go wrong.
Just don't make the warnings into roadblocks. Inform the user and let them decide to proceed or not.
Most of the time it's a small bar on the top or bottom of the screen. Stop whining.
Regardless of the laws, though, when a site fails to function, it should tell you when cookies are the reason. It's not hard to do.
Limi's blog post "Checkboxes that kill your product" is cited in the bug as a good explanation of the motivation behind this: http://limi.net/checkboxes-that-kill/
The option has been added to the DevTools for developers who find it useful: https://bugzilla.mozilla.org/show_bug.cgi?id=864249
And of course addons like NoScript or js-switch are available if you still want this in your UI: https://addons.mozilla.org/en-us/firefox/addon/noscript/ and https://addons.mozilla.org/en-us/firefox/addon/js-switch/
I'd be mad about this, except I haven't used firefox in years. One less reason to go back I guess.
However, I will concede that your opinion appears to be the most commonly-held one, even among some developers. And it's probably not going to change for the better with news like this Firefox development... :-/
There's already so many moving parts, saying "this browser handles cookies, every newest features of css, html5 and everything. Except js won't run." is just a recipe for ugly user experiences.
Slightly OT, IMO blacklisting specific js (e.g facebook, twitter etc), or having browser giving an option to kill scripts that take too much time or too many resources should be healthier for the devs and the user than just turning js off on the whole site.
How are we meant to handle AJAX requests that fetch data to display on the web page that allows users to achieve the goal of their visit? Without JS enabled, that part of the page will be blank, and many modern, rich content-heavy sites now pull data from different places on the fly, it's just how it is.
Is your idea of gracefully handling this situation putting a noscript tag there saying "please enable JS"? If so, what exactly is your problem with removing the option which we only ask users to re-enable anyway?
As many others have pointed out, you can still disable JS if you really need to. It's average non-technical users who don't require that option.
You might think AJAX is amazing, but I call it an accessibility nightmare.
Make the request from your server, parse it on your server, template it on your server, and deliver the HTML result to your user.
> Without JS enabled, that part of the page will be blank, and many modern, rich content-heavy sites now pull data from different places on the fly, it's just how it is.
Perhaps the developers of these modern, rich content-heavy sites can learn how to do their jobs properly?
> Is your idea of gracefully handling this situation putting a noscript tag there saying "please enable JS"?
Sometimes it comes down to doing it with client side AJAX, or not doing it at all.
With developers learning to do their jobs properly, sure when the luxury of time and starting a new site from scratch is on your side. And with backend developers and engineers ready to configure the ultimate content delivery mechanisms. But what of when you don't have that luxury? What then? Just decline the job? Maybe, but then someone else will come along and do the AJAX, and get paid because the content appears when the site loads every single time (provided JS is enabled ;-).
I can say the new version I am working on looks better, and is actually usable on a phone, just the same, I am not sure I'd like to see the UX on a bandwidth constrained mobile connection.. it's still well under 1MB total, but it seems that we should be working towards being under 100K for an initial load, and given all the targets for different browsers, and work arounds, and libraries, tools etc.. I just don't know where we are going.
We have more target browsers and size constraints than ever, and it's more complicated than ever. I don't miss the V4 browser wars (IE4/NN4) but it seems that targeting a 700px wide or 960px wide site was way easier than the rules today, mobile first or not.
As for non-technical users -- they're probably not going to be opening Firefox's Preferences dialog in the first place. And if they do, they probably aren't going to start randomly checking and unchecking stuff to see what it does. That's something an adventurous geek might try, but certainly not your typical non-technical user.
If Firefox developers wanted to additionally protect the average user from this dangerous button, they could have simply stuck it in the Advanced tab of the Preferences dialog, or added a scary warning about being doubly sure that the user knows what he's doing (like they do with about:config).
You would be surprised what non-geeks tend to do when they have no clue what to do.
You are on the mark.
You clearly haven't worked with the same non-technical users I have. It took ages to figure out that "use TLS" getting unchecked was the reason our site wouldn't load for one particular visitor.
I wholeheartedly support removing all of these check boxes.
w3m has image support in some terminals though, which fascinates me. I feel like I should probably investigate that some more.
I installed the w3m-img package on Ubuntu 1304, running it in xterm allows image viewing inline.
You are reliant on factors outside of your control. For example, a well-intentioned DNS Blacklist took down loads of Fortune 500 companies:
(I agree that the changing of existing settings is the offensive part.)
At least for the moment, the dom.disable_window_move_resize and dom.event.contextmenu.enabled preferences still exist in about:config, though.
Want your Firefox to behave like a 1990s browser with one window per website? You can configure that.
EDIT: Per this comment  holding shift causes Firefox to bypass event handlers, so hopefully that wouldn't be possible.
I think this line says it all.
Non-technical user don't even know what HTML is, the concept they'd ever "grasp of the differences between static HTML and programatically manipulated HTML"? Do these people live in the real world?
JS makes the web feel responsive and interactive. I helps keep the user engaged with you site if used in the correct manner. Removing the option that easily disables it for a majority of users if the right step. Hackers will always find a way around it.
One man's 'responsive and interactive' is another man's "Did it work?"
I simply don't understand why you would want to browse the web without JS enabled and the average user definitely would never turn it off except in error, causing them to think the browser is broken.
It's faster. Much faster. Every time I disable noscript to use some website (90% of the time it's video that doesn't work) I'm always astonished how much GARBAGE most website have. Totally useless stuff.
Popup boxes, annoying underlining with mouse overs, certificate verifiers, bookmarks, social network promoters, chat boxes, and helpers galore.
I suppose that stuff pays the bills? Maybe. But pages are so much faster without it.
Advertising for paying the bills, analytics tracking to work out who is using their site, chat/comments boxes for social interaction.
And all for what? Someone who isn't going to make us anything near the time it will take to develop.
I'm not saying what you want is wrong. Rather, what you are asking for is to have a game written in c to be rewritten in python because you don't want to use c applications.
This cuts out the majority of the garbage while still letting most sites work. (I've whitelisted a bunch on CDNs.)
I allow analytics.
And I am not interested in social interaction, because the comments are so intensely stupid you become dumber just by your computer loading them.
For the minority that do click on advertising, or do not get a instant distaste for any company displayed on advertising that are forcible pushed into ones face, I suggest using a opt-in system. Same goes for tracking, or the constant push for integrating different companies websites with ones personal social network profile.
Last, the golden days of pay-with-your-eyeballs or pay-with-your-personal-data supported services might be counting down. Sooner or later, tax officers will start consider those as transaction as any other, and thus enforce taxes on them.
For some people and some sites, the answer is an obvious yes. Especially when the script is an integral part of the app or site you're visiting, such as a game or a highly interactive tool.
Sometimes though, the content should be enough. There are plenty of sites out there, like blogs, that shouldn't need js to provide their primary function. For example, I don't feel that I should need to enable client side scripting to view a 140 character tweet on the twitter site.
For some people, tracking via js is the primary concern, and in their case it makes sense to disable js whenever possible, and use offline tools for everything that needs to be interactive.
In any case, this move has a solid precedent, and as others have noted there are plenty of plugins that allow granular control over js execution.
Security, performance, JS ads ...
My company provides a web based app to Fortune 500 banks, around 15% of the browsers we see have JS disabled.
Security? The browser sandboxes everything.
If you disagree with me, and believe it can, I would just love to see a webpage that dumps out valuable data inside my browser. I'll visit it without any browser plugins using the same session I have been using for over a month, promise!
How many are bots/scrapers?
Every mainstream browser supports Flash, too - does that mean Flash is the way of the future?
I run with NoScript, and it makes the web a quieter, more peaceful place.
Users with js still get the "fuller" experience, but users who choose to disable js still have full access to the site.
This "extra functionality" is the same "extra functionality" as having a safety cage designed and implemented in a car. Sure, it's just extra functionality that most people will never ever use. Hopefully. Touch wood.
Nobody is forcing developers to give a damn about accessibility, but it's a bit sad that so many have thrown graceful degradation out the window.
Although some counter by saying that you shouldn't need to provide wheelchair ramps for the < 1% of people who are unable to use stairs.
Sometimes it's not just about ROI.
Not that most web apps wouldn't implement it that way to begin with anyway, but this would be the only choice with a HTML-only site.
So? A complete HN page is smaller than JQuery.
I'm starting to feel old, since no one seems to remember HTML webpages instead of apps or those people that would say they can "program" html.
Most 'non-technical users' don't have a clue about HTML, Javascipt, static features, etc. To them the internet consists of Facebook, Google and Youtube.
I read threads like this all the time: someone talks about "non-technical users" or "your grandma" or "pointy-haired bosses" or the like, and then goes to great length to discuss, in detail, the capacities or cognitive styles or knowledge base of members of these hypothetical categories.
It all seems like a bunch of arbitrary assumptions.
And while we are at it, I wish Firefox would add a search box in that Preferences panel. Its usefulness has been demonstrated in Chrome's Settings and Windows' Control Panel.
Also, Firefox rocks and I'm so happy to see it improve.
Name another browser where the Firebug-like functionality is an extension and not something built-in.
Examples of browsers that embedded Gekko: Camino (a Firefox fork for OS X that happened in a time when Firefox wasn't as polished for OS X), Flock and K-Meleon. Google's Picassa for Linux was also using Gekko.
Also, Firefox's UI toolkit is not GTK, but rather XUL+XPCOM, abstracting over the various native toolkits: https://developer.mozilla.org/en/docs/XUL
Only Firefox on Linux uses GTK. Even on Linux, there have been previous attempts at supporting Qt as the backend for KDE, but all failed because of the easiness with which you can make GTK look like whatever KDE theme you've got selected - not perfect, but the flaws where not enough to gather interest in further development.
There's even XULRunner, for easily building and packaging XUL+XPCOM standalone apps: https://developer.mozilla.org/en-US/docs/XULRunner
This isn't to say that XUL/Gekko are perfect as their complexity was often the subject of criticism, which is why Mozilla replaced XUL completely with HTML5 in Firefox OS and will probably do so in future Firefox versions - as they are also working on Servo, a next-gen rendering engine that doesn't do XUL anymore: http://www.mozilla.org/en-US/research/projects/
For example, if my Firebug example wasn't enough, when Chrome was released, many people loved the light download progress functionality that wasn't opening an annoying modal window. Pretty soon an extension called the Download Statusbar happened: https://addons.mozilla.org/en-US/firefox/addon/download-stat...
True, but only goes to show my point - if firefox's extension mechanism made it so super-customizable, surely there would be no need for such browsers?
>Firefox's UI toolkit is not GTK, but rather XUL+XPCOM
Fair enough, but the point stands; when writing extensions you're restricted to using the XUL toolkit. Contrast with e.g. activex-based add-ons in Internet Explorer, where AIUI you get the standard windows API and can thus use any toolkit you like.
There are plenty of good things about firefox, but I don't think you can say it's more or less customizable than the alternatives without defining customizability in a very arbitrary way. All browsers have a succession of methods of customization, from simple userjs to custom extension formats to embedding the engine in a new executable, with the power and complexity increasing at each step. That firefox's "extensions" lie at a bit more powerful and complex point along the line than chrome's is not the basis for this blanket claim of greater customizability.
And it doesn't force you to use GTK for your UI.
Progressively enhancing a website enables you to still deliver a whizz-bang, fancy-pants UI but ensure that it degrades to a sane text document when viewed in, say, lynx . And it doesn't mean doubling the development time of every feature, which I often hear cited as an argument against. Often it can involve providing a very cut-down equivalent that takes relatively little time to build.
Stop talking. Start doing instead. Employers and product owners are hiring you for your skills, so use them. Don't ask permission to follow best practice, just do. You are more than a code monkey.
Do your employers really not care if a third party outside of their control decide to do something to affect the availability of their site?
Do your employers control, audit and manage every single byte that gets delivered as part of their website? For those they don't completely and accurately manage and control, how do they absolutely ensure that every byte that needs to be delivered arrives correctly and is interpreted correctly in their users browser? How do they remove the risk of all those server hops between their web server and the customer's browser? How do they control that?
The Web cannot be controlled or managed in this way. There are simply too many factors outside of a website owners control that affect how their site is perceived by customers. Without pragmatic approaches it's either an all-or-completely-broken situation, or when a site is built properly with progressive enhancement, a slight degradation of usability that customers don't really notice - because the core experience just works.
Want a good data point? How about a couple that decided rather vocally that progressive enhancement is dead. $100,000 spent on a bootstrapped application, and then this astonishing comment: http://unicornfree.com/2013/why-we-shut-down-charm-on-the-ev... -- read the third paragraph of that comment.
Sometimes, it's an expensive lesson to learn.
My bet is that there is Less then 10% of users who cares about this. And less then 5% who just cant stand to disable it in about:config instead of UI.
And if you DO have such a big concern over a missing UI features, you can always go to Opera.
Its amazing to me how many people don't appreciate that goal or really take it into account.
The web should be words and documents first (I think this page is worth reading http://justinjackson.ca/words.html). It's too late to say but if you want a sandboxed application platform, develop it out of the web. I still believe the plug-in was not a that bad idea, not the best idea though. At least you can disable it anytime and you have freedom of choice.
I suspect that the back button will be eliminated next. Because it collapses most web applications and "user experience".
If the web want to become a perfect application platform, all virtue of the web will be lost.
Web has always been about managing documents in one way or the other. Now those documents are interactive and interesting to watch and listen.
I mean, if my old chem book had cool animations I could tinker with I'd probably be having fun with it right now. I don't understand the outcry for GOW. It's still around and you can still make those sites, but they are usually hard to read (no fancy column layout to make it easy on the eyes) and you have to be a great writer to really engage the audience.
Going back to GOW won't make bad writters instantly better. No more than returning to 8-bit graphic won't instantly make all games better.
I really wish we had just let html be documents and made a real remote-access application framework to work along side it, rather than having your program be 2 - 3 tags of html and 5MB of js. I'd much rather be sharing a qml application than an html5 one, because the latter was ground up designed to be a full featured interactive graphical interface program.
Don't get me wrong, I always wished Opera mainstream success. But I think there is also something to be said for niches, and the desire to appease the existing average just because the balance book says that's the best, needs to be called out on sight. Imagine authors only writing books 98% of the people agreed with or cared about. We'd still be in caves with that attitude.
I know making tools isn't exactly the same, but it's also not totally different, IMHO. We need to aim higher than were we are. Every sports fan knows more and more complicated facts than even using all features of Opera would require. Riding a bicycle, much less driving a car, is more complicated than being aware of what option you just clicked - ffs!
If even Firefox can't help but caving in like that, I simply won't dare to hope Opera does better, until I actually see that happening.
I am sorry for ranting, this topic is a huge pet peeve of me. Like when Apple talked about how folder hierarchies are "too complicated", gah. I know I'm expecting too much of people, but I really would rather err on the side of that, than on the side of expecting too little, and then getting exactly that.
They'll probably add most of it back, but it'll take a long time.
It's only being removed from the UI
The backend ability is still there.
Extensions like no-script and yes-script (I prefer) will still function.
Even if such functionality can be restored by using about:config, or by installing extensions, it becomes a hassle.
They did this with the menu bar, and it hurt Firefox's usability. Now many of us have to waste time and effort reconfiguring it to make the menu bar reappear every time I install Firefox.
They did this with the status bar, and it hurt Firefox's usability. Now many of us have to waste time installing extensions to restore this core functionality.
Many of us are just plain getting fed up with Mozilla's bad decisions, and very justifiably so.
- How does removing the status bar hurt usability? You still see links when you hover over them, and the add-on bar can be toggled instantly with Ctrl+/
- Always displaying the menu bar by default is a waste of space, it can still easily be accessed with Alt or configured to always display.
Honestly you seem to just dislike change, and I'd advise you to simply turn off automatic updates. The rest of us are happy for improvements to be made.
As for the status bar, the URL popup shown when hovering over links is much less usable than the status bar. It is harder to quickly focus on, for instance. Having to remember yet another obscure keyboard shortcut for functionality that should be enable by default, like the addon bar, does not promote usability, as well.
The menu bar is not a "waste of space" because it more than pays back its cost by making a huge amount of commonly-used functionality very easily accessible. It is especially valuable because of the cross-application conventions it embodies, making it take even less effort to perform common tasks.
We shouldn't have to manually enable core functionality like menus or the status bar, for example. Such functionality should already be enabled by default when Firefox is first installed. Anyone who doesn't like the menu bar or the status bar should have the option to disable them, of course. But they should not have been disabled by default, or even removed completely.
Today, browsers have far more in common (regarding js/dom) with each other (IE8+ too) than at any point pre-2005. And it is about damned time. I still think the likes of jQuery round out a ton of those rough edges, and it still disappoints me to see so many who hate JS because they want it to be (insert preferred language here).
JS is, and has been my favorite language for a very long time.
I'd prefer if browsers treated the Web as less of a black box, and if they erred more toward helping users understand the world they are exploring.
This is a nonissue, but continue to make it more than it is.
Make the primary tradeoffs clear, supply a link to a mozilla.org site with a more comprehensive explanation of what you give up and gain.
Programmers like to simplify, abstract, and modularize, but that isn't always the best strategy with language. Sometimes, even with control panel tooltips, it's better to be a little bit more verbose, take up a little more screen real estate, if it saves your users some trial-and-error time or a trip to Google.
FWIW, I don't think we should avoid educating users. Pandering to the dumbest common denominator only makes dumb things in the long run.
Like say using tor where having JS enabled is like asking to be tracked.
I know disabling JS is not an option on the modern web but then ship with something like noscript instead don't just leave users exposed.
This is not a feature that can just be removed it needs to be replaced instead.
This is a good move. Option still exists in about:config.
The current trend in removing features from software seems like a great way to have a dire shortage of engineers in 50 years time. The attitude that "software is a magic and untouchable black box, you can only use it to do the specific thing the developer wants you to" destroys the true power of the computer as a tool, it might as well be a radio or a TV that incessantly produces other peoples ideas.
Write useful, empowering and well tested modular code. Let the user work out what crazy and wonderful ways they arrange those modules. Don't make changes that serve only to glob more functionality up in to impenetrable, monolithic black boxes.
Also: Overriding peoples existing preferences during upgrade? Nice work guys :/
They don't want to be 'empowered' by developers, and they definitely don't want to have to deal with arranging a bunch of poorly documented modules that make no sense if you are not familiar with the underlying architecture.
As a person who uses noscript every day in FF, at first I thought this was a bad idea, but the more I think about the support aspect of this, the only time I think you really should turn off JS is when you understand enough to find the advanced options.
Every change is prone to break someone's workflow. But if there is a good enough alternative and if the change is better for everyone, I think that should be left alone. If there was no way to disable JS after this update, I'd be pretty mad as well. But having an option deep enough to keep away from unsuspecting eyes is only sane.