This is the rarely-seen hour-long version of my Resilience talk. It’s the director’s cut, if you will, featuring an Arthur C. Clarke sub-plot that goes from the telegraph to the World Wide Web to the space elevator.
Wednesday, February 7th, 2018
Tuesday, May 17th, 2016
Marvellous insights from Mark on how the robustness principle can and should be applied to styeguides and pattern libraries (‘sfunny—I was talking about Postel’s Law just this morning at An Event Apart in Boston).
Being liberal in accepting things into the system, and being liberal about how you go about that, ensures you don’t police the system. You collaborate on it.
So, what about the output? Remember: be ’conservative in what you do’. For a design system, this means your output of the system – guidelines, principles, design patterns, code, etc etc. – needs to be clear, unambiguous, and understandable.
Thursday, July 9th, 2015
The full text of Jason’s great talk at this year’s CSS Summit. It’s a great read, clearing up many of the misunderstandings around progressive enhancement and showing some practical examples of progressive enhancement working at each level of the web’s technology stack
Friday, April 24th, 2015
And that’s why you always use progressive enhancement!
Thursday, April 23rd, 2015
A profile of a legend.
Sunday, April 12th, 2015
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.
Monday, May 30th, 2011
Hashbangs. Yes, again. This is important, dammit!
There seems to be a general concensus that hashbang URLs are bad. Even those defending the practice portray them as a necessary evil. That is, once a better solution is viable—like the HTML5 History API—then there will no longer be any need for
#! in URLs. I’m certain that it’s a matter of when, not if Twitter switches over.
But even then, that won’t be the end of the story.
There’s no such thing as a temporary fix when it comes to URLs. If you introduce a change to your URL scheme you are stuck with it for the forseeable future. You may internally change your links to fit your new URL scheme but you have no control over the rest of the web that links to your content.
Therein lies the rub. Even if—nay when—Twitter switch over to proper URLs, there will still be many, many blog posts and other documents linking to individual tweets …and each of those links will contain
#!. That means that Twitter must make sure that their home page maintains a client-side routing mechanism for inbound hashbang links (remember, the server sees nothing after the
Sunday, May 29th, 2011
A superb post by Dan on the bigger picture of what’s wrong with hashbang URLs. Well written and well reasoned.
Thursday, February 10th, 2011
Tim Bray calmly explains why hash-bang URLs are a very bad idea.
This is what we call “tight coupling” and I thought that anyone with a Computer Science degree ought to have been taught to avoid it.
Wednesday, February 9th, 2011
I wrote a little while back about my feelings on hash-bang URLs:
I feel so disappointed and sad when I see previously-robust URLs swapped out for the fragile #! fragment identifiers. I find it hard to articulate my sadness…
It would appear that hash-bang usage is on the rise, despite the fact that it was never intended as a long-term solution. Instead, the pattern (or anti-pattern) was intended as a last resort for crawling Ajax-obfuscated content:
So the #! URL syntax was especially geared for sites that got the fundamental web development best practices horribly wrong, and gave them a lifeline to getting their content seen by Googlebot.
I’m always surprised when I come across as site that deliberately chooses to make its content harder to access.
This is no accident. The web stack is rooted in Postel’s law. If you serve an HTML document to a browser, and that document contains some tags or attributes that the browser doesn’t understand, the browser will simply ignore them and render the document as best it can. If you supply a style sheet that contains a selector or rule that the browser doesn’t recognise, it will simply pass it over and continue rendering.
That’s why I’m so surprised that any front-end engineer would knowingly choose to swap out a solid declarative foundation like HTML for a more brittle scripting language. Or, as Simon put it:
Gizmodo launches redesign, is no longer a website (try visiting with JS disabled): http://gizmodo.com/