Following on from Ire’s post about linting HTML with CSS, here’s an older post from Ebay about how being specific with your CSS selectors can help avoid inaccessible markup getting into production.
Smart use of attribute selectors in CSS to catch mistakes in HTML.
Jason revisits responsive images. On the whole, things are looking good when it comes to browser support, but he points out that
scrset’s precursor in CSS—
image-set seems to have dropped off the radar of most browser makers, which is a real shame.
Jake is absolutely spot-on here. There’s been a lot of excited talk about adding an
h element to HTML but it all seems to miss the question of why the currently-specced outline algorithm hasn’t been implemented.
This is a common mistake in standards discussion — a mistake I’ve made many times before. You cannot compare the current state of things, beholden to reality, with a utopian implementation of some currently non-existent thing.
If you’re proposing something almost identical to something that failed, you better know why your proposal will succeed where the other didn’t.
Jake rightly points out that the first step isn’t to propose a whole new element; it’s to ask “Why haven’t browsers implemented the outline for sectioned headings?”
Ever wondered what the most commonly used HTML elements are?
A nice straightforward introduction to web development for anyone starting from scratch.
bastianallgeier/letter: Letter is a simple, highly customizable tool to create letters in your browser.
A nice little use of print (and screen) styles from Bastian—compose letters in a web browser.
Instead of messing around in Word, Pages or even Indesign, you can write your letters in the browser, export them as HTML or PDF (via Apple Preview).
A nice and clear description of how browsers parse and render web pages.
PPK has posted some excellent thinking on calendar widgets to Ev’s blog.
I understand how bloated and non-reusable code can get when a dozen people who don’t talk to each other work on it over a period of years. I don’t believe the problem is the principle of semantic markup or the cascade in CSS. I believe the problem is a dozen people working on something without talking to each other.
Some great thoughts here from Francis on how crafting solid HTML is information architecture.
This philosophy doesn’t apply to every website out there, but it sure as hell applies to a lot of them.
I always loved the way that Gov.uk styled their radio buttns and checkboxes with nice big visible labels, but it turns out that users never used the label area. And because it’s still so frickin’ hard to style native form elements, custom controls with generated content is the only way to go if you want nice big hit areas.
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?
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>
Some more food for thought, following on from Shaun’s post about HTML as the foundation of web development:
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.