Nope. Firefox 1.1 is nearing an alpha release so it's too late to start working on so many bugs and new features. I wouldn't be surprised if the next release of Firefox (1.2 or 1.5) passes the test, though.
The test looks like a face so that humans can easily see when a browser supports the web standards tested or how badly it fails to support them. Of course, it's not how you would actually want to display a face in practice or how you would write a good testcase for a browser.
In addition, I'd like to see an iMac Mini product line that has the same specs as the iMac line. Of course, the case would have to be larger and it would be more expensive than the current Mac Mini line. Still, I'd consider buying an iMac Mini + 17" display over an iMac even if it cost $100 more. It would be worth it to be able to re-use the display.
If I did something like that, I'd use the mnemonic name of the bit given in the manual (probably something like EMC for endian mode control):
bitset(slurp->serial, kSlurpSerialEMC);
That improves the readability of the code, but doesn't make the code self-documenting. With that code change, I'd leave the comment unchanged.
The reason I didn't write code like that was because I would have had to write the enumerations for all of the thousands of bit fields available in the SCC chip I was using. The reason I was able to use mnemonics for the control registers was because Motorola was kind enough to have make a.h file available for download that was a C data structure representation of every register.
More readable code is usually a good goal, but sometimes isn't worth it, and often doesn't make comments unnecessary.
Did you read the last paragraph of my post about multi-line comments for each line of code in low-level bit-fiddling code? You just might have missed that.
My basic rule of thumb about comments is to comment the interface. In C/C++ this would mean writing the comments at the beginning of all function declarations in.h files instead of.c files, and in Java would mean writing Javadoc comments at the beginning of all methods. The idea is that if you know what a function/method does, you should be able to understand how it does it. The inside of functions/methods should have minimal comments, usually just a one-line comment for each major section explaining what that section does. Sometimes how the function/method works needs to be commented, as in:
Of course, there are always exceptions. When I was writing low-level code that manipulated hardware registers, I wrote a multi-line comment before each line of bit-fiddling code, complete with what the code did and a cross-reference into the hardware manual. Something like:
// Set the serial port to big-endian mode // See SlurpSCC manual page 3-5 bitset(slurp->serial, bit(13));
A small black hole certainly could devour the earth. Although its gravitational attraction would be weak, it could make direct contact with other matter and draw it into the black hole. This would increase its gravitational pull and draw more matter in. This would continue until there was no more matter to come into contact with.
Re:Not being trollish, but...
on
Opera 8 Released
·
· Score: 2, Insightful
They don't "also" work at Red Hat. Their job at Red Hat is to work on Firefox. Google recently hired two top Firefox developers, too, and IBM just posted a job offer for a Firefox developer.
Re:But does it pass the ACID2 Test?
on
Opera 8 Released
·
· Score: 4, Informative
Re:Not being trollish, but...
on
Opera 8 Released
·
· Score: 3, Informative
You're referring to developers who are working on the Firefox user interface. Most of Firefox is the Gecko core that's shared with Thunderbird, the Suite, Camino, etc. There are more than ten full-time active developers who work on various parts of Firefox (several of whom work at other companies such as Red Hat), plus hundreds of part-time volunteer developers.
The development of the Mozilla Suite isn't separate from Firefox at all. Most of the code is shared between the two products, and improvements to Firefox automatically improve the Suite, too. The 1.8 version of the Suite is still a Mozilla project, just not a Mozilla product, meaning that QA and releases will be done by the community instead of by the Mozilla Foundation.
Displaying ads within a web page that go away when we navigate to another page is one thing. Displaying popups and popunders that clutter our desktop until we manually close them is another.
If advertisers want to reach the widest audience possible, they should go with the least offensive medium -- text ads or simple static graphics. Google's figured this out; when will the rest realize?
Some parts of the map do have about 1 meter per pixel resolution. Go to Coralville, IA and zoom all the way in. You can see individual cars parked at shopping centers.
There were no checkins on the 1.7 branch from March 17 through March 21. Any nightly build produced between those dates should be essentially the same as the official release.
Yes, when you submit a bug to Bugzilla you can mark it as a security bug. If you do that, only you and the security group will be able to see it. If it's a new legitimate security bug, you can then expect a check for $500.
And this is exactly one of the big reasons many dislike the discontinuation of the Mozilla Suite.
It hasn't been discontinued. In the interview with Mitchell Baker she mentioned that the Mozilla Foundation will provide Mozilla 1.7.x maintenance and security releases for the next two years, and possibly longer depending on how many users it has then. The Mozilla Foundation handed off the task of testing and building releases beyond Mozilla 1.7.x to the Seamonkey group.
To block pop-ups from plugins, open your Firefox 1.0 or 1.0.1 browser, type about:config in the address field. Right-click in the resulting config page somewhere and select New -> Interger. Type privacy.popups.disable_from_plugins in the resulting dialog, hit OK, type 2 in the next dialog and you're all set.
This pref can actually take three values:
0: open allowed
1: the opened windows are treated as popups, but they're allowed to open (we limit the number of these types of popups)
2: the window is a popup, block it
Now if Slashdot could only fuse duplicate stories into one...
Yes, part of Acid2 is about testing whether browsers handle invalid CSS according to the standards.
Nope. Firefox 1.1 is nearing an alpha release so it's too late to start working on so many bugs and new features. I wouldn't be surprised if the next release of Firefox (1.2 or 1.5) passes the test, though.
You probably looked at the reference image instead of the actual test. Opera 8 doesn't render Acid2 properly.
Apple employee David Hyatt fixed Safari to display the Acid2 test as part of his job at Apple as Safari developer. It wasn't "just some schmoe".
The test looks like a face so that humans can easily see when a browser supports the web standards tested or how badly it fails to support them. Of course, it's not how you would actually want to display a face in practice or how you would write a good testcase for a browser.
In addition, I'd like to see an iMac Mini product line that has the same specs as the iMac line. Of course, the case would have to be larger and it would be more expensive than the current Mac Mini line. Still, I'd consider buying an iMac Mini + 17" display over an iMac even if it cost $100 more. It would be worth it to be able to re-use the display.
The reason I didn't write code like that was because I would have had to write the enumerations for all of the thousands of bit fields available in the SCC chip I was using. The reason I was able to use mnemonics for the control registers was because Motorola was kind enough to have make a .h file available for download that was a C data structure representation of every register.
More readable code is usually a good goal, but sometimes isn't worth it, and often doesn't make comments unnecessary.
Did you read the last paragraph of my post about multi-line comments for each line of code in low-level bit-fiddling code? You just might have missed that.
Of course, there are always exceptions. When I was writing low-level code that manipulated hardware registers, I wrote a multi-line comment before each line of bit-fiddling code, complete with what the code did and a cross-reference into the hardware manual. Something like:
Firefox has been making progress (see bug 290297), too. And how do you know that Opera and IE developers aren't also fixing the bugs?
A small black hole certainly could devour the earth. Although its gravitational attraction would be weak, it could make direct contact with other matter and draw it into the black hole. This would increase its gravitational pull and draw more matter in. This would continue until there was no more matter to come into contact with.
They don't "also" work at Red Hat. Their job at Red Hat is to work on Firefox. Google recently hired two top Firefox developers, too, and IBM just posted a job offer for a Firefox developer.
No browsers pass Acid2. So far, the development version of Safari comes closest.
You're referring to developers who are working on the Firefox user interface. Most of Firefox is the Gecko core that's shared with Thunderbird, the Suite, Camino, etc. There are more than ten full-time active developers who work on various parts of Firefox (several of whom work at other companies such as Red Hat), plus hundreds of part-time volunteer developers.
Yeah, I wish they'd sync the versions of Gecko and Firefox/Thunderbird so this confusion wouldn't happen.
The development of the Mozilla Suite isn't separate from Firefox at all. Most of the code is shared between the two products, and improvements to Firefox automatically improve the Suite, too. The 1.8 version of the Suite is still a Mozilla project, just not a Mozilla product, meaning that QA and releases will be done by the community instead of by the Mozilla Foundation.
Mozilla 1.8 will be released, just under a different name with QA done by the Seamonkey group instead of the Mozilla Foundation.
If advertisers want to reach the widest audience possible, they should go with the least offensive medium -- text ads or simple static graphics. Google's figured this out; when will the rest realize?
Some parts of the map do have about 1 meter per pixel resolution. Go to Coralville, IA and zoom all the way in. You can see individual cars parked at shopping centers.
There were no checkins on the 1.7 branch from March 17 through March 21. Any nightly build produced between those dates should be essentially the same as the official release.
Yes, when you submit a bug to Bugzilla you can mark it as a security bug. If you do that, only you and the security group will be able to see it. If it's a new legitimate security bug, you can then expect a check for $500.
Apparently 2 allows popups only from whitelisted sites, and 3 disallows all popups, but I haven't tested this.
To block pop-ups from plugins, open your Firefox 1.0 or 1.0.1 browser, type about:config in the address field. Right-click in the resulting config page somewhere and select New -> Interger. Type privacy.popups.disable_from_plugins in the resulting dialog, hit OK, type 2 in the next dialog and you're all set.
This pref can actually take three values:
0: open allowed
1: the opened windows are treated as popups, but they're allowed to open (we limit the number of these types of popups)
2: the window is a popup, block it