Ever since HTML 5 was introduced I’ve bemoaned how it undoes so much of the intent and good practices of HTML 4 Strict.

New redundant tags like <section>, <header>, <video>, and <audio>. Elements like <embed> that should NEVER have been allowed into HTML in the first place. Etc, Etc.

They even introduced — then quickly deprecated — the <hgroup> tag proving the WHATWG didn’t know enough HTML to be making the new specification!

Don’t get me wrong there are a number of improvements, or things I can live with even if I don’t 100% approve…

But over the past ten years it feels like every blasted month I find one more thing that makes me want to tell the W3C to suck it. …

From various sources — front end framework fanboys in particular — you’ll hear a lot of nonsense about how modifying the live DOM is “bad” or magically “slow”. Oh you need to batch your changes, oh you need to use a document fragment or the shadow DOM instead, blah blah blah blah…

And to be brutally frank, 99% of the time people say this stuff they’re flapping their arse-cheeks in the wind.

The only time this might make sense — using innerHTML — isn’t even true. And you know what? Just stop using that outdated, insecure, train wreck laundry list of how NOT to add stuff to a page… Or at least, how not to do so in all but a few corner-cases where speed doesn’t matter and you know the content is safe. …

In my work as an accessibility consultant, one of the classic problems that’s always been an issue with websites is how so many artists under the delusion that they are “web designers” continue to spew out pixel based layouts.

Pixels are from an accessibility standpoint the least useful measurement. Because so many displays of different sizes have the same resolutions, or displays of the same sizes have different resolutions, there is no “physical standard” by which a pixel is based. …

I’m currently working on a job proposal / contract for a potential new client, where their existing website isn’t just in trouble for accessibility woes, ’tis too slow for many visitors to even want to use. We’re talking 50+ second pageloads on broadband cache-empty with only six images, none of those images being particularly massive (though I can likely cut them in half by adding webm and optimizing the png fallbacks).

I thought that what I’m finding — and one of the false paths to diagnosing the problems I went down — might help others. …

I’m an accessibility consultant. I solve problems.

One of the most common problems with websites I’m called in to fix are broken malformed incomplete inaccessible forms. There are few things that prosecutors or the lawyers of disabled plaintiffs laser-focus on as a form that users with disabilities cannot use for whatever reason.

Now, there are a LOT of ways a form can be “broken”… but the chief problems I come across all the time are:

1. No <label> tags.
2. <label> not properly wrapping form elements and/or lacking “for/id” relationships.
3. Using placeholder=”” to do <label>’s job
4. No <fieldset> around related radio/checkbox sets or around groups of user changeable form elements. …

First off let me just clarify, when I’m talking about grids here, I’m NOT talking about the “CSS3 Grid Layout Module”. I am referring to the layout concept of dividing the width of a page into a fixed number of sub-units such as twelfths of the screen width, a pre-determined max-width, or breaking things up by fractions of 960 pixels.

Back in the ‘00’s the biggest problem with layouts was how people created them as a fixed width. Grids became a part of this where one of the most common questions being “what width should I design for”. The most common answers being either 768px for 800px friendly, or 960px for 1024px friendly. …

In web development — and programming in general — we have a severe problem with echo-chambers, blind parroting of lies, and taking otherwise good ideas and blowing them completely out of proportion to the point of doing more harm than good.

And just as in my previous article “Stop Turning Avoid Into Never” we have a number of good ideas that people blanket apply in unrealistic, unreasonable, and over-reaching ways.

Looping Is Not An Evil You Need To Fight

Functional programmers are some of the worst for this. One of the most efficient constructs in programming — the simple loop — has of late been branded as “bad” by so many people who to be frank, are talking out their backsides. …

As a whole, web development has a real problem with honesty and rational thought. There’s a lot of pedantic nonsense promoted as good practice, based entirely in manufactured “truths” that aren’t based in any way, shape, or form in reality.

One such bald faced lie is the idea that the “universal selector” — a lone asterisk — is slow, confusing, difficult to understand, and I’ve even seen a few people call it outright evil. To be brutally frank, what a load of malarkey. Actually, I have stronger words for it, but I’m trying to behave here.

I recently added this to my…