A Ruby script to generate simple Amazon S3 Redirection Rules XML file.
Update: There is an app for that now! Use Amazon S3 Redirector (Web app) and you can generate the XML without any knowledge about Ruby. Thanks to @rainforestapp. BTW, It's open source too.
| // Support routines for automatically reporting user timing for common analytics platforms | |
| // Currently supports Google Analytics, Boomerang and SOASTA mPulse | |
| // In the case of boomerang, you will need to map the event names you want reported | |
| // to timer names (for mPulse these need to be custom0, custom1, etc) using a global variable: | |
| // rumMapping = {'aft': 'custom0'}; | |
| (function() { | |
| var wtt = function(n, t, b) { | |
| t = Math.round(t); | |
| if (t >= 0 && t < 3600000) { | |
| // Google Analytics |
| <!DOCTYPE html> | |
| <html> | |
| <head> | |
| <meta charset=utf-8 /> | |
| <title>JS Bin</title> | |
| </head> | |
| <body> | |
| <h2>Original CSS</h2> | |
| <style style="display: block; white-space: pre; font-family: monospace"> | |
| h2 { margin:0; } |
| #!/bin/sh | |
| base=$1 | |
| convert "$base" -resize '29x29' -unsharp 1x4 "Icon-Small.png" | |
| convert "$base" -resize '40x40' -unsharp 1x4 "Icon-Small-40.png" | |
| convert "$base" -resize '50x50' -unsharp 1x4 "Icon-Small-50.png" | |
| convert "$base" -resize '57x57' -unsharp 1x4 "Icon.png" | |
| convert "$base" -resize '58x58' -unsharp 1x4 "Icon-Small@2x.png" | |
| convert "$base" -resize '60x60' -unsharp 1x4 "Icon-60.png" | |
| convert "$base" -resize '72x72' -unsharp 1x4 "Icon-72.png" | |
| convert "$base" -resize '76x76' -unsharp 1x4 "Icon-76.png" |
| # IE is still braindead so still use favicon.ico | |
| convert -resize x16 -gravity center -crop 16x16+0+0 -flatten -colors 256 input.png output-16x16.ico | |
| convert -resize x32 -gravity center -crop 32x32+0+0 -flatten -colors 256 input.png output-32x32.ico | |
| convert output-16x16.ico output-32x32.ico favicon.ico | |
| # Then, HTML needs to specify size="XxY" as largest size due to browser bugs | |
| <link rel="shortcut icon" href="/favicon.ico" sizes="32x32"> |
Before I watched this, if someone would have asked about why Pointer Events wasn't getting into Chrome, I'd have pointed at Safari. I don't love that reason, but it makes sense with their current dominance on mobile. However, I don't necessarily agree, I think if every other browser implemented them, they'd come around. That's tended to be true on the web for the last 20 years (Old IEs, webgl, innerHTML, video codecs when hardware is present, etc)
As far as the main issues brought up here, which I hopefully have fairly summarized (in one sentence each, lol, sry) below, I don't see them as entirely compelling for dropping PE altogether, especially since so many real-world folks (jQuery, Dojo, IE-y people) like the unification quite a bit.
From what I can read from the previous calls and conversations[0] about this, it's less of an issue than it seems. From those conversations, it seemed like hit tests weren't cached, and Chrome at
Just some early draft thoughts
Increased modularity is a long-standing request of jQuery. 3.0 should deliver on that. Many authors will use jQuery 3.0 in ES6 codebases, and often alongside frameworks that have overlap in functionality.
That said, a majority of developers will use a monolithic build. jQuery 3.0 must aggressively remove API surface area and functionality from this core build to protect developers from performance footguns. The jQuery team has reasonably voiced concern that removing modules means it's less likely for people to upgrade. While some users do attempt jQuery version upgrades, many freeze their version and never revisit it. I'd like to get more data on this phenomenon as I think we're optimizing API deprecation policy for a small audience.
Lastly, it's 2015 and the gap between JavaScript developers and jQuery developers has never been bigger. Let's bridge that gap. We should encourage the developer to use modern DOM APIs (that don't suck) and polyfill as neccessary.
All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.
Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.
elem.offsetLeft, elem.offsetTop, elem.offsetWidth, elem.offsetHeight, elem.offsetParent
| /** | |
| * MIT No Attribution | |
| * | |
| * Copyright 2015 Giovanni Thenstead | |
| * | |
| * Permission is hereby granted, free of charge, to any person obtaining a copy | |
| * of this software and associated documentation files (the "Software"), to deal | |
| * in the Software without restriction, including without limitation the rights | |
| * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell | |
| * copies of the Software, and to permit persons to whom the Software is |