[CSS Sprites are] only a win if your images are tiny. Why are you
optimizing for this? Tiny images do not take long to download, even on
dialup, because they are tiny.
The point is to reduce the number of HTTP connections, and thus avoid
pointless latency. A TCP connection takes time to set up because there's a
back-and-forth, and if the client is far from the server this can
introduce a significant delay in loading static resources.
It's significant in relative terms, but not so much in actual wall time.
We're talking about sub-1k files here. They don't take long to transmit, even
if you do it the stupidest way possible (to wit: the way HTTP does it:) ).
A 15k file will always, always, always take longer to retrieve from the
server than a 1k file would have. That's 15 times longer that you have to
wait until the bandwidth being used to transmit that file becomes available
if you need it for something more important, such as the portion of the
actual content of the page that hasn't finished loading.
You can make your page load faster overall and still end up making it slower
for the purpose the page was originally loaded in the first place. You don't
see it so much on broadband, since you have bandwidth to burn on two large
files, but on dialup where everything larger than a few KB takes full seconds
to load under the best of circumstances, it's rather apparent.
Not to mention that the browser may have to reflow the page as the new
images come in, which looks ugly. (Albeit that can be mitigated if image
width/height are specified in the HTML).
If you're using CSS sprites you have to specify the width/height, so it's
only fair to assume you are willing to do the same with normal images.
What, seriously? Are you really optimizing for your visitors who load
one and only one page before their cache is cleared? Even though you
"measured... and found the number of page views with a primed cache is
75-85%"?
For a public site, this can be important. A user coming to your site for
the first time may only be there on a whim: if it's taking a while to
load, then they may either abandon the load or get a bad first impression
that your site runs slowly.
If you could improve the experience for your visitors with empty caches with
no impact on those who return regularly, that'd be a no-brainer. I'm not
convinced, though, that that is the overall effect these guidelines,
naively-implemented, would have. And they would inevitably be
naively-implemented, since the documentation for each test is written as a
justification for the test, rather than a discussion of the situations where
the technique recommended is and is not appropriate.
Keep in mind, if you use a far future Expires header you have to
change the component's filename whenever the component changes.
And if you ever change something but forget to change the file name,
your visitors will have to reload everything on the damn page to get
the current version of the one thing you changed.
True, but a good engineer can solve this problem. We solved it by
including each resource's last-updated-version (from source control) in
the URL, via some clever template and filesystem magick. This means the
developer doesn't have to remember to change the file name, which would be
a version control nightmare anyway.
I'm trying to imagine how this might be implemented. I'm assuming a source
control system su
And if you ever change something but forget to change the file name, your visitors will have to reload everything on the damn page to get the current version of the one thing you changed. Assuming, of course, they even realize there should be a newer version than the one they're seeing. And assuming that they actually know how to do that.
For one, having the Expires header reduced the load-latency - Your JS and CSS files are unlikely to change within a scope of a day or an hour. In theory, the browser does not have to re-validate the files that have an Expires: header set. So, when the user clicks from one link to another in Your site, he makes less HTTP requests. This improves latency, especially as there is the two connections per host rule. As for site upgrades append the version number to a file (automated build scripts are there to help) - it is not difficult.
So, developers and admins: please set the Expires header, it is a Good Thing[tm]
Right, but they are not merely advocating for the Expires header, but for setting a completely absurd Expires header in the far future, and later hacking around the problems that causes by playing games with the resource name. They wouldn't have to do that if they didn't arbitrarily hate ETags.
Well, let me put it to you this way. Let's say your little icons are 400B apiece. And say your headers are another 400B each way, bringing the effective size of the file up to just shy of 1.2KB. It's an ideal application for a CSS sprite, because you'll no question get huge wins in file size. On lousy 28.8 dialup I can still download three of them every second. Alternately, if the page is still loading, the bandwidth can be divided between loading the images and the page without much perceptible impact on either.
Downloading a single 15k file when you hit a site, on the other hand, is painful on dialup. It takes five seconds in the best case, and if you've got anything downloading at the same time (note: Firefox defaults to 8 simultaneous connections to any given server and 24 overall), it's only going to be worse. When the file breaks about 50k, you start running into servers that just drop link midway through because they can't be assed to wait for you to finish downloading the image. So you get to try again, and probably get cut off again. And the gain that is supposed to justify this is a scant few tenths of a second per image. And even that will only actually be realized on the first visit.
I hate to see how popular this technique is getting, because it's flat out a dumb optimization. If people doing this were actually interacting with their page over a dialup connection instead of just looking at a pretty graph, they wouldn't bother.
Perhaps the problem of lots of little images vs a single 'sprite' is more psychological. Perhaps it just appears fast seeing lots of individual images load.
I would agree with this. As I said, loading a big image tended to make the content itself take longer. If I'm reading while the images load, I'll not notice or honestly even care if the page as a whole is 100% larger. Conversely, if you've done something to cut the load time in half, but I have to wait for the entire thing before I can actually use any of it, you've in a pragmatic way actually made the page slower.
So, both quotes are correct: 50% of daily unique visitors came in with an
empty cache, 87% of total page requests were made with a primed cache.
Sorry, I didn't mean to suggest that their numbers didn't add up, just that
small optimizations that service half your visitors don't make sense when
they are something that only has any impact on the first request. The
disadvantages of aggregating files together in the manner they are suggesting
just outweigh that small benefit.
It's a classic case of all things in moderation: If you're going to one or
other extreme, you're probably hamstringing yourself. If you're picking
somewhere in the middle, informing yourself with the statistics, getting
the best understanding of where that sweet spot lies, you're probably
going to be far more successful.
Yes, thank you. I think this sums up my real objection to the tool better
than anything. If you did nothing at all, chances are you're already
on that middle ground, since your HTTP server would be by default configured
for the generally-useful case. If you blindly follow the advice of this tool,
you've gone to such extremes that you're actually making things worse.
Between the letter grades, the hard line taken by the tool, and the complete
absence of any guidelines on the website to help you decide when its advice
should not be followed, I almost think the thing was
designed to have that effect. Not in a mustache-twirling villain
kind of way, of course, but more in an "I am an expert and this is what I say
you should do and this is why I am right and did I mention I have a book?"
kind of way.
[Inlining images] is hands down the stupidest idea I have ever heard.
This can improve performance drastically, because there is less communication involved and because you can actually reach full transmission speed. With TCP/IP it always starts slowly and the speed gets ramped up step by step. With small files the full speed often isn't reached, because the download is complete way earlier.
That means that downloading a single file (even if it is ~33% bigger) can be a lot faster.
Googling isn't turning anything up (not suprising, since it's pretty impossible to google anything when "http" is one of the keywords), so I'd be very interested if you could provide some numbers that support this. I can imagine small images falling within the slow start period (heck, some of them would fit wholesale in a single datagram), but normally you wouldn't establish a brand new connection to download the image, you'd just issue a second GET over the connection you already have.
So I would expect slow start to have the same impact either way, but this is honestly an OSI layer or two above where I normally work, and I'd love to see some hard figures.
This is only a win if your images are tiny. Why are you optimizing for
this? Tiny images do not take long to download, even on dialup, because
they are tiny.
And because they are tiny and numerous, the overhead from the HTTP headers
is huge. Headers can easily be a few hundred bytes. Looking at the default
'icons' that come with Apache, the majority are little GIF's under 400
bytes. So if you go and download them with individual HTTP requests,
you're throwing away 30-50% of your bandwidth just in HTTP overhead. Not
to mention the delay as the request is sent and handled by the server, or
TCP connection overhead, although hopefully your web/proxy server supports
keep-alives and pipelining.
Yes, it certainly is. Further, the overhead of the image header is
also huge. The icons on Yahoo's page would be 4x the size if they
were individual files. There's a lot of completely unused resources in their
sprite files, but it's actually smaller on the whole.
But my experience on dialup was that larger images tended to saturate my
connection. The icons might load faster, but it would be at the expense of
the actual content. Since it doesn't take long to download a few dozen
individual 1k files, and since each one you successfully download is cached
and subsequently not downloaded at all, I again have to question the value of
this optimization.
Your point about having a single 'sprite' image fail and losing lots of
page graphics stands. But if you make sure the image is nice and
cacheable, it will hang around longer and there will be fewer
opportunities to fail.
Well, it's not even the case that you can just make the image easy to cache
and be home free. Eventually you're going to want to change some part of the
image. Consider the list of links down the left side of the page. The icons
for that list are ideal for this technique; about 900B each when
split into 22x22x8bpp GIFs rather than 213B as part of that composite image.
But the link in that list (labeled "OMG") has a little "New" flag floating
beside it. When they added that link, everybody had to download that 15k file
again instead of just 900B of the new icon.
Using an Expires: header with distant dates also sounds dodgy to me. You'd
really only want to do that with static content. And like they noticed, be
sure to increment some version/revision number in the filename/URL.
Honestly, the more I think about this strategy, the less sense it makes. If
you have to change the name of the resource to invalidate everyone's
eternally-cached copies, that means you have to change everything that uses
it as well. Maybe not a big deal if your pages were dynamic and not cachable
to begin with, but if they weren't you have to blow away their cached copies
as well.
The Anonymous Coward here is spot on. This thing gives awful, awful advice.
Some of these in particular I really hated as a dialup user.
CSS Sprites are the preferred method for reducing the number of
image requests. Combine all the images in your page into a single image
and use the CSS background-image and background-position properties to
display the desired image segment.
This is only a win if your images are tiny. Why are you optimizing for this?
Tiny images do not take long to download, even on dialup, because they
are tiny. Frankly I would prefer to have all the site's little icons
progressively appear as they become available than have to wait while a
single image thirty times the size of any one of them loads. Or, perhaps,
fails to load, so that I have to download the whole thing again
instead of just the parts I have.
Inline images use the data: URL scheme to embed the image data in
the actual page. This can increase the size of your HTML document.
Combining inline images into your (cached) stylesheets is a way to reduce
HTTP requests and avoid increasing the size of your pages.
This is hands down the stupidest idea I have ever heard. Ignoring for the
moment that it won't even work for the 70% of your visitors using
IE, sending the same image multiple times as base64-encoded text
will completely swamp any overhead that would have been introduced by the
HTTP headers.
Combined files are a way to reduce the number of HTTP requests by
combining all scripts into a single script, and similarly combining all
stylesheets into a single stylesheet.
Less egregious than suggesting CSS Sprites, but it still suffers from the
same problems. These are not large files, and if they are large
files, the headers are not larger.
As described in Tenni Theurer's blog Browser Cache Usage - Exposed!,
40-60% of daily visitors to your site come in with an empty cache. Making
your page fast for these first time visitors is key to a better user
experience.
What, seriously? Are you really optimizing for your visitors who load one and
only one page before their cache is cleared? Even though you
"measured... and found the number of page views with a primed cache is
75-85%"?
Add an Expires Header
...
Browsers (and proxies) use a cache to reduce the number and size of HTTP
requests, making web pages load faster. A web server uses the Expires
header in the HTTP response to tell the client how long a component can be
cached. This is a far future Expires header, telling the browser that this
response won't be stale until April 15, 2010.
Expires: Thu, 15 Apr 2010 20:00:00 GMT
...
Keep in mind, if you use a far future Expires header you have to change
the component's filename whenever the component changes.
And if you ever change something but forget to change the file name,
your visitors will have to reload everything on the damn page to get the
current version of the one thing you changed. Assuming, of course, they even
realize there should be a newer version than the one they're seeing. And
assuming that they actually know how to do that.
Put CSS at the Top
While researching performance at Yahoo!, we discovered that moving
stylesheets to the document HEAD makes pages load faster. This is because
putting stylesheets in the HEAD allows the page to render progressively.
Um. Duh? link elements are not valid in the body.
style elements are
Well, that's true, it treats it as it would any other malformed HTML document. But HTML5 seems more of an offshoot of HTML4 than of XHTML1. Consider this, from the section describing the syntaxes supported by the standard:
The second concrete syntax uses XML, and is known as "XHTML5". When a document is transmitted with an XML MIME type, such as application/xhtml+xml, then it is processed by an XML processor by Web browsers, and treated as an "XHTML5" document. Generally speaking, authors are discouraged from trying to use XML on the Web, because XML has much stricter syntax rules than the "HTML5" variant described above, and is relatively newer and therefore less mature.
Some further testing reveals, however, that IE will not fill the password if the resource portion of the URL differs. This is a vulnerability in only Firefox because only Firefox uses the form action to choose the password, and only Firefox does so without user intervention.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <title>P assword Test</title> <form method="post" id="login"> <div> <input type="text" name="un"> <input type="password" id="pw" name="pw"> <input type="submit"> </div> </form> <script type="text/javascript"> var f = document.getElementById('login') f.onsubmit = function () { alert(document.getElementById('pw').value) } </script>
This produces a message box revealing the contents of the password field when the form is submitted. It reveals passwords entered by the visitor as well as those automatically filled in by IE. The password box is not filled in until the user name has been entered. Tested in IE6SP2 and IE7.
I would be interested to know what of HTML is not supported by user agents commonly in use today. I've seen plenty of lists of bugs in their support of CSS, but the only one that comes to mind for HTML is that Internet Explorer doesn't support <abbr>.
For it to be a fair comparison, you would have to compare OpenBSD + GNOME (for example).
This isn't strictly true. OpenBSD deliberately ships without a desktop environment to avoid the security issues inherent in including so much and such complex software. Vista deliberately ships with a GUI and numerous support services to make it easier to use as a desktop operating system.
Their goals are different, but if the question is simply "is Vista the most secure?" then it's perfectly fair to compare the two as configured out-of-the-box. I mean, it's not like Theo DeRaddt snuck in to Redmond HQ and added a notoriously buggy and insecure web browser to their OS when they weren't looking.
Actually, it only seems like it isn't working because the timelines are diverging. Keep trying, eventually you will randomly be on the one where you receive your message!
Sure, which is why I use that dialog box example. It was a straight-forward but non-optimial solution to a major problem that was dismissed because eventually there would supposedly be some magic perfect solution that would take care of it better.
I can absolutely appreciate that threads introduce a whole host of issues that you don't have to deal with in a single-threaded app, but that brings me not much comfort when a script on ImageShack or GMail has locked the browser up for the third of fourth time in an evening.
Yeah, that's great. Know what else sucks, Mr. Eich? The whole app becoming completely inoperative because one script on one tab is stuck doing who knows what. Smacks of the old "dialog boxes suck" line that was used to explain why we couldn't have a confirmation box to avoid accidentally shutting down the entire app when we were just trying to close a tab.
I don't have a land line. Why? The cell phone is _cheaper_. If you're going to be pragmatic, ditch the land line.
It's not about new and hip. It's about being fed up with how the old-fashioned phone company rips you off and charges you out the a$$ for features that simply come included with cell plans.
As someone who also overall gets better value out of his mobile, I can still think of some pragmatic reasons that a landline is better.
Believe that you are paying for all the features that are included in a mobile plan. I hate using voicemail, but I don't get a discount for having it disabled on my mobile.
Your landline is powered, and will work even if the power is out for a week.
If your landline phone is stolen, they get a phone that is probably worth five bucks new. If your mobile phone is stolen, they get to make calls on your dime until you miss it.
You can connect as many extensions as you like to a line, no additional charge. Even if you wanted to pay for it (and believe that you would have to pay for it), I'm not even sure you could get two mobiles to ring on the same number.
You can hook about anything you like to a landline. Answering machines, fax machines, remote ringers, crazy voice-driven menu systems, an old 486 running Wildcat! for nostalgia's sake; whatever.
Local calls are included in the price of the service. Inbound calls are paid by the caller, instead of you and the caller. Outbound calls are billed for what you actually use.
I think if I was going to do it, I'd make the buttons larger and align the label along the top. Your thumb wouldn't obscure the label, and you'd still be pressing the button instead of someplace vaguely in the vicinity of the button.
For widgets that are more information-dense--say a list of contacts in your address book--split the list into two columns and make the list items twice as tall.
in one corner, well-moneyed corporate interests with lawmakers and enforcers in their pockets
in the other corner, legions of poor, borderless, highly motivated, technically astute, and media loving teenagers who couldn't give one rats ass about the bloated overreaching joke that copyright law in this country has become, because it is way beyond speaking to them in the language of right and wrong
They don't need to defeat the legions of media-loving teenagers. They just need to defeat one. Just you. The way this works is, they put laws on the books that make criminals out of the entire population. Then whenever they need to pin something on you, there's a de facto conviction right at hand. It doesn't have to be an effective way to stop piracy, since it's really not about stopping piracy at all.
There's a checkbox to turn that feature off, if you want to see BSODs, in the System control panel I believe. Or just check your Event Viewer when you have a mysterious reboot.
Every time I encounter a crashy Windows machine I have had to turn that feature off, since it unfailingly corrupts the event log on the way down.
While there is a fair amount of pr0n and the like, there is a *lot* of traffic from China and other countries with restrictive laws about what you can and cannot research.
Pardon me if I am displaying my ignorance, but if your proxy is really anonymous and you really do not keep any logs, how would you possibly be able to know this?
Slashdot Mirror
It's significant in relative terms, but not so much in actual wall time. We're talking about sub-1k files here. They don't take long to transmit, even if you do it the stupidest way possible (to wit: the way HTTP does it :) ).
A 15k file will always, always, always take longer to retrieve from the server than a 1k file would have. That's 15 times longer that you have to wait until the bandwidth being used to transmit that file becomes available if you need it for something more important, such as the portion of the actual content of the page that hasn't finished loading.
You can make your page load faster overall and still end up making it slower for the purpose the page was originally loaded in the first place. You don't see it so much on broadband, since you have bandwidth to burn on two large files, but on dialup where everything larger than a few KB takes full seconds to load under the best of circumstances, it's rather apparent.
If you're using CSS sprites you have to specify the width/height, so it's only fair to assume you are willing to do the same with normal images.
If you could improve the experience for your visitors with empty caches with no impact on those who return regularly, that'd be a no-brainer. I'm not convinced, though, that that is the overall effect these guidelines, naively-implemented, would have. And they would inevitably be naively-implemented, since the documentation for each test is written as a justification for the test, rather than a discussion of the situations where the technique recommended is and is not appropriate.
I'm trying to imagine how this might be implemented. I'm assuming a source control system su
Right, but they are not merely advocating for the Expires header, but for setting a completely absurd Expires header in the far future, and later hacking around the problems that causes by playing games with the resource name. They wouldn't have to do that if they didn't arbitrarily hate ETags.
Well, let me put it to you this way. Let's say your little icons are 400B apiece. And say your headers are another 400B each way, bringing the effective size of the file up to just shy of 1.2KB. It's an ideal application for a CSS sprite, because you'll no question get huge wins in file size. On lousy 28.8 dialup I can still download three of them every second. Alternately, if the page is still loading, the bandwidth can be divided between loading the images and the page without much perceptible impact on either.
Downloading a single 15k file when you hit a site, on the other hand, is painful on dialup. It takes five seconds in the best case, and if you've got anything downloading at the same time (note: Firefox defaults to 8 simultaneous connections to any given server and 24 overall), it's only going to be worse. When the file breaks about 50k, you start running into servers that just drop link midway through because they can't be assed to wait for you to finish downloading the image. So you get to try again, and probably get cut off again. And the gain that is supposed to justify this is a scant few tenths of a second per image. And even that will only actually be realized on the first visit.
I hate to see how popular this technique is getting, because it's flat out a dumb optimization. If people doing this were actually interacting with their page over a dialup connection instead of just looking at a pretty graph, they wouldn't bother.
Wow. There's superior, and then there's superior!
I would agree with this. As I said, loading a big image tended to make the content itself take longer. If I'm reading while the images load, I'll not notice or honestly even care if the page as a whole is 100% larger. Conversely, if you've done something to cut the load time in half, but I have to wait for the entire thing before I can actually use any of it, you've in a pragmatic way actually made the page slower.
Sorry, I didn't mean to suggest that their numbers didn't add up, just that small optimizations that service half your visitors don't make sense when they are something that only has any impact on the first request. The disadvantages of aggregating files together in the manner they are suggesting just outweigh that small benefit.
Yes, thank you. I think this sums up my real objection to the tool better than anything. If you did nothing at all, chances are you're already on that middle ground, since your HTTP server would be by default configured for the generally-useful case. If you blindly follow the advice of this tool, you've gone to such extremes that you're actually making things worse.
Between the letter grades, the hard line taken by the tool, and the complete absence of any guidelines on the website to help you decide when its advice should not be followed, I almost think the thing was designed to have that effect. Not in a mustache-twirling villain kind of way, of course, but more in an "I am an expert and this is what I say you should do and this is why I am right and did I mention I have a book?" kind of way.
Googling isn't turning anything up (not suprising, since it's pretty impossible to google anything when "http" is one of the keywords), so I'd be very interested if you could provide some numbers that support this. I can imagine small images falling within the slow start period (heck, some of them would fit wholesale in a single datagram), but normally you wouldn't establish a brand new connection to download the image, you'd just issue a second GET over the connection you already have.
So I would expect slow start to have the same impact either way, but this is honestly an OSI layer or two above where I normally work, and I'd love to see some hard figures.
Yes, it certainly is. Further, the overhead of the image header is also huge. The icons on Yahoo's page would be 4x the size if they were individual files. There's a lot of completely unused resources in their sprite files, but it's actually smaller on the whole.
But my experience on dialup was that larger images tended to saturate my connection. The icons might load faster, but it would be at the expense of the actual content. Since it doesn't take long to download a few dozen individual 1k files, and since each one you successfully download is cached and subsequently not downloaded at all, I again have to question the value of this optimization.
Well, it's not even the case that you can just make the image easy to cache and be home free. Eventually you're going to want to change some part of the image. Consider the list of links down the left side of the page. The icons for that list are ideal for this technique; about 900B each when split into 22x22x8bpp GIFs rather than 213B as part of that composite image. But the link in that list (labeled "OMG") has a little "New" flag floating beside it. When they added that link, everybody had to download that 15k file again instead of just 900B of the new icon.
Honestly, the more I think about this strategy, the less sense it makes. If you have to change the name of the resource to invalidate everyone's eternally-cached copies, that means you have to change everything that uses it as well. Maybe not a big deal if your pages were dynamic and not cachable to begin with, but if they weren't you have to blow away their cached copies as well.
The Anonymous Coward here is spot on. This thing gives awful, awful advice. Some of these in particular I really hated as a dialup user.
This is only a win if your images are tiny. Why are you optimizing for this? Tiny images do not take long to download, even on dialup, because they are tiny. Frankly I would prefer to have all the site's little icons progressively appear as they become available than have to wait while a single image thirty times the size of any one of them loads. Or, perhaps, fails to load, so that I have to download the whole thing again instead of just the parts I have.
This is hands down the stupidest idea I have ever heard. Ignoring for the moment that it won't even work for the 70% of your visitors using IE, sending the same image multiple times as base64-encoded text will completely swamp any overhead that would have been introduced by the HTTP headers.
Less egregious than suggesting CSS Sprites, but it still suffers from the same problems. These are not large files, and if they are large files, the headers are not larger.
What, seriously? Are you really optimizing for your visitors who load one and only one page before their cache is cleared? Even though you "measured... and found the number of page views with a primed cache is 75-85%"?
And if you ever change something but forget to change the file name, your visitors will have to reload everything on the damn page to get the current version of the one thing you changed. Assuming, of course, they even realize there should be a newer version than the one they're seeing. And assuming that they actually know how to do that.
Um. Duh? link elements are not valid in the body. style elements are
Well, that's true, it treats it as it would any other malformed HTML document. But HTML5 seems more of an offshoot of HTML4 than of XHTML1. Consider this, from the section describing the syntaxes supported by the standard:
Some further testing reveals, however, that IE will not fill the password if the resource portion of the URL differs. This is a vulnerability in only Firefox because only Firefox uses the form action to choose the password, and only Firefox does so without user intervention.
This produces a message box revealing the contents of the password field when the form is submitted. It reveals passwords entered by the visitor as well as those automatically filled in by IE. The password box is not filled in until the user name has been entered. Tested in IE6SP2 and IE7.
I would be interested to know what of HTML is not supported by user agents commonly in use today. I've seen plenty of lists of bugs in their support of CSS, but the only one that comes to mind for HTML is that Internet Explorer doesn't support <abbr>.
Prying into the personal documents of your customers is not the least bit in a "grey area".
I like the way you think. I suggest mounting the device in the lens of a WWII gas mask to heighten the effect.
What about Professor Mann's EyeTap and similar devices? Closer to home, what about half the cell phones released in the past five years or so?
This isn't strictly true. OpenBSD deliberately ships without a desktop environment to avoid the security issues inherent in including so much and such complex software. Vista deliberately ships with a GUI and numerous support services to make it easier to use as a desktop operating system.
Their goals are different, but if the question is simply "is Vista the most secure?" then it's perfectly fair to compare the two as configured out-of-the-box. I mean, it's not like Theo DeRaddt snuck in to Redmond HQ and added a notoriously buggy and insecure web browser to their OS when they weren't looking.
Actually, it only seems like it isn't working because the timelines are diverging. Keep trying, eventually you will randomly be on the one where you receive your message!
Sure, which is why I use that dialog box example. It was a straight-forward but non-optimial solution to a major problem that was dismissed because eventually there would supposedly be some magic perfect solution that would take care of it better.
I can absolutely appreciate that threads introduce a whole host of issues that you don't have to deal with in a single-threaded app, but that brings me not much comfort when a script on ImageShack or GMail has locked the browser up for the third of fourth time in an evening.
Yeah, that's great. Know what else sucks, Mr. Eich? The whole app becoming completely inoperative because one script on one tab is stuck doing who knows what. Smacks of the old "dialog boxes suck" line that was used to explain why we couldn't have a confirmation box to avoid accidentally shutting down the entire app when we were just trying to close a tab.
As someone who also overall gets better value out of his mobile, I can still think of some pragmatic reasons that a landline is better.
I think if I was going to do it, I'd make the buttons larger and align the label along the top. Your thumb wouldn't obscure the label, and you'd still be pressing the button instead of someplace vaguely in the vicinity of the button.
For widgets that are more information-dense--say a list of contacts in your address book--split the list into two columns and make the list items twice as tall.
They don't need to defeat the legions of media-loving teenagers. They just need to defeat one. Just you. The way this works is, they put laws on the books that make criminals out of the entire population. Then whenever they need to pin something on you, there's a de facto conviction right at hand. It doesn't have to be an effective way to stop piracy, since it's really not about stopping piracy at all.
Every time I encounter a crashy Windows machine I have had to turn that feature off, since it unfailingly corrupts the event log on the way down.
Pardon me if I am displaying my ignorance, but if your proxy is really anonymous and you really do not keep any logs, how would you possibly be able to know this?