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.
Here’s a CSS3 property that has very little support and that I’m not sure has too many real world applications or if it would even be extremely beneficial — the CSS3 resize property.
The resize property is part of the W3C’s Basic User Interface Module, which is in the candidate recommendation stage.
Unfortunately, the resize property is listed in the Features at Risk section of that same document, so it’s quite possible that this feature will be removed if browser-makers don’t support it. Nonetheless, here’s a quick review of exactly what this property is all about so you can decide if it’s of any practical use in your projects.
One of things that we need to get used to when making the switch from HTML4/XHTML to HTML5 is the way HTML5 validation works, because it’s drastically different from what we’ve become accustomed to in previous iterations of web markup.
First, it should be noted that the W3C’s HTML5 validation engine is “experimental”, so it’s a work in progress that will likely see many changes over the next year or more. Also, we shouldn’t refer to it as a “validator” anymore; it’s now more accurately referred to as a “conformance checker” (although for simplicity I’ll be using the term “validation” and its derivatives).
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.
When coding JavaScript, I find myself using the for loop fairly often. Recently, when I coded, then re-coded these drop-down menus, during the re-code I ran my JavaScript/jQuery through JSLint using the option called “The Good Parts”.
I don’t know a whole lot about JSLint, but I figured that would be a pretty good way to ensure the code was efficient, relatively future-proof, and easy to maintain (i.e. it uses best practices).
The info JSLint provided, as well as other stuff I’ve read in the past, got me thinking about the simple JavaScript for loop and how it’s customarily written.
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.
If you were to use <strong> and <em> tags in HTML5 the same way that you’re accustomed to, it would be fine. As many have stated, HTML5 is backwards-compatible with old-style trends in SEO, accessibility, and markup, so your pages won’t break or be considered obsolete or deprecated.
But that doesn’t mean that some of these elements aren’t evolving. One good example is the use of tags to make what we normally know as “bold” and “italic” text.
Here I describe some things to take note of when adding HTML elements that are usually associated “bold” or “italic” text.
I was thinking that you should know how to do some code in the areas of jQuery, CSS3, HTML5 and everything else you can think of.
This post will clarify all those matters. They are all matters of which you should be clarified.
But before I explain all those things in the greatest of all detail, I should warn you of a few things:
