I don't use Skype, and I'm no fan of Microsoft, but this security advisory is just shameless (and harmful) self promotion.
274 karma · joined January 25, 2011
I don't use Skype, and I'm no fan of Microsoft, but this security advisory is just shameless (and harmful) self promotion.
This will make JavaScript parsing faster for the vast majority of sites, and for the majority of users.
If you have a single JavaScript file that is 1MB after gzipping, you really should think about modularising your code and lazy-loading the bits that aren't immediately required. See http://ajaxpatterns.org/On-Demand_Javascript
Tracking within your own website for analytical purposes doesn't fall under the functional interpretation of "strictly necessary"; your site continues to function just fine if the Google Analytics beacon isn't fired, or can't distinguish between a first-time visitor and a repeat visitor or follow a particular user through the site.
I have heard people argue that analytics are operationally strictly necessary; that we need some insight into the behaviour of site visitors in order to operate an online business effectively. There may be something in that interpretation, but I'm a lowly web architect, not a lawyer. As such, I would be wary of accepting this more lenient interpretation without significant input from someone more schooled in the laws of our land (or any land, for that matter) than I.
I'm glad the Optimizely guys have released their version, because based on our user testing novice users really respond well to this kind of interactive product tour.
http://www.varnish-software.com/blog/varnish-30-changes-esi-...
http://www.varnish-software.com/blog/bans-and-purges-varnish...
http://www.varnish-software.com/blog/streaming-varnish-30
Something to pay attention to from that streaming post: if the asset you're streaming isn't already in the varnish cache, only the first user to request it will get it streamed. All other clients will be blocked until the first stream is complete and cached.
> The object will be set to busy while it is streamed. Other clients will be put on hold. Furthermore, the rate at which the object is fetched by the client dictates how fast Varnish will fetch it from the backend.
Unless I'm reading the above wrong, [re-warming your cache for these large objects would seem more prudent than relying on streaming.
There's also a nice write-up by Redpill Linpro employee and Varnish contributor Kristian Lyngstøl:
http://kristianlyng.wordpress.com/2011/06/09/varnish-3-0-0-r...
Crockford may be an opinionated cantankerous old goat, but at least he gives you options to dial down some of the crazy he's baked into JSLint.
* He's also awesome, but anyone who's worked at Yahoo! or glanced at the JSLint Issues list or Pull Request queue can attest that he has strong opinions.
They do. As I understand it, this law applies just as well to the likes of Google, Yahoo and Facebook as it does to the sites that host their ads. There is some ambiguity over exactly who is responsible for gaining consent for 3rd party cookies — ICO have stated that this is a complicated area and more guidance may be forthcoming — but my approach is that I can't trust these third parties to cover my arse so I'll do it myself.
If you think that having analytics data is such a benefit to the user, explain to them why you want to track how they use your site and let them decide whether they're happy with that. That's all this law requires.
The real saviour will likely come in the shape of browser support for Do Not Track [1]. While it's not fine-grained enough to be used as the sole mechanism for gaining user consent for all non-essential cookies, it at least covers the 3rd party tracking cookies that were the motivation behind this law change. Note that DNT specifies that the default MUST NOT be opt-in:
> A user agent MAY adopt NO-EXPRESSED-PREFERENCE or OPT-OUT by default. It MUST NOT transmit OPT-IN without explicit user consent.
Government IT moves at a glacial pace, and just like everyone else they're still trying to figure out how this stuff should work. That's why they've deferred enforcement for a year.
There are plenty of situations where developers can find themselves dealing with insane JavaScript implementations and irresponsible JavaScript frameworks. While the article doesn't explain exactly what the issue is and which browsers it affects (leading me to believe the author himself doesn't truly understand these memory leaks), the recommendation given is a sound one.
In the other cases, there's no memory leak while the DOM node still exists, because the DOM still has a reference to it so it shouldn't be garbage collected.
There is a related application-level memory leak if you have some other reference to the closure that doesn't belong to the DOM node, and that applies to all browsers. See http://news.ycombinator.com/item?id=2567847 for a simple way to deal with that.
function foo(element, a, b) {
element.onclick = function() { /* uses a and b */ };
element = null; // avoid memory leak
}
The closure contains a reference to foo's activation object, not to its properties. As a consequence, you can clear out the element reference after the event handler has been defined and this will break the circular reference.The above technique is also useful when creating anonymous functions for other purposes when element references happen to be lying around. Depending on how long these anonymous functions are kept alive and what you do with the elements in the meantime, this would normally lead to a memory leak (due to the dangling reference to the DOM element, rather than a circular reference as described in the article).
See http://jibbering.com/faq/notes/closures/ for a seriously nerdy deep-dive into closures in JavaScript.
The sources quoted in this article in no way support the conclusion present in the title. As phlux said, other browsers have enabled you to turn off the address bar. Are they trying to "kill the URL" too? No, and neither are Google.
This article comes off as little more than sensationalist (albeit apparently effective) link bait.
Switching from progressive enhancement (applying styles if you detect a feature is supported) to graceful degradation (applying styles if you detect that a feature isn't supported) doesn't solve the underlying problem. In fact, it makes the situation worse. JS failure with the progressive enhancement approach means that everyone gets the fallback experience; failure with the graceful degradation approach means that you're potentially asking a browser to apply CSS that it doesn't understand and not offering it a fallback.
No matter which way you cut it, having CSS predicated on classes set by JavaScript creates a dependency where one should not exist. I realise that's the whole point of Modernizr, but in my opinion it isn't the right way to solve this problem. Others may not agree, and that's fine, but it's critically important that developers being encouraged to use Modernizr (or its underlying techniques) are made aware of the tradeoff they are making and the potential impact that may have on their users.
http://en.wikipedia.org/wiki/White_Light_(novel)
I picked this up at a end of line book shop when I was 13 or 14, along with a bunch of other Wired Press books, and it blew my mind.
See:
http://tools.ietf.org/html/draft-pantos-http-live-streaming-...
Users want those "incremental features" that Allan mentioned in this post, and don't care too much what the underlying architecture looks like. It's hard to believe that it wouldn't have been possible to deliver those features whilst iteratively refactoring the underlying architecture.