> The design goal of Mozilla (and IE) was to allow > these tricks without touching the source. Of > course, if you run into a bug, it's easier to fix > with Mozilla.
That's actually a big deal. That's why "Galeon" is actually *good* for the core Mozilla project: because if Galeon becomes popular, fixes and improvements to Gecko will find their way back to Mozilla.
The difference is that Netscape has repented and thrown everything into Mozilla, with total committment to standards compliance and open source, even though this has cost them dearly in market share.
Microsoft, on the other hand, has never repented of anything.
Netscape did wrong in trying to capture the Web. However, they have now repented and are doing the right thing with Mozilla: total standards compliance, and open source as well. They've paid a big price: doing the right thing has cost them time and market share, as they knew it would. For this they deserve commendation, forgiveness, and aid.
The sidebar is tiny. Skinnning isn't much work either, once you have XUL.
XUL is the thing that adds weight. But it makes development much easier because now, each part of Mozilla's UI only has to be implemented once instead of three times as was required in Netscape Classic (Win, Mac, X). It also means that ports of Mozilla to other platforms (OS/2, BeOS, and others) are far easier.
XUL means that when some Linux user adds a nice UI hack, Windows users get it too. XUL means that if you want to hack the UI yourself, all you need is a text editor and and some knowledge of Web standards (Javascript, XML, CSS, DOM), plus a quick tutorial in XUL: http://www.mozilla.org/xpfe/xulref/
For one thing, Microsoft's implementation of XML namespaces is nothing like the standard, so scripts that try to manipulate XML content through the DOM just won't work if they depend on namespaces. And namespaces are a very important and useful part of the XML standards.
Those links you included point to documents about writing C++ code that goes into Mozilla. They do not support the statements you made. Were you hoping no-one would look?
Now, it is true that there are W3C recommendations that Moz doesn't fully support yet (e.g. SVG, a few small bits of DOM2). However, the important facts are that Mozilla does implement more of the standards correctly than any other browser, and that the Mozilla community is fully committed to finishing the job as quickly as resources allow.
It is also true that Mozilla has created its own "standards" in areas where the W3C standards are incomplete or inadequate (XBL, a few CSS extensions). However, these extensions are being proposed to the W3C when that makes sense, they aren't being pushed on Web developers, and they are based on and compatible with existing W3C standards whenever possible. Furthermore, because Moz is open source, whatever extensions it supports are open to the whole world; there can never be any hidden features that only one group knows about, and an open-source implementation of those extensions is always available.
I know a number of people at MSR. Some of them are my friends. Unfortunately, it is definitely the case that MSR people --- even those at MSR Cambridge --- are as brainwashed about the company as are the other employees. It's quite sad.
They're certainly just as smart as they used to be, but then, a lot of the regular employees are talented too. Their talent is just directed differently.
Tim Rowley is not a Netscape developer. No resources were taken away from other parts of the browser to get MNG in. If he wasn't working on MNG, he probably wouldn't be working on any other part of Mozilla either (except for PNG maybe).
Animated images are quite useful in the context of Mozilla-the-toolkit. For example, the animation in the throbber in the top right corner of the browser is trivially implemented as an animated GIF.
It's all about lag time. You can't replace a basic format like GIF until some very high % of your users can view the new format. This takes years. You just have to be patient.
All the more reason to get the new formats supported by browsers ASAP, of course
> I want support for the real standard, not the > browser's own personal "new standard"
With Mozilla, that's exactly what you get: the best support for W3C standards. Check out any of the 3rd party test sites, e.g. http://www.richinstyle.com Look at the new stuff that's being added right now: SVG, MNG, XSL, MathML, and more. All true, open, non-Netscape standards. (How many of those are even being worked on for Opera?) And where's Opera's DOM1/DOM2 support?
> The most recent versions of Mozilla are just > about catching up with the early v3.x versions > of Opera in terms of funcionality
In the UI, perhaps. In terms of standards support, however, Mozilla is already far head of any Opera version.
Java is already in an optional module which is not even included in the default distribution.
Mail and news are already optional modules that just happen to be bundled in the default distribution. They are never loaded into memory if you don't use them. I agree that someone should produce a Mozilla-browser distribution that includes the minimum modules required for browsing; it would be very easy to do. I'm sure someone will do it sooner or later.
The entire UI is built out of Javascript and DHTML, so you can't lose those without writing your own native UI. Some people are actually doing that, just using the Gecko browser widget in their own applications (Eazel). You still can't remove DHTML capability from Gecko though (or at least it wouldn't profit you much if you did). The reason is that the big cost of DHTML is supporting "incremental everything" --- on the fly dynamic parsing, re-styling, re-layout and re-rendering as the document changes underneath you. That's not a feature you can just add or remove, that's a fundamental design principle.
There is a lot of work to be done on reducing Mozilla's footprint. I'm sure it can be made much lighter than it currently is. A lot of people are interested in putting it to work in small devices, so I'm sure this work will be done.
DHTML based on W3C standards (XML, DOM2, CSS2) is incredibly powerful. You can build all kinds of stuff with it: plain Web pages, presentations, interactive Web pages, games, application user interfaces, whatever.
Of course it can be abused. So what? Indeed, it is useful to have some control over what gets displayed; DHTML browsers can give you that just as Opera can. Mozilla supports user style sheets, for example, in which you can override anything you want.
> Instead, we have to deal with a big, ugly morass > of disgusting pages that should have been just > rendered to PDFs....
PDF has almost nothing in common with DHTML. Hint: the D stands for Dynamic.
DHTML can be abused, but it can also be used for amazingly cool things. You will want a DHTML browser sooner or later.
You cannot simply bolt DOM support onto your browser as just another feature.
If you don't support the DOM, then you're simply dealing with static documents that are loaded once and don't change after that. If you want to support the DOM, then you have to deal with dynamic documents that can change in arbitrary ways after they're loaded. That means you need to support *incremental* parsing, styling, layout and rendering (as well as provide all the DOM glue and so on). It means that you get to rewrite your browser engine, basically, and it's a LOT harder than the static case.
IE and Mozilla have tackled this problem. As far as I know, other browsers have not.
I haven't tried it, but I too think that HTML/Javascript might be a good idea. It has some features that are good for beginners, if not for more mature programmers, like not having to predeclare variables.
It also scales nicely: you can start writing straight-line "global" code, then introduce functions, then introduce objects.
It also teaches C syntax, which will help get them into Java and C later.
You can build displays in HTML/CSS, which don't really require programming skill, and then script them with Javascript. That's a nice learning curve, and gives you nice concrete structures to manipulate with your programs.
You can build interfaces and graphical stuff (very COOL graphical stuff soon, with SVG), and do lots of other things, using the powerful libraries built into modern browsers.
Another nice thing is that when you've done something, you can put it on the Net and show all your friends, or email the results around.
Also, these skills are very useful and marketable.
That's how I got started in programming! For my first computer, my dad lugged home an old DTC-80 machine from work. The 8" floppies that came with it had exactly two useful programs on them: MS-BASIC, and a Fortran compiler. Of course no-one I knew had ever heard of this thing so there was no hope of "trading" software. So I started playing around with MS-BASIC and trying to clone the stuff I'd seen on other people's machines, in magazines, etc.
Unfortunately, today there are so many games, and they're so good, that there's little incentive for kids to do anything but use what's there.
Actually the original poster was wrong. Client-side scripting, including DOM access, IS one of the goals of this project; you can read about it in netscape.public.mozilla.xpcom. Basically Activestate are going to go through the code and rip out all the Javascript-specific assumptions. It's going to rock!
The truth is, that they have to do client-side scripting to make this really useful, because building an application in Mozilla basically depends on the client-side scripting functionality.
MS was driven to support multiple scripting engines in IE3 because 1) they HAD to support Javascript (and still do) because everyone uses it and 2) they wanted to provide an MS-owned alternative, VBScript, that they could try to push people to use and get locked into.
Slashdot Mirror
Funny you should mention that. My patch showing tooltips for TITLE attributes was just checked in. Try a build from the last few days.
(The "Location:" tooltips on all anchors were not my idea and hopefully they'll be removed soon.)
This is not unreasonable.
If Netscape management thinks other bugs are more important than this bug, then Netscape's engineers will fix those other bugs first.
If you think this bug is most important, then you're free to assign whatever engineering resources you have to fixing this bug first.
> There are still plenty of things in the HTML spec
> I don't see support for.
Such as?
> The design goal of Mozilla (and IE) was to allow
> these tricks without touching the source. Of
> course, if you run into a bug, it's easier to fix
> with Mozilla.
That's actually a big deal. That's why "Galeon" is actually *good* for the core Mozilla project: because if Galeon becomes popular, fixes and improvements to Gecko will find their way back to Mozilla.
The difference is that Netscape has repented and thrown everything into Mozilla, with total committment to standards compliance and open source, even though this has cost them dearly in market share.
Microsoft, on the other hand, has never repented of anything.
Netscape did wrong in trying to capture the Web. However, they have now repented and are doing the right thing with Mozilla: total standards compliance, and open source as well. They've paid a big price: doing the right thing has cost them time and market share, as they knew it would. For this they deserve commendation, forgiveness, and aid.
The sidebar is tiny. Skinnning isn't much work either, once you have XUL.
XUL is the thing that adds weight. But it makes development much easier because now, each part of Mozilla's UI only has to be implemented once instead of three times as was required in Netscape Classic (Win, Mac, X). It also means that ports of Mozilla to other platforms (OS/2, BeOS, and others) are far easier.
XUL means that when some Linux user adds a nice UI hack, Windows users get it too. XUL means that if you want to hack the UI yourself, all you need is a text editor and and some knowledge of Web standards (Javascript, XML, CSS, DOM), plus a quick tutorial in XUL:
http://www.mozilla.org/xpfe/xulref/
For one thing, Microsoft's implementation of XML namespaces is nothing like the standard, so scripts that try to manipulate XML content through the DOM just won't work if they depend on namespaces. And namespaces are a very important and useful part of the XML standards.
Independent sites such as http://www.richinstyle.com disagree with you.
Those links you included point to documents about writing C++ code that goes into Mozilla. They do not support the statements you made. Were you hoping no-one would look?
Now, it is true that there are W3C recommendations that Moz doesn't fully support yet (e.g. SVG, a few small bits of DOM2). However, the important facts are that Mozilla does implement more of the standards correctly than any other browser, and that the Mozilla community is fully committed to finishing the job as quickly as resources allow.
It is also true that Mozilla has created its own "standards" in areas where the W3C standards are incomplete or inadequate (XBL, a few CSS extensions). However, these extensions are being proposed to the W3C when that makes sense, they aren't being pushed on Web developers, and they are based on and compatible with existing W3C standards whenever possible. Furthermore, because Moz is open source, whatever extensions it supports are open to the whole world; there can never be any hidden features that only one group knows about, and an open-source implementation of those extensions is always available.
This is very very close to being fixed. Search for "session history" in Bugzilla.
I know a number of people at MSR. Some of them are my friends. Unfortunately, it is definitely the case that MSR people --- even those at MSR Cambridge --- are as brainwashed about the company as are the other employees. It's quite sad.
They're certainly just as smart as they used to be, but then, a lot of the regular employees are talented too. Their talent is just directed differently.
Tim Rowley is not a Netscape developer. No resources were taken away from other parts of the browser to get MNG in. If he wasn't working on MNG, he probably wouldn't be working on any other part of Mozilla either (except for PNG maybe).
Animated images are quite useful in the context of Mozilla-the-toolkit. For example, the animation in the throbber in the top right corner of the browser is trivially implemented as an animated GIF.
It's all about lag time. You can't replace a basic format like GIF until some very high % of your users can view the new format. This takes years. You just have to be patient.
All the more reason to get the new formats supported by browsers ASAP, of course
> Opera will be able to display the most fancy,
> hyped up pages around..in due time.
Yeah, once they've rewritten it to support dynamic documents. And then we'll need to reevaluate how fast and light it is.
One reason is that people are still regularly finding and fixing bugs with comments like "wastes 50-100K on startup".
> I want support for the real standard, not the > browser's own personal "new standard"
With Mozilla, that's exactly what you get: the best support for W3C standards. Check out any of the 3rd party test sites, e.g. http://www.richinstyle.com
Look at the new stuff that's being added right now: SVG, MNG, XSL, MathML, and more. All true, open, non-Netscape standards. (How many of those are even being worked on for Opera?) And where's Opera's DOM1/DOM2 support?
> The most recent versions of Mozilla are just
> about catching up with the early v3.x versions
> of Opera in terms of funcionality
In the UI, perhaps. In terms of standards support, however, Mozilla is already far head of any Opera version.
Java is already in an optional module which is not even included in the default distribution.
Mail and news are already optional modules that just happen to be bundled in the default distribution. They are never loaded into memory if you don't use them. I agree that someone should produce a Mozilla-browser distribution that includes the minimum modules required for browsing; it would be very easy to do. I'm sure someone will do it sooner or later.
The entire UI is built out of Javascript and DHTML, so you can't lose those without writing your own native UI. Some people are actually doing that, just using the Gecko browser widget in their own applications (Eazel). You still can't remove DHTML capability from Gecko though (or at least it wouldn't profit you much if you did). The reason is that the big cost of DHTML is supporting "incremental everything" --- on the fly dynamic parsing, re-styling, re-layout and re-rendering as the document changes underneath you. That's not a feature you can just add or remove, that's a fundamental design principle.
There is a lot of work to be done on reducing Mozilla's footprint. I'm sure it can be made much lighter than it currently is. A lot of people are interested in putting it to work in small devices, so I'm sure this work will be done.
DHTML based on W3C standards (XML, DOM2, CSS2) is incredibly powerful. You can build all kinds of stuff with it: plain Web pages, presentations, interactive Web pages, games, application user interfaces, whatever.
Of course it can be abused. So what? Indeed, it is useful to have some control over what gets displayed; DHTML browsers can give you that just as Opera can. Mozilla supports user style sheets, for example, in which you can override anything you want.
> Instead, we have to deal with a big, ugly morass > of disgusting pages that should have been just > rendered to PDFs....
PDF has almost nothing in common with DHTML. Hint: the D stands for Dynamic.
DHTML can be abused, but it can also be used for amazingly cool things. You will want a DHTML browser sooner or later.
You cannot simply bolt DOM support onto your browser as just another feature.
If you don't support the DOM, then you're simply dealing with static documents that are loaded once and don't change after that. If you want to support the DOM, then you have to deal with dynamic documents that can change in arbitrary ways after they're loaded. That means you need to support *incremental* parsing, styling, layout and rendering (as well as provide all the DOM glue and so on). It means that you get to rewrite your browser engine, basically, and it's a LOT harder than the static case.
IE and Mozilla have tackled this problem. As far as I know, other browsers have not.
MSR Cambridge has great people, but has produced almost nothing noteworthy since it was founded.
I haven't tried it, but I too think that HTML/Javascript might be a good idea. It has some features that are good for beginners, if not for more mature programmers, like not having to predeclare variables.
It also scales nicely: you can start writing straight-line "global" code, then introduce functions, then introduce objects.
It also teaches C syntax, which will help get them into Java and C later.
You can build displays in HTML/CSS, which don't really require programming skill, and then script them with Javascript. That's a nice learning curve, and gives you nice concrete structures to manipulate with your programs.
You can build interfaces and graphical stuff (very COOL graphical stuff soon, with SVG), and do lots of other things, using the powerful libraries built into modern browsers.
Another nice thing is that when you've done something, you can put it on the Net and show all your friends, or email the results around.
Also, these skills are very useful and marketable.
That's how I got started in programming! For my first computer, my dad lugged home an old DTC-80 machine from work. The 8" floppies that came with it had exactly two useful programs on them: MS-BASIC, and a Fortran compiler. Of course no-one I knew had ever heard of this thing so there was no hope of "trading" software. So I started playing around with MS-BASIC and trying to clone the stuff I'd seen on other people's machines, in magazines, etc.
Unfortunately, today there are so many games, and they're so good, that there's little incentive for kids to do anything but use what's there.
Actually the original poster was wrong. Client-side scripting, including DOM access, IS one of the goals of this project; you can read about it in netscape.public.mozilla.xpcom. Basically Activestate are going to go through the code and rip out all the Javascript-specific assumptions. It's going to rock!
The truth is, that they have to do client-side scripting to make this really useful, because building an application in Mozilla basically depends on the client-side scripting functionality.
MS was driven to support multiple scripting engines in IE3 because 1) they HAD to support Javascript (and still do) because everyone uses it and 2) they wanted to provide an MS-owned alternative, VBScript, that they could try to push people to use and get locked into.