This is a deep, deep dive into responsive images and I can only follow about half of it, but there are some really useful suggestions in here (I particularly like the ideas for swapping out images for print).
An in-depth look at where web components stand today, together with some very good questions about where they might be heading tomorrow.
Here’s a really nifty use of the
:checked behaviour pattern that Charlotte has been writing about—an interface for choosing a note from a piano keyboard. Under the hood, it’s a series of radio buttons and labels.
I like this nice straightforward approach. Instead of jumping into the complexities of the final interactive component, Chris starts with the basics and layers on the complexity one step at a time, thereby creating a more robust solution.
If I had one small change to suggest, maybe
aria-label might work better than offscreen text for the controls …as documented by Heydon.
A superb piece by Ross Penman on the importance of being true to the spirit of the web.
Github’s pattern library.
As always, it’s great to see how other organisations are tackling modular reusable front-end code (though I can’t imagine why anyone other than Github would ever want to use it in production).
Lea wasn’t happy with the lack of styling and extensibility of the datalist element, so she rolled her own lightweight autocomplete/type-ahead widget, and she’s sharing it with the world.
The Web is the printing press of our times; an amazing piece of technology facilitating a free and wide-scale dissipation of our thoughts and ideas. And all of it is based on this near 20-year old, yet timeless idea of the Hyper Text Markup Language.
I just noticed that I’m mentioned in the acknowledgements of this most handy of W3C documents. This pleases me disproportionately.
With all my talk about extending existing elements instead of making new ones, I was reminded of one of my favourite examples of custom elements in action: Github’s extensions of the
I completely share Bruce’s concern about the year-zero thinking that’s accompanying a lot of the web components marketing:
Snarking aside, why do so few people talk about extending existing HTML elements with web components? Why’s all the talk about brand new custom elements? I don’t know.
I’m a fan of web components. But I’m increasingly worried about the messaging surrounding them.
A history lesson and a love letter to the early web, taking in HTML, Photoshop, and the web standards movement.
Those were long years, the years of drop-shadows. Everything was jumping just slightly off the screen. For a stretch it seemed that drop-shadows and thin vertical columns of text would define the web. That was before we learned that the web is really a medium to display slideshows, as many slideshows as possible, with banner ads.
This strikes me as an eminently sensible idea by Emil: using the picture element to begin providing WebP alternatives to JPG.
Of course, picture-supporting browsers will have to adjust their decision-making algorithm to support this pattern.
Paul Ford’s potted history of web standards, delivered in his own inimitable style.
Reading through the standards, which are dry as can be, you might imagine that standardization is a polite, almost academic process, where wonks calmly debate topics like semicolon placement. This is not the case.
A great primer on using
picture. I think I’ll be referring back to this a lot.
Following on from that post of Jason’s I linked to, Chris also emphasises that, for most use cases, you probably only need to use srcset (and maybe sizes), but not the picture element with explicit sources.
It’s really, really great that people are writing about this, because it can be quite a confusing topic to wrap your head around at first.
Léonie gives a great, clear description of how screen readers switch modes as they traverse the DOM snapshot.
Jason points out that the picture element might not be needed for most responsive image use cases; the srcset and sizes attributes will probably be enough—that’s what I’m doing for the photos on my site.
Remember when I was talking about refactoring the markup for Code for America? Well, it turns out that Heydon Pickering is way ahead of me.
He talks about the viewpoint of a writer (named Victoria) who wants to be able to write in Markdown, or HTML, or a textarea, without having to add classes to everything. That’s going to mean more complex CSS, but it turns out that you can do a lot of complex things in CSS without using class selectors.
There are slides.
Some very handy techniques for working with right-to-left text.
This (literally) charts the evolution of HTML, tracking which elements have been added and which have been removed.
A lovely little tale of empowerment through HTML and CSS.
I really hope that this is the kind of usage we’ll see for web components: enhancements for the browsers that support them without a good ol’ fashioned fallback for older browsers.
A look at how the website for An Event Apart is using the picture and Picturefill …featuring Jessica as the cover girl.
A truly wonderful piece by Mandy detailing why and how she writes, edits, and publishes on her own website:
No one owns this domain but me, and no one but me can take it down. I will not wake up one morning to discover that my service has been “sunsetted” and I have some days or weeks to export my data (if I have that at all). These URLs will never break.
A great article by Susan on getting started with creating a styleguide for any project.
I’ve seen firsthand how style guides save development time, make communication regarding your front end smoother, and keep both code and design consistent throughout the site.
Funny because it’s true:
The thing I regret the most is how my class addiction affected my relationship with HTML.
A great post from Anna on the front-end styleguides she’s worked on for A List Apart and Code for America. ‘Twas a pleasure working with her on the Code for America project.
A-mer-ica! Fuck yeah!
A fascinating look at the early history of HTML, tracing its roots from the dialect of SGML used at CERN.
Another front-end style guide for the collection. This time it’s from A List Apart. Lovely stuff!
A nice bit of markup archeology, tracing the early development of HTML from its unspecced roots to the first drafts.
I recognise some of the extinct elements from the line-mode browser hack days at CERN e.g. HP1, HP2, ISINDEX, etc.
A fascinating snapshot from 1995, arguing for the growing power of HTML instead of the siren song of proprietary formats.
I’m very happy that this is still available to read online 18 years later.
The authors of the Extensible Web Manifesto explain the thinking behind their …uh… thinking.
Alex starts with a bit of a rant about the phrase “semantic HTML”, which should really just be “well-written HTML, but there then follows some excellent thoughts on the emergence of meaning and the process of standardising on vocabularies.
Hot on the heels of the Mailchimp styleguide, here’s the collection of patterns used by Mapbox. I’m not keen on some of their markup choices, but again, it’s great to see organisations publicly documenting this stuff.
The definition of the cite element (and the blockquote element) has been changed for the better in HTML5 …at least in the W3C version anyway.
A love letter to HTML, prompted by the line-mode browser hack event at CERN.
Once you get past the cheesy intro music, there are some gems from Robert Cailliau in here.
Jason provides some instruction in using the correct quotation marks online.
Go, Dan, go!
The semantics of the cite element are up for discussion again. Bruce, like myself, still thinks that we should be allowed to mark up names with the cite element (as per HTML 4), and also that cite elements should be allowed inside blockquotes to indicate the source of the quote.
Let’s pave that cowpath.
A very, very clever hack to provide fallback images to browsers that don’t support SVG. Smart.
A very handy starting point for creating a front-end style guide.
I kind of love the interaction design of this site.
A terrific case study in progressive enhancement: starting with a good ol’ form that works for everybody and then adding on features like Ajax, SVG, the History API …the sky’s the limit.
This is wonderful stuff! I’m a big fan of the
datalist element but I hadn’t realised how it could be combined with
input types like
Here are some nice patterns that Paul uses for starting points in his own projects.
Related to my rant on links that aren’t actually links: buttons that aren’t actually buttons.
You’re probably doing each of these already but just in case your’e not, Andy has listed six quick wins you can get from HTML5.
Bruce takes a look at the tricky issue of styling native form controls. Help us, Shadow DOM, you’re our only hope!
A good explanation of HTML5’s sectioning content and outline algorithm.
Bruce sits down for a chat with Hixie. This is a good insight into the past and present process behind HTML.
Here’s a treasure trove of web history: an archive of the www-talk list dating back to 1991. Watch as HTML gets hammered out by a small group of early implementors: Tim Berners-Lee, Dave Raggett, Marc Andreessen, Dan Connolly…
Why you should say HTML classes, CSS class selectors, or CSS pseudo-classes, but not CSS classes - Tantek
I love that Tantek is as pedantic as I am …although I don’t think “pedantic” is exactly the right word.
Tantek has put together a wiki page to document the arguments for and against adding a new “main” element to HTML.
A handy step-by-step guide to scraping HTML to get data out. Useful for services (—cough—Twitter—cough—) that keep changing the rules of their API use.
Less wireframing, more prototyping.
Bruce’s thoughts on the proposed inclusion of a “content” or “maincontent” element in HTML5.
Personally, I don’t think there’s much point in adding a new element when there’s an existing attribute (role=”main”) that does exactly the same thing.
Also, I don’t see much point in adding an element that can only be used once and only once in a document. However, if a “content” or “maincontent” element could be used inside any sectioning content (section, article, nav, aside), then I could see it being far more useful.
A really great markup and CSS pattern for “content first, navigation second” from Aaron.
An interesting approach to squishing down large data tables for small-screen viewing …though I wonder if there isn’t a “Mobile First” approach that could scale up, say, lists to become tables on large screens.
Have you thought “There must be a good reason for the blink element.” Well, read on.
Anna goes through some of her favourite pattern libraries. It’s really, really great to see this stuff getting documented.
I met one of the guys from the Starbucks team at South by Southwest and he mentioned that they had a markup pattern library. I encouraged them to make it public, and it here it is!
I really hope that more companies and agencies will start sharing stuff like this.
An in-depth look at naming patterns for classes to help streamline CSS.
Richard gives the lowdown on the new translate attribute in HTML.
A great pattern library from Dan.
Some valuable musings from Ben on how browsers could be better — and I don’t mean the usual moaning about performance or device APIs.
A superb rallying cry from Mandy on the importance of markup literacy for professionals publishing on the web: writers, journalists, and most importantly, editors.
A Responsive Design Approach for Complex, Multicolumn Data Tables | Filament Group, Inc., Boston, MA
A really nice pattern for data tables in responsive designs. Just as with conditional loading, the key point is making a distinction between essential and optional content.
This helps to clarify the difference between native semantics and ARIA additions.
This is a great response to my recent post about semantics in HTML. Steve explores the accessibility implications. I heartily concur with his rallying cry at the end:
A very even-handed look at the time and data debacle in HTML5.
A single-serving website expressing the frustration and bewilderment at Hixie’s unilateral decision to drop the time element from HTML.
This is such a great idea: magnetic HTML elements. And now Cameron is sharing the source files so that we can all print our own.
Good design and good markup provide structure to content. Good markup is a fundamental part of good design: beautiful on the inside, beautiful on the outside. HTML and CSS give another venue to provide structure to content in the native language of the web, and learning these guides decisions by surfacing the affordances of the medium.
Insanely in-depth look at how browsers work, right down to the nitty gritty. You’d think there’d be a lot of engineering talk, but actually a lot of it is more about linguistics and language parsing.
A brave attempt to explain the new outline algorithm in HTML (although it inaccurately states that no browsers have support for it—Firefox shipped with it a while back).
You can safely skip the comments: most of them are discouraging, ignorant, and frankly, just plain stupid.
A really nice little primer on getting started with HTML5.
Leonie points to a change in the semantics of the a element in HTML5 that could be very handy for accessible navigation.
A great round-up by Richard of some of the most common semantic pitfalls encountered with HTML5.
Everything you ever needed to know about adding HTML5 audio and video to your site, courtesy of the mighty John Allsopp.
A fascinating examination by Hixie of web technologies that may have technically been “better” than HTML, but still found themselves subsumed into the simpler, more straightforward, good ol’ hypertext markup language.
The follow-on comments are definitely worth a read too.
I agree 100% with Mark’s thoughts on what a Content Management System should and shouldn’t attempt to do.
I think that markup is too important to be left in the hands of the people who make content management systems. They all too often don’t care enough about it, and they can never know the context that you will be using it in, and so in my opinion they shouldn’t be trying to guess.
An excellent explanation from Richard of the bdi element (bi-directional isolate) for handling a mixture of left to right and right to left languages in HTML5.
I agree with Oli’s conclusion:
A handy list of regular expressions that you can use in the new pattern attribute on the input element in HTML5.
Mike takes on the very tricky task of explaining the new outline algorithm—definitely one of the hardest features of HTML5 to explain, in my opinion.
I’m getting behind Oli’s proposal to allow non-quoted footers within blockquotes in HTML. Here’s where I quote the design principles to support his case.
New Mobile Safari stuff in iOS5: position:fixed, overflow:scroll, new input type support, web workers, ECMAScript 5 | David B. Calhoun – Developer Blog
An excellent article from Oli on markup patterns for quotations …though I still think that the cite element can be used for people’s names.
This dovetails nicely with my recent post about the spirit of distributed collaboration. Here’s a great little bit of near-history spelunking from Paul, all about styling new HTML5 elements in pesky older versions of Internet Explorer.
Buy. This. Book.
I mean it.
A good round-up by Jack Osborne of where things currently stand with the hgroup group.