Future Directions Proposed For Mozilla
Ars-Fartsica writes "MozillaZine is now featuring a set of slides regarding future directions for Mozilla that were detailed at the recent Mozilla developers meeting. SVG and integration with programming languages are among the directions discussed."
They've been working on SVG for a long time...
Why the heck isn't it included in the default build already?
SVG's gonna be killer when we can actually use it (and count on users being able to use it too)
Yup, and that appears to be all you can see if you run with Javascript disabled. Good job, guys!
Gotta love that "degrade gracefully" concept.
Why do you want to integrate everything? You integrated mail, news, irc, calendar and probably million of other shits I never used in Mozilla. What is so amazing in one integrated monster? Do we really need to follow Microsoft path? I always though Unix way is to build many small tools, not one big piece of shit.
This is more than a cosmetic issue. Mozilla has the OK and cancel buttons in dialog boxes in the "wrong order" compared to the rest of my desktop, and so I frequently find myself hitting the wrong button by reflex. I also run into bugs in the mozilla widgets all the time. Try middle-clicking on the scroll bar of a textarea widget (under X): its supposed to absolute-reposition the scrollbar; it does that, but in addition pastes the clipboard into the textarea! Another benefit of native widgets would be to decrease memory usage, since the widget libs in memory would be shared.
Its nice they've been listening to their users.
--
Wanna play some word games?
A more flexible toolbar (ability to stack toolbars left and right and not just up and down).
If you're going to compete with IE, javascript is the way to go. Start with matching the functionality (IE the ability to reference objects without needing to go through getelementByID the way you can in the MS browser, this will eliminate 90% of the javascript incompatibilities between the two browsers).
3] Realize that as far as the end user is concerned browser rendering technology is done and will be done until there's enough bandwidth for full motion picture browsers (Think tivo on steroids). Adding more features just adds to bloat for very, very minimal gain. To that end the focus should hinge on a better, more intuitive interface -- the more you can make it disappear while still providing easy access to navigation and google the better. And don't forget the art, IE still makes pages look better that definately needs to be fixed.
4] Firefox and Thunderbird are killer apps but Thunderbird especially has a lot of room for improvement. When Thunderbird can piece together split usenet files and handle Y-ENC then it will probably truly have arrived for many usenet junkies. After that you need to out exchange exchange and realize email is a centeral pda application and to that end we need scheduling, address books that sync with our newtons, and help us manage our lives. Indeed, do Thunderbird right and you can really shake up the world because there's a real hunger and need for an ultra powerful email/usenet/scheduler/contact/pda manager.
A question: Does Mozilla/Firefox/Phoenix really need to do this itself?
Something like this is ultimately a gamble which may or may not pay off...and if it doesn't work, there's a huge amount of cruft dumped in the codebase?
I'd rather see something like the approach Apple used with KHTML in making Safari. If someone wants to make a program called, say, "Mozilla Platform" that *uses* Mozilla, I think that'd be a lot safer than trying to make one massive integrated push.
I think that trying to integrate everything has been the largest problem facing the Mozilla project. I have, many times, contributed patches to open source projects. I have never contributed to Mozilla, because the project was (at least to me) very large and overwhelming...and I only really cared about fixing problems that affected me. If I ran into a problem, it was often something that would require learning a huge amount about how Mozilla is structured to fix. I'm okay spending a day or two fixing a minor problem on a project that's irritating me. I'm not willing to spend a week doing so.
The "integrated" approach is a turn off from a resource standpoint. It made the Mozilla suite large from a disk and memory usage standpoint.
It meant that releases had to be spaced widely apart, and that one broken component could hold up releases of the rest of the package.
It meant that you had to lug around a mail client, web page design program, etc that you might really not be interested in.
In general, I think that Open Source does better if taken in smaller chunks. It makes rewrites and bugfixes more localized, it lets users choose the best option for them (rather than using that mail client that's bundled and always in their face), it keeps resource usage low, and it lets developers release on a more timely schedule.
May we never see th
Much as I hate to admit it, and as strongly as I feel that rollover highlighting is a flawed UI concept, enough websites rely on rollover capabilities being present in a browser that it may be rough to disable them.
On the other hand, I think there there are few compelling reasons for allowing websites to modify the status bar information. Doing so is a serious security issue. Users (well, they won't think in about this in rigorous terms, but they do so unconsciously) treat the status bar as a source of trusted communication between their browser and them. If remote websites can muck with it, they lose the ability to trust that area.
I suspect that there are more sites that break with popups disabled than with status bar text and rollovers disabled combined...but we still do it. The main reason remote websites have so much control over browsers today is because of a Microsoft-started prescedent of trusting websites, of treating web developers as application developers. They aren't. Every website you visit just plain isn't trusted, and there should be much tougher rules on what websites can do to a browser. Allowing a website to, say, change the appearance of widgets is, IMHO, unacceptable.
May we never see th
A browser that kills your machine every hour? I suppose it will be all the kernel level drivers that Mozilla installs that cause that. Oh wait, it doesn't have any. Mr Senior IT Manager for a Corporate, you should know that a userland app should never be able to take down an OS, Windows or not. And you'd know that more often than not, XP is configured not to display a blue screen, but just to reboot. My advice? Check that it is configured to stop on a crash. Apply all the patches. Disable services you don't need. Use Firefox again, and see if it crashes the OS. If it does, make a note of the info on the blue screen, and Google for it. Try swapping the memory/cpu with another similar machine.
But don't go blaming Firefox for crashing your machine.
Get your own free personal location tracker
But to make it a standard on the web, Mozilla has to want it.
It doesn't matter if only a part of it is implemented, html or css isn't 100%ly implemented either, so include SVG in the default build
SVG support is already good enough for most uses.
I can tell users to "download Mozilla version x.y or above", I can't tell them to "download that special SVG-build, but you won't get any localization and everytime you upgrade you will lose SVG".
So the sad state of affairs is that solely because of political reasons SVG in Mozilla is completely worthless and I would advise users to download the Adobe plugin instead.
Konqueror comes with SVG-support out of the box in the default build and it's what I already use for some admin interfaces (where I am the only user) to rotate text (a real shame that you can't do that with HTML. But it's currently the only use I have for SVG and Mozilla could do it if they wanted to.) - because even I am too lazy to mess with specialized builds for Mozilla.
I've tried the SVG-build half a year ago and it was at that time working really well and was technically probably better than Konqueror's current implementation. But because of moronic politics, SVG in Mozilla will continue to rot away completely useless in real life while Konqueror will have lots of SVG users (and bug-reporters) and will improve fast and overtake Mozilla soon.
There were times when Mozilla was really leading development, unfortunately the Mozilla project got obsessed with the idea to dumb everything down and even throw out advanced features (like MNG support!). The future belongs to KHTML and Konqueror, that project has dynamics, the will to improve and is not hindered by politics. Apple has seen that and that's exactly the reason why they chose KHTML over Gecko, IMO.
That all said, I really hope that Mozilla wakes up and proves me wrong. Mozilla is currently the only real cross-platform browser, which is a great advantage over KHTML. Gecko is also a great rendering engine. Include SVG in the default build. NOW.
To all the above posters - this is an INTERNAL document which happened to be released to the public. There is no reason to think that they would make it pretty for other browsers when they only ever intended to properly use it once, and on a Mozilla browser.
Free iPods - now in the UK!