Since I'm not a GMail user, I didn't know about the new button design that Google implemented until I saw a reference to this post by their designer. As an exercise in HTML and CSS trickery, it's pretty impressive. As a look into the sausage-making for serious web application design, it fills me with abject horror.
I've been writing HTML code, off and on, for more than ten years now, and I have hated every minute of it. I don't claim to be very good at it, of course, so maybe that's the problem. But it's always struck me as a technology stuck awkwardly between two worlds. On the one hand, a platform- and display-agnostic representation of textual content. On the other, the desire to build attractive, well-designed presentation layouts, including application interfaces. These are not, I think, entirely compatible with each other. Google's new buttons illustrate that tension, as they torturously beat text layout elements into paintbrushes (ones that will display across all the various browser quirks, no less).
The interesting thing about computing trends, though, is that they're cyclical. Displaying information through a clumsy "semantic" thin client/fat server relationship? We've been there, and then most of us ran away to something better as fast as we possibly could. It's only a matter of time, I suspect, before something replaces HTML for doing UI (while maintaining the lessons we've learned about REST and open communication standards), and at that point we will look back in horror, and wonder how we managed for so long.
If you want to see how this is going to go, consider Twitter. All the basic functionality is available from twitter.com, but almost no-one I know uses that if they can help it. Invariably, you get a better experience from one of the clients (I use Twhirl and TinyTwitter for desktop and mobile, respectively). They're more reponsive, they take advantage of the native platform, and they don't require a browser to be open all day long. The communication with the server is still standard Web 2.0, but Twitter developers have largely abandoned the idea that they need to muck around with HTML, and everyone's better for it.
For the last few years, tech pundits have repeatedly predicted that the browser will take over the space currently occupied by the operating system: via solutions like Google Gears or Prism, or a custom shell like gOS, you'll run everything over the network via HTML/JS/CSS. It's failed to happen so far, and it'll continue to fail. The closer the browser comes to "real" applications, as with GMail, the more its shortcomings become apparent, and the more developers have to rebuild basic functionality in a system that's just not meant to handle it.
If anything, the future is in the middle ground: a heavyweight, native or bytecode platform that can be run in a distributed fashion over the web, splitting application programming back out from the browser and providing a real API for developers to leverage. Such a format addresses the weaknesses of modern binary applications, such as heavy installation and slow startup, without abandoning the advantages that a real operating system provides. AIR, Silverlight, and XUL (as well as Java, to a much lesser extent) are possibilities that could achieve this. HTML, if we're lucky, is not.