Actually the proposal is to require UAs to only treat the code in and "application/ecmascript;version=4" as ES4. No one suggests treating the code in or in as ES4, that would break the existing pages. See http://wiki.ecmascript.org/doku.php?id=proposals:versioning
Pratap Lakshman, Microsoft, is on record saying "We do not support or agree to the current ES4 proposal, either in whole or in part. We intend to continue to work with interested TG members to develop a proposal for a more incremental revision of the current specification." (http://weblogs.mozillazine.org/roadmap/archives/2007/10/open_letter_to_chris_wilson.html http://wiki.ecmascript.org/doku.php?id=meetings:minutes_sep_27_2007#unresolved_proposalsthe_sequel)
There weren't any technical arguments against the proposal from the dissenters as far as I can see, other than it is too large a change from ES3. There was lots of FUD against ES4 on the other hand. This is where the "closing the web" thought comes from; maybe it's not the reason MS is against the proposal, but it's a reasonable explanation of their actions.
However, the way mozilla/firefox does it is not good. As a one time extension developer I can attest to your example. When 1.5 came out, and the entire extension structure changed [...]
Uh, you've probably misunderstood something. The entire extension structure changed to make new extensions easier to write, but old-style extensions are still supported. Sure, much of them broke anyway, but it's not because of the extension structure change.
And guess what! They are doing it again for 2.0 the whole extension mechanism is going to be redone once more, so if I update to 1.5, I'll just have to relearn again in a few months.
Huh? That is so not true. There are UI changes to the extension manager and support for cool things like addons blacklisting and extension dependencies, but there's no major breakage anticipated.
Quite the contrary, the existing XPCOM components (even the non-frozen ones) are supposed to stay backwards compatible on 1.8 branch, and people try not to make changes to permanently-unfrozen UI code without a reason. Of course some extensions will still break (e.g. those that extend bookmarks and history), but mozilla devs are trying to minimize the breakage.
Sounds like a bug. Bugs 265406 and 237558 are related.
p.s. Inline spell check would be nice
Inline spellcheck was implementedfor Mozilla Suite by Linspire recently. It will probably be included in future versions of Thunderbird (not necessarily in 1.0).
As far as I know, the extension system will be frozen with 1.0, and from then on, there won't be any incompatibilities. The incompatibilities have been a result of changes, and the changes a result of Firefox's unfinished state.
This is not true. Since most of extensions rely on non-frozen browser code they *will* break.
AFAIK, it is truth. But: I'm using Firefox very intensively, and it never started paging on my PC with only 256MB ram. Never had to kill Firefox neither under Windows nor on Linux.
BTW: You slashdotters are bad, bad, very bad. You./ed my favourite forums!
The major downsides are probably: 1. Users need to spend time downloading and finding out if plugins exist for their needs. Well, in Opera you have to spend time finding out if feature X is included in Opera, and where is it in the UI.
2. Users need to keep up to date with more than the main application if the plugins contain bugs he/she wish to see fixed. This will be done automatically with 0.9's new Extension Manager. It will automatically check for updates of extensions and install them.
3. Inexperienced users who aren't used to plugins, users with a lack of patience, or users who don't want to spend time to tinker with their application to get the features they need might be put off by the lack of features in the main application and switch to another one that's advertised having a larger feature set. Again, IMO inexperienced users are likely to be afraid of way too complex UIs.
For me personally, the process of installing as many as 30 extensions with each Firefox install (on a new PC) is a little annoying.
Slashdot Mirror
Actually the proposal is to require UAs to only treat the code in and "application/ecmascript;version=4" as ES4. No one suggests treating the code in or in as ES4, that would break the existing pages. See http://wiki.ecmascript.org/doku.php?id=proposals:versioning
Pratap Lakshman, Microsoft, is on record saying "We do not support or agree to the current ES4 proposal, either in whole or in part. We intend to continue to work with interested TG members to develop a proposal for a more incremental revision of the current specification." (http://weblogs.mozillazine.org/roadmap/archives/2007/10/open_letter_to_chris_wilson.html http://wiki.ecmascript.org/doku.php?id=meetings:minutes_sep_27_2007#unresolved_proposalsthe_sequel)
There weren't any technical arguments against the proposal from the dissenters as far as I can see, other than it is too large a change from ES3. There was lots of FUD against ES4 on the other hand. This is where the "closing the web" thought comes from; maybe it's not the reason MS is against the proposal, but it's a reasonable explanation of their actions.
Uh, you've probably misunderstood something. The entire extension structure changed to make new extensions easier to write, but old-style extensions are still supported. Sure, much of them broke anyway, but it's not because of the extension structure change.
Huh? That is so not true. There are UI changes to the extension manager and support for cool things like addons blacklisting and extension dependencies, but there's no major breakage anticipated.
Quite the contrary, the existing XPCOM components (even the non-frozen ones) are supposed to stay backwards compatible on 1.8 branch, and people try not to make changes to permanently-unfrozen UI code without a reason. Of course some extensions will still break (e.g. those that extend bookmarks and history), but mozilla devs are trying to minimize the breakage.
Inline spellcheck was implemented for Mozilla Suite by Linspire recently. It will probably be included in future versions of Thunderbird (not necessarily in 1.0).
This is not true. Since most of extensions rely on non-frozen browser code they *will* break.
> Not sure if this is gospel truth
./ed my favourite forums!
AFAIK, it is truth.
But: I'm using Firefox very intensively, and it never started paging on my PC with only 256MB ram. Never had to kill Firefox neither under Windows nor on Linux.
BTW: You slashdotters are bad, bad, very bad. You
The major downsides are probably:
1. Users need to spend time downloading and finding out if plugins exist for their needs.
Well, in Opera you have to spend time finding out if feature X is included in Opera, and where is it in the UI.
2. Users need to keep up to date with more than the main application if the plugins contain bugs he/she wish to see fixed.
This will be done automatically with 0.9's new Extension Manager. It will automatically check for updates of extensions and install them.
3. Inexperienced users who aren't used to plugins, users with a lack of patience, or users who don't want to spend time to tinker with their application to get the features they need might be put off by the lack of features in the main application and switch to another one that's advertised having a larger feature set.
Again, IMO inexperienced users are likely to be afraid of way too complex UIs.
For me personally, the process of installing as many as 30 extensions with each Firefox install (on a new PC) is a little annoying.