Dragscroll is a micro JavaScript library (734 bytes minified) which enables scrolling via holding the mouse button (“drag and drop” or “click and hold” style). It has no dependencies and is written in vanilla JavaScript (which means it works anywhere).
The post Dragscroll : JavaScript Drag Drop Scrolling Library appeared first on jQuery Rain.
Mikado is a WordPress image gallery based on random grids with a lot of features.
It’s responsive and images will adapt with a nice and smooth animation when the browser is resized. You just need to decide width (also percentage) and height and Mikado will create a random grid inside the rectangle.
Features:
The post Mikado Grid Gallery for WordPress appeared first on jQuery Rain.
A small (2KB) jQuery plugin that creates a fixed progress indicator based on your content and allows linking between them.
The post jQuery Progress Tracker appeared first on jQuery Rain.
This article is part of a web development series from Microsoft. Thank you for supporting the partners who make SitePoint possible.
Edge is Microsoft's new web browser sporting a new rendering engine – EdgeHTML – and an underlying OS to boot in Windows 10. Since upgrades from Windows 7, 8 and 8.1 will be free for most, you can expect a huge influx of Edge users hitting sites in the coming months. Edge is a departure from the past, actually to complete rewrite from past versions of Internet Explorer and I’m sure many web devs will welcome that. With that in-mind, I wanted to share five ways in which you can prepare your site for modern web interoperability and also test for Microsoft Edge in parallel:
Common libraries like jQuery are often updated to address bugs when new browser versions are released. By simply updating your JS frameworks, you can avoid many compatibility bugs with Edge. In our internal research we found that 57% of the top 20,000 sites are using JavaScript frameworks that have issues that have been fixed in newer versions of the same library. You can use the site scanner to determine if you are using out of date JavaScript frameworks on your sites.
CSS prefixes are used by browser vendors to implement new, emerging CSS features before they have been fully ratified by the W3C. If a vendor implements a CSS prefix, it will look something like the example below (this is an IE-specific implementation of the 'hyphens' feature to hyphenate text across multiple lines):
-ms-hyphens: auto;
It's really common for sites to have missing vendor-specific prefixes, or have implemented vendor-specific prefixes when they are not required in common CSS properties. This may cause a webpage to render incorrectly in Microsoft Edge or other modern browsers.
Browser vendors are using prefixes much less now because of the management problems associated with them. Some browsers, Microsoft Edge included, rarely if ever use prefixes at all.
Where possible, avoid the use of vendor-specific prefixes. However, if you absolutely must use vendor prefixes, use Grunt PostCSS to automate the management of prefixes within your CSS.
Continue reading %5 Ways to Make Your Site Rock on the Modern Web (and Microsoft Edge)%
As he mentions in this Google tech talk on Git, Git was created out of necessity for the Linux project. At the time the talk was given, Git was very young and people were getting used to it. It seemed to solve all the problems faced by version control software, and this contributed to its meteoric rise.
Fast forward a few years, and people started noticing the first real flaw in Git: it was difficult to handle very large repositories. How large are we talking here? It's Facebook large. Facebook's team projected that in a few years, a simple git status would take up to half a minute to show the result, as Facebook adds a large number of commits from thousands of developers every day. Facebook shifted its whole codebase to Mercurial, and its team actively started contributing to Mercurial to meet Facebook's needs.
Where did Git fail? A Mercurial contributor, Prasoon Shukla, on the comparison of scaling in Git and Mercurial, says that this can be attributed to the way Mercurial and Git store commits. Mercurial manages a couple of objects (or files) for each file in your repository, whereas Git creates an object for each commit. Therefore, on increasing the number of commits, the number of objects in Mercurial remains constant, in contrast to a linear increase in Git. Therefore, when you run a simple git status command, Git has to sift through all these objects, which takes a considerable amount of time (in spite of the high efficiency of Git).
Another area where Git might fall short is managing large binary files in the repository. Because Git tracks the changes in files, it's not able to interpret the content of binary files. And the size of the repository increases with every commit, because Git has to store the exact binary, rather than the change from the last version.
Over the years, developers of Git have tried to solve these problems. Each third-party service has come up with solutions to enable Git to manage larger repositories—such as GitHub's Large File Storage extension.
This post looks at techniques that can be used to handle large repositories in Git—in terms of large histories, as well as the presence of large binary files, or both.
I'll firstly look at a few ways to manage repositories with large histories more efficiently.
As mentioned earlier, the primary reason why projects with large histories slow down is the huge number of commits. In a distributed system like Git, when you clone a repository, its full project history gets downloaded. However, Git provides a way to specify the number of commits you want to have in your clone of a project. This is known as a shallow clone. When you get the number of commits down, your Git operations run faster.
To perform shallow cloning, you need to add the --depth option, with the number of commits we want, to the clone command:
git clone --depth [number_of_commits] [url_of_remote]
In earlier versions of Git, there was limited support for shallow clones. If your truncated history didn't stretch long enough, you weren't allowed to push or pull. However, with the release of Git 1.9.0, support for shallow clones was increased significantly.
When you clone a repository, all the branches in the remote get downloaded. (If you run git branch in a newly cloned repository, it shows only the master branch. You should run git branch -a to list all the branches that were a part of the remote.) It's probable that many of the commits present in other branches are irrelevant to one developer's work. Therefore, you can clone just the master or the branch relevant to your development. Doing so significantly reduces the number of commits that make up the history of the cloned version, especially if branches in the repository have divergent histories.
To clone only a single branch of a remote, you can run the following command:
git clone [url_of_remote] --branch [branch_name] --single-branch
This command instructs Git to clone only the branch_name branch from the remote.
Continue reading %Managing Huge Repositories with Git%
Hi, my name is Lauren, and I’m an addict. I’m addicted to two things: quotes and tools. Quotes because they inspire me and motivate me to keep pushing through during the hard times. Tools because I pride myself on being an early adopter, and, well, tools make my life more efficient and/or easier. Last weekend, […]
Continue reading %This is What I Learned After Watching Videos for 48 Hours%