> That document is over 4 years old at this point.
That's because you didn't bother to click the "latest version" link, which points to the September 2008 version of the same draft. You might be interested in comparing border-radius between the two drafts.
The key is that this draft (emphasis on DRAFT, as in "not done") spec is not in CR yet, which means that implementation under the draft name is actually actively discouraged by the W3C. The reason for that is that if before CR a change has to be made to the way the property works, existing implementations with the "correct" property name might make that impossible: the change would break pages.
And in fact, there have been quite recent changes to the way border-radius works in this draft.
> When Firefox introduces support for CSS3, why make people change all of their > stylesheets to use the official name instead of the hack?
You can use the "official" (draft, not REC or even CR, just a proposal) name right now. Just make sure to track all changes to the spec in your stylesheet.
Seriously, you seem to be assuming that the spec for border-radius is done. In reality, it's very much in flux right now.
> Creating your own invalid identifiers for things like CSS or HTML attributes is a bad > practice, period.
You do realize that -vnd-* identifiers are the officially sanctioned (by the CSS Working Group) way for UAs to implement properties from pre-CR drafts so that implementation experience can feed into the spec, right?
> The bottom line is that using a proprietary name for these things does not offer a > single advantage over using the already decided-upon name
It offers the advantage of not poisoning the already-decided-upon name with behavior that differs from its behavior. Note that the latter hasn't been decided on yet; that's the crux of the whole issue. If the border-radius spec were stable, people would actually be implementing it under the unprefixed name. In the meantime they're being good citizens and not stomping on the namespace.
The problem is that browser exploits sell for about $10,000 at the moment (that's how much various "security" companies will pay for them). The bug bounty above is $500...
The problem is that actually measuring things gives different results... When Firefox 3 was measured head to head against other web browsers, it used less memory pretty consistently.
> Is browsing the web really so hard that it takes more memory and processing to do it > than Eclipse and Outlook combined?
In a word, "maybe". Depends on the sites you're loading and what they do.
> It's using roughly twice what IE6 would use under the same circumstances.
You mean you've tried the same browsing pattern on the same sites and IE6 has 2x less memory usage? Or you have memories of how much IE6 used on some other set of pages some other time? Or something else?
> there's got to be a way to make it so that it's not the heaviest thing running on my > machine
Not really, if it's the most heavily used app that has to do the most things... If you have 7 tabs worth of web applications open, then one would expect memory usage to be approximately equivalent to having 7 desktop applications open; if it's not, that's great.
Seriously, though, it's not uncommon for the browser to have to run several hundred kilobytes (no, I'm not making this up) of script when loading a web page. Let's take a simple example: http://www.cnn.com./ This has about 95KB of HTML (including inline scripts and such) and links to 270KB of external scripts. Those scripts do various stuff that creates objects and are generally poor at dropping object references. Which means that while the page is open, every object it's created will typically still be around: it can't be garbage collected, because the page is still referencing it.
This is not to say that memory usage can't be improved; it can be and people are working on it. Same for CPU usage. In particular, the "cpu being used all the time" thing is a serious problem that's being looked into. A lot of that is in fact Flash being stupid (easy to test how much by disabling Flash), but not all. But in the end, Firefox is not particularly more "bloated" than any other browser that does similar things in terms of web compat and rendering (yes, it's more memory-hungry than lynx, I agree).
Birth rate:
10.15 births/1,000 population (2008 est.)
Death rate:
10.24 deaths/1,000 population (2008 est.)
That is, below replacement levels. Is this caused by the leave policies, or the cause for the policies? Hard to tell. Wikipedia's numbers for 2006 are closer to 11.7 and 10.0 respectively, so not quite as bad. For comparison's sake, the US numbers are 14.18 and 8.28 respectively for 2008 per worldfactbook and 13.20/8.30 for 2007 according to Wikipedia.
In your job, can you take a bit over a year off and then just come back to work with no other overhead? I know I can't... (Not because of policy but because it'll take me months to catch up to what's going on.)
> In the meantime though, individual apps could improve things and set a good example by at > least making sure their own popups a little more courteous
Right. I assumed that's what we were talking about, and my comments about when popus are allowed during typing are based on the Firefox popup blocker code.
I'll get a bug filed to reevaluate the setup.
> unnecessary browser tabs, which in every windowing system I've ever seen they are simply > redundant
Speaking as someone who never uses tabs on Linux, they're pretty useful on Windows because the window manager is so crappy. On Mac it's a hard call; with Spaces a lot of the use cases for tabs (keeping stuff out of sight but unminimized so it's easier to find) go away.
> And in Firefox anyway, last I looked (I've stopped using it, frankly), tabs that > you can't completely turn off and insist on taking up real estate.
For the first time, I truly have no idea what you're talking about. Looking at my Firefox preferences, in the "Tabs" toplevel section (which is the second of only 7 such sections):
* Uncheck "Open new windows in a new tab instead"
* Uncheck "Always show the tab bar"
That should ensure you never see a tab from web content and that the tabbar is invisible if only one tab is open (which will be always, unless you open one manually). That leaves Ctrl-click (Cmd-click on Mac) on links opening new tabs; Shift-click opens windows instead. Up to you which you use, though I agree that it would be nice if you could remap those. Similar for the "Open in" context menu options on links.
> Did someone actually ask for those stupid things?
Actually, yes. And more to the point, it's been wildly popular (to the point where every browser implements it now). Again, I think this is largely due to the default window manager being so poor on Windows and the fact that changing it is rocket science.
Interface simplicity is one of the main goals, yes. So is small footprint; in case you missed the measurements, Firefox 3 had a smaller footprint than other browsers when loading pages. Firefox 3.1 is no worse in this respect. The focus in Firefox 3.1 was on performance in some areas and added web-facing features in others.
Popups on typing is an interesting issue. Right now, popups are only allowed during the handling of certain user events, and the ones relevant here would be:
* keypress of a return key * keyup of a space key (needed for handling space being used to trigger buttons) * input
I'm not sure why input is on the list; that should probably be revisited.
Is there a bug filed on this, or were you expecting people to fix your #1 beef without knowing anything about it?
SQLite replaced an existing database (non-SQL, but still a database) that was already there. That was Mork. SQLite is a vast improvement.
As far JSON, you can get JSON from wherever you want, and sites commonly do. XHR is not the only way to get JSON. People pass it around in query strings, for example.
Bug filed? The pyxpcom stuff is not tier-1 (or even tier-2), so not maintained or supported by anyone on a regular basis. That said, if there's a bug report, better yet a patch, I can see what I can do about getting that dealt with.
What's your estimate on the number of changes made between Firefox 3.0 and this beta and the number of those that are new features?
Trust me, bugfixes are happening too. They just don't make the release notes for the most part, because most people don't care to have long boring release notes.
I doubt feature additions to Firefox have much to do with revenue stream issues. Mostly they're added for one of two reasons:
1) Implementation of additional core browser functionality (most common source of
security bugs here). This arises from a need to compete for developer mindshare
against other browsers, Silverlight, Flash, etc. 2) Attempts to improve the user experience (this would be the new url bar in Firefox 3,
for example).
Both are eventually relevant to revenue insofar as they increase marketshare (if done right) which increases revenue, but the real driver behind reason 1 is that it'd be nice if the web didn't become a giant Flash app, and the real driver behind reason 2 is maybe it's nice to actually improve the experience of your users.
> Nothing is written for periods between 45-120 seconds
Actually, the article (if you read carefully) says that the major "OMG all my files are truncated" issues arise when file renames are committed to disk before the data is written to said files, so that this coding pattern:
1) Open a new file x.new 2) Write your data to x.new 3) mv x.new x
leads to a zero-length file x because the mv is committed before the write and then the crash leaves a 0-length file.
No comment on whether the rename commit has to do anything with the journal; I don't know enough about ext4 to say.;)
> The rename system call guarantees that at any point in time the name will refer to either > the old or the new file.
If you read the article, this is precisely false with ext4. Or rather, the rename can be committed to disk before the data writes have been; if you crash in between, you lose.
> If you are not logged in to your machine as Administrator/root, then how will this work.
Easily. The fonts are not installed system-wide. In fact, doing that would be a spec violation: the spec requires that downloaded fonts not be made available to any other applications. So you keep the font in memory, and use it if the page asks for it.
> Same with Firefox's AutoUpdate "feature" - it assumes that you're logged > in as Administrator/root.
And disables itself if you're not, on the assumption that the administrator has clue and will handle updates himself. Note that on Mac, where it's trivial to install apps into non-system locations, the update feature can Just Work. If the app _is_ installed in a system location and the account has administrator access, then the update just puts up a standard sudo prompt.
> If there's anybody out there still surfing the web as Administrator/root, then >... well - I give up
Most people on Windows do just that.
> I wonder how many people know about this and actually use their computer according to > these guidelines.
Very few, of course.
> On Linux/Unix this is the first thing you learn
On Linux, the vast majority of users get Firefox from their distro, not Mozilla directly, and then it's updated via the distro's standard update mechanism (yum, apt, whatever).
For what it's worth, we _did_ look into this pretty carefully at some point... Most of the XSync calls that happen now in Gecko are done by GTK2 itself. Not much we can do about those.:(
What would really help Linux performance compared to Windows a good bit if g++ managed to produce code anywhere near as good as what MSVC++ produces.
> Can somebody tell me why programmers of open source browsers decide not to code to > standards?
1) Some of the standards require things that make no sense. 2) Some of the standards are self-contradictory. 3) Some of the standards contradict each other. 4) Some of the standards keep changing (e.g. if you implement CSS Generated Content per
CSS2, it's buggy per CSS 2.1).
Those are the obvious issues with the standards themselves. There's also the fact that a lot of the standards involved are really complicated and have no test suite, which means it's hard to tell whether you actually implemented it correctly. And even for simple stuff, people make mistakes sometimes.
It's also very common to complain about imperfect adherence to drafts which are not yet standards (CSS 2.1, I'm looking at you).
Note that the way Dromaeo calculates its "overall" score is a geometric mean of subscores; this heavily weights tests on which one can be a lot faster than the competition for whatever reason, even if the differences are 1ms vs 2ms.
> In W3C land to become a recommendation there must be two completely interoperable > implementations
This is a recent development, and wasn't in place when the specs ACID3 tests were written. None of them have two interoperable implementations, and none even come close. Some are impossible to implement a written due to self-contradictions. It's great fun.
Speaking as a Gecko developer, the article's author is just confused. Either that, or in desperate need of copy, no matter how inane.
What _is_ true is that Tracemonkey at ship will be reasonably competitive with then-shipping Safari (as opposed to Webkit nightly builds, which should be compared to the then Firefox nightly builds) and V8 (depending heavily on the test; it'll be a lot slower on the V8 tests).
Due to the way the jits involved work, it's pretty easy to find tests where one or the other of the engines above is a lot faster; for example nightly Tracemonkey is about 5x faster than nightly Webkit on a fractal-generator script I have lying around. That's mostly because I made sure that everything the script hit ended up on trace. Can't test with Chrome easily, since I don't have a useful Windows machine to hand (performance tests in a VM are pretty much worthless). As I said, V8 is a lot faster on its own tests, since Tracemonkey leaves those completely on the interpreter so far. Other tests will fall somewhere in between.
Now you're correct that whole-system DOM performance in Webkit tends to be better than Gecko. We're working on it.;)
Slashdot Mirror
> That document is over 4 years old at this point.
That's because you didn't bother to click the "latest version" link, which points to the September 2008 version of the same draft. You might be interested in comparing border-radius between the two drafts.
The key is that this draft (emphasis on DRAFT, as in "not done") spec is not in CR yet, which means that implementation under the draft name is actually actively discouraged by the W3C. The reason for that is that if before CR a change has to be made to the way the property works, existing implementations with the "correct" property name might make that impossible: the change would break pages.
And in fact, there have been quite recent changes to the way border-radius works in this draft.
> When Firefox introduces support for CSS3, why make people change all of their
> stylesheets to use the official name instead of the hack?
You can use the "official" (draft, not REC or even CR, just a proposal) name right now. Just make sure to track all changes to the spec in your stylesheet.
Seriously, you seem to be assuming that the spec for border-radius is done. In reality, it's very much in flux right now.
> Creating your own invalid identifiers for things like CSS or HTML attributes is a bad
> practice, period.
You do realize that -vnd-* identifiers are the officially sanctioned (by the CSS Working Group) way for UAs to implement properties from pre-CR drafts so that implementation experience can feed into the spec, right?
> The bottom line is that using a proprietary name for these things does not offer a
> single advantage over using the already decided-upon name
It offers the advantage of not poisoning the already-decided-upon name with behavior that differs from its behavior. Note that the latter hasn't been decided on yet; that's the crux of the whole issue. If the border-radius spec were stable, people would actually be implementing it under the unprefixed name. In the meantime they're being good citizens and not stomping on the namespace.
Odd. Cnn's website is pretty typical as news sites go, for what it's worth, and doesn't seem to cause any undue slowdown over here....
I assume the above test was performed in safe mode?
> The respective companies should offer a running bounty on exploits on their browsers.
You mean like http://www.mozilla.org/security/bug-bounty.html ?
The problem is that browser exploits sell for about $10,000 at the moment (that's how much various "security" companies will pay for them). The bug bounty above is $500...
> No data, just anecdotes
The problem is that actually measuring things gives different results... When Firefox 3 was measured head to head against other web browsers, it used less memory pretty consistently.
> Is browsing the web really so hard that it takes more memory and processing to do it
> than Eclipse and Outlook combined?
In a word, "maybe". Depends on the sites you're loading and what they do.
> It's using roughly twice what IE6 would use under the same circumstances.
You mean you've tried the same browsing pattern on the same sites and IE6 has 2x less memory usage? Or you have memories of how much IE6 used on some other set of pages some other time? Or something else?
> there's got to be a way to make it so that it's not the heaviest thing running on my
> machine
Not really, if it's the most heavily used app that has to do the most things... If you have 7 tabs worth of web applications open, then one would expect memory usage to be approximately equivalent to having 7 desktop applications open; if it's not, that's great.
Seriously, though, it's not uncommon for the browser to have to run several hundred kilobytes (no, I'm not making this up) of script when loading a web page. Let's take a simple example: http://www.cnn.com./ This has about 95KB of HTML (including inline scripts and such) and links to 270KB of external scripts. Those scripts do various stuff that creates objects and are generally poor at dropping object references. Which means that while the page is open, every object it's created will typically still be around: it can't be garbage collected, because the page is still referencing it.
This is not to say that memory usage can't be improved; it can be and people are working on it. Same for CPU usage. In particular, the "cpu being used all the time" thing is a serious problem that's being looked into. A lot of that is in fact Flash being stupid (easy to test how much by disabling Flash), but not all. But in the end, Firefox is not particularly more "bloated" than any other browser that does similar things in terms of web compat and rendering (yes, it's more memory-hungry than lynx, I agree).
> It's bloated, has terrible memory management
Do you have data to back this up, by any chance? And we're talking about Firefox 3 or later, right?
> not to mention the old standby SOCKET support
You might be interested in the Web Sockets specification (formerly part of HTML5, now handed over to the Web Apps working group at the W3C).
> I wonder if javascript and html 5 can make Silverlight become as useless
That's more or less the goal, yes.
> check Sweden's stats here
And don't forget here: https://www.cia.gov/library/publications/the-world-factbook/print/sw.html
The relevant numbers:
Birth rate:
10.15 births/1,000 population (2008 est.)
Death rate:
10.24 deaths/1,000 population (2008 est.)
That is, below replacement levels. Is this caused by the leave policies, or the cause for the policies? Hard to tell. Wikipedia's numbers for 2006 are closer to 11.7 and 10.0 respectively, so not quite as bad. For comparison's sake, the US numbers are 14.18 and 8.28 respectively for 2008 per worldfactbook and 13.20/8.30 for 2007 according to Wikipedia.
In your job, can you take a bit over a year off and then just come back to work with no other overhead? I know I can't... (Not because of policy but because it'll take me months to catch up to what's going on.)
> This would explain it as open in new tab does open it behind the active page,
That's also controlled by one of the checkboxes in the tabs preferences: "When I open a link in a new tab, switch to it immediately".
> In the meantime though, individual apps could improve things and set a good example by at
> least making sure their own popups a little more courteous
Right. I assumed that's what we were talking about, and my comments about when popus are allowed during typing are based on the Firefox popup blocker code.
I'll get a bug filed to reevaluate the setup.
> unnecessary browser tabs, which in every windowing system I've ever seen they are simply
> redundant
Speaking as someone who never uses tabs on Linux, they're pretty useful on Windows because the window manager is so crappy. On Mac it's a hard call; with Spaces a lot of the use cases for tabs (keeping stuff out of sight but unminimized so it's easier to find) go away.
> And in Firefox anyway, last I looked (I've stopped using it, frankly), tabs that
> you can't completely turn off and insist on taking up real estate.
For the first time, I truly have no idea what you're talking about. Looking at my Firefox preferences, in the "Tabs" toplevel section (which is the second of only 7 such sections):
* Uncheck "Open new windows in a new tab instead"
* Uncheck "Always show the tab bar"
That should ensure you never see a tab from web content and that the tabbar is invisible if only one tab is open (which will be always, unless you open one manually). That leaves Ctrl-click (Cmd-click on Mac) on links opening new tabs; Shift-click opens windows instead. Up to you which you use, though I agree that it would be nice if you could remap those. Similar for the "Open in" context menu options on links.
> Did someone actually ask for those stupid things?
Actually, yes. And more to the point, it's been wildly popular (to the point where every browser implements it now). Again, I think this is largely due to the default window manager being so poor on Windows and the fact that changing it is rocket science.
I try not to ignore fellow curmudgeons. ;)
Interface simplicity is one of the main goals, yes. So is small footprint; in case you missed the measurements, Firefox 3 had a smaller footprint than other browsers when loading pages. Firefox 3.1 is no worse in this respect. The focus in Firefox 3.1 was on performance in some areas and added web-facing features in others.
Popups on typing is an interesting issue. Right now, popups are only allowed during the handling of certain user events, and the ones relevant here would be:
* keypress of a return key
* keyup of a space key (needed for handling space being used to trigger buttons)
* input
I'm not sure why input is on the list; that should probably be revisited.
Is there a bug filed on this, or were you expecting people to fix your #1 beef without knowing anything about it?
SQLite replaced an existing database (non-SQL, but still a database) that was already there. That was Mork. SQLite is a vast improvement.
As far JSON, you can get JSON from wherever you want, and sites commonly do. XHR is not the only way to get JSON. People pass it around in query strings, for example.
Bug filed? The pyxpcom stuff is not tier-1 (or even tier-2), so not maintained or supported by anyone on a regular basis. That said, if there's a bug report, better yet a patch, I can see what I can do about getting that dealt with.
What's your estimate on the number of changes made between Firefox 3.0 and this beta and the number of those that are new features?
Trust me, bugfixes are happening too. They just don't make the release notes for the most part, because most people don't care to have long boring release notes.
Joe average web developer will certainly notice a big difference, not just in terms of performance but various features as well.
I doubt feature additions to Firefox have much to do with revenue stream issues. Mostly they're added for one of two reasons:
1) Implementation of additional core browser functionality (most common source of
security bugs here). This arises from a need to compete for developer mindshare
against other browsers, Silverlight, Flash, etc.
2) Attempts to improve the user experience (this would be the new url bar in Firefox 3,
for example).
Both are eventually relevant to revenue insofar as they increase marketshare (if done right) which increases revenue, but the real driver behind reason 1 is that it'd be nice if the web didn't become a giant Flash app, and the real driver behind reason 2 is maybe it's nice to actually improve the experience of your users.
Yep. Sounds like we're on the same page here; fully agreed with your characterization of the two numbered situations.
> Nothing is written for periods between 45-120 seconds
Actually, the article (if you read carefully) says that the major "OMG all my files are truncated" issues arise when file renames are committed to disk before the data is written to said files, so that this coding pattern:
1) Open a new file x.new
2) Write your data to x.new
3) mv x.new x
leads to a zero-length file x because the mv is committed before the write and then the crash leaves a 0-length file.
No comment on whether the rename commit has to do anything with the journal; I don't know enough about ext4 to say. ;)
> The rename system call guarantees that at any point in time the name will refer to either
> the old or the new file.
If you read the article, this is precisely false with ext4. Or rather, the rename can be committed to disk before the data writes have been; if you crash in between, you lose.
> If you are not logged in to your machine as Administrator/root, then how will this work.
Easily. The fonts are not installed system-wide. In fact, doing that would be a spec violation: the spec requires that downloaded fonts not be made available to any other applications. So you keep the font in memory, and use it if the page asks for it.
> Same with Firefox's AutoUpdate "feature" - it assumes that you're logged
> in as Administrator/root.
And disables itself if you're not, on the assumption that the administrator has clue and will handle updates himself. Note that on Mac, where it's trivial to install apps into non-system locations, the update feature can Just Work. If the app _is_ installed in a system location and the account has administrator access, then the update just puts up a standard sudo prompt.
> If there's anybody out there still surfing the web as Administrator/root, then ... well - I give up
>
Most people on Windows do just that.
> I wonder how many people know about this and actually use their computer according to
> these guidelines.
Very few, of course.
> On Linux/Unix this is the first thing you learn
On Linux, the vast majority of users get Firefox from their distro, not Mozilla directly, and then it's updated via the distro's standard update mechanism (yum, apt, whatever).
For what it's worth, we _did_ look into this pretty carefully at some point... Most of the XSync calls that happen now in Gecko are done by GTK2 itself. Not much we can do about those. :(
What would really help Linux performance compared to Windows a good bit if g++ managed to produce code anywhere near as good as what MSVC++ produces.
> Can somebody tell me why programmers of open source browsers decide not to code to
> standards?
1) Some of the standards require things that make no sense.
2) Some of the standards are self-contradictory.
3) Some of the standards contradict each other.
4) Some of the standards keep changing (e.g. if you implement CSS Generated Content per
CSS2, it's buggy per CSS 2.1).
Those are the obvious issues with the standards themselves. There's also the fact that a lot of the standards involved are really complicated and have no test suite, which means it's hard to tell whether you actually implemented it correctly. And even for simple stuff, people make mistakes sometimes.
It's also very common to complain about imperfect adherence to drafts which are not yet standards (CSS 2.1, I'm looking at you).
Yeah, those numbers look about right.
Note that the way Dromaeo calculates its "overall" score is a geometric mean of subscores; this heavily weights tests on which one can be a lot faster than the competition for whatever reason, even if the differences are 1ms vs 2ms.
> In W3C land to become a recommendation there must be two completely interoperable
> implementations
This is a recent development, and wasn't in place when the specs ACID3 tests were written. None of them have two interoperable implementations, and none even come close. Some are impossible to implement a written due to self-contradictions. It's great fun.
Speaking as a Gecko developer, the article's author is just confused. Either that, or in desperate need of copy, no matter how inane.
What _is_ true is that Tracemonkey at ship will be reasonably competitive with then-shipping Safari (as opposed to Webkit nightly builds, which should be compared to the then Firefox nightly builds) and V8 (depending heavily on the test; it'll be a lot slower on the V8 tests).
Due to the way the jits involved work, it's pretty easy to find tests where one or the other of the engines above is a lot faster; for example nightly Tracemonkey is about 5x faster than nightly Webkit on a fractal-generator script I have lying around. That's mostly because I made sure that everything the script hit ended up on trace. Can't test with Chrome easily, since I don't have a useful Windows machine to hand (performance tests in a VM are pretty much worthless). As I said, V8 is a lot faster on its own tests, since Tracemonkey leaves those completely on the interpreter so far. Other tests will fall somewhere in between.
Now you're correct that whole-system DOM performance in Webkit tends to be better than Gecko. We're working on it. ;)