Mozilla Branches For 1.0 RC1
At the end of last month, the Mozilla Project closed the tree for what will become Mozilla 1.0. Now jkeiser writes "Mozilla has branched for 1.0 RC1, which is the first last step to a final Mozilla 1.0! Mozilla has spent four long years getting the browser standards-compliant, fast and solid. Cross your fingers for a rockin' final release around the corner." Reader whovian points to the just-modified roadmap, too.
RC1 comes out tentatively this week (I'm on the build and release team).
The strange result is that 1.0.3 is scheduled to be released about a month after the final 1.1. Are they really planning something huge for the 1.1 branch that they don't trust themselves to re-merge the tree? I guess there is precedent for this, with Netscape 4.08 being released after the 4.5 releases were well on their way. Also, it seems that this is how Linux kernel releases work, with 2.2 still being maintained after the release of 2.4. Still, this is a new policy for Mozilla.
First off, kudos to the Mozilla project team for getting this far... it's shaping up to be an excellent browser especially once you count the security track record of the opposition.
:).
One question I have as a DHTML web designer, is that will v1.0 fix the DHTML timing issues? The v0.98 changelog indicated that "DHTML performance has regressed", which I can verify is putting it lightly -- one of my animations that revealed a DIV via clipping worked fluidly in Moz 0.97 and hardly at all in Moz 0.99, which still hasn't patched it. Check out the "Popup Menu v5" script on my homepage on a slower computer if you want to see what I mean.
A quick search of Bugzilla reveals some articles also mentioning this issue. Does anyone know what plans are afoot to improve this?
I hope DHTML performance improves before this tree is used for another NS6 or AOL browser release, as otherwise it could render some of the more technically involved sites unviewable. If anyone's more involved in Bugzilla than I and knows the bug ID that most work is going into, please post a link to vote for it, otherwise try this one
Apart from that, I'm finding new Mozilla releases to be strides above the versions this time last year. Hopefully once fully mature it'll be the cross-platform web page development environment of choice... that's one area in which IE can never beat it, with the huge differences between IE on Windows and Mac.
More power to the lizard!
<!-- DHTML / JavaScript menu, popup tooltip, Ajax scripts -->
ObMozBugComplaintBitchSlap
In 2 years of reporting 800 bugs, I've been told "fix it yourself" two or three times. Mozilla developers appreciate bug reports and most don't mind an occasional "I think this bug is important because...". If you just go around complaining "This bug has been known for x months" or "I can't believe you didn't fix obscure bug y, nobody will use your browser", you might get that response, but you're more likely to be ignored.
The shareholder is always right.
One of the main things that I still haven't figured out (and I have looked) is how to go to the address bar using the keyboard. In Opera you hit F8. In IE you hit Alt-D. I'm sure Mozilla must have this really obvious feature or people would go insane, but I just can't seem to find it.
h elp/
Ctrl+L. For other shortcuts see http://www.cs.hmc.edu/~jruderma/mozilla/keyboard-
The other thing that's a bit annoying, though has improved greatly since I first tried the 0.9.3 release, is the feeling that Mozilla is a little sluggish. I don't know if it's actually slower rendering an average page than Opera is (perhaps a tiny bit), but it feels slower. Opera seems to get everything worked out in the background before drawing a page; Mozilla seems to draw it as it goes.
What's wrong with incremental rendering? One thing that often annoys me when I use Opera is that it will download an entire 4MB page before displaying anything. Mozilla sometimes does that as well, but we consider it a bug (129640) when it does. Mozilla has an optimization that makes not display anything for the first 1.2 seconds of interpreting a page (unless it finishes in under 1.2 seconds), so once the first screenful of the page appears, you can usually read it while the rest of the page loads quietly.
The shareholder is always right.
That's why the tags in the core HTML describe content like <em> indicates that the text should be displayed with emphasis as opposed to the newer <i> tag that does something similar. HTML marks content with rendering hints, but it's not designed to be able to lay out a page. It's designed to describe rendering hints on a page. Any time HTML is used to lay out a page, it's using a bastardization of tables and using tags that have been removed in HTML 4.01 strict (and are merely deprecated in HTML 4.01 transitional).
CSS (Cascading Style Sheets) is designed to lay out a page. CSS can be applied directly to an XML document (in the spec, maybe not via any tools yet), and it can also describe the page layout. I'd point you to my website that uses CSS to lay out the page, but it's currently offline, so I'll just have to send you to the W3 CSS site. If you're using a CSS compliant browser (Mozilla is the best at rendering it properly but IE works - dunno about anything else), you should notice the menu and the various links scattered about the top of the page that are defined via CSS page lay out rules.
HTML as originally designed is intended to describe sections of a document. At some point, people started developing fancy webpages and HTML 3 was born which included a lot of page lay out tags. However, more recently, with IE 5 and Mozilla, CSS and HTML have taken over for page design, meaning that newer sites can be designed using HTML 4.01 strict with CSS describing how it should be displayed. (This is the preferred, "proper" method.) Historically, HTML was originally designed to define a page structure, delinating paragraphs and lists. With HTML 4.01 it returns to the ideal, while using CSS to allow for fancy page layout.
You are in a maze of twisty little relative jumps, all alike.