Web standards killed the HTML star(jeffcroft.com)
jeffcroft.com
Web standards killed the HTML star
http://jeffcroft.com/blog/2014/jan/03/web-standards-killed-the-html-star/
21 comments
I strongly agree. CSS is rife with extrinsic complexity—complexity greater than the problem domain required. As often happens with such designs, its pieces don't line up and many simple questions have complicated (or no) answers. It's by far the weakest element of the web stack. I often find myself just writing Javascript to adjust layout instead of bothering to learn the CSS for it.
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. [1]
HTML and Javascript, for all their messiness, have the former quality, while CSS is a case of the latter.
[1] 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.
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. [1]
HTML and Javascript, for all their messiness, have the former quality, while CSS is a case of the latter.
[1] 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.
Thirded.
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.
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.
I agree with you completely but one of the things I always struggle thinking about is what a potential alternate to CSS even looks like. Although there are so many things wrong with it, you can pull off just about any look and feel you want with it. I mean, at least we're not using Swing or handing the decorating off to the OS or something.
In an ideal world, what's the best way to decorate HTML?
In an ideal world, what's the best way to decorate HTML?
I think bootstrap (and similar frameworks) are the closest thing we have. It makes simple tasks like "put these things in a nice grid" or "center this thing" so much easier than if you were using raw CSS.
Bootstrap gets a lot of flak for its styles, but I think its real value is in making layout somewhat sane.
Bootstrap gets a lot of flak for its styles, but I think its real value is in making layout somewhat sane.
I don't think the article said that CSS and HTML do not have their quirks anymore. What is said was that if that is ALL you could do, that isn't enough for a job, which is true enough. Would you have a use for someone who knows all that, but can't actually write any code?
There are lots of people on the web design via graphic design that fit into this category. Of course there is a range of competency in this group, but at the top end you have the sort of people that can do absolutely amazing things with just HTML and CSS. As someone who focuses on backend and can build an acceptable looking front end, I am blown away by a lot of the examples I see on codepen from people who use no javascript at all.
I'd say the one category of people that might have to worry about future jobs is the 'designer with decent but not expert HTML and CSS knowledge'.
Specialization is key in this regard. If you're really, really good with CSS and HTML, you can find decently paying work doing just that. If you don't specialize in that way, you should probably catch up on 'real' programming what with all the developments in front-end development, and you might even get away with rudimentary css knowledge.
We have heaps of people where I work that do exactly that. CSS all day long without any code (or maybe the occasional bit of jQuery). I couldn't think farthing would rather do less, but whatever ;)
> "none of these things can be learned quickly, and they seem to require many months of experience to actually get right consistently in practice."
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.
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.
> That's the same for any language. Especially those that don't just clone the language you already know.
I don't think that's true. Sure, it takes a bit of time to learn a new syntax, a bit more time to learn language-specific concepts. And every language has it's gotchas and quirks. But most languages I've worked with, even javascript ('the good parts'), are ultimately quite consistent and allow you to focus on solving actual problems pretty quickly.
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.
I don't think that's true. Sure, it takes a bit of time to learn a new syntax, a bit more time to learn language-specific concepts. And every language has it's gotchas and quirks. But most languages I've worked with, even javascript ('the good parts'), are ultimately quite consistent and allow you to focus on solving actual problems pretty quickly.
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.
Where do compile-to-CSS languages like SASS or LESS fit into this picture?
I couldn't disagree more with this post. I'm a full-stack engineer, and deal with both the front-end, back-end and server. I've been doing front-end since my career began, so over 13 years now. I've lived through the IE6 days, and I have to say that things are almost as bad now as they were back then. At least IE6 bugs were well documented and we knew how to work around them. Nowadays we work in a fragmented ecosystem where the same operating systems behave differently on different devices (HTML5 video on Android is a prime example).
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.
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.
What you're saying is true, but it's a tautology. It doesn't matter what technology you use, your job will always be "just as bad". As a developer it's your job to push the limits of what you can accomplish until it starts to hurt a little. That will always be true of the web: we'll push what browser capabilities we try to harness all the way to the point where compatibility work really starts to burn.
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 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.
When I read the OP's comment all I could think about was what it would be like writing a decent web app in the bad ol' IE days if it also had to work in most of those crappy symbian flip phone browsers. I agree with you completely. Meeting expectations today is really tough, but the expectations are much higher in most ways.
Indeed. As a contractor I often have to use the latest and greatest because project leads read about it somewhere and designers go wild. Which means that the work is not significantly easier because the goal-posts just moved.
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).
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).
This may be true of front end devs in SF, but not in the agency world. Agencies need really competent HTML coders that can slice up designs into cross browser compatible HTML as quickly as possible. In most cases, elementary knowledge with jQuery suffices, and you'll never need to deal with node, angular, or backbone. When you're making websites for big clients, you have to deal with things like browser compatibility on every version of IE back to 7 (and yes, it is expected that those rounded borders work on IE7 and render the same as in chrome). You need an HTML star to pull that off.
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.
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.
> "When you're making websites for big clients, you have to deal with things like browser compatibility on every version of IE back to 7 (and yes, it is expected that those rounded borders work on IE7 and render the same as in chrome). You need an HTML star to pull that off."
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.
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.
You're right, and I often try to do as you say. But in the end the customer's wishes are the deciding factor for me, and unfortunately they often don't budge despite my argumentation. And I consider myself pretty good at convincing and explaining.
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.
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.
What's particularly interesting is that even though "Web standards" are just another skill every developer/designer needs; they still require significant time to learn.
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.
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.
This could happen in segments of the industry. We see a similar pattern with new just-out-of-school backend devs being put in testing or QA Developer roles for the first few years. I generally thing this is a bad idea, since testing is often more difficult than writing the code itself and requires lots of experience, but that might not apply here if the work of the "paralegal" dev was properly defined (I have no clue how, since it seems the only way to learn these standards is repeated failure and iteration).
If the problem you are solving is gone, you better be the person who solved it and collected the coins.
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.
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.
> HTML/CSS is nothing more than a way to describe the way a page should look like.
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.
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.
Hmm, semantics came from the APIs. Machines understand machines not by interpreting HTML but by special language that is made to be spoken between machines. The web of data has been largely achieved but but the organization of the data flow is taken over by human beings by tightly controlling what machines are talking with each other behind the scenes. HTML has been pushed even further to be a presentation tool rather than the medium for interconnected documents. machines rarely speak HTML these days but they talk with each other much more than before.
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.
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.
That's right. HTML/CSS/JavaScript is just another pile of technology for rendering graphics. There have been many others, and there will be more in the future. Those "web" technologies are useful now because the enabling runtimes (browsers) are in everything from smartphones to toasters.
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.
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.
>Machines understand machines not by interpreting HTML but by special language that is made to be spoken between machines.
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.
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.
> "The HTML/CSS guru should not exist anyway since the designer is supposed to decide how the page should look like,"
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.
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.
> 80% of what made us useful was the way we knew all the quirks and intracries of the browsers. Guess what? Those are all gone.
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.
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.
I worked as a front end dev for a very large company/codebase. Sounds to me like you are writing pretty shoddy CSS and using things you aren't supposed to be using yet. For example Flexbox.
What's shoddy about this?
> -webkit-animation: spin 2s infinite linear;
And please don't presume you know my code or my specifications.
> -webkit-animation: spin 2s infinite linear;
And please don't presume you know my code or my specifications.
This is true, but the time we're not spending compensating for browser inadequacies we're spending working with the new capabilities of html and css.
There's plenty of new features to master to make truly knowing the domain still valuable.
There's plenty of new features to master to make truly knowing the domain still valuable.
This is an excellent point. Most developers I've worked with don't understand the ins and outs of html5
I was glad to see that this wasn't another post about how the nature of the Web let it be overtaken by the iOS App Store.
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.
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.
I really think that people who call themselves web developers / front-end developers though don't actually know any javascript are in for a serious contraction in available work. It really isn't that important for a small business to have their own website vs social media / google places etc. That said, obviously the market for people who make the websites that let ordinary people make websites is growing and growing...
In making HTML/CSS the admittedly convoluted mess that it is, we nevertheless dodged the larger bullet of the Web converting to Flash, XHTML FO and/or PDF. In this way HTML5/CSS is the lesser of evils, since it still has semantic components in a readable non-binary format.
Oh man, is XHTML FO dead yet? Haven't heard that term in years, made me shiver.
It's XSL FO, isn't it? You could use XSLT and FO to render XHTML to some graphical output, but it's not an intrinsic part of XHTML.
EDIT: You could use XSLT and FO to render XHTML to some graphical output if you were totally mental.
EDIT: You could use XSLT and FO to render XHTML to some graphical output if you were totally mental.
The haters should check out this site called "Zen Garden". It totally shows how powerful CSS is - at least on a single, static HTML page.
And I'm pretty sure the approach will scale to multiple, dynamic pages, right?
And I'm pretty sure the approach will scale to multiple, dynamic pages, right?
[deleted]
[deleted]
This is absolutely and wholeheartedly true.
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...
We now have a completely saturated market with people that started with HTML and CSS, with very little knowledge of actual programming. With the emergence of Atwood's law, and everything javascript.. these 'jQuery experts' have little to no relevance in the long term.
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.
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...
We now have a completely saturated market with people that started with HTML and CSS, with very little knowledge of actual programming. With the emergence of Atwood's law, and everything javascript.. these 'jQuery experts' have little to no relevance in the long term.
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.
This is exactly the thought I console myself with when I spend an entire day debugging something obscure- it may suck, but programming being hard is the entire reason I have a well paid job. If it was easy, I wouldn't be useful in any way.
News Flash: Just HTML/CSS has always been commodity work that got paid 50% of what other developers made (if that). Most old school front end people knew a bit of Javascript also but higher powered devs never did javascript because just a few years ago not much javascript was even needed. The solution to js quirks was to avoid it like the plague so there was a more natural distinction between backend/frontend. Now since there is plenty of real coding to be done in the browser, there is no reason for this new breed of js developers to not do the markup and css as well. And since really this new breed of js devs is just people who were or would have been the backend guys we now refer to them as "full stack" devs.
browser quirks and deficiencies still exist they have just moved to the mobile platform. Android is the new IE
I think if you are a front end designer and don't know javascript, you will become irrelevant very quickly.
I'm a HTML/CSS guru, with an intermediate understanding of javascript. I work for a massive tech company and I'm the only ones with these skills in my office. I've been doing it for about a year and most of the developers I work with haven't worked with someone like me before but they really enjoy it. The way I have differentiated my skill set is by having a background in visual design and ux. In any decent app or website, there will always be a need for someone to translate the actual visual design into front end code. Backend developers either don't know how to do this or aren't interested in doing it. Therefore, I think there will always be a place for people with my skill set. However, I am working on my javascript skills to make myself more valuable. I do have a good understanding of programming concepts though (eg: loops, mvc, some database stuff, etc...). This allows me to talk to the backend guys, and even though I don't know exactly how something works, I understand enough to get my point across. That is where the real value for the other devs comes from. Someone that understands the principals but specializes in something they can't do or care about.
You are the only guy that does HTML and CSS (with an implicit: to a sufficiently high quality).
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)?
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)?
You make a good point. There isn't really anywhere to go from my current position if I don't pick up more javascript. However, I'm currently happy in my role.
This subject made me remember a famous quote by Alan Kay:
"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."
"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."
What shocks me is that the quote is from 2012:
http://www.drdobbs.com/architecture-and-design/interview-wit...
You have to be brave to criticize the web founders nowadays (personally, I like Berners-Lee and company).
You have to be brave to criticize the web founders nowadays (personally, I like Berners-Lee and company).
Browsers are full of quirks, but today those quirks go beyond layout/rendering.
Another niche for the html/css guru that is still valid is the ability to really customize something like twitter bootstrap. Anyone can throw together a site using bootstrap but actually wrangling it to look unique is another challenge in itself. You really need to understand css inheritence and how use the real power of the framework. Not to mention using 3rd party bootstrap plugins and customizing their look and feel to fit your theme. The ability to skin any framework or cms that has templating is a valuable skill to have.
Things like the differences between padding and margin, things like negative margins, CSS precedence, !important, box models, floats, clearing floats, vertical centering, and what kinds of layouts can be done with CSS versus which ones simply require JavaScript due to CSS's bizarre deficiencies at even the most trivial things -- none of these things can be learned quickly, and they seem to require many months of experience to actually get right consistently in practice. And then there are the differing philosophies on how to get CSS not to turn into spaghetti in practice, with things like "object-oriented" CSS and tools like LESS/SASS.
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.