New Skin and Another Big Change!
Tuesday October 26th, 1999
The new skin is in the 10-26 builds. Visit our builds page to get the latest. I find myself not minding the whitespace around the sidebar's border as much as I expected I would. However, there is one issue that troubles me. When you move the sidebar's "splitter", instead of moving a "ghost" of the splitter, you move the splitter itself. the problem is that if you're expanding the sidebar, the splitter disengages from the top and bottom border of the sidebar, leaving a white gap. If you shrink the width of the sidebar, the splitter moves past the right edge of the top and bottom borders of the sidebar, and the effect is just as bad. The answer would be to either 1) expand and contract the sidebar in realtime as the splitter is moved (probably slow), or 2) manipulate a "ghost" of the splitter during resize, and when the mouse button is released, move the actual splitter and resize the sidebar.
The second bit of news is that they've made more changes to the "incremental reflow" of the rendering engine. Now, the page will start rendering content even before reaching closing tags. This means a dramatic decrease in the time taken to get content displayed, and it's a great benefit when loading pages with long lists of data. But I find the content shifting disconcerting (check out mozilla.org, mozillazine.org and slashdot.org for examples if you have a 56k connection or slower), and the decrease in scrollbar responsiveness is vexing. Hopefully that will be working on these issues in the coming weeks leading up to the beta.
#1 incremental reflow
Tuesday October 26th, 1999 5:04 PM
incremental reflow is much more important than rendering speed for me. I have a fast computer so rendering isn't a problem for me but I still have to wait and look at the status bar before I can see anything-and sometimes the only thing I get to see is the banner ad. oh and remember the rule: text should always come before graphics
#6 incremental reflow
Tuesday October 26th, 1999 5:53 PM
I would go further than that: when selecting new files (page components) I think Mozilla should have some kind of scoring system that would cause banners and stuff like that to be loaded last.
For example: off-site images should have low priority. Slightly higher priority (but still low) would be for on-site images linked off-site. Unsized and banner-sized images should also be downgraded. Things linked with relative links should be upgraded.
#11 incremental reflow
Tuesday October 26th, 1999 9:34 PM
No. Breaking the ad banner model will only benefit users and Mozilla in the short run:
1. Sites will develop new banner technology that gets a higher score, and will begin mixing advertising and editorial more often. One of the big advantages of the banner ad model is that ads *look* like ads. Sites that don't have this capability, well, who needed them anyway?
2. Advertisers and sites that depend on advertising revenue will discourage Mozilla, either by active support of IE-specific technology, or simple benign neglect. Why should Yahoo or Alta Vista give a damn about a browser deliberately engineered to sabotage their revenue stream?
3. When the ad banner model goes, what replaces it? More pay sites? Mandatory registration with demographic information and no opt-out for junk mail? Sites just plain shutting down?
If you want to get rid of ads, install and improve the several proxy servers designed for ad blocking. Don't poison Mozilla with this, because in the long run it only makes IE look more and more reasonable for the companies that decide whether or not you can use their Web.
#12 incremental reflow
Tuesday October 26th, 1999 9:54 PM
I disagree here. I believe that the purpose of the Mozilla project is to build the best browser possible *for the user of the browser*. It is not a product designed for commercial gain, and design decisions should not be made as such. I'd like to see cookie-control and banner-ad-suppression built in...and in fact, I suspect that they will be, sooner or later, because someone will want them enough to put them in. Whether they make it into Netscape's distribution is, of course, up to Netscape.
#23 Nothing wrong with Living in the Real World
Wednesday October 27th, 1999 10:17 AM
I'll agree: Let's build the best browser for the user. But advertisers will easily circumvent a simple check like banner size. And I like banner sized ads - you can tell it's an add even before the graphics load. So users, seeing as they live in the real world, are going to face the consequences of more annoying ads. I don't like software that is going to encourage this.
That said, I am looking forward to when someone builds an ad-blocker plug in. If I had the free time, I'd be investigating it myself (but who has free time).
Of course, I also agree: text before graphics. and offsite graphics loading last makes sense to me.
#16 incremental reflow
Wednesday October 27th, 1999 12:35 AM
No don't get rid of the ads. Just don't make them (or any graphic) load first before the content.
#20 Ad Model
Wednesday October 27th, 1999 5:53 AM
banner ads will bite the dust eventually anyway. there's just no way the current system will sustain itself long term. I think you are being overly alarmist here.
I also think it is a good idea to load images with off site origins last. They are likely to be the largest images on the page and people shouldn't be held hostage to problems connecting to other servers before they can read the content they came for.
That said, showing text before graphics would alleviate the need for this quite a bit.
#49 Old discussion, new engine...
Thursday October 28th, 1999 7:28 AM
This has been on the list of things to do inside Netscape for as long as I can remember - over three years now. The idea of prioritizing netlib so that it could be told to give a higher priority to loading things which were actually on-screen, and loading things which came from the server the document was on before loading images offsite within a priority scheme... it's worth mentioning again, as it might be a lot more possible with the new netlib, but the old netlib just couldn't easily be twigged to do it.
Bring it up in the newsgroups, or file it as a bug/feature - it's worth mentioning.
#63 incremental reflow
Tuesday November 2nd, 1999 3:45 AM
That's why I use IE5. Display text, then graphics.
#2 No skin
Tuesday October 26th, 1999 5:36 PM
I downloaded the win32 build for 10/26 and the skin is the same.
#4 Don't know how that happened
Tuesday October 26th, 1999 5:42 PM
I downloaded it, and it was the new skin.
#8 My Impression
Tuesday October 26th, 1999 9:04 PM
I think the skin is a step in the right direction, but it too contrasty. Looks like an updated throbber is due too.
The sidebar is much different, and needs to make more efficent use of the space. The old style had its advantages, but could most accomodate large peices of info. The new design can, but then you can only see one "window" at a time.
I am sure it will all get ironed out.
#3 No skin
Tuesday October 26th, 1999 5:37 PM
I downloaded the win32 build for 10/26 and the skin is the same.
#5 Call me old fashioned...
Tuesday October 26th, 1999 5:53 PM
...but I still like the look of all the old Netscape browsers I'm used to.
Will there be a retro-skin shipping, sans sidebar, and with all the buttons across the top, please ? (Especially "Find in Page" -- why did this ever get the chop ?)
#18 You can hide the sidebar ...
Wednesday October 27th, 1999 1:24 AM
With a single mouse click.
And rest assured, people will be creating skins to imitate every browser under the sun -- I note that Chromezone http://www.mozillazine.org/chrome/ has skins mimicking Navigator 3 and IE 4 already.
#7 first impressions
Tuesday October 26th, 1999 7:56 PM
Its a good skin. I still don't like the look but its functional and they finally got the disabled buttons with opacity: 0.5; going :)
The icons are okay but I can't figure out why some of them have circles around them and others only have the circles over them when I mouse over (Messenger). Some sort of grouping scheme although I don't see it right now. On second though it looks like anything to do with composing has circles and anything to do with nav. doesn't.
The search the internet dialog has white on white text... tweaking needed there :)
Other than that I can just say I like how little space it takes up.
PS The incremental reflows are cool, although I have a hard time scrolling the page while its happening. I guess that will come with time.
#9 New Skin and Another Big Change!
Tuesday October 26th, 1999 9:08 PM
Curse this slow-@$$ 33.6 modem -- I wanna check this out NOW. :-)
#10 Hacking on this new skin
Tuesday October 26th, 1999 9:22 PM
Since I downloaded the latest build, i've been messing around with the CSS files... mostly because I don't find the new skin too attractive. I guess that's because my taste in UIs is pretty "boring" and minimalistic. So this is how I tweaked it: http://members.home.com/decklin/temp-screenshot.png And here's the patch file: http://members.home.com/decklin/temp-mozillaskin.patch take it and hack some more on it! email comments to firstname.lastname@example.org.
#13 Forget the stinking skin...
Tuesday October 26th, 1999 10:01 PM
This build is AWESOME. So much fixed stuff. The RDF/Flash stuff is WAY improved. At first I didn't like the MAC feel, but I really like it now. More than anything I like the fact that it can be so radically different. I can't wait for some graphics wizards to start creating skins for this stuff!
I love the incremental reflow as well. I am excited about moving closer to beta on this! Mozilla team u guys/gals are awesome!
#14 The XUL Bandwagon
Tuesday October 26th, 1999 11:15 PM
I like this new skin and now I wanna learn XUL! Now where do I go about doing that? Thanx!
#17 Re: The XUL Bandwagon
Wednesday October 27th, 1999 12:53 AM
This would probably be the place to start:
#15 Another Incremental Question
Tuesday October 26th, 1999 11:37 PM
Okay, I noticed that something was different about the rendering as I was surfing a few sites using Mozilla.
Now I have a question about incremental reflow: does the rendering engine rerenders/adjusts the page each time it downloads a certain number of bytes or each time after a certain time interval?
I have a high speed connection (the wonders of college life) and while I can see the page render as it downloads, the rendering seems to be slowed by the fact that it has to render it constantly as it download more of the page.
I figured that this won't be a problem when downloading with a modem.
Not completely sure but it seems that way on my decent running PC.
#21 Another Incremental Question
Wednesday October 27th, 1999 7:41 AM
no kidding! i'm on a t3, and the rendering time to complete a page looks like its gone up quite a bit!
#35 RE:Another Incremental Question
Wednesday October 27th, 1999 5:09 PM
I heard that netlib ( a.k.a necko) still slower than rendering. See this bug: http://bugzilla.mozilla.org/show_bug.cgi?id=11677
they have made some improvements but you might want to bring to their attention that it is still not fast enough. ;-)
#19 After a certain number of bytes
Wednesday October 27th, 1999 1:35 AM
From Vidur Apparao's posting http://www.deja.com/=dnc/getdoc.xp?AN=540804219 :
`The old content sink did content append notifications with a fairly coarse granularity (only for complete children of the BODY element). As a result, frame creation (and, hence, display) for pages that had the bulk of their content in a single table or some other container was delayed till the entire page loaded.
`With the new changes, frame creation happens every time we are done with a buffer passed in from the networking library, irrespective of where we are in the content hierarchy. Subsequent content created by the sink is added more incrementally to the content model.'
#22 Mac: no go
Wednesday October 27th, 1999 9:47 AM
How come I can't download the Macintosh Nightly build???
#24 Get the user involved?
Wednesday October 27th, 1999 10:28 AM
What about some type of user defined stats? Like maybe I'm happy to let the whole thing repaint itself all at once... unless it takes longer than 10 seconds, then I want incremental updates every ten seconds or something. People with faster connections won't see choppy displays as often, while with big sites/slow connections, we can all start reading a little sooner.
I dunno.. make any sense at all?
#25 Get the user involved?
Wednesday October 27th, 1999 11:37 AM
I agree. I don't like seing content shift for the duration of a download. That's what I don't like about IE. I would use 5 seconds instead of 10 to switch to reflow mode.
#27 Get the user involved?
Wednesday October 27th, 1999 12:27 PM
interesting ... but many users (for the commercial audience later anyway) would certainly NOT understand any of this ...
but hey, great for us!
#57 Get the user involved?
Friday October 29th, 1999 11:07 PM
Can't they just set up some good default setting for users who don't understand it all? Maybe setting it to redraw every 5 seconds for people with adequate processor and connection speed, and some other setting for everybody else. The settings could still be adjustable for picky people who understand it better.
#28 Get the user involved?
Wednesday October 27th, 1999 1:07 PM
I also think that's a very good idea. Why let slow computers or fast connections do a lot of re-rendering, when people can select not to do this...
Would be great if that would be implemented. Did you post it to some mozilla newsgroup or bugzilla as wanted feature???
#29 It's already at Bugzilla
Wednesday October 27th, 1999 1:40 PM
It's already submitted to Buzilla (bug #17325) so add further details or info if you want:
#26 incremental reflow
Wednesday October 27th, 1999 12:24 PM
just curious ... how this impacts pages with scripts ... I'm sure the mozilla folks have all this well in hand, but pages with dynamic content, document.writes, external scripts, <script> tags in places other than the <head> ... man what a headache ...
loving it ...
#30 Newbie Question
Wednesday October 27th, 1999 3:03 PM
I downloaded the win32 nightly build, but how do I start the app? The milestones come with a file called apprunner.exe, don't they?
#32 Newbie Question
Wednesday October 27th, 1999 3:34 PM
No more apprunner.exe, try mozilla.exe
#43 Newbie Question
Wednesday October 27th, 1999 8:31 PM
I tried that, but it just exited without an error message of any kind. Then I remembered the mozregistry.dat file needs to be deleted from the windows dir(oops). It's working now.
#48 Why not put a README file in the nightly builds
Thursday October 28th, 1999 6:54 AM
Why isn't there a README file in all the milestone and nightly builds whick could remind users to delete c:\winnt\mozregistry.dat and the name of the executable file that they should run.
#31 My thoughts...
Wednesday October 27th, 1999 3:26 PM
To be completely honest, for a change, I must say I not in any way like the new skin.
It does not in any appeal to me. The Personal Toolbar folder is located ina very weird place and looks horrible. The circular buttons are plain stupid-looking to me, and there are also (in my build, 10-26 on Mac OS 8.5) some things that must be plain mistakes, like totally misplaced colours etc.
Like someone said - a NeoPlanet skin - made by a 45-year old man that wants to impress his 14-year old son that thinks WinAMP skins is the greatest thing.
The GUI shall be functional, and while still maintaing functionality, appearance can be polished.
Yeah I know my look upon these things might sound a little bit fascist, but a change in this direction was _not_ something I expected from the Mozilla/Netscape team.
To be a bit positive, "incremental flow" feels alright. Maybe a bit choppy at times, but overall it's good.
And another thing: what is going to be done about the very, very slow-loading contextual menu's (on mac, 10-26, 8.6, g3 300, 192mbram...) ?
#40 My thoughts...
Wednesday October 27th, 1999 6:57 PM
try to revive this bug http://bugzilla.mozilla.org/show_bug.cgi?id=15916
#33 New Skin and Another Big Change!
Wednesday October 27th, 1999 4:29 PM
I think this is a good start. There are lots of improvements that can yet be made, however I think it is a solid beginning. I, for one, am not interested in going back to a traditional skin - this is a new & innovative browser, it should have a new and innovative skin...
#34 Style applied _after_ loading?
Wednesday October 27th, 1999 5:02 PM
I've noticed that on pages with style sheets, the initial formatting seems to disregard the styles, which are then layered on afterwards. This makes loading these pages really annoying, as they look really ugly while loading and then suddenly "jump" into being correct.
#37 Style applied _after_ loading?
Wednesday October 27th, 1999 5:45 PM
See bug #17309.
#66 style sheets aren't cached
Thursday November 4th, 1999 7:23 AM
Part of the current problem is that style sheets aren't being cached. When that is fixed, a lot of the annoyance will go away.
#67 Your problem, my friend....
Thursday November 4th, 1999 8:24 AM
Is solved. Hyatt and Waterson have gotten the XUL cache going, and I think it also caches the CSS files. :)
#42 Style applied _after_ loading?
Wednesday October 27th, 1999 7:30 PM
Oddly enough, this is the way I've always expected it to happen - and I don't mind it. The main page is downloaded, if there is an external .css file its download is started after the main page - thus it can get a little behind. When the .css file comes in the engine reapplies it and thats where you see the jump. If the .css is included inside the html file I'm sure you wouldn't see this.
This was probably happening in 4 but it was so slow and refreshed so often I don't think you noticed it :) I did notice it with the bitstream fonts in 4 if I can remember correctly.
#44 Style applied _after_ loading?
Wednesday October 27th, 1999 8:43 PM
I'm certain that it doesn't happen the same way in NS4. Mozilla seems to demonstrate this behavior even if loading the page from a local web server or even from cache. This seems a bit silly. If you're designing a web site, you want your users to have a nice experience as they navigate the site, with a minimum of weirdness. And reformatting like this really seems like weirdness.
(I'm going to research this a bit more, and then it's off to bugzilla to add comments to the existing bug mentioned above...)
#47 Style applied _after_ loading?
Thursday October 28th, 1999 6:25 AM
What if the style sheet doesn't exist on the server or the download of it craps out half way? I still want to be able to read the text - I don't care if it looks how its intended to look. Or the style sheet could be on a really slow server. I'd much rather see the page now as opposed to waiting for the css file to come across.
On my connection (ADSL) the jump isn't that bad and a couple of weeks ago when I was still on 33.6 I still didn't find it annoying enough to complain about it.
#64 when to apply styles
Wednesday November 3rd, 1999 1:25 PM
Sure, if there's problems with getting the stylesheet, go ahead and display as-is. But if the stylesheet is already cached, it makes sense to use it.
The speed of your connection doesn't matter -- the jump is obvious and annoying when browsing <I>local</I> files.
#36 Skin transparency? + responsiveness
Wednesday October 27th, 1999 5:42 PM
Secondly, I know skins now use XUL/XML?, but does that allow for transparency at all? Can you make a BeOS type titlebar with it (only the part of the titlebar with text on it is solid, the rest is transparent?). A BeOS titlebar is aligned to the left side of the window, would XUL allow me to align it to the right side while having the left transparent and dynamically resized as titlebar text changes? (If transparency is even possible?)
#41 Re: Skin transparency?
Wednesday October 27th, 1999 7:24 PM
No, you can't have "holes" in the window. Images/text etc can be transparent/translucent (Translucent text looks kinda cool in some places)
#52 this is a browser...
Thursday October 28th, 1999 5:44 PM
...not winamp! we all (hopefully) know that there are really important things that are still not finished and there are tons of bugs (naturally) in the code currently.
let's focus on important parts of the project!!
also, you wrote: "I hope mozilla just figures out how to incrementally render like IE5" hey - as if microsoft has ever done a superb job on coding good software ;-) (just a joke, don't want to start a flame war again...!)
#38 Bug report on rerendering.
Wednesday October 27th, 1999 5:46 PM
Those who don't like rerendering may want to check out http://bugzilla.mozilla.org/show_bug.cgi?id=17322 .
#39 New Skin and Another Big Change!
Wednesday October 27th, 1999 5:51 PM
I put some screenshots at http://www.micropop.com/mozilla/screenshots.html (Linux). My favourite is the one of Spanish Yahoo translated into English ;)
#45 New Skin and Another Big Change!
Wednesday October 27th, 1999 8:49 PM
On my aging Cyrix 120 Win98, incremental reflow, well, doesn't. The page is blank until all the data rolls in, then it gets dumped on the screen. However, on a P2/300 also with Win98, it is very good.
Hopefully the Mozilla team have got heaps of optimisations to find and implement. Otherwise I fear Mozilla will not be good for people with machines slower than a 300.
#46 Browser or web page?
Wednesday October 27th, 1999 8:58 PM
I'm impressed with the possibilities of this technology, but the current skin is not to my taste. It looks too much like a part of the web page I'm displaying. It's hard to look at! It's nice to see exactly where the content ends and the broswer gui begins. Maybe some bevelling would help?
The project seems to be progressing rapidly... I can't wait for the beta!
#58 New Skin and Another Big Change!
Friday October 29th, 1999 11:53 PM
No, this skin isn't quite to my taste either....
#50 More Frequent Crashes?
Thursday October 28th, 1999 3:02 PM
Ever since incremental reflow, has anyone else been experiencing a significant increase in Mozilla crashes?
Well I have, not sure if the issues are related but I want to see if anyone else is experiencing anything similar, thanx
#51 Dislike of incremental reflow
Thursday October 28th, 1999 5:40 PM
Make it optional! It may _feel_ faster, but it's damned annoying to stab at a link, only to have it shift out from under you, and another take it's place before your finger finishes the motion. This behaviour is (IMO) the worst feature of MSIE and Mozilla. However, some people like it. Make it OPTIONAL.
#53 hmmm, scripts?
Friday October 29th, 1999 3:29 AM
As a web developer i am worried about scripts and their correct functioning - like if you need to pur random generated number (like in ads) on few instances - if it renders the page continuosly - it will break down the script...or maybe they thought of this? gonna go check :)...go mozilla, go!
#54 Braindamaged Windoze Scrollbars
Friday October 29th, 1999 6:59 AM
A question...I notice on some of the builds that at least one of the left-side panels has a NeXT-like scrollbar instead of the standard Windows scrollbar.
Is there any plan to replace the stock Windows scrollbar with this kind of scrollbar? I hope so. I HATE the way Windows deals with scrollbars...ie if you move your pointer off the scrollbar while scrolling it jumps the whole document back up to the top.
#55 Braindamaged Windoze Scrollbars
Friday October 29th, 1999 8:50 AM
Eventually, yes. I think that's postponed until after beta 1, though (there are some pretty serious issues with the scrollbars, and they don't want to mess anything up that's working before beta, as they have enough bugs as is). I must say, though, I wouldn't mind scrollbars that act as they do now but that look similar to the ones on the specific platform (Windows isn't so bad, but Mac scrollbars are supposed to look like all other Mac scrollbars according to Apple).
#59 But I thought that was a GOOD thing ...
Saturday October 30th, 1999 8:22 AM
It's entirely consistent for a scrollbar to snap back to its original position if you move the mouse too far away. MacOS scroll bars do this, as well as Windows ones.
Why? Because that's the way other GUI widgets work -- buttons, menus, checkboxes, etc, all allow you to cancel a selection in mid-click by dragging the pointer off the control. (The exception to this is items which are meant to be dragged and dropped, but there's usually a `do-nothing' zone you can drag them to anyway.)
With scroll bars, it's the same -- if you drag the mouse too far away from the scroll bar, it starts assuming that you didn't mean to scroll at all. And this feature can be very useful, if you want to do a quick scroll around a large document and then snap back to where you were.
But I'm getting way off-topic here, so I'll stop. :-)
#65 Wheel mice do not work with the new scrollbars
Thursday November 4th, 1999 6:50 AM
If you turn on the gfx scrollbars in mozilla rather than use the platform specific scrollbars you have a few major problems: 1) Wheel mice don't work with these scrollbars 2) The look and feel of the scrollbars are different to other applications. 3) If you're using a themable OS (e.g. Linux running GNOME) then the scrollbar won't change to match the theme that you're using.
Basically we need to make a browser that acknowledges the users preferences across the OS which in the case of Linux means respect any GTK themes, and in MacOS and Windows respect any default colour preferences, etc.
In XUL (I don't know if there is already) there should be options that can be set to OS default.
So for example you can write a theme that uses the OS default options for some characteristics but the theme for others.
#56 Check out IE 5's scrollbars
Friday October 29th, 1999 4:16 PM
If you look at behavior of IE 5's scrollbars, you will notice that it couldn't have been better -- you can move your mouse pointer off your screen and have the scrollbar keep on behaving as even the pointer were right on it. MS might have added more features to its common controls (IE 5 does update COMCTL32.* files during installation), but no app, except for IE 5, takes advantage of them yet. Mozilla developers should investigate this. However, this can wait.
#60 Ah, the possibilities
Saturday October 30th, 1999 1:39 PM
Wouldn't it be great if you can configure the skin per-site? When I browse slashdot.org, Mozilla pulls up my Slashdot skin. When I go to Weather.com I get a nice weather-like theme. That would be real nice. Because many sites have different color schemes that may not look right with your skin-of-the-day. If it changes automatically, you don't need to worry about this.
But *don't* let the web site control this! We'll end up having ads next to our stop button or something similar. Just think what these companies can do with that much power (think about a possible GeoCities theme, the horror!). No, this should definitely be controlled by the user exclusively.
#61 New Skin and Another Big Change!
Saturday October 30th, 1999 3:57 PM
I agree with anon regarding the use of incremental reflow. Since the user experience is so varied, make it a configurable display option!! If its ON, you could even add options like how often (MAX) to reflow per sec or per page of content. This lets the user tweak it for their own platform experience.
#62 me no think so
Tuesday November 2nd, 1999 3:43 AM
excusy my englisho!!!!!!
i thought the first one was naguski, this is even wurse