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%
A tutorial about creating custom select elements with unique style. It's created by using jQuery and CSS.
After months of anticipation, anxious tweets asking for the disclosure of a release date, and a few scattered scraps of news by Mark Otto and Jacob Thornton, having the effect of intensifying rather than quenching our curiosity, Bootstrap 4 alpha is out.
As a designer, I love crafting my own CSS. However, I confess, I find Bootstrap such a well thought-out and strongly supported front-end framework that I’ve immensely enjoyed using it, both to build my projects and to learn more about writing better, modular CSS.
After the much awaited news, as you can probably guess, I downloaded the source files for Bootstrap 4 and spent some time going back and forth between reading the docs and digging into the code to find out more.
I expect the alpha release of Bootstrap 4 will undergo a number of changes in the coming weeks, even months. The curious among you, can keep an eye on the issues section of the project’s GitHub repository. However, the features I’m going to list here are more like broad coding principles and practices that keep improving on each new release of the framework. That’s why I think it’s likely they’re here to stay. If anything, they can only get better.
Here they are. I hope you find them awesome too!
The Bootstrap documentation has been exemplary since the framework’s early days. It’s always had the crucial role of being a living document, that is, a tool in sync with the collaborative effort of building the framework and communicating it to others:
Abstracting and documenting components became part of our process for building this one tool and Bootstrap in tandem.
Mark Otto in 2012
Mark himself is quite a fan of great documentation. His Code Guide by @mdo is evidence of his approach to high quality documentation as being part and parcel of outstandingly coded projects.
The documentation for version 4 has been rewritten from scratch using Markdown. Understandably, given the alpha stage of this version at the time of writing, it’s still a work in progress.
The Bootstrap docs …
If you take the time, you’ll soon find a few valuable nuggets scattered throughout various sections of the docs. For instance, dealing with over-sized SVG images that use the .img-responsive class in IE9-10, accessibility best practices, enabling the mq4-hover-shim to fix sticky :hover styles on mobile devices, and much more.
Finally, if you’d like to run the Bootstrap docs locally on your computer, install Jekyll, a great website building tool, and follow these instructions.
Bootstrap has often been the target of complaints about code bloat, too opinionated CSS styling, and a profuse quantity of components. The good news is: Bootstrap 4 has both simplified and further modularized its structure.
To begin with, some components have been eliminated altogether: the Glyphicons icon library is not bundled with the framework any more; panels, wells, and thumbnails are replaced by the Cards component. Also, all CSS reset/normalize code and basic styling are now dealt with in a single brand new module called Reboot.
Further, more than ever before, using Bootstrap now feels like assembling and arranging Lego blocks in different ways. Here are some examples to clarify what I mean.
Continue reading %Bootstrap 4 Alpha: Super Smart Features to Win You Over%