And just stupid things like not being able to define "position: relative" on a <td> so that you can absolutely position things within it, the way you can within a <div>. It may not be a browser quirk, it's just a CSS quirk, but I don't really care -- there are TONS of stupid "quirks" in CSS to keep people in their jobs still. Browsers may not suck any more, but CSS still sure does.
Edit: CSS also seems to me the least webby element of the web stack, in the way that Adam Bosworth brilliantly described the web:
That software which is flexible, simple, sloppy, tolerant, and altogether forgiving of human foibles and weaknesses turns out to be actually the most steel-cored, able to survive and grow, while that software which is demanding, abstract, rich but systematized, turns out to collapse in on itself in a slow and grim implosion. 
 http://adambosworth.net/2004/11/18/iscoc04-talk/ - one of the most insightful things I've read about the web and about software in general.
I'm likely a textbook CSS "hater" according to wisty's post in this thread.
But I don't hate CSS because I don't believe it is powerful, rather because the amount of concepts and context-specific modalities you have to understand to do things that would be trivial with any other layout framework (like vertically center one thing in another thing) is absolutely bonkers.
CSS gurus will often knee-jerk defend it from people who say things like that, but objective third-parties need only read through CSS questions on a site like stackoverflow to see a mountain of questions where someone is trying to accomplish something that is conceptually quite simple and they are faced with page after page of jsfiddle "answer" links that don't actually even fix the problem they were having because their layout implementation was using a different display model on the divs in question (or whatever other random context-specific thing that makes the actual solution non-universal).
Being powerful is nice, and CSS is powerful, but there's something to be said about keeping the simple things simple and CSS fails massively on that.
In an ideal world, what's the best way to decorate HTML?
Bootstrap gets a lot of flak for its styles, but I think its real value is in making layout somewhat sane.
That's the same for any language. Especially those that don't just clone the language you already know.
CSS just happens to be the one that takes a structured document and styles it for presentation. Like Latex, like XSL-FO, troff, PostScript. Relatively, CSS is easier to pick up and run with.
CSS, on the other hand, has tons of quirks that lead to issues that require either annoying trial-and-error to fix, after-the-fact bugfixing for particular devices or browsers, or a deep knowledge of the logic involved.
Back in high school, I loved mathematics and physics, because difficult things felt 'fair'. And figuring them out felt satisfying. On the other hand, I disliked biology and to a lesser degree chemistry, because it seemed like there were gotchas and quirks everywhere that required rote memorization, not understanding. Or at least not at a high school level.
I've only met a handful of people who seemed to really know the fundamentals of css. These people read the specs, but also played a role in the development of new css features. I think there's still a market for 'true' css/html experts. Knowing the exact ins and outs of html and css across browsers and platforms is arcane knowledge, and if you know this you might get away with not being much of a programmer.
It's just really boring.
If you don't experience browser-dependent bugs or quirky undefined behaviour, then you're only doing trivial stuff.
If you're just building a blog you won't bump into them of course, but in a way with all the new API's that constantly are being added, it's getting more difficult to work your way around the minefield of problems. It doesn't help that browsers are extremely lagging in fixing well-reported, well-reproducable bugs.
A handful of examples off the top of my head: there's the bug where Chrome taxes the GPU 100% whenever a CSS animation happens (draining battery for a rotating font-awesome icon), there's the unpredictable nondeterministic behaviour of Safari's Flash blocker, there's the bug where GPU layers get different AA applied and whose width is calculated differently causing the layout to jump and the fonts to thinnen whenever an animation happens, there's the bug where Chrome's background images disappear, there's the bug where an inset box-shadow disappears when you're using mask at the same time, there's the difference between Firefox' flexbox behaviour and all the other browsers, there's the only partial LocalStorage API support in certain browsers, etc...
Those are a few of the handful I bumped into the last 6 months and I'm not even a webdesigner.
> -webkit-animation: spin 2s infinite linear;
And please don't presume you know my code or my specifications.
There are all kinds of odd bugs when dealing with mobile browsers, and even on desktop canvas and CSS3 animations don't always behave consistently depending on how you are using them.
Just an example of the most obscure of bugs that you might have to deal with: if you try to translate the position using CSS3 of an object that contains Flash in Firefox, the flash object will disappear entirely. Good luck working around that one.
But if you look at things in absolute terms, what you're saying is crazy. I can build, in a week, something that is better in every way than Gmail was when it was originally released, that works on a larger proportion of devices. That's progress
Your subjective experience might be that you still work in the weeds but that's because you're insanely more productive for the same effort than you were 8 years ago.
But for smaller clients that I have full control over, I usually take a subset of functionality that I know is stable and consistent by now, and I only go for bleeding-edge stuff if the budget allows it (because, of course, it is fun to play with shiny new stuff).
The death of the "HTML star" is a good thing, and one that was bound to happen given how much of HTML/CSS can be abstracted through higher-level interfaces, libraries, and frameworks (such as Bootstrap). The next thing I'd like to see die is HTML/CSS starter courses aimed at those who want to "learn to code"
Not because HTML/CSS are useless skills, regardless of what the OP says, but because they are, on their own, pretty much useless. How much good is your memorization of HTML5 tags going to do if you can't set up Apache or S3 static webhost, and are relegated to using a WYSIWYG editor? Hell, I know how to set up my own web stack and I almost never ever go beyond the markup that oldschool Markdown is limited to...and that's been a great thing.
But the problem is that HTML/CSS can be tricky to learn and early on, they give the impression of how fickle and cruelly arbitrary "coding" can be...whereas with programming and scripting languages...yes, you'll get that a bit with certain stack traces and error messages...but at least with programming, you can actually do something, including using programming to quickly and easily build and maintain a static site (such as Jekyll, with a little Ruby knowledge).
I've known a few people who've taken semester long HTML/CSS courses as adults (i.e. they were professionals in non-web-dev fields)...none of them, to my knowledge, ever used that knowledge again after their classes.
That said, I enjoyed learning both HTML and CSS on my own time. HTML taught me the idea of structure through markup, and CSS (or rather, the amazing CSS Zen Garden) taught me the pragmatic concerns involving separation between content and display. It still befuddles and antagonizes me that people can't logically separate the two...but perhaps the difference is that I learned how to make webpages without CSS, and then with CSS...and learned the valuable lessons in doing so.
EDIT: You could use XSLT and FO to render XHTML to some graphical output if you were totally mental.
I can see this going somewhere like law, where you're expected to work as a paralegal for a few years doing all the boring stuff, before you're allowed up to the echelons of people actually get things done.
"The Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made. When was the last time a technology with a scale like that was so error-free? The Web, in comparison, is a joke. The Web was done by amateurs."
You have to be brave to criticize the web founders nowadays (personally, I like Berners-Lee and company).
I hire technical staff for a fairly large agency, and I can tell you right away that the climate is getting a lot more difficult.
This article touches on the same progression from another angle; http://www.daedtech.com/how-developers-stop-learning-rise-of...
Unless FEDs actually understand programming, and unless they actually apply that knowledge in their work, they are being rapidly commoditized.
This is a real issue for the career future of many FEDs, but very few seem to realize it.
If the existence of HTML/CSS guru depends on the bugs/problems of the browsers, they had plenty of time to see it coming. HTML/CSS is nothing more than a way to describe the way a page should look like. The HTML/CSS guru should not exist anyway since the designer is supposed to decide how the page should look like, so finally HTML/CSS is spoken by the right person without the translator, that is why HTML/CSS is just another yes no question.
That completely misses the viewpoint of a standards guru (for HTML). HTML should describe semantics, meaning. No, I can't tell you what gives it meaning, even after 12 years of arguing about it...
The hours I've poured into debating "What is the best markup structure to mark up 'X'" (where there's no obvious HTML equivalent) is embarrassing. It mattered because as it had meaning it had to be right. Never mind that nothing read or interpreted the meaning so carefully inserted. It was about being part of a bigger movement and doing the right thing.
I used to refuse to do things for clients that weren't semantic, which blurred the line. This would now be laughable. Yet I feel empty on the inside in the 'new world' - if HTML and CSS are just the presentation framework, then nothing has the purpose or can support the meaning that writing good HTML used to bring.
It's the end of an era, and I would retire from web development if I could find another industry that brought the same challenges and successes as online in 2003. I've diversified and become a full-stack developer, but it's too large to maintain mastery of.
At the end of the day, HTML is just another text file that tells the browser how to display some content to the human beings while machines exchange data by API.
The skill the author ought to master isn't the trick pony of HTML circa 2003, but rather how to present information to humans. That said, I'm sure the self-described gurus of buggy whip grip design probably were annoyed by the obsolescence of their hard-won knowledge too (or at least until they started working on driving wheels and road bikes).
Today, the debate is between the various native toolkits on mobile devices and HTML5. The winner will have the most engaging apps as measured by the success of their owners' companies. Maybe iOS 7 will win. Maybe Android. Maybe Microsoft's windowing kit in its next OS will win.
That special language is called html, that's the point.
>At the end of the day, HTML is just another text file that tells the browser how to display some content to the human
Just because you use it for only such tasks, doesn't mean the rest of the world does too. Plenty of us use it as intended.
It's this idea that leads to a whole host of trouble. It's the implicit statement that HTML and CSS is just about a visual presentation. A designer (in the typical "I'm a web designer" mould) is singularly unqualified to deliver an accessible experience. Because they cannot let go of the visual aspects, and focus on the non-visual elements. And a lot of that is because Photoshop doesn't support concepts like text-equivalents to images, and tests for whether the page reads correctly in a non visual way.
And then there's interaction design. It's rare to see a web designer have a solid grasp of interaction. Again, because Photoshop doesn't support these concepts.
A static visual representation isn't enough. And so the output from designers with some HTML experience is not enough.
But you're right. The HTML/CSS guru should not exist. But designers are not amenable enough to take up those reins at a high enough quality. And programmers and engineers also seem incapable of generating high quality markup and CSS.
HTML/CSS is where the technical meets design, and neither specialists seems to comfortably handle this intersection. So integration is a pain point.
What does your career path look like at that company? Do you actually have a future at that company?
Or have you reached the point where you are perfectly happy doing HTML and CSS until you retire (assuming that's even possible)?
Many of the frontend dev's I know graduated with art degrees and have little interest in backend or architectural coding. Their career path tends to lead more towards design or UX.
Or a diligent resetter of expectations. And HTML star should be able to effectively argue against that sort of requirement. Otherwise, what are you paying him for? Markup monkeys are dime a dozen, and there's an A List Apart Sliding Doors article those code monkeys can just follow.
I'd expect more from an HTML star than just knowing how we did rounded corners before border-radius. I'd expect leadership, and standing for correctness.
In both Yahoo and Amazon we succeeded in pushing back against rounded corners in browsers that don't support border-radius. Because that's the pragmatic thing to do.
Browser compatibility doesn't mean pixel-exact layouts, it means that the core objectives of the site are functioning in a customer-supportive way.
Rarely do customers bring up the site in two browsers side-by-side and decide not to buy because the website wasn't identical in both.
If I were a full-time employee, I would fight hard, but I feel that my role as a freelancer is to inform, and then do as the client asks anyways, within reason. Rounded corners on ie7 is within reason, as far as I'm concerned.
Obviously if a client keeps insisting on all sorts of ridiculous things, my enjoyment of the project plummets and I might look elsewhere for projects that I actually enjoy. But that's only because I can afford to say no in the current economy.
There's plenty of new features to master to make truly knowing the domain still valuable.
And I'm pretty sure the approach will scale to multiple, dynamic pages, right?