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.
The cursor is blinking in the search field. This means the cursor has been automatically focused into the search field, either via JavaScript or using HTML5′s autofocus attribute.
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.
As a result, if you wanted the data from the orphaned control to be submitted along with the rest of the form data, you’d have to implement some fancy JavaScript tricks to pass the information into the submission — which has many obvious drawbacks.
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 <style> element.
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 <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.