This is not a knock against my current area of work. I love what I do, and I don’t intend to change. But I think most of us think about what we might do (or what we might have done) if web design wasn’t in the equation.
In this case, though, I’m taking it a little further. Instead of just saying “here’s what I’d do if I couldn’t do web design”, this is actually a list of legitimate jobs that I would rather have if I could jump into them immediately and not do anything related to the field of web design. These are not necessarily in preferred order.
After publishing Easy HTML5 Template last week, and getting some constructive feedback on the contents of the template, something dawned on me that has apparently been alluded to in a few different articles, including one on HTML5 Doctor.
Basically, it seems that HTML5’s new <section> element is confusing and it’s hard to discern its true value. I’ll try to demystify it here by referring back to the spec and discussing, through process of elimination, some ways it could be used.
I’ll be the first to admit that when I see a default template like HTML5 Boilerplate, it brings about a swirl of emotions.
On the one hand, I’m ridiculously intimidated by the incredible amount of knowledge and experience that’s been collected into one place for the benefit of front-end developers. So much so, that I wonder what I’m even doing in this industry, because it reminds me of how far behind I am.
On the other hand, I’m inspired, because there’s so much more to learn, and it’s exciting to add new nuggets of knowledge to my toolkit, and I can’t wait to hit the books and grow my knowledge base. It also helps when others express the same feelings about lagging behind. But I’m getting sidetracked.
This article was first published on June 1, 2010 and has been updated to include a few extra features and an improved code base.
I’m a huge baseball fan, so earlier this year, just for a fun side project, I recreated the MLB.com Flash content switcher using jQuery and CSS3.
My goal with this project was to try to recreate the switcher without any extraneous images or other non-essential elements that tend to make stuff less maintainable.
My version uses CSS3’s border-radius, RGBA colors, opacity, and a small use of a gradient, and still looks acceptable in non-supportive browsers (although the jQuery is not as smooth in IE6 & IE7). Be sure to look at the real version on MLB.com for comparison; there are a few small differences, but mine is basically the same.
Before I go into the main content of this post, I just want to say that Bruce Lawson has done a fantastic job of promoting HTML5 education both online and in print. I haven’t had a chance to get a copy of his and Remy Sharp’s book Introducing HTML5 but it is on my definite to-read list.
But sometimes it seems that HTML5 evangelists can get a little bit carried away in their zeal for promoting these new technologies and features, and they inadvertently end up misusing terms.
In my opinion, Bruce does this in Issue #204 of .net magazine, in the recently-revamped “gallery” section that now includes HTML5 websites.
The improvements that have been added to HTML5 and how markup is evolving are great for the future of the web.
But I can’t help but feel frustrated that while we’ve come so far in certain areas, that we’re still a long way from being where we really want to be. One of those problematic areas is HTML5 video.
Why it’s taken so long to have a universal way to embed video natively in the browser without the need for a third-party plugin is beyond me. But it’s very difficult to get excited about something that is realistically not very practical or real-world ready.
I’m going to discuss here why I think HTML5 video is a great concept in principle, but a complete disaster in most practical usage.
I think this is a pretty basic point, but I often see people throwing terms around in inappropriate ways (which I’ve also been guilty of), so I thought I would clear this up.
As fallible humans we tend to lean towards making excuses, blaming others, or trying to justify our mistakes or shortcomings. This is why you’ll often read comments from people discussing CSS and web standards, and they’ll say “I don’t use Internet Explorer; I use a standards-compliant browser”. Well, no you don’t. Nobody does.
Over the years I’ve continued to refine my understanding of front-end development terms, especially CSS terms and definitions.
I’m constantly reminded that as developers we should be consistent in the use of our terms. This post will attempt to list all common CSS terms, and what they represent in CSS code. Much of this is pretty easy stuff for most experienced developers, but some is not used as often colloquially or in writing, so a refresher could help clear up some inconsistencies.
Yesterday I was looking at the services offered by Squarespace, a “fully hosted, completely managed environment for creating and maintaining your website.” Don’t worry, I’m not going to go off on a rant about how bad this kind of thing is for web developers.
I recognize that not everyone can afford to pay thousands of dollars to hire a designer and/or programmer to create a website for them. Squarespace offers quite a flexible service for website noobs and at a pretty reasonable monthly rate.
But I couldn’t help but laugh when I read the following paragraph on a page describing their services as offering total creative control: