Jay Hoffmann on the origins of the HTML Editorial Review Board (which would later become the HTML Working Group):
In February of 1996, this new HTML ERB held their first meeting. The board had representation from all across the map, from browser vendors to software makers to standards advocates. And they each had a different idea of what HTML could do. What they needed was some uniform consensus. A common enemy to bring them together.
Which brings us back to
blinkandmarquee.
This document explains the various ways of hiding things and the implications that come with that.
Indeed it does! This is a very thorough, detailed article on the ins and outs of hiding content with markup and CSS.
This document provides readers with an understanding of how to use WAI-ARIA 1.1 [WAI-ARIA] to create accessible rich internet applications. It describes considerations that might not be evident to most authors from the WAI-ARIA specification alone and recommends approaches to make widgets, navigation, and behaviors accessible using WAI-ARIA roles, states, and properties. This document is directed primarily to Web application developers, but the guidance is also useful for user agent and assistive technology developers.
htmlreference.io is a free guide to HTML. It features all elements and attributes.
This site—along with its sister site, cssreference.io—is an excellent, thorough, and well-designed resource.
The elements list is clearly alphabetized, but it’s some small pleasure seeing the almighty anchor listed first.
In this helpful article, Elliot Dahl details his process for creating and aligning SVG icons to text.
In a lengthy response to a hyperbolic, ill-informed opinion piece, Aaron Gustafson describes progressive enhancement:
It’s a philosophy that recognizes the nature of the Web as a medium and asks us to think about how to build products that are robust and capable of reaching as many potential customers as possible. It isn’t concerned with any particular technology, it simply asks that we look at each tool we use with a critical eye and consider both its benefits and drawbacks. And it’s certainly not anti-JavaScript.
I spent a good deal of time in 2015 writing and speaking on the benefits of this approach to designing and building for the Web:
The observant reader would note that Aaron and I address the same tenuous arguments made—coincidentally—by the same people.
Jeremy, on how he thinks about building progressive web apps:
In my opinion, the term “progressive web app” can be read in order of priority:
- Progressive—build in a layered way so that anyone can access your content, regardless of what device or browser they’re using, rewarding the more capable browsers with more features.
- Web—you’re building for the web. Don’t lose sight of that. URLs matter. Accessibility matters. Performance matters.
- App—sure, borrow what works from native apps if it makes sense for your situation.
He also links to Jason Grigsby’s Designing Responsive Progressive Web Apps which is another great read.
The first review for The Orchid’s new album and it’s in German! Related: my band The Orchid has a new album out today. Give it a listen and let me know what you think.
Decades after the fall of the Third Reich, it feels impossible to understand how Adolf Hitler, the tyrant who orchestrated one of the largest genocides in human history, could ever have risen to power in a democratic country. So how did it happen, and could it happen again? Alex Gendler and Anthony Hazard dive into the history and circumstances that allowed Hitler to become Führer of Germany.
Jason Kottke shared this excellent video which gives a high-level overview of Hitler’s rise through the ranks of German government in the run up to World War II. As chance would have it, I’ve recently been reading up on the very same subject (thanks, Wikipedia).
The video is part of a TED-Ed lesson that includes additional links and resources.
Making work accessible creates a better experience across the board. Use this checklist to help build accessibility into your process no matter your role or stage in a project.
The team at Vox open-sourced their accessibility guidelines. Check the announcement blog post for more details on their process.
This book will assist frontend developers in building accessible e-commerce websites and components.
A tremendous living resource documenting eBay’s approach to building accessibly for the Web.
Zack Bloom, co-creator of the supremely useful You Might Not Need jQuery, returns with another helpful resource. Here he details some useful—and at times obscure—bits about the mighty <script> element.
Docubyte photographed the original machines at the National Museum of Computing at Bletchley Park, and the images were then retouched by Ink—and placed on a series of rather lovely coloured backgrounds—to restore them digitally to how they would have looked when new.
So. Cool.
SVG icons for popular brands.
Libraries extend the functionality of the Google Maps APIs by adding new features, implementing common design patterns, or making some tasks a little easier.
I’m spending a fair amount of time with Google Maps this week and this collection of libraries from Google is proving useful.
Are you building your own website? Indie reader? Personal publishing web app? Some other digital magic-cloud proxy? If so, come by and join a gathering of people with like-minded interests. Bring your friends that want to start a personal web site. Exchange information, swap ideas, talk shop, or help work on a project.
After a brief hiatus, Homebrew Website Club returns to LivingSocial next week. Come on by, share what you’re doing with your personal website, and learn about what others are doing with theirs.
Ideas, inspiration and examples for your own projects.
This site aims to provide simplest possible examples of HTML, CSS and JavaScript.
Does what it says on the tin.
This repository is a community-curated list of flexbox issues and cross-browser workarounds for them. The goal is that if you’re building a website using flexbox and something isn’t working as you’d expect, you can find the solution here.
An exciting accessibility change is coming to Chrome 50. Google calls it “focus starting point” and it’s a small—but incredibly helpful—change to how their Web browser manages focused elements and tab order.
If something has focus, it’s also the focus navigation start point, just like before. Also, just like before, if nothing else has set the focus navigation start point, then it will be the current
documentor, if available and supported, the currently activedialog. If we navigate to a page fragment like in the example above, that will now set the focus start point. Also, if we click any element on the page, regardless of whether it is focusable, that will now set the focus navigation start point. Finally, if the element which was the focus start point is removed from the DOM, its parent becomes the focus start point. No more focus whack-a-mole!
As the article explains, prior to this change, focus management can be difficult when tabbing around and moving within a document (or into and out of modal dialog boxes). Take heed of the note in the article’s caveats section:
Sequential focus navigation starting point is currently only supported in Chrome 50, Firefox, and Opera. Until it is supported in all browsers you’ll still need to add
tabindex="-1"(and remove the focus outline) to your named anchor targets.
Looking for more great links organized by year? Browse the archives.