And so far it's been a very profitable investment.
I am writing applications that require extensive hardware-specific testing (file manager, network-based stuff, system tools). I certainly have plenty of complaints about Android with regard to cross-device compatibility, and I've even found plenty of egregious omissions in the API (e.g., how do you find all user-writable storage without going down to/proc/mounts). That said, I find it to be an overall excellent platform. And it seems to pay the bills.
My only real complaint with the investment in devices is that I would love for cell carriers and/or Motorola/HTC/Samsung/etc to respond to my requests to have even slightly early access (or guaranteed release day access) to new devices. I'm sick and tired of visiting random cell phone stores who won't reserve product and lie about availability. And I'm tired of explaining that yes I want to pay full retail and no I do not want a contract no matter how much of a better deal it is.
Just received an unsolicited commercial email from them advertising this new site (what's that other term for these again?) It went to one of our support accounts...the kind that wouldn't be found unless one were to skim a web site for email addresses.
The unsubscribe link from this invitation to join requires that I first "log into my account". The email is an invitation to join.
From a technical perspective, I'm impressed by both platforms.
Be aware however that deployment of iOS applications to the general public may only be done with Apple's approval of your specific application. And unless you are targeting jailbroken phones, all revenue must pass through Apple. They may choose to reject an app for reasons stated in their developer agreement, or for unstated reasons: http://www.macworld.com/article/151680/2010/06/myframe_rejection.html
The Android market's terms are more lenient than Apple's, and the Android market does not have a formal approval process of any kind. Apps may however be removed for violations of the Android Market developer agreement.
But even then, Android phones allow the installation of apps from sources other than the Android market.
First, please beware that I barely qualify as a layman when it comes to knowledge of cellular networks and/or RF transmission.
If I recall correctly though, the transmitting power used by a cellular phone is inversely proportionate to the proximity of a tower. That is, if the tower is far away and more difficult to reach, the phone will use more transmitting power.
So from a radiation perspective, is it safer to have towers located far away at the expense of having our cell phones constantly running at maximum power mere inches from our reproductive organs or brains?
This is a very impressive evolution. Thinner, better display, more processing power, better battery life, better camera, new sensors, and more capabilities across the board, both hardware and software.
I'd love to develop for it.
I just wish there was some way I could know that if I spent thousands of hours creating software for it, that such software would continually be available for purchase via the App Store. I'd be okay with explaining in detail to Apple how the software was going to work before developing it. But it would be necessary to obtain an authoritative answer to inform as to whether the software would be accepted (if implemented to a proposed specification) and for what minimum duration the software would be allowed on the store.
There is a fundamental risk in developing new software: "Will customers buy this?" This risk can be calculated to a certain extent. My concern with developing for iOS is that an additional incalculable risk exists, and it is simply too much to bear.
I can't stand hearing everyone talk about multitasking on things like Android devices as though it works the same way as it does on their desktop PC. Nothing could be further from the truth.
The first form of multitasking on Android is that applications can elect to receive messages, e.g. "someone is calling", or "wifi state changed".
If you actually need to do constant work in the background (e.g., listening on a network port), you can do so as well, using a "service". And even services will be killed by the system if resources are needed.
No one is talking about running a Handbrake encode session, Firefox with a bunch of animated Flash ads, and a kernel compile at the same time on their phone.
Multitasking on a phone is being able to record breadcrumbs of a journey with a GPS app, listen to streaming internet radio, and receive notifications from an instant messaging client at the same time.
If I open Google Chrome and Mozilla Firefox, with a few tabs active in each on popular sites, the entirety of both cores of my Intel E7500 CPU will be consumed by Flash advertisements.
I'm on a Linux machine with a lot of memory, which makes for the worst case scenario: First, Flash is horrible on Linux. Second, I use virtual desktops and leave browsers open for days at a time. Memory is not a problem.
Flash ads tend to be poorly written by a creative designer who could give a rat's rear end about your system resources.
The ads interfere with my ability to work, which costs me money. They also cause my computer to consume significantly more power. So in effect, your Flash ads are even bad for the environment.
They're also of course quite annoying, and if given only the options of browsing the internet with Flash ads or not browsing the internet at all, I'll choose the latter.
How about you try this experiment: Turn off Flash ads. Post a banner at the top of your site that says, "Hey, we've turned off Flash ads. Please exclude this site from your ad blocker so we can make money."
Love the new UI, and really appreciate the option of another well done browser. But they still refuse to fix a trivial CSS bug which has horrible consequences for AJAX apps.
(This is very hard/impossible to do on a mac, as they don't really have one).
Unfortunately the bug is not limited to resizing with the vertical handle...it manifests itself in other ways. It seems the browser is incorrectly measuring/reporting the vertical size of elements, and sometimes uses this data internally (as in the case of this test).
Yes, Android currently only lets you install application packages on internal memory. Application developers know this, so there's a major effort made to keep the application footprint small, and then have the applications download and store additional resources on the SD card, which has no such limitations. As an example, a game would store its levels/media on the SD card. Or in the case of an offline GPS app, the map data would be stored on the SD card.
With my Droid, I've yet to get anywhere close to this limitation, and I'm always on the hunt for neat apps on the market. I currently have 162MB free (I believe it originally had 250MB available).
Yes, it's not inconceivable that you'll run into this limitation, but at the same time, it doesn't come up all that often. Don't be concerned that your iPhone is using 3GB for app storage...on an Android device those apps would be putting 95% of their data on the SD card.
I made a webapp in early 2001 that used both AJAX (with a hidden frame for client-server communication, rather than an XHR) and a Java applet. It was used to create presentations from within a web browser. The Java applet was used for laying out a presentation slide, providing the user with the capability to create/position elements of the presentation (text, images, and so forth). The app was operational more than a year before the filing date of US7599985.
The application made use of Netscape's LiveConnect (an old Java/JavaScript communication API) to do this. LiveConnect was introduced in 1997, with Netscape 4. As far as I can see, LiveConnect was designed to enable what this patent claims to invent.
It still fails at my simple CSS test.
on
Opera 10.0 Released
·
· Score: 5, Interesting
I reported this about a year ago. Create a simple page, with two absolute positioned DIVs, nested one inside the other. Resize the browser vertically (but not horizontally). Watch as the DIVs are no longer positioned according to your specification.
The consequences get a bit more catastrophic with applications with larger quantities of nested DIVs. Things really start to break when you start measuring using Element.offsetHeight.
Apologies for posting it here...again...but I'm tired of replying to users who ask "why does component X not render properly in Opera, it passes Acid3 thus something must be wrong with the component."
Firefox on Windows looks great/awesome/beautiful....name it. But on Linux, it is inherently ugly. The beast looks ancient and the fonts and dialogs make matters worse.
In Ubuntu 9.04 here, and I personally think the stock DejaVu fonts on Linux look quite nice. Actually prefer the traditional toolbar on Linux with Tango icons (tango.freedesktop.org) rather than the "enlarged back button" version found on Windows and OSX.
The only problem I see is the topic of this thread, i.e., performance. It's slow enough to feel slow, and the fact that most Linux distros run so well on old hardware makes the problem worse.
The bigger problem for the "Linux browsing experience" still seems to be Flash. Visiting a Flash-heavy site (like the horrible items produced by any given automaker) is a painful experience...it's bad enough that I'll typically crack open the MacBook. I find Flash sites consume an order of magnitude more CPU running natively in a Linux browser than they do running in a Windows XP VirtualBox instance hosted by the same Linux OS.
AdBlockPlus and FlashBlock are the only things that enable me to continue to use this computer for web browsing. It's somewhat of a sad state of affairs, given that it's more than quick enough to run multiple VirtualBox instances, Eclipse instances, and a GIMP instance with dozens of files open at the same time. But give it one web page with a few Flash advertisements, and you'll think you're on a Pentium 60.
To see it fail, just go to this page in Opera 10: http://echo.nextapp.com/content/test/operacss/ , and resize your browser vertically (but NOT horizontally). It's been reported in the bugtracker, forums, forum PMs to developers, etc..
So please, when you file that bug report today that "Opera 10 doesn't render things correctly" to whatever your AJAX framework of choice happens to be, don't make a big deal out of the fact that it's "Acid3 compliant" and thus the AJAX framework developers must be in the wrong.
I hadn't heard about this bug before, but I just tested out the bug using your web page, and the bug must have been fixed. All three pages (17 DIV, 21 DIV, and 25 DIV) loaded instantaneously. I'm using an unreleased internal build of IE8. Thank you for submitting the bug report to the IE team!
Good to hear it's still the case. This is what I've been told by other MS folks working on the problem. My concern is not about this bug, but rather the fact that IE8 RC1 had quite a few major flaws in it, yet there will be no RC2. With a product as influential as Internet Explorer, you need to wait until your release candidates are reasonably well accepted by the public before you fire the final.
As a software developer, I find that when you ship a really buggy alpha version (or beta/RC), all you're going to get as feedback are the truly GLARING bug reports. If you want to get the edge cases, you've got to release something that's polished enough for people to spend time using. IE8 hasn't done that yet.
As a developer of an AJAX-based web framework, I'm upset to see IE8 being thrown out the door so quickly. RC1 was nothing short of a disaster: it had a performance bug where nesting absolute-positioned DIVs would result in exponential performance decreases.
The 25-nested DIV test would require killing the browser. Nesting absolutely positioned DIVs is somewhat fundamental to delivering application-style user interface layouts in a web browser.
I reported this bug everywhere I could, and Microsoft actually did a great job in responding to it. They say they've found it and fixed it. But there is no way for us to test this. We must simply take their word for it and wait. They're going from RC1 to final, and begging and pleading for an interim build didn't warrant much of a response.
From reading forums (e.g. Ajaxian: http://ajaxian.com/archives/push-back-digital-tv-or-ie-8), my IE8 experience is not uncommon with other web frameworks as well. The average developer's opinion there suggests RC1 is nowhere near ready for a final release. Every build of IE8 (beta1, beta2, win 7's "beta2+", and the RC) have each had major unique problems not found in other releases.
I have developers asking me if their software will work in IE8 on day 1 and the only honest answer is "I have absolutely no idea." Anyone (without a final build) who tells you otherwise, even offerring a rough estimate, is a liar, IMHO.
I don't understand the point of putting out a "release candidate" and then not using feedback to determine whether the next release is a "candidate" or a "final". Our bug alone means that IE8 RC1 has never been publicly tested with many complex web-based applications.
It seems to be fixed in Opera 9.61 or 9.62 - I'm using 9.62 here, and I cannot reproduce your problem on your sample page.
According to the CSS code, the green box should always be 20px away from the browser edge. The red box should be perfectly and symmetrically inside the green box, with its edges 40px away from the browser edge. Basically, the page should always be rendered exactly as it was in its initial state.
If you resize the browser VERTICALLY in Opera, the red box won't always resize to maintain the above rules. The red box will remain its original size. If you try this in IE7, FF, or a WebKit based browser, it will work as described in the previous paragraph.
If you're on a Mac or otherwise running an OS with a window manager theme that doesn't have a "vertical-only" resize handle, it may be difficult/impossible to reproduce with this example. (The problem will still affect such users in other cases that do not require a resize though).
That looks like a corner case situation to me. Maybe you would do better by not inflating the importance of bugs you report?:)
I strongly disagree. It breaks valid, commonly-used layouts and is quite difficult to workaround.
The example case is as simplified as possible to demonstrate the bug. I too don't think the example scenario will be hit very often. I think most people use the lower-right corner handle rather than bottom/top handles to resize a window, or simply use the maximize function. I used this example because it easily illustrates the issue.
The underlying problem however seems to come up quite often in my experience. Working around it has proven between difficult and impossible because all height data in the browser is incorrect (not current). It appears height data is not recalculated until the browser is *horizontally* resized.
There's quite a bit more information in that my.opera.com thread if you're interested.
Just tried it out, and of course it passes ACID3 as advertised. I still can't recommend this browser on the grounds that it can't correctly render absolutely positioned CSS elements, as demonstrated by the following code:
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Resize your browser with the vertical handle!</title>
</head>
<body>
<div style="position:absolute;left:20px;right:20px;top:20px;bottom:20px;background-color:lime;">
<div style="position:absolute;left:20px;right:20px;top:20px;bottom:20px;background-color:red;">
</div>
</div>
</body> </html>
Opera 9.50, 9.60, and now 10.0alpha will not render the above properly if the browser is resized vertically. (9.27 and prior work perfectly) On the initial render, 9.5/9.6 and 10 do fine, but the moment one resizes the browser vertically (and NOT horizontally as well), things go awry. I reported this to their bug tracker six months ago, and posted a thread on their forums 2.5 months ago: http://my.opera.com/community/forums/topic.dml?id=250572 Have also mentioned it in their 9.6-about-to-be-released-post-non-working-sites thread.
This bug has additional consequences for AJAX applications that make use of on-screen measuring using offsetWidth/offsetHeight information. In such cases, even the initial rendering can be seriously flawed as offsetHeight returns incorrect values. (Note: offsetXXX properties are not part of a proper W3c standard, but are universally supported).
Apologize for the quasi-rant, but I just don't want to see another bug report about how our applications don't look right in a supposedly ACID3 compliant browser, thus indicating that the problem "MUST" be our fault. Please realize that passing ACID3, while a neat accomplishment and generally good thing, is far from a guarantee of standards compliance.
Because the world's climate scientists have so much to gain by tricking people into driving more fuel efficient cars.
There is money and fame to be had in promoting either side of the global warming argument (or any major political/scientific/economic issue for the matter). As will be the case with any "hot" scientific issue, there is certainly adequate motive to do this. I'm not taking either side here, but the statements in the article cannot be dismissed on the basis that there would be no motive for scientists to overstate global warming.
IE7 will matter (to me at least) only when the following two things happen:
CSS support becomes reasonably good.
IE6 is not significantly used to an extent to warrant supporting it.
In my opinion, #1 may actually happen. Beta2 is still a long way off from having "reasonable" CSS support, but they've got close to another year to pull it off, if I'm correct in assuming that IE7 will launch with Vista.
The second item won't happen for at least four years, assuming IE7 comes out in one year. At this point we all have plenty of historical data on the rate at which corporate networks upgrade things like web browsers. 3yrs for 90% to upgrade is probably wishful thinking.
The reason that I believe IE7 will be significant at that point is that web development time, be it in the context of writing your personal homepage or an advanced AJAX-based framework, will take approximately 50% as long as it did when IE6 support was required.
Re:Javascript is insecure - AJAX is security hole
on
Ruby On Rails Goes 1.1
·
· Score: 2, Insightful
First let me say that I'm the lead developer of Echo2, which absolutely requires JavaScript in order to function, so please take that into account as a bias if you desire.
I disagree with the statement "JavaScript is insecure". Implementations may be insecure, but the specification itself has no such problem. There have certainly been security holes discovered in JavaScript implementations. There have been equally dangerous security holes discovered in other aspects of the browser.
My other question to the "disable JavaScript" camp is, "what do you propose as an alternative?" Flash, client-side Java or any similar technology has the same security concerns as client-side JavaScript. The answer of "just use plain HTML" is not a solution. JavaScript and this "AJAX" stuff is not just about adding bling to applications--it's about eroding the barrier between remote and desktop applications.
"My in-laws have a Chevrolet Trailblazer with the nav system. You cannot access any of the menus or buttons while the car is moving. Even the passenger cannot override the system. Since auto manufacturers typically reuse systems like this through out all their cars, presumably all Chevyrolet models are in the same...er...boat."
I retrofitted this same system into my pickup. I found this limitation to be extremely frustrating, as they disabled far too much of the system and failed to take into account the fact that a passenger could operate the system. For example, they disabled the functions to "navigate to a previous address" and the function to "navigate to a preset memory point". Further, many GM vehicles have a weight sensor in the passenger seat to determine the weight of an occupant for correct airbag deployment (including my truck), but this information is not used in determining if the system should be fully operable.
There is however a solution. These navigation systems take their primary data feed from a vehicle speed sensor (VSS) and a directional gyro (rather than the GPS signal). The features are disabled whenever the VSS signal wire is sending input (I believe greater than 5mph). The solution is thus to install a toggle switch on this wire (you'll need to find the wiring diagram for the nav radio on your particular truck, but they're readily available on the net). If anyone does this, I highly recommend continuing to refrain from using the text-entry keypads while driving!
Slashdot Mirror
And so far it's been a very profitable investment.
I am writing applications that require extensive hardware-specific testing (file manager, network-based stuff, system tools). I certainly have plenty of complaints about Android with regard to cross-device compatibility, and I've even found plenty of egregious omissions in the API (e.g., how do you find all user-writable storage without going down to /proc/mounts). That said, I find it to be an overall excellent platform. And it seems to pay the bills.
My only real complaint with the investment in devices is that I would love for cell carriers and/or Motorola/HTC/Samsung/etc to respond to my requests to have even slightly early access (or guaranteed release day access) to new devices. I'm sick and tired of visiting random cell phone stores who won't reserve product and lie about availability. And I'm tired of explaining that yes I want to pay full retail and no I do not want a contract no matter how much of a better deal it is.
Just received an unsolicited commercial email from them advertising this new site (what's that other term for these again?) It went to one of our support accounts...the kind that wouldn't be found unless one were to skim a web site for email addresses.
The unsubscribe link from this invitation to join requires that I first "log into my account". The email is an invitation to join.
From a technical perspective, I'm impressed by both platforms.
Be aware however that deployment of iOS applications to the general public may only be done with Apple's approval of your specific application. And unless you are targeting jailbroken phones, all revenue must pass through Apple. They may choose to reject an app for reasons stated in their developer agreement, or for unstated reasons: http://www.macworld.com/article/151680/2010/06/myframe_rejection.html
The Android market's terms are more lenient than Apple's, and the Android market does not have a formal approval process of any kind. Apps may however be removed for violations of the Android Market developer agreement.
But even then, Android phones allow the installation of apps from sources other than the Android market.
First, please beware that I barely qualify as a layman when it comes to knowledge of cellular networks and/or RF transmission.
If I recall correctly though, the transmitting power used by a cellular phone is inversely proportionate to the proximity of a tower. That is, if the tower is far away and more difficult to reach, the phone will use more transmitting power.
So from a radiation perspective, is it safer to have towers located far away at the expense of having our cell phones constantly running at maximum power mere inches from our reproductive organs or brains?
This is a very impressive evolution. Thinner, better display, more processing power, better battery life, better camera, new sensors, and more capabilities across the board, both hardware and software.
I'd love to develop for it.
I just wish there was some way I could know that if I spent thousands of hours creating software for it, that such software would continually be available for purchase via the App Store. I'd be okay with explaining in detail to Apple how the software was going to work before developing it. But it would be necessary to obtain an authoritative answer to inform as to whether the software would be accepted (if implemented to a proposed specification) and for what minimum duration the software would be allowed on the store.
There is a fundamental risk in developing new software: "Will customers buy this?" This risk can be calculated to a certain extent. My concern with developing for iOS is that an additional incalculable risk exists, and it is simply too much to bear.
I can't stand hearing everyone talk about multitasking on things like Android devices as though it works the same way as it does on their desktop PC. Nothing could be further from the truth.
The first form of multitasking on Android is that applications can elect to receive messages, e.g. "someone is calling", or "wifi state changed".
If you actually need to do constant work in the background (e.g., listening on a network port), you can do so as well, using a "service". And even services will be killed by the system if resources are needed.
No one is talking about running a Handbrake encode session, Firefox with a bunch of animated Flash ads, and a kernel compile at the same time on their phone.
Multitasking on a phone is being able to record breadcrumbs of a journey with a GPS app, listen to streaming internet radio, and receive notifications from an instant messaging client at the same time.
If I open Google Chrome and Mozilla Firefox, with a few tabs active in each on popular sites, the entirety of both cores of my Intel E7500 CPU will be consumed by Flash advertisements.
I'm on a Linux machine with a lot of memory, which makes for the worst case scenario: First, Flash is horrible on Linux. Second, I use virtual desktops and leave browsers open for days at a time. Memory is not a problem.
Flash ads tend to be poorly written by a creative designer who could give a rat's rear end about your system resources.
The ads interfere with my ability to work, which costs me money. They also cause my computer to consume significantly more power. So in effect, your Flash ads are even bad for the environment.
They're also of course quite annoying, and if given only the options of browsing the internet with Flash ads or not browsing the internet at all, I'll choose the latter.
How about you try this experiment: Turn off Flash ads. Post a banner at the top of your site that says, "Hey, we've turned off Flash ads. Please exclude this site from your ad blocker so we can make money."
Love the new UI, and really appreciate the option of another well done browser. But they still refuse to fix a trivial CSS bug which has horrible consequences for AJAX apps.
Just go to this page, and resize your browser with the vertical (not horizontal) handle.
http://echo.nextapp.com/content/test/operacss/
(This is very hard/impossible to do on a mac, as they don't really have one).
Unfortunately the bug is not limited to resizing with the vertical handle...it manifests itself in other ways. It seems the browser is incorrectly measuring/reporting the vertical size of elements, and sometimes uses this data internally (as in the case of this test).
Full thread is here:
http://my.opera.com/community/forums/topic.dml?id=250572
And one of the Ajax apps that experiences more serious failures as a result: http://demo.nextapp.com/
Yes, Android currently only lets you install application packages on internal memory. Application developers know this, so there's a major effort made to keep the application footprint small, and then have the applications download and store additional resources on the SD card, which has no such limitations. As an example, a game would store its levels/media on the SD card. Or in the case of an offline GPS app, the map data would be stored on the SD card.
With my Droid, I've yet to get anywhere close to this limitation, and I'm always on the hunt for neat apps on the market. I currently have 162MB free (I believe it originally had 250MB available).
Yes, it's not inconceivable that you'll run into this limitation, but at the same time, it doesn't come up all that often. Don't be concerned that your iPhone is using 3GB for app storage...on an Android device those apps would be putting 95% of their data on the SD card.
I made a webapp in early 2001 that used both AJAX (with a hidden frame for client-server communication, rather than an XHR) and a Java applet. It was used to create presentations from within a web browser. The Java applet was used for laying out a presentation slide, providing the user with the capability to create/position elements of the presentation (text, images, and so forth). The app was operational more than a year before the filing date of US7599985.
The application made use of Netscape's LiveConnect (an old Java/JavaScript communication API) to do this. LiveConnect was introduced in 1997, with Netscape 4. As far as I can see, LiveConnect was designed to enable what this patent claims to invent.
See http://en.wikipedia.org/wiki/LiveConnect and http://en.wikipedia.org/wiki/Netscape_Navigator
My example: http://echo.nextapp.com/content/test/operacss/
The consequences get a bit more catastrophic with applications with larger quantities of nested DIVs. Things really start to break when you start measuring using Element.offsetHeight.
Apologies for posting it here...again...but I'm tired of replying to users who ask "why does component X not render properly in Opera, it passes Acid3 thus something must be wrong with the component."
Firefox on Windows looks great/awesome/beautiful....name it. But on Linux, it is inherently ugly. The beast looks ancient and the fonts and dialogs make matters worse.
In Ubuntu 9.04 here, and I personally think the stock DejaVu fonts on Linux look quite nice. Actually prefer the traditional toolbar on Linux with Tango icons (tango.freedesktop.org) rather than the "enlarged back button" version found on Windows and OSX.
The only problem I see is the topic of this thread, i.e., performance. It's slow enough to feel slow, and the fact that most Linux distros run so well on old hardware makes the problem worse.
The bigger problem for the "Linux browsing experience" still seems to be Flash. Visiting a Flash-heavy site (like the horrible items produced by any given automaker) is a painful experience...it's bad enough that I'll typically crack open the MacBook. I find Flash sites consume an order of magnitude more CPU running natively in a Linux browser than they do running in a Windows XP VirtualBox instance hosted by the same Linux OS.
AdBlockPlus and FlashBlock are the only things that enable me to continue to use this computer for web browsing. It's somewhat of a sad state of affairs, given that it's more than quick enough to run multiple VirtualBox instances, Eclipse instances, and a GIMP instance with dozens of files open at the same time. But give it one web page with a few Flash advertisements, and you'll think you're on a Pentium 60.
It may be ACID3 compliant, but it still can't correctly render two nested DIVs:
http://my.opera.com/community/forums/topic.dml?id=250572
To see it fail, just go to this page in Opera 10: http://echo.nextapp.com/content/test/operacss/ , and resize your browser vertically (but NOT horizontally). It's been reported in the bugtracker, forums, forum PMs to developers, etc..
So please, when you file that bug report today that "Opera 10 doesn't render things correctly" to whatever your AJAX framework of choice happens to be, don't make a big deal out of the fact that it's "Acid3 compliant" and thus the AJAX framework developers must be in the wrong.
I hadn't heard about this bug before, but I just tested out the bug using your web page, and the bug must have been fixed. All three pages (17 DIV, 21 DIV, and 25 DIV) loaded instantaneously. I'm using an unreleased internal build of IE8. Thank you for submitting the bug report to the IE team!
Good to hear it's still the case. This is what I've been told by other MS folks working on the problem. My concern is not about this bug, but rather the fact that IE8 RC1 had quite a few major flaws in it, yet there will be no RC2. With a product as influential as Internet Explorer, you need to wait until your release candidates are reasonably well accepted by the public before you fire the final.
As a software developer, I find that when you ship a really buggy alpha version (or beta/RC), all you're going to get as feedback are the truly GLARING bug reports. If you want to get the edge cases, you've got to release something that's polished enough for people to spend time using. IE8 hasn't done that yet.
Just tried your link with IE8 from W7.7000 and had no problems at all...
The stock W7 IE8 build is unaffected. It's between beta2 and RC1 though.
As a developer of an AJAX-based web framework, I'm upset to see IE8 being thrown out the door so quickly. RC1 was nothing short of a disaster: it had a performance bug where nesting absolute-positioned DIVs would result in exponential performance decreases.
Test case here: http://echo.nextapp.com/content/test/ie8/
The 25-nested DIV test would require killing the browser. Nesting absolutely positioned DIVs is somewhat fundamental to delivering application-style user interface layouts in a web browser.
I reported this bug everywhere I could, and Microsoft actually did a great job in responding to it. They say they've found it and fixed it. But there is no way for us to test this. We must simply take their word for it and wait. They're going from RC1 to final, and begging and pleading for an interim build didn't warrant much of a response.
From reading forums (e.g. Ajaxian: http://ajaxian.com/archives/push-back-digital-tv-or-ie-8), my IE8 experience is not uncommon with other web frameworks as well. The average developer's opinion there suggests RC1 is nowhere near ready for a final release. Every build of IE8 (beta1, beta2, win 7's "beta2+", and the RC) have each had major unique problems not found in other releases.
I have developers asking me if their software will work in IE8 on day 1 and the only honest answer is "I have absolutely no idea." Anyone (without a final build) who tells you otherwise, even offerring a rough estimate, is a liar, IMHO.
I don't understand the point of putting out a "release candidate" and then not using feedback to determine whether the next release is a "candidate" or a "final". Our bug alone means that IE8 RC1 has never been publicly tested with many complex web-based applications.
It seems to be fixed in Opera 9.61 or 9.62 - I'm using 9.62 here, and I cannot reproduce your problem on your sample page.
According to the CSS code, the green box should always be 20px away from the browser edge. The red box should be perfectly and symmetrically inside the green box, with its edges 40px away from the browser edge. Basically, the page should always be rendered exactly as it was in its initial state.
If you resize the browser VERTICALLY in Opera, the red box won't always resize to maintain the above rules. The red box will remain its original size. If you try this in IE7, FF, or a WebKit based browser, it will work as described in the previous paragraph.
If you're on a Mac or otherwise running an OS with a window manager theme that doesn't have a "vertical-only" resize handle, it may be difficult/impossible to reproduce with this example. (The problem will still affect such users in other cases that do not require a resize though).
That looks like a corner case situation to me. Maybe you would do better by not inflating the importance of bugs you report? :)
I strongly disagree. It breaks valid, commonly-used layouts and is quite difficult to workaround.
The example case is as simplified as possible to demonstrate the bug. I too don't think the example scenario will be hit very often. I think most people use the lower-right corner handle rather than bottom/top handles to resize a window, or simply use the maximize function. I used this example because it easily illustrates the issue.
The underlying problem however seems to come up quite often in my experience. Working around it has proven between difficult and impossible because all height data in the browser is incorrect (not current). It appears height data is not recalculated until the browser is *horizontally* resized.
There's quite a bit more information in that my.opera.com thread if you're interested.
Just tried it out, and of course it passes ACID3 as advertised. I still can't recommend this browser on the grounds that it can't correctly render absolutely positioned CSS elements, as demonstrated by the following code:
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Resize your browser with the vertical handle!</title>
</head>
<body>
<div style="position:absolute;left:20px;right:20px;top:20px;bottom:20px;background-color:lime;">
<div style="position:absolute;left:20px;right:20px;top:20px;bottom:20px;background-color:red;">
</div>
</div>
</body>
</html>
Hosted version of the above:
http://echo.nextapp.com/content/test/operacss/
Opera 9.50, 9.60, and now 10.0alpha will not render the above properly if the browser is resized vertically. (9.27 and prior work perfectly) On the initial render, 9.5/9.6 and 10 do fine, but the moment one resizes the browser vertically (and NOT horizontally as well), things go awry. I reported this to their bug tracker six months ago, and posted a thread on their forums 2.5 months ago: http://my.opera.com/community/forums/topic.dml?id=250572 Have also mentioned it in their 9.6-about-to-be-released-post-non-working-sites thread.
This bug has additional consequences for AJAX applications that make use of on-screen measuring using offsetWidth/offsetHeight information. In such cases, even the initial rendering can be seriously flawed as offsetHeight returns incorrect values. (Note: offsetXXX properties are not part of a proper W3c standard, but are universally supported).
Apologize for the quasi-rant, but I just don't want to see another bug report about how our applications don't look right in a supposedly ACID3 compliant browser, thus indicating that the problem "MUST" be our fault. Please realize that passing ACID3, while a neat accomplishment and generally good thing, is far from a guarantee of standards compliance.
(emphasis added)
My apologies, but "FecesFlingingRhesus" is not on our list of paid shills. My best guess is that he might be a member of the cult.
Best regards
--Tod Liebeck (Director of Shills and Level 6 Cult Leader)
NextApp, Inc.
There is money and fame to be had in promoting either side of the global warming argument (or any major political/scientific/economic issue for the matter). As will be the case with any "hot" scientific issue, there is certainly adequate motive to do this. I'm not taking either side here, but the statements in the article cannot be dismissed on the basis that there would be no motive for scientists to overstate global warming.
In my opinion, #1 may actually happen. Beta2 is still a long way off from having "reasonable" CSS support, but they've got close to another year to pull it off, if I'm correct in assuming that IE7 will launch with Vista.
The second item won't happen for at least four years, assuming IE7 comes out in one year. At this point we all have plenty of historical data on the rate at which corporate networks upgrade things like web browsers. 3yrs for 90% to upgrade is probably wishful thinking.
The reason that I believe IE7 will be significant at that point is that web development time, be it in the context of writing your personal homepage or an advanced AJAX-based framework, will take approximately 50% as long as it did when IE6 support was required.
First let me say that I'm the lead developer of Echo2, which absolutely requires JavaScript in order to function, so please take that into account as a bias if you desire.
I disagree with the statement "JavaScript is insecure". Implementations may be insecure, but the specification itself has no such problem. There have certainly been security holes discovered in JavaScript implementations. There have been equally dangerous security holes discovered in other aspects of the browser.
My other question to the "disable JavaScript" camp is, "what do you propose as an alternative?" Flash, client-side Java or any similar technology has the same security concerns as client-side JavaScript. The answer of "just use plain HTML" is not a solution. JavaScript and this "AJAX" stuff is not just about adding bling to applications--it's about eroding the barrier between remote and desktop applications.
I retrofitted this same system into my pickup. I found this limitation to be extremely frustrating, as they disabled far too much of the system and failed to take into account the fact that a passenger could operate the system. For example, they disabled the functions to "navigate to a previous address" and the function to "navigate to a preset memory point". Further, many GM vehicles have a weight sensor in the passenger seat to determine the weight of an occupant for correct airbag deployment (including my truck), but this information is not used in determining if the system should be fully operable.
There is however a solution. These navigation systems take their primary data feed from a vehicle speed sensor (VSS) and a directional gyro (rather than the GPS signal). The features are disabled whenever the VSS signal wire is sending input (I believe greater than 5mph). The solution is thus to install a toggle switch on this wire (you'll need to find the wiring diagram for the nav radio on your particular truck, but they're readily available on the net). If anyone does this, I highly recommend continuing to refrain from using the text-entry keypads while driving!