The majority of people are “visually oriented”. They like to think about how things look before most other concerns. When it comes to web development this is a hard “habit” to break oneself of, but it’s an essential one given that HTML is for more than just perfectly sighted users. It’s why bass-ackward nonsense like artists under the DELUSION they’re “designers” pushing pixels around in Photoshop are able to sucker nubes and rubes alike, flipping the bird at UX and accessibility in their ignorance of anything other than art. …

Over the past decade the improvements to CSS have transformed how websites are built, mostly for the better. One of the most powerful of these has been the CSS transition, allowing us to make animations without the slew of JavaScript we threw at sites in the past.

Yet frustratingly the one transition that’s hard to do is between “0” and “Auto” values. The automatic size calculation — sizing to the content — simply isn’t something browser makers seem to be willing to even consider implementing.

This makes show/hide animations of all sorts a lot harder than need be. I’ve seen all sorts of crazy convoluted answers to this. Some people try to use fixed heights which requires the content and screen size to be static, an utterly impractical solution. Others intercept the trigger of the animation or create one using JavaScript, and then try to calculate the values on the fly. In many cases, the folks with the scripting answers ignore how page resizing can screw up the layout, or layer hook upon hook to try and compensate for it. They even go so far in some cases as to revert to the old JavaScript way of animating things. …

In my voyages from company to company as a freelance accessibility and efficiency consultant, I am constantly butting heads with web developers who have some genuinely queer notions of what semantic markup is and isn’t. From those saying “Isn’t that just for SEO?” to “It really doesn’t matter”, to “Well that’s just for coders to look at”, there’s a lot of disinformation, misunderstandings, and just plain lies out there.

To put it as plainly and succinctly as possible:

Semantic markup is nothing more than a sick euphemism for “Using HTML properly!”

Semantic markup is the reason HTML existed from the start. It’s not “just for SEO” since it had semantics two years before JumpStation — the first “real” HTML based search engine — was a twinkle in Feltcher’s eye. …

I want to like BEM — Block, Element, Modifier — I really do! Any time someone comes up with a uniform consistent naming scheme, I’m usually all-in… BUT… when it comes right down to it how it works and what it does defeats most if not all of why HTML exists and why CSS is separate from it.

It reeks of people too stupid to understand the simplicity of selectors, combinators, and proper semantics trying to just slop classes everywhere to fix their own ineptitude; when really if using combinators and the proper markup is “so hard” you need this stuff, maybe it’s time to give up, walk away, and go flip burgers for a living. …

If you’ve not already read it, be sure to check out part 1.

In part 1 I showed how to take someone else’s simple example, and give it a bit of spit and polish cutting the code size almost in half. Since it was already tiny, that now gives us room to enhance it with more functionality.

In particular the use of two objects containing our sort types and data gathering methods lays the groundwork for easily adding more types of sorts.

New CAPTION and THEAD Markup

To show off our new filters we need a new table with new data.

The table caption/header is where most of the changes take…

There are a number of decent articles out there about doing this. In particular, Bobby Jack’s article here on Medium stands out for a few reasons:

1. They hook the markup from the JavaScript which leaves the proper semantics alone. That’s REALLY GOOD scripting as ’tis a form of “progressive enhancement”. That means we get “graceful degradation” for users who don’t have JavaScript available or in cases — like screen/braille readeres — where it’s highly irrelevant. As much as possible when you write JavaScript you should at least TRY to make pages that are still usable for users who have scripting off/blocked/otherwise unavailable. Failing to do so basically tells large swaths of users — particularly those with accessibility needs — to go shtup themselves. …

Note, sorry but this article is going to skip between languages a bit.

Everyone knows about count, for and foreach. They’re the staple of programming array loops. If you work in PHP, you likely know what they do and how to use them…

But what aboutcurrent, end, key, last, next, prev, and reset?

Much less how if/do/while can be used to smartly make loops in most all C syntax languages?

I’ve been shocked the past year or so how many dev’s I come across who’ve never even heard of them, much less understand their use. What prompted this article is that I was just working on a “function stack” of anonymous that other processes can add to, and I used this because of the “You can’t add to an array inside a foreach” issue; and a colleague saw it and said “what the devil is that?!?” …

Over on DigitalPoint it was asked if it were possible to make a clock face using just HTML and CSS. Whilst I answered their question as cleanly as I could in a drive-by answer, I thought a more polished and robust copy would make a good article.

One of the things I constantly see is how many implementations tend to use a lot of JavaScript with no scripting-off graceful degradation plan. As if <noscript> is some arcane tome too hard understand. …