I am currently working on the new Mozilla style guide. There is an existing one but, it being part of the larger mozilla.org site, is not ideal, and makes it overly complicated for designers and UX people to contribute. It also makes sense to have this live in it's own little pod, where it can be the source of truth for others inside, and outside Mozilla.
Two of the cornerstones of the open web is choice, and trust. Recently more and more attention has been focused on a practice that's eroding these cornerstones. I am here of course referring to online tracking as done by, among others, behavioral advertising companies, governments, mobile carriers, ISPs online. Not only are they breaking user trust by tracking them without permission, they do not offer users a choice in this regard.
In fact, it is even worse than that.
I have switched to using DuckDuckGo as my preferred search engine some time ago now, and I have really ben enjoying it. Of course, on of the biggest reasons for doing this is related to my online privacy.
We all know that Google used to be the
Do no Evil company but, this has changed drastically in recent history, and most people now know how Google is tracking you all over the web. Now, whether you are ok with this or not, is of course up to you. For me though, I choose to support services that does not track me.
Over and above that, and to get of my soap box, there is another great reason for everyone, but specifically developers/designers to use DuckDuckGo on a daily basis.
In part 1 of this series I covered the bulk of the attributes as well as the basic usage of the
An important aspect I did not cover is some of the best practices when using the
video, or other media, elements. Although I did mention the use of
preload="none", to prevent automatically downloading media and, using the
autoplay attribute sparingly, there are two more important topics left to discuss.
I have been working with HTML for a number of years now but, in especially the last 2 to 3 years, the language has grown and evolved at a very rapid pace.
Since I started blogging again a while ago I decided to forgo the usual Wordpress route and try this thing called Octopress. I have to say, I am extremely delighted, and the fact that I can host it all on Github for free, well that is just the Siracha on my Chipotle.
Octopress also makes previewing your site and deploying it to Github super simple. Want to preview the site locally and auto generate the appropriate files when things change, well, just run:
Every so often when implementing a new design or working on an existing project, one runs into situations where the color contrast between the background and foreground (read text copy) just feels wrong. It either feels that the colors simply clash or, that the content is illegible.
The Web Content Accessibility Guidelines(WCAG) defines a set of ratios at which point the contrast is sufficient to avoid common accessibility problems related to low, or poor contrast of web content and images.
But how does one test whether the contrast of your web page meets these guidelines?
In exploring the HTML language in more detail I came across the
crossorigin attribute that can be used on media elements such as
audio. The specification of this seems pretty foggy to me so I went in search of some answers. Below is where I am currently at in my understanding of the use and purpose of this attribute.
Every now and again it so happens that you open a pull request, forgetting to check the diff before doing so, only to find that there is an unintended submodule commit in your pull request.
Now submodules in Git is a touchy subject for many but alas, many projects do use them. So, what to do when caught in this situation? Well, luckily it is rather easy to get that unwanted submodule commit out of your pull request. First things first.