The other day I sent out a tweet asking what everyone thought was the best source for browser usage stats.
I wanted to know if there were any sources I’d not yet heard of that offer reliable global statistics for usage stats for various browsers.
Well, I didn’t get too many responses to the tweet, but I decided to put together my own list of sources for reliable browser usage stats.
As many of you may be aware, validating your pages in HTML5 has become a whole new adventure.
Along with changes in what now constitutes “valid” and “invalid” markup, the HTML5 Validator (which, by the way, is the same tool that runs the W3C’s HTML5 validator) will provide some warnings about obsolete features in HTML5.
Feel free to go through that document on the W3C’s site, but here I’ll touch on some things that you may want to be aware of with regards to obsolete elements and attributes.
Over the winter and spring I’ve been pretty busy researching and putting the final touches on four chapters of a new book published by SitePoint.
The book is called HTML5 & CSS3 for the Real World and was officially launched on SitePoint this morning (North American time).
Two other authors took part in this exciting new project: Estelle Weyl — who probably doesn’t need much of an introduction if you’re familiar with many conference speakers in the web standards world — and Alexis Goldstein, a well-rounded programmer from Brooklyn.
If you’re starting to incorporate some HTML5 and CSS3 into your pages, then you’ve probably also looked into the possibility of polyfilling those features for older versions of IE.
Of course, you could instead opt for “progressive enrichment” and leave IE in the lurch while prettying things up for the newer browsers. That’s the method that Andy Clarke recommends, and it’s certainly a valid option.
But if for whatever reason (usually something political or the fact that the client demands it) you have to give IE a similar experience, then you face a very bizarre circumstance.
This is not going to be a long article, but just a quick note about something that all front-end developers should be paying attention to.
If you don’t already know, the W3C has formulated a fairly brief, yet valuable document called HTML Design Principles that outlines exactly what principles have guided and continue to guide the creation and evolution of HTML5 and its related APIs and other technologies.
It would seem that with the introduction of HTML5′s semantic elements, styling those new elements should be an easier task. But as I’ve started to use HTML5 more, I’ve realized that it takes quite a bit of forethought to create maintainable CSS that targets the new semantic elements in a future-proof way.
In some cases, it could be fairly straightforward, but in others it’s a little disheartening because targeting the new elements actually creates more verbose markup.
Let’s consider a few examples. If you had a page that used the <header> element to hold the logo, nav, etc, and the <footer> element to hold the website’s footer, then your CSS would look something like this:
Alright, that title might be a bit exaggerated. Flame wars are bad for the community, and I don’t condone them. I think differences of opinion can be expressed in respectful ways that don’t involve unrelated personal attacks. I guess what I really mean to say here is that you can benefit from “heated discussions” that sometimes escalate into flame wars.
But nearly every super-heated discussion (whether in the web design community or elsewhere) has a common denominator: Two opposing sides with valid points of view. It’s unfortunate that sometimes these discussions turn a bit ugly and the actual pros and cons being discussed can go somewhat unnoticed and often forgotten.
I believe those of us who choose not to get directly involved in these discussions should get involved in another way: By reading the content of the original post carefully, and reading the responses. Of course, in some cases, the responses can be downright rude, obscene, and pointless. If you can skim past all that and see the real arguments behind what’s being said, you’ll become a better developer.
Creating a website with HTML5 and CSS3 without having to worry about using techniques like progressive enrichment and polyfills is the ultimate dream for modern-day front-end developers.
But unfortunately, mainly because of the widespread use of IE6-8, that is still just a distant dream. But it is getting closer.
I thought it would be a good idea to summarize where CSS3 stands as far as browser support goes, so you can feel comfortable making decisions about what to use or abuse when incorporating CSS3 into new projects.
This outline will be divided up into sections beginning with the safest CSS3 features to use, and going down the list towards the not-so-safe. Of course, in all cases, you have the option to declare fallbacks and polyfills that will give nonsupporting browsers a similar and/or acceptable experience. Just remember to take care that your content is accessible and your brand isn’t negatively impacted by any design decisions you make. Also, for the purpose of this article, I’m only taking into consideration A-Grade browsers.
Here’s a nice lesson for web app designers and developers, to help streamline the user’s progress when interacting with your application.
In many cases, it’s enough to log users in and then redirect them to the main screen of the app, where they can then choose what they want to do. It’s also good practice to send them back to whatever screen they were on before they logged in, instead of just sending them to the main screen.
But here’s a way to handle a user log-in when the user has not yet interacted with your pages, as shown below from PayPal:
What?? $3.99 for an iPhone app? Are you crazy? The nerve of some people. Lunatics.
How can you expect me to pay $3.99 for this? Every single iPhone app I’ve ever downloaded is either free or costs 99 cents. Now, you expect me to pay $3.99, and all I’m able to judge it by is a couple of screenshots, a brief description and a few shill-sounding reviews.