Snippets

Everyone who’s ever messed around with dates knows that they are terribly user-hostile — not only for software developers, but also for users. True, users will be able to tell you their date of birth or today’s date without trouble, but ask them to fill them out in a web form and they will encounter problems.

Month first, day first, or year first? And what about slashes, dashes, and other separators? Usually the website engineer has a strong personal preference and enforces it religiously upon unsuspecting users with stern and incomprehensible error messages in a lurid shade of red that are too tiny for anyone over 25 to read.

input type=”date”

In theory, there’s a solution to this problem: <input type=”date”>. It offers a special interface for picking dates, and it enforces a standard format for the value that’s sent to the server. Better still, the mobile browsers support it.

[…]

Here’s a test page for <input type=”date”> and a few related types. Remember that some don’t work in some browsers.

[…]

I think it’s time that we trust browser vendors a bit more. The days of useless features for the sake of having a longer feature list are long gone. Nowadays, browser vendors try to add features that are actually useful for users, and are actually implemented by web developers. If a browser says it supports <input type=”date”>, you should trust it to deliver a decent experience to its users. If it says it does not, and only in that case, you should use a custom widget instead.

[T]he data’s in now. The hamburger menu doesn’t work well, and it’s time for everyone to move on. At this point, there aren’t many good excuses for using them in new site designs, and it very well may be worth revisiting older sites to see if they might perform better with an updated navigation structure.

Exposing long navigation menus on small screens is tricky. Hamburger menus are everywhere, although often discouraged. Displaying “just enough” navigation at every breakpoint can feel like an impossible task. This is especially true for template developers needing to accommodate an arbitrary number of menu items.

The Priority+ design pattern seeks to display as many items as possible given an arbitrary screen width, while making the rest accessible via a single click. I’ll go over the implementation I worked on at Goshen College that includes both dropdown menus and horizontal scrolling, which I’ve yet to find in the wild:

You could settle for a basic grey box to show your placeholder images or you could substitute actual photos of the most gnarly places in the universe. We created SpaceHolder to help pull these amazing images straight from NASA’s photo archives into your Web project.

The intersection of rushed (or careless) development and unintended consequences:

We’re doing a story about people that have names that websites and computers don’t seem to like - for example, we spoke to a guy named William Test, and a woman named Katie Test, both of whom can’t seem to keep a hotel or airplane booking because the name “test” is flagged by internal systems.

We also spoke to a guy named Christopher Null who had the same problem, and woman named Joan Fread, who can’t use paypal because her last name is the same as a PHP command.

I’m curious if there’s anyone in the dev community that is thinking about this, and how to deal with it. Is it even considered a problem? Is the population that this affects so small that people don’t even think about it?

WebSlides makes HTML presentations easy.
Just the essentials and using lovely CSS.

[…]

Each parent <section> in the #webslides element is an individual slide.

Code is clean and scalable. It uses intuitive markup with popular naming conventions. There’s no need to overuse classes or nesting. Making an HTML presentation has never been so rewarding.