HTML5 Differences from HTML4
I just noticed that I’m mentioned in the acknowledgements of this most handy of W3C documents. This pleases me disproportionately.
I just noticed that I’m mentioned in the acknowledgements of this most handy of W3C documents. This pleases me disproportionately.
A handy starting point for creating a front-end styleguide: a single document of HTML elements.
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
A superb article by Josh on planning for progressive enhancement—clearly laid out and carefully explained.
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.
A great presentation on web components by Marcy, with an emphasis on keeping them accessible.
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.
This is hilarious …for about two dozen people.
For everyone else, it’s as opaque as the rest of the standardisation process.
HTML5 is now a W3C recommendation. Here’s what a bunch of people—myself included—have to say about that.
The Android vs. iOS debate is one hinges around whether you think it makes more sense to target a (perceived) larger market, or target one that the technorati favor. But why choose? Building a good responsive web app has a series of benefits, the primary one being that you target users on every platform with one app. Every user. Every platform. All the time. Release whenever you want. A/B test with ease. Go, go go.
Léonie gives a great, clear description of how screen readers switch modes as they traverse the DOM snapshot.
A bit of web history reacted by Paravel: the Microsoft homepage from 1994. View source to see some ooooold-school markup.
The challenges of maintaining a living breathing front-end style guide for an always-evolving product (the Lonely Planet website in this case).
Here’s a dystopian vision of the web in ten years time, where professional developers are the only people able to publish on the web.
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.
Here’s the chat I had with Jen and Doug about the prospect of DRM in browsers.
Today, a basic HTML/CSS site seems almost passé. But why? Is it because our new tools are so significantly better, or because we’ve gone overboard complicating simple things?
He’s right, y’know.
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.
Great suggestions from Dave for podcasters keen on allowing easier sharing.
Oh, how I wish Soundcloud would do this and be less of an audio roach motel!
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!
John shares his concerns about the increasing complexity involved in developing for the web.
Some excellent practical advice on progressive enhancement.
I agree completely with the sentiment of this article (although the title is perhaps a bit overblown): you shouldn’t need a separate API—that’s what you’re existing URL structure should be.
I’m not entirely sure that content negotiation is the best way to go when it comes to serving up different representations: there’s a real value in being able to paste a URL into a browser window to get back a JSON or XML representation of a resource.
But this is spot-on about the ludicrous over-engineered complexity of most APIs. It’s ridiculous that I can enter a URL into a browser window to get an HTML representation of my latest tweets, but I have to sign up for an API key and jump through OAuth hoops, and agree to display the results in a specific way if I want to get a JSON representation of the same content. Ludicrous!
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.
This is the talk I gave at the border:none event in Nuremberg last month. I really enjoyed it. This was a chance to gather together some thoughts I’ve been mulling over for a while about how we approach front-end development today …and tomorrow.
Warning: it does get quite ranty towards the end.
Also: it is only now that the video is released that I see I spent the entire talk looking like a dork with a loop of wire sticking out of the back of my head.
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.
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.
Henri gives an overview of the DRM-style encryption proposed for HTML. It’s a very balanced unbiased description, but if you have the slightest concern about security, sentences like this should give you the heebie-jeebies:
Once you get past the cheesy intro music, there are some gems from Robert Cailliau in here.
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 terrific long-zoom look at web technologies, pointing out that the snobbishness towards declarative languages is a classic example of missing out on the disruptive power of truly innovative ideas …much like the initial dismissive attitude towards the web itself.
A very handy starting point for creating a front-end style guide.
I kind of love the interaction design of this site.
I love this. I love this sooooo much! The perfect reminder of what makes the web so bloody great:
You and I have been able to connect because I wrote this and you’re reading it. That’s the web. Despite our different locations, devices, and time-zones we can connect here, on a simple HTML page.
Dr Harry Halpin writing in the Guardian about the crucial crossroads that we have reached with the very real possibility of DRM mechanisms becoming encoded within HTML:
Most of us are simply happy to launch our browsers and surf the web without a second thought as to how the standards like HTML are created. These standards are in the hands of a fairly small set of standards bodies that have in general acted as responsible stewards for the last few years. The issue of DRM in HTML may be the turning point where all sorts of organisations and users are going to stop taking the open web for granted.
My presentation from the Industry conference in Newcastle a little while back, when I stepped in for John Allsopp to deliver the closing talk.
A great post by Stuart on the prospect of DRM-by-any-other-name in HTML.
The argument has been made that if the web doesn’t embrace this stuff, people won’t stop watching videos: they’ll just go somewhere other than the web to get them, and that is a correct argument. But what is the point in bringing people to the web to watch their videos, if in order to do so the web becomes platform-specific and unopen and balkanised?
Josh has been teaching HTML and CSS schoolkids. I love the pages that they’ve made. I really mean it. I genuinely think these are wonderful!
Want to style those new HTML5 input types? I hope you like vendor prefixes.
A good history lesson in rendering engines: KHTML, WebKit, and now, Blink.
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
A handy one-stop-shop for tips on improving front-end performance.
Chris takes a look at all the different ways you can use SVG today.
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…
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.
A really nice explanation by Todd Kloots of Twitter’s use of progressive enhancement with Ajax and the HTML5 History API. There’s even a shout for Hijax in there.
Andrea looks at support for HTML5 input types in IE10 Mobile.
A worrying look at how modern web developers approach accessibility. In short, they don’t.
I had a lot of fun chatting with Chris and Dave on the Shop Talk Show. It is now available for your listening and huffduffing pleasure.
James Craig is a mensch. This is how you give feedback to a working group.
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.
Bruce writes about a worrying trend in standards work:
Tossing a specification that you’ve written in-house, in secret and already implemented onto a table at W3C, saying “here, standardise this” as you saunter past isn’t a Get Out of Jail Free card for proprietary misdemeanours. And it isn’t standardisation.
Here’s a brainbuster for ya: a single file that renders both as HTML and as a JPEG. As an HTML page, it even contains an img element with a src of …itself!
Compare the “view source” output with the generated source output to see it’s being interpreted.
This is a well-reasoned, thoughtful article on avoiding class names in CSS …but I don’t agree with it. That said, perhaps there’s a reasonable middle ground to be found between this extreme stance and the opposite (but in some ways just as extreme) stance of OOCSS.
Some good practical advice on improving performance. This should all be familiar to you, but it’s always worth repeating.
A well thought-out evaluation on responsive images from Bridget.
Have you thought “There must be a good reason for the blink element.” Well, read on.
An oldie but a goodie: Clay Shirky looks at the design principles underlying HTML in order to figure out what made it so successful. Even though this is fourteen years old, there are plenty of still-relevant insights here.
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.
A look at the new pseudo-classes in CSS3 that go hand-in-hand with the form enhancements introduced in HTML5.
The slides from Chris’s presentation on the known unknowns of the web.
Richard gives the lowdown on the new translate attribute in HTML.
A great pattern library from Dan.
A superb rallying cry from Mandy on the importance of markup literacy for professionals publishing on the web: writers, journalists, and most importantly, editors.
This helps to clarify the difference between native semantics and ARIA additions.
Some future-friendly musings on mobile from Mozilla and Yahoo.
Here’s a geek advent calendar I missed. There are some great CSS techniques here.
An in-depth look at browser polyfills: what they are, how they work, and how you can make your own.
Put this one on speed dial.
It’s responsive. It looks great. It’s using HTML5 structural elements and microformats.
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 fun platform game with a twist.
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.
The HTML5 doctors are hosting a copy Mark Pilgrim’s Dive Into HTML5 at http://diveinto.html5doctor.com/ and they plan to keep it updated via Github.
This presentation from Lea contains some CSS gems (and it’s all delivered in HTML).