Recently I came across a CodePen demo by a developer/engineer named Jane that was Tweeted out by Šime Vidas. The demo has a neat collection of HTML and CSS tricks rolled into one that I thought was worth examining in detail.
This week I did some research to try to build a hamburger menu that opens a slide-out navigation panel, a common design pattern nowadays. But I wanted to ensure the whole thing was keyboard-friendly and as accessible as possible.
I’m not 100% sure what I’ve come up with is the most accessible solution, but I did consult a number of decent sources on building accessible navigation menus like these. I also did some rudimentary testing using the free NVDA screen reader, to ensure there are no major problems.
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.
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.
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’sconcerns 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: