High-end GPUs have been larger than CPUs for many, many years now. It's a matter of perspective whether you find 471 mm^2 a significant step up from 195mm^2.

You might e.g. compare https://en.wikipedia.org/wiki/... die sizes and https://en.wikipedia.org/wiki/...

Really old generations aren't listed with die sizes there, but even the first generation that is (geforce 8xxx) includes e.g. the GeForce 8800 GTS (nov 2006) at 484 mm^2

Even a 10-core (modern) broadwell-E chip is around half that (http://hothardware.com/reviews/intel-core-i7-6950x-extreme-edition-10-core-cpu-review-broadwell-e-arrives lists that as 246mm^2)!

When I last evaluated zxcvbn (2 years ago) it was, however, a denial of service waiting to happen: it tries to estimate entropy by brute forcing its way through a bunch of different strategies for predicting structures in passwords. At the time it was possible to let a single (server-side) check take minutes of CPU time by carefully constructing your password. It may have improved, but I'd be careful if you really want to deploy it. Preferably use some client-side port; at least that way you just chase away a user with bad habits rather that let anyone that wants to DOS you.

The medieval warm period wasn't as warm as you're suggesting (I can't find any citations for more than 2 degrees, and the delta may well be less), and it wasn't world-wide: northern Europe (and some other parts of the northern hemisphere) was warmer, and as it turns out, europe ended up writing a disproportionate part of modern history, so that was remembered.

Globally, temperatures were lower than they are now.

This isn't a secret, nor is the information hard to find; e.g. https://en.wikipedia.org/wiki/...

There may be some truth to the inevitability of global warming, but make no mistake: our generation sure is screwing over the future thoroughly. Even in optimistic assumptions, it seems likely that greenland will lose most of its ice; which sounds to me like the world is likely to experience sea level rises of at least 10 meters (since greenland isn't the only glacier on the planet, and because warm water expands).

The question is whether that takes thousands of years - so cultures and populations get to adapt relatively calmly - or something scarier than that.

People aren't great at dealing with rapid change.

At issue are the speech (sythesis+recognition) API's, not the audio API's. However...

You're right - I was mislead by the fact that the feature is listed as providing 5 points, but that seems to be in error. The same also goes for speech api's incidentally.

The test isn't as bad as it seemed at first glance (though it's unfortunate that it's unclear what counts for what). Nevertheless, it counts proposed and experimental features, and misdetects at least keygen (which doesn't bode well for others), fails to do even basic validation whether a feature is implemented correclty, and it doesn't clearly make the distinction between html5 and the living spec, going so far as to link to the w3c spec for features like datetime inputs, even though that's not in the spec, but is in the whatwg living spec (from which likely later iterations 5.1 will emerge). It largely follows the living spec, but not everywhere (e.g. keygen, as you point out.)

In short: it's still not a good idea to read anything much into these numbers.

You're quoting out of context. What you say is true, but doesn't affect the validity of my argument that html5test is poorly designed.

Note that if you're going to exclude the living spec in an attempt to rationalize html5test's behavior, be aware that many features it checks for aren't present in the static html5, only in the living spec.

There are multiple perspectives here. As you point out, keygen wasn't always deprecated, and it hasn't been removed from the standard yet. So, as you point out, it's OK for a browser to support that. And I totally agree with that.

But also look at the context - the suggestion here is that a low score means a browser that is lagging in standards support. And that's clearly misleading. There may be nothing wrong with supporting keygen; but clearly the aim is to *remove* it, and there should certainly not be anything wrong with actually doing that. I understand that webkit+blink need to deal with a lot of legacy, but we shouldn't be cheering that on, just like we weren't cheering on all the IE6 quirks that lingered for years on the web.

If html5test wants to promote a modern, standards compliant web that keeps up to date with the standards - and clearly that *was* once its aim - then it too should deprecate keygen. It's understandable to support keygen (and if you do - follow the deprecated standard). But it's best to move on and drop support.

Incidentally, evaluating keygen due to this conversation leads me to question html5test even more - I tested keygen in chrome+firefox+edge, and it actually works in chrome and firefox, even though html5test suggests it works only in chrome. In other words, the test isn't just misguided, it's buggy too...

That would only further demonstrate the misleading nature of html5test. An test aiming to measure support for modern "html5" should not award bonus points for non-standard (speech apis), deprecated (keygen) or outright rejected features (websql).

The keygen feature has been deprecated. It's likely edge will support more open formats in the future: http://blogs.windows.com/msedg..., including opus+vorbis.

Between firefox, chrome and edge, I'd suggest that today it is chrome that has the greatest support for non-standard features, tracing back to the hastily designed extensions to webkit for the early iphones. In particular many non standard things like speed synthesis and recognition are only on in blink/webkit, as is WebSQL (which, to be fair, was at least once proposed as a standard, even though it was rejected). Those three features alone account for a 15 point headstart (17 if you count keygen) that chrome has over edge+firefox, even though their support should if anything, decrease the score.

It's no coincidence than non-webkit browsers started supporting -webkit- prefixed css properties - webkit has included a large amount of non-standard extensions over the years. Edge's declared preference for feature toggles (and firefox I believe prefers those too, exposing speech api's only if an about:config flag is set for instance) is friendlier to standardization because it means that non-standard features do not become entrenched and hard to fix.

If anything, a high score in html5test means a non-standard browser. Just take a look at the actual features where the major browsers differ and that amount to chrome's advantage - almost all of them are experimental, entirely non-standard, deprecated, or rejected. Why exactly should that count as standards compliant?

I meant to say deprecated like keygen, but slashdot stripped the "html" tag.

Well, sunspider certainly doesn't have the most reliable name:
http://news.softpedia.com/news...

Don't read too much into sunspider scores. Octane v2 isn't perfect either, but it's a lot better. Mozilla's kraken is probably even better, but it's much more focused on what CPU-intensive JS can do than on what normal JS actually does. I wouldn't call it a general purpose JS benchmark.

Despite what the summary may suggest, there's no evidence presented that edge lacks standards compliance or indeed that chrome leads in standards compliance. The test used (html5test) isn't a test of standards compliance nor of html5; it's simply a large grabbag of features some of which happen to be defined in html5 - and those features aren't even really tested for, they just use feature detection. Many of those features are experimental (i.e. it's probably better if a browser *doesn't* support those without a feature toggle or prefix), and a few are deprecated or even rejected.

html5test should probably be renamed webkit-as-of-2013-test. As is, higher scoring browsers aren't more standards compliant, they simply include more legacy and experimental features (i.e. are *less* standards compliant).

See http://tech.slashdot.org/comme... - in short, the html5test site is deeply flawed. If anything, a high score suggests a browser that supports deprecated, rejected or experimental features without decent feature toggles. Not a good idea.

HTML5test is not a test of standards compliance; the title is misleading. It's a wishlist of features, some of which are standardized, but many of which are not (or are not part of HTML5). For example, html5test doesn't (in general) test whether you've really implemented a feature correctly (or really - at all) it just uses feature detection to check whether you've claimed to implement a feature. Fortunately, browsers are never buggy and this distinction doesn't matter.

Then, html5test follows the whatwg's "living standard" instead of the less-cutting year-old actual standard html. This makes sense at first glance - we want to know which browsers support "new" features too! As a developer, that's great. As a score for a browser, that's questionable. Many features are added to the standard because one of the browsers initially experimented with a non-standard extension; lately that's been webkit/blink due to the mobile push, but previous names have included IE6. By *intent* the whatwg living spec is a few steps ahead of the browsers. What this means is that if you use this as a score is that you're going to penalize whoever is following the spec, and promote those leading the spec. That deserves at least a separate score.

Then, there are HTML5 features that are deprecated, like . The continued support for scores chrome two points, and edge+firefox none. Is that really what you wanted to know? I bet there are *lots* of deprecated features in old IE; if you're going to start counting those...

Then there's features like speech synthesis and recognition. Those aren't part of the spec, have never been part of the spec, yet they're worth 5 points together. Or worse, the Web SQL features, that have explicitly been rejected, also worth 5 points (only webkit-derived browsers support this).

Almost all of the point differences between browsers can be explained by features that are experimental, deprecated or rejected.

In short: don't use html5test. It's pointless.

HTML5test is not a test of standards compliance; the title is misleading. It's a wishlist of features, some of which are standardized, but many of which are not (or are not part of HTML5).

Many laptops have a battery preservation mode which avoids full recharges. Long term storage (or worse, usage) at 100% capacity is damaging to a lithium ion battery, so limiting charge capacity to (e.g.) 50% the lifetime can be dramatically extended. It helps in any case, but it's particularly useful if your laptop is usually plugged in. Unfortunately, this feature is often hidden away somewhere, or requires an extra download - almost nobody uses it, which is a shame.