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
| # Docs @ https://github.com/causes/scss-lint/blob/master/lib/scss_lint/linter/README.md | |
| linters: | |
| BorderZero: | |
| enabled: false # nerdery - no existing standard for 'none' or '0' | |
| CapitalizationInSelector: | |
| enabled: false # nerdery - capitalization in camelCase is possible | |
| ColorKeyword: |
| #!/usr/bin/python | |
| # -*- coding: utf-8 -*- | |
| import sublime_plugin | |
| import subprocess | |
| from time import sleep | |
| import sys | |
| cl = lambda line: subprocess.Popen(line, shell=True, stdout=subprocess.PIPE).communicate()[0].strip() | |
| log = lambda message: sys.stderr.write("Log: %s\n" % message) |
| param ([Parameter(Mandatory=$True)][string]$SitemapUrl, | |
| [int]$Max=0) | |
| function Validate($url) { | |
| if(-not $url.StartsWith("http")) { | |
| $parsed = [System.Uri]$SitemapUrl | |
| $url = "{0}://{1}{2}" -f $parsed.Scheme, $parsed.Host, $url | |
| } |
Whether you're trying to give back to the open source community or collaborating on your own projects, knowing how to properly fork and generate pull requests is essential. Unfortunately, it's quite easy to make mistakes or not know what you should do when you're initially learning the process. I know that I certainly had considerable initial trouble with it, and I found a lot of the information on GitHub and around the internet to be rather piecemeal and incomplete - part of the process described here, another there, common hangups in a different place, and so on.
In an attempt to coallate this information for myself and others, this short tutorial is what I've found to be fairly standard procedure for creating a fork, doing your work, issuing a pull request, and merging that pull request back into the original project.
Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite git client to clone your repo or j
They say that one of the pros of NodeJS is that you use the same language on the back-end and the front-end, so it's easy to share code between them. This sounds great in theory, but in practice the synchronous dependency handling in NodeJS works completely different than any client-side frameworks (which are asynchronous).
Usually that means that you end up copy-pasting your code between your NodeJS sources and your client-side sources, or you use some tool like Browserify, which is brilliant, but they add an extra step in the build process and most likely will conflict with the dependency handling of the framework of your choice (like AnularJS DI). I couldn't look in the mirror if I would call that code sharing.
Fortunately, with a couple of lines of boilerplate code, you can write a module which works in NodeJS and AngularJS as well without any modification.
No globals in the front-end, and dependencies will work. The isNode and isAngular va
| /* | |
| Sample object that should work is: | |
| var exampleObj = { | |
| tag: 'div', | |
| attr: { | |
| id: '1234', | |
| href: 'some/url/path', | |
| class: ['createdElement', 'example', 'parent'], | |
| text: 'some text' | |
| }, |
| <script type="text/ng-template" id="one.html"> | |
| <div>This is first template</div> | |
| </script> | |
| <script type="text/ng-template" id="two.html"> | |
| <div>This is second template</div> | |
| </script> |
