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
| //based on https://gist.github.com/pburtchaell/e702f441ba9b3f76f587 | |
| //with added support for iphone 3 and 4 and orinetation support for iphone 5. | |
| //this is for all devices which can run iOS7 in all orientations. | |
| //not a mixin to avoid to much duplicate code when using on multiple selectors. | |
| .selector { | |
| $height: 70; //set your height in vh | |
| $heightPercent: $height/100; | |
| height: #{$height}vh; | |
| package main | |
| import "fmt" | |
| // 料理を作るI/F | |
| type Cooker interface { | |
| Cook() string | |
| } | |
| // 塗るI/F |
| 1033edge.com | |
| 11mail.com | |
| 123.com | |
| 123box.net | |
| 123india.com | |
| 123mail.cl | |
| 123qwe.co.uk | |
| 126.com | |
| 150ml.com | |
| 15meg4free.com |
Ideas are cheap. Make a prototype, sketch a CLI session, draw a wireframe. Discuss around concrete examples, not hand-waving abstractions. Don't say you did something, provide a URL that proves it.
Nothing is real until it's being used by a real user. This doesn't mean you make a prototype in the morning and blog about it in the evening. It means you find one person you believe your product will help and try to get them to use it.
| import com.twitter.util.{Future => TwFuture} | |
| import scala.concurrent.{Future => ScFuture, promise => ScPromise} | |
| implicit def twFutureToScala[T](twFuture: TwFuture[T]): ScFuture[T] = { | |
| val prom = ScPromise[T] | |
| twFuture.onSuccess { res: T => | |
| prom.success(res) | |
| } | |
| twFuture.onFailure { t: Throwable => | |
| prom.failure(t) | |
| } |
The reflow appens as many times as there are frames per seconds. It recalculate all positions that change in order to diplay them. Basically, when you scroll you execute a function where you move things between two reflows. But there are functions that triggers reflows such as jQuery offset, scroll... So there are two things to take care about when you dynamically change objects in javascript to avoid too many reflows:
##How Homakov hacked GitHub and the line of code that could have prevented it
Please note: THIS ARTICLE IS NOT WRITTEN BY THE GITHUB TEAM or in any way associated with them. It's simply hosted as a Gist because the markdown formatting is excellent and far clearer than anything I could manage on my personal Tumblr at peternixey.com.
If you'd like to follow me on twitter my handle is @peternixey
For a while, I have felt that the following is the correct way to improve the mass assignment problem without increasing the burden on new users. Now that the problem with the Rails default has been brought up again, it's a good time to revisit it.
When creating a form with form_for, include a signed token including all of the fields that were created at form creation time. Only these fields are allowed.
To allow new known fields to be added via JS, we could add:
