Today, too many websites are still inaccessible. In our new book Inclusive Design Patterns, we explore how to craft flexible front-end design patterns and make future-proof and accessible interfaces without extra effort. Hardcover, 312 pages. Get the book now →
It was the summer of 2013 and I was working on a project for my employer, Box. I had just finished wiring up JSDoc as a nightly build using a plugin to detect T3 patterns in our code and document them automatically. It occurred to me that these patterns might be easy to get wrong, and I started looking for a way to automatically detect incorrect patterns. I immediately turned to JSHint because we were already using it and I thought it could support plugins. Unfortunately, it could not.
A while back, I wrote a post about starting an open-source project. The focus of that article was on starting an open-source project as an individual. I received a lot of positive feedback and also some questions about how the process changes when you’re open-sourcing a project at work.
Many companies are starting to investigate and participate in the open-source community, and yet few guides for doing so exist. This article focuses primarily on the process of open-sourcing a project at work, which brings with it other concerns and decisions.
At Velocity 2011, Nicole Sullivan and I introduced CSS Lint, the first code-quality tool for CSS. We had spent the previous two weeks coding like crazy, trying to create an application that was both useful for end users and easy to modify. Neither of us had any experience launching an open-source project like this, and we learned a lot through the process.
After some initial missteps, the project finally hit a groove, and it now regularly get compliments from people using and contributing to CSS Lint. It’s actually not that hard to create a successful open-source project when you stop to think about your goals.
When I was studying computer science in college, I had one extremely tough professor. His name was Dr. Maxey and he taught the more complicated courses like data structures and computer architecture. He was a wonderful teacher with a talent for articulating difficult concepts, but also an extremely tough grader. Not only would he look over your code to make sure that it worked, he would take off points for stylistic issues.
If you were missing appropriate comments, or even if you misspelled a word or two in your comments, he would deduct points. If your code was “messy” (by his standards), he would deduct points. The message was clear: the quality of your code is not just in its execution but also in its appearance. That was my first experience with coding style.
Earlier this week we published two articles by Louis Lazaris: one on why old browsers are holding back the Web and another encouraging Web users to upgrade their browsers and use modern browsers other than IE. This article presents another perspective on this issue. Nicholas C. Zakas, a well-respected member of the developer community, goes into specifics of why we should focus on the good parts of our job so we can tolerate the bad ones and why fixating on circumstances that you can’t change isn’t a recipe for success. Do you share Louis' or Nicholas' view? Leave a comment.—Ed.
A couple of days ago, Smashing Magazine published an article entitled, Old Browsers Are Holding Back The Web. The author of this article, Louis Lazaris, suggests that “old browsers” are holding Web developers back from creating beautiful experiences. Old browsers, in this case, apparently referred to Internet Explorer version 6-9. That’s right, the author groups Internet Explorer 9 into the same group as Internet Explorer 6. He goes on to list some of the things that you can’t use in Internet Explorer 8 and 9.