As most of us probably are aware, a significant part of the HTML5 spec is the expansion of the History API.
This post will not be a super extensive discussion of this subject, especially since it’s something that I’m only now just getting into understanding better. But I thought I would put down the main components of the API, for my own quick reference, and I hope it will prove useful to my readers and those searching via Google.
Let’s say you’re viewing different pages in your browser, and in the midst of your browsing you decide to visit a Google’s home page.
On many sites and apps, you’ll often have to mark up and style a button that is not part of a list of links, and that basically stands alone, apart from surrounding content.
How should a single, standalone link or button be marked up? As with many things in web development, there isn’t really a right or wrong way to do this, but here’s a summary of some of the different methods.
With all the hype surrounding the new APIs and the fancy parts of CSS3, I had almost forgotten about the new
reversed attribute that allows you to write a descending list of numbered items, as opposed to the default ascending list of numbered items.
You can get full details in the specification, but here I’ll summarize what it does and I’ll offer a solution for the fact that there is (from what I can see) no browser support for this attribute.
One challenge that developers have faced when creating forms is the inability to separate a form control from its parent
<form> element without having to resort to some undesirable methods to get that form control to submit its data along with the form.
If you tried to do this in HTML4 or XHTML, the form would not submit the information from the form control that’s structurally outside the form.
The topic of scoped CSS styles in HTML5 came up twice in the comments of a recent post by Chris Coyier.
The post itself was discussing the contenteditable attribute, but a few users brought up HTML5’s new scoped attribute, used on the
Let’s take a brief look at this future HTML5 feature and see how it might be useful in the ever-changing web development landscape.
Ever since HTML5 has started to gain wider use, many developers have wondered what syntax style should be most prevalent. When coding HTML in XML format, it was easy–because the validator forced you to code in a consistent manner.
Well, since code validation in HTML5 is a bird of another feather, a consistent coding style is going to be extremely unlikely across the web. While an exact coding style across all sites is not really necessary, I think some level of consistency is in order. People’s concerns in this area are valid.
So here are my own personal point-by-point recommendations for clean and consistent markup, and some reasons behind the decisions.
Here’s something interesting I came across while reading Introducing HTML5 by Bruce Lawson and Remy Sharp, which I recently purchased.
In one of the early chapters, Bruce mentions that when tags are not nested properly, the resulting generated DOM will be seen differently in different browsers. Of course, when you “view source”, the code will be the same in all browsers. It’s when you inspect the page (or view the “generated source”) using developer tools that the results can differ.
After some testing, this is indeed the case. Here’s the code that I tested:
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).
If you were to use
<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.