Some great thoughts here from Francis on how crafting solid HTML is information architecture.
A little tool for testing common form issues.
- Did we remember to give every input a label? (No, placeholders are not an adequate replacement)?
- Do our labels’ for attributes match our inputs’ ids?
- Did we take advantage of the url, email, and password input types, or did we forget and just use text?
- Are our required fields marked as such?
Really, really smart thinking from Paul here, musing on the power relationship between the creators of custom elements and the users of custom elements.
This is nice example of a web component that degrades gracefully—if custom elements aren’t supported, you still get the markdown content, just not converted to HTML.
<ah-markdown> ## Render some markdown! </ah-markdown>
Building a good foundation using HTML is like building a good foundation for a house. Without it, you run the risk of having to deal with issues that are difficult and expensive to fix later on.
Chris runs through the process and pitfalls of POSSEing a site (like CSS Tricks) to Apple’s News app, Facebook’s Instant Articles, and Google’s AMP.
Hey, whatever you want. As long as…
- It’s not very much work
- The content’s canonical home is my website.
I just want people to read and like CSS-Tricks.
Heydon asked screen readers some questions about their everyday interactions with websites. The answers quite revealing: if you’re using headings and forms correctly, you’re already making life a lot easier for them.
Choosing the right input type for your form field.
I wrote a while back about how I switched from using a button to using a link for progressive disclosure patterns. That looks like it was a good move—if I use a button, I’d need to use
aria-controls and, as Heydon outlines here, the screen reader support is pants.
A great series of short videos from Marcy on web accessibility.
Build JS apps responsibly - cover your basics, render strategically and enhance into true apps.
I love this back and forth between Brad and Jonathon. I think they’ve both got some good ideas:
- I agree with Brad that you can start marking up these kind of patterns before you’ve got visual designs.
- I agree with Jonathon that it’s often better to have a generic wrapper element to avoid making assumptions about which elements will be used.
A good introduction to custom elements, one piece of the web components stack.
Accessibility Matters: Meet Our New Book, “Inclusive Design Patterns” (Pre-Release) – Smashing Magazine
I think it’s a safe bet that this new book by Heydon will be absolutely brilliant.
It’s a handbook with valuable, time-saving techniques that will help you avoid hacky workarounds and solve common issues effectively.
I need to wrap my head around the details of this approach, but it sounds like it might be something I could do here on my site (where I feel nervous about my current dependency on a database).
You’re supposed to be able to create two-handled sliders with
input type="range" but the browser support isn’t there yet. In the meantime, Lea has created a nice lightweight polyfill.
Snook has been on a roll lately, sharing lots of great insights into front-end development. This is a particularly astute post about that perennial issue of naming things.