What it says on the tin—a few suggestions to ensure the accessibility of your site.
dialogs are here.
Training a neural network to do front-end development.
I didn’t understand any of this.
Suggestions for small interface tweaks.
The philosophy behind these tools matches my own philosophy (which I think is one of the most important factors in choosing a tool that works for you, not against you).
Ana goes into exhaustive detail on all the differences in the shadow DOM and styling of
input type="range" across browsers.
I’m totally fine with browsers providing different styling for complex UI elements like this, but I wish they’d at least provide a consistent internal structure and therefore a consistent way of over-riding the default styles. Maybe then people wouldn’t be so quick to abandon native elements like this in favour building their own UI components from scratch—the kind of over-engineering that inevitably ends up being under-engineered.
Paul walks us through the process of making some incremental accessibility improvements to this year’s 24 Ways.
Creating something new will always attract attention and admiration, but there’s an under-celebrated nobility in improving what already exists. While not all changes may be visual, they can have just as much impact.
Everything you ever wanted to know about the
title attribute in HTML.
What’s hot: using
What’s not: using
title on anything else.
Great advice on keeping your hyperlinks accessible.
An excellent level-headed evaluation of styling and scripting form controls, weighing up the benefits and trade-offs. The more tightly you control the appearance, the less you get to benefit from the functionality (and accessibility) that the browser gives you for free …meaning you’ve now to got to work harder to replace it.
HTML elements like check buttons, radio buttons or select options can be hard to style with CSS in a custom design. There are many workarounds for this, but are they accessible?
In which Brian takes a long winding route through an explanation of why the
is attribute for custom elements is dead before he demonstrates the correct way to use web components:
<!-- instead of writing this --> <input type="radio" is="x-radio"> <!-- you write this --> <x-radio> <input type="radio"> </x-radio>
Sadly, none of the showcase examples I’ve seen for web components do this.
Practical advice from Ire on localising web pages.
Brad always said that carousels were way to stop people beating each other up in meetings. I like the way Heydon puts it:
Carousels (or ‘content sliders’) are like men. They are not literally all bad — some are even helpful and considerate. But I don’t trust anyone unwilling to acknowledge a glaring pattern of awfulness. Also like men, I appreciate that many of you would rather just avoid dealing with carousels, but often don’t have the choice. Hence this article.
Instead of being prescriptive about error messaging, we use what the browser natively gives us.
Good question! And a good answer:
If you really need it, which you probably don’t,
readonlyis what you want.
James has been tweaking the accessibility of his site navigation. I’m looking forward to the sequel.
One of the things we’d hoped to enable via Web Components was a return to ctrl-r web development. At some level of complexity and scale we all need tools to help cope with code size, application structure, and more. But the tender, loving maintainance of babel and webpack and NPM configurations that represents a huge part of “front end development” today seems…punitive. None of this should be necessary when developing one (or a few) components and composing things shouldn’t be this hard. The sophistication of the tools needs to get back to being proportional with the complexity of the problem at hand.
I completely agree with Alex here. But that’s also why I was surprised and disheartened when I linked to Monica’s excellent introduction to web components that a package manager seemed to be a minimum requirement.
Occasionally, people e-mail me to say something along the lines of “I’ve come up with something to replace HTML!”.
Five years ago, Hixie outlined the five metrics that a competitor to the web would have to score well in:
- Be completely devoid of any licensing requirements.
- Be vendor-neutral.
- Be device-neutral and media-neutral.
- Be content-neutral.
- Be radically better than the existing Web.
You come at the king, you best not miss.
Here’s a great free curriculum for teaching HTML and CSS.
I quite like this proposal for
geo element in HTML, especially that it has a fallback built in (like
video). I’m guessing the next step is to file an issue and create a web component to demonstrate how this could work.
That brings up another question: what do you name a custom element that you’d like to eventually become part of the spec? You can’t simply name it
geo because you have to include a hyphen.