I agree with this. I don't believe 80 would fail if he reconsidered his metrics.
To pinpoint one of his major gripes - I've moved further "back" down the stack since, but when I was doing strictly front-end I had to make a fully accessible page for some clients, but not others. If anything this post gets me aware that portfolio content is also judged for accessibility, so it provided me that benefit should I take on front-end projects in the future. Some may call it lazy, but I tend to focus on "bigger picture" accessibility issues such as contrast and font scaling.
Also with clearfix - many times its actually abused and painted on every element including ones that don't need to clear its children. It's also not the only way to solve the problem - soon display: flow-root will be adopted across browsers.
I respectfully disagree. I'd much prefer to understand the real technologies that run the web -- HTML, CSS, HTTP, and so on -- and then use tools and build abstractions on top when it's useful.
Starting with some specific framework or tool set inevitably limits what you can achieve. Surely the recent emphasis on frameworks over fundamentals has been a major contributor to the Web full of bland, practically identical sites that we see today.
A lot of these objections to abstraction sound like the objections to abstraction that we had back when we first invented interpreters and compilers. Are you sure that you want to be objecting to abstraction itself, rather than to our current, potentially inferior, implementations of abstractions?
I'm not objecting to abstractions at all. I'm just advocating understanding the fundamentals first.
I want to use abstractions and tools where they offer an additional benefit, but without being limited to whatever some predetermined choice of tools or abstractions can do.
>Surely the recent emphasis on frameworks over fundamentals has been a major contributor to the Web full of bland, practically identical sites that we see today.
It used to be mostly plaintext and basic colors with no responsiveness, under construction gifs, basic images, and flashing text. Before that, just text. We're still learning as an industry. Web technology has not (and may never) settled like the hardware in your toolbox.
Those frameworks are geared for productivity, not possibility. Productivity is where the money is.
I think you overlooked about a decade where we'd moved well beyond slightly annotated text but hadn't yet entered the era of framework dominance. The Web was a smaller place then, but IMHO a much more interesting one in terms of trying out different designs and interaction styles.
As for productivity vs. possibility, I certainly don't dispute that productivity is one place where the money is[1]. However, that doesn't mean there isn't also room for innovation, and it certainly doesn't mean there's no money in doing things better than what you can achieve with Bootstrap, Angular, and a couple of junior developers who don't know much else. In an increasingly monotone and commoditised technology field, more interesting and/or effective presentation can certainly be a USP.
[1] I might question how sustainable that productivity proves to be over the longer term with many framework-heavy projects, but that's a separate issue and probably not worth getting distracted here.
I think you missed the point of the post you're replying to. What's the reason that you feel that you want to understand the "real technologies" that run the web? So that you can build better apps with those technologies, right?
So, what you really want to do is just build some apps, not learn CSS. See the difference?
If we had been talking about means vs. ends, I would agree.
However, we were talking about knowing HTML and CSS vs. knowing abstractions built on top of them. In that context I didn't interpret the post I replied to the same way that you did.
The person you were replying to did emphasized "wants to" vs "have to" though - so I think they were trying to insert the point about means vs ends. Anyway, whoever was trying to make that point - I think it's been made (however painfully).
I find bland, practically identical sites to be the most useful sites. The design gets out of the way and puts the important thing - the content - front and center.
I remember someone on here scoffing at Googles main page on an article on design. It seemed to have bypassed him that it was designed for usability not shiny-shiny design.
I want to understand better, but its difficult to find intermediate resources. Everything is either beginner stuff, or way to complex and over my head. (I am a back end dev, so generally don't have loads of time to spend on front end stuff).
Do you think any of those things are difficult to learn? You certainly don't seem to think so. It's like you're looking for reasons to throw up your hands and not hire anyone.
At 80 people it might start being the time to question whether its really everyone else thats unskilled or your approach to evaluation is wrong.
Asking a pop quiz of arbitrary tools / techniques that you happen to have remember really isn't a good way to evaluate if someone is a good developer. I am a good developer and I only just remember what clearfix is, I most certainly couldnt explain how it works.
Totally agree. I see front end job descriptions asking for understanding of Java and .Net but no mentioning of JS, CSS or any HTML. There could be easily a miscommunication of misunderstanding what the company want. Not saying the job description used here is wrong, just an example of miscommunication.
10 points for who can name the movie that has the quote...
"Well, you told me I have a plethora. And I just would like to know if you know what a plethora is. I would not like to think that a person would tell someone he has a plethora, and then find out that that person has no idea what it means to have a plethora".
In my experience job postings like that focus solely on JavaScript and whatever tools the company uses—HTML/CSS is usually implied, no one has ever asked me about it.
Agreed. I understand missing accessibility (either you have ARIA or you don't), but what does "solid markup skills" mean? The differences between many tags is just user agent stylesheet defaults. If I wanted to be extra crazy, I could build a website using <div> alone. Or maybe I am just a bad developer.
It matters for accessibility. Marking up headers as headers, lists as lists, etc. is valuable for people using assistive technology like screen readers.
If this post were phrased as "web developers don't know accessibility" it would be obviously true and uncontroversial. Unfortunately.
Then my scraper that reads headlines on your website with `//(h1|h2|h3)` will not work. And I will not be able to read and linearize your tabular data. And plenty of other things. (Things you probably do not care about.)
Oh, and you website will have no links (the `href` attribute of `<a>` is not simulable via CSS).
The thing is, most developers aren't targeting your scraper. At most they're targeting Google's, which can handle all sorts of whacky and not very semantic markup - and glean a decent amount of semantic structure from it.
You can do some hacky stuff with onClick listeners for links, especially if its a single page. That said, I do not do this. But I don't think I use much beyond div, span, a, ul, li, table (and friends), form (and crew), h1-6, script, body, head, and html. I know there are more HTML tags, but I rarely use them. They are all pretty self explanatory, and I have hard time believing the author looked at 80 pages and everyone used the wrong tags.
I'd be worried about both! If you have to clear a float, you can do it even more cleanly in CSS by using a psuedo element.
The old trick was to set `overflow: hidden` on the element containing floated items so it would always expand to contain it - but then things like box-shadows get cut off by the containing element. To get around this, you can use an `:after` pseudo-element on the element that contains the float items. This comes after the last floated item and automatically clear the float without needing `overflow: hidden`.
The advantage of clearing a float this way over sticking `<div style=clear:both></div>` or a `.clearfix` class in your HTML is that when doing responsive design, my method keeps the clear in your CSS (and possibly only one @media query). With a `<div>` or class in your HTML you have to deal with that element at all widths - now do you have to specifically override your `.clearfix` class inside a @media query when doing responsive styles? How intuitive is that?
If I interviewed anything but a junior candidate and they said this I'd immediately dismiss them. Sure, flexbox can solve most of the problems, but flexbox isn't always an option. Any candidate worth their grain of salt would know this regardless of whether or not they knew exactly how clearfixes work. I'd much rather them tell me they knew the purpose, but didn't exactly know how they worked than immediately dismiss it.
When isn't it? If you're developing for old (now unsupported) versions of Internet Explorer I'm not sure they'd be bothered about being turned down (unless they knew about that when applying). Just because something was done some way once doesn't make it right, and putting emphasis on 'clearing float' questions would show your company use old, bad practices.
I wouldn't dismiss a candidate for not knowing how a clearfix works. What's important is they understand positioning and layout and how things tend to fit together. I'd reasonably be able to extract this information from them. Asking about clearfixes is one of many ways I'd go about picking their brain.
What I would dismiss them for, however, is the cocky attitude that they never need to bother learning any "old, bad practices." I'd dismiss them for thinking they are "above" working for a company that supports technology that was released just 4 years ago. Further, I'd dismiss them for the attitude that their solution solves all the problems without considering potential drawbacks. These are all huge red flags that show they may technically be knowledgable, but are very difficult to work with. Not someone I want on my team.
"...is the cocky attitude that they never need to bother learning any "old, bad practices." - so before learning ES6 everyone should learn how to use inline onclick events, alerting to debug etc otherwise they're "cocky"?
"..technology that was released just 4 years ago" - if you haven't been keeping up with the news on IE10 then... yeah
"I'd dismiss them for the attitude that their solution solves all the problems without considering potential drawbacks." - no one said there weren't any drawbacks, just when compared with old bad-practice hacks.
"but are very difficult to work with. Not someone I want on my team." - it sounds like the kind of people who're using react would be sad about that.
This post is evidently about junior developers, just because something is old/established doesn't make it right or that it shouldn't be questioned, because there's usually a better way.
Last time i checked, IE9+ are still supported browsers. Of which, IE9 has no support for Flexbox and IE10+, only have partial support.
(Not counting Edge on those stats as it is after all an entirely new browser).
"At the end of 2015, the combined market share for IE8 (8.95 percent), IE9 (6.67 percent), and IE10 (4.18 percent) was 19.80 percent,"
Sure, use flexbox exclusively if you want to push away nearly 20% of visitors. Also notice how the older of those browsers has the highest single percentage of use, and reflect on what that might mean about how likely those users are to upgrade.
I prefer the more customer-centric method of looking at what browsers my customers use and supporting them, rather than the more developer-centric view of "X is hard, I don't want to do X anymore and it's no longer supported anyway so there!".
By all means keep an eye on the browser usage for your audience and drop active support for older browsers once they fall below a certain percent, but don't take another company's actions as a license to screw over your (hopefully paying) customers.
That's % of desktop users (desktop use itself is declining rapidly - I don't know anyone non-tech who uses a PC/Laptop and most devs should be mobile/tablet-first now). Also that was before the big "please upgrade" message Microsoft send out to everyone using IE8/9/10.
If it was purely about numbers, I'd attempt to support to Opera Mini and it's 300 million users. But I don't, and I've never met anyone who does, yet some people bring up IE10 support on a React-driven, Mobile-first web app to appease managers who have always wanted support for older versions of IE "just because". Unless the clients are government/big bank I can't really see any justification for supporting them (and no one supports IE8 - even though it has double the usage IE10 has).
Imho, clearfix as a solution to a problem that existed before CSS3, when people used the `float` role to align things in a row -- when time came to stop the alignment behavior, you applied a clearfix. Today, you really only float things that have a block flow inside an inline context, like asides, pictures, blockquotes, etc. You don't really need clearfix since your inline content should just flow around it. If you are using floats on entire sections you are obviously doing something wrong, and you ought to ask your self if `display: flex` on the parent wouldn't be a better fit.
It doesn't even sound like he interviewed the candidates at all.
> Although I only had the chance to review their personal websites or github profiles and this might of course not be a full show-off of their knowledge, it assured my lately developed opinion on web developers.
Apparently because people's personal projects weren't developed with accessibility in mind he concluded that developers don't know HTML/CSS.
>I only had the chance to review their personal websites or github profiles
>Many are not able to [...] to explain why and how a clearfix works, or what ARIA roles are for
I have only had the chance to review this blog post but this person doesn't seem to be able to explain simple arithmetic, describe the difference between something that is round vs square, or tell me what a spoon is used for.
Personal projects are a bit questionable as a skill test.
I've been planning to do a personal site for a long time and wishing i could contribute on github more but most of the time the only contribution on github ends up to be bug fixes to libraries I use at work and I still haven't gotten anywhere with my personal website.
Most of my best code will never be seen by any interviewer since it's done at work.
Now if any of my personal code was making me money that would be different but I have nothing like that at the moment.
Agreed. And on top of that, any personal projects I do actually find time to work on are typically pretty rushed (due to the lack of time) and are not going to be the best examples of my work product.
Typically I am just trying to write something quick and dirty to accomplish some task and want to share it in case somebody else might benefit. I'd love to make time to go back and polish things, but rarely do I have the time.
I know great, not just good but GREAT developers who don't even have a GitHub. Yes, it's awesome when someone has one, but if someone doesn't have something on their blog or GitHub does that mean they don't know said subject? Nope. I'm questioning the methods used here.
I've encountered this clearfix problem and solved it independently perhaps five times over the last decade, but just had to look it up since I had no idea it was called "clearfix" ... someone's marketing term for it.
Or, at a higher level, maybe their approach to soliciting candidates is wrong. A lot of the job descriptions I see are sloppy. Or they're so vague that you can't figure out what you'd actually be doing (or what the day-to-day would be like). Some of them throw in peripheral technologies just to cover all the bases or something.
It seems like a lot of hiring managers/companies treat a job description as an afterthought when it actually has a huge effect on who applies for a position (_obviously_). People who have more options will tend to ignore the sloppy, vague postings.
The person who wrote this article seems more conscientious than this, but it's something to consider.
Because there's not a well known standard of what solid markup skills are. It's not really a surprise that people come to you without knowledge you claim as necessary when they had no idea it was necessary.
The same is basically true for any position in any area of software.
There used to be a decent standard with (x)HTML 4.1, and the commonly followed process of designing with progressive-enhancement.
HTML 5 added the semantic tags, which are great, but there is less clear decisions for deciding section/article/div that the prior selection of just using div. There are other cases where it has introduced more confusion into the process where the semantics aren't straightforward to determine.
And progressive-enhancement is pretty much forgotten anymore. All the Javascript frameworks and pushing to work on the cutting edge of what's available, have forced a huge portion of effort to be spent on graceful-degradation instead. And working at the edge means that everyone is already working off any adopted standard, and just shimming everything to do what they want.
The front-end development out there is just kind of dumb at the moment in those regards.
I've used `nav` or `section` for a long time, never found of the difference from `div`. Screen readers? Maybe for `nav`, what about `section` and other 1000 tags with subtle different semantics?
Correct me if I'm wrong but I believe there are aria attributes (e.g.: role="navigation") that can also be used as well for this same purpose. Nav is probably safer, but agreed on the CSS reset.
The contrarian argument is that this signifies an important truth, that HTML never worked the way it was suppose to. In the same way that we might argue that a misunderstood product is the fault of the designer, not the user, we could argue that developers moving away from HTML is the fault of HTML, not the developers.
This has been discussed many times, both here on Hacker News as well as elsewhere. To recap that argument, HTML started life with 2 competing and conflicting goals. One goal was to become a GUI for TCP/IP packets. The other was to provide structured information, as SGML had done for publishing.
The conflict was obvious by the late 90s, and then for awhile the good folks at W3 thought that XML would provide the answer. And XML did work at providing structured data, much as SGML had for printing (though the criticism arose that attributes should have been left out of XML, as they were only useful for printing). But when XML was stretched to again try to be a GUI for TCP/IP, the system broke.
Somewhere around 2006, Sam Ruby (W3C working group co-chair) shared a wonderful anecdote on his blog that revealed how broken XHTML was. He said that he had sent his daughter an SVG image, and she wanted to share it with her friends on MySpace. But she couldn't. Because MySpace was not XHTML compliant, and SVG could only render on XHTML compliant pages. And yet if he had sent her a gif or a jpeg, she would have been able to share it. Draconian error checking might be great for an information exchange system such as XML, but it did not work for a GUI that had to be somewhat informal.
In 2004 Mark Pilgrim wrote the great piece "XML on the Web Has Failed":
Now it is 2016. We are looking back at 25 years of failed experience. We can clearly see that HTML and XML both failed, completely, as GUIs for TCP/IP packets.
So developers are being rational. They are "voting with their feet" (actually their minds). They don't learn HTML because they know HTML has failed.
What is the best way to create a GUI for TCP/IP packets? I don't know, but nearly all developers agree that Javascript is a better way to get there than HTML.
There might be something even better than Javascript, and we should all keep experimenting and learning and trying new things.
But HTML has failed, and it is good that developers recognize that.
I'm not sure I understand what you mean by a "GUI for TCP/IP" yet it seems central to your argument. I didn't realize HTML was ever intended to be anything other than structured information.
You have never seen HTML used to build something that a human might look at? What are you looking at right now? Aren't you looking at a web page? Aren't you human? Aren't you using your eyes to see what I've written? Unless you "View Source" on every page you visit, you are looking at the GUI, not the structured information.
If you think HTML can be used to send structured information, I would urge to read the essay that Mark Pilgrim wrote in 2004. I posted the link before.
Also, please consider all the many arguments that Sam Ruby has made against HTML-as-structured-data. From 2005 forward, there were many people who wanted HTML5 to be an extension of XHTML, but as Sam Ruby kept asking "Why should we call something XML if it is clearly not XML?" Over the years, in his role as co-Chair of the W3C working group, he kept making the point that "draconian error checking" is part of the XML spec, and it can not be reconciled to people's actual use of the Web. That is why HTML5 relaxed all the rules regarding validation and structure.
This is Sam Ruby in 2009:
"So, while I doubt that I will ever understand why there are people who insist on calling their pages they produce with the intention of being processed as HTML by the name “XHTML”, I can’t deny that there clearly is something that such people want. (By way of comparison, I am quite happy to say that this page is served as XHTML to browsers that support such, and as HTML to browsers that don’t). From my experience, this is tricky stuff, and not something that should be recommended lightly.)"
If the skills you're looking for are that basic, why wouldn't you just hire one of those 80 applicants and spend an hour teaching them what aria attributes are?
One has to wonder how much time was spent dismissing applicants, and if that time would be better spent showing the new hire his personal preferences (which are only preferences, there wouldn't be 100+ comments on this thread if it was standard)
The value of a developer is managing complexity and solving business needs. If that can be done with a framework and stackoverflow, then what's the problem? The one off occasion where something doesn't go right? That's why you have the one "goes deep" person on the team that you throw that issue to.
What a ridiculous set of requirements and self aggrandizement. I've read about aria attributes more than a few times, but do I care to remember them? No, because you set them up once and move on.
Hiring people, don't confuse route memorization with job performance. It's an absolute ridiculous requirement.
Thankfully not one of those applicaments would have wanted to work there.
Took me a minute to get that this is a mailing list newsletter with a random selection of interesting links from the past week, not a blog post listing things front end developers should know.
If you get 80 applications and none of them have what you are looking for, this seems like the issue is being able to get the right candidates to apply. Or, perhaps it's just not possible to find enough people who have the skills in which case, I suppose you should train them?
Alternatively it seems like a good case for putting some sort of earlier filtering mechanism, like giving a short quiz or coding exercise to see if they know what you want them to know. I remember reading an article by TripleByte on how their quiz actually was a better filtering mechanism than a coding exercise though.
> After reviewing a lot of applications in the past days, I can only agree with Kristian Glass here and say: “If you get the chance, always send a cover letter”. It’s your opportunity to say something about yourself and make clear why you apply for the job.
I can understand why employers feel this way, but from an applicant's perspective, the reason someone applies to your company most likely is that they need to make a living. Frankly I don't think there's anything wrong with that and it's not something I would think stops people from being good employees. After all, it's difficult to know how much you'd like to work somewhere unless you've actually been there.
Although I only had the chance to review their personal websites or github profiles
and then
Many are not able to choose the right HTML elements, to explain why and how a clearfix works, or what ARIA roles are for, but they can use React and Angular.
No kidding. They couldn't explain clearfix because you never asked them any questions.
You want to talk about incompetence, and your "application review" consists of browsing the web.
This guy's gold! Someone can learn react and angular but he thinks they're incapable of learning some accessibility attributes? I wonder how competent he is with angular/react...
I would bet good money you're part of the problem. Most devs I know maintain other people's applications and don't get the opportunity to create new HTML or CSS often. It doesn't take long to get up to speed, especially with all the great online resources available. As long as the person understands the concept, give them a chance!
129 comments
[ 4.3 ms ] story [ 231 ms ] threadTo pinpoint one of his major gripes - I've moved further "back" down the stack since, but when I was doing strictly front-end I had to make a fully accessible page for some clients, but not others. If anything this post gets me aware that portfolio content is also judged for accessibility, so it provided me that benefit should I take on front-end projects in the future. Some may call it lazy, but I tend to focus on "bigger picture" accessibility issues such as contrast and font scaling.
Also with clearfix - many times its actually abused and painted on every element including ones that don't need to clear its children. It's also not the only way to solve the problem - soon display: flow-root will be adopted across browsers.
It's almost like we've spent decades layering abstractions on this stuff so we don't have to wrangle it ourselves, isn't it.
Starting with some specific framework or tool set inevitably limits what you can achieve. Surely the recent emphasis on frameworks over fundamentals has been a major contributor to the Web full of bland, practically identical sites that we see today.
I want to use abstractions and tools where they offer an additional benefit, but without being limited to whatever some predetermined choice of tools or abstractions can do.
It used to be mostly plaintext and basic colors with no responsiveness, under construction gifs, basic images, and flashing text. Before that, just text. We're still learning as an industry. Web technology has not (and may never) settled like the hardware in your toolbox.
Those frameworks are geared for productivity, not possibility. Productivity is where the money is.
As for productivity vs. possibility, I certainly don't dispute that productivity is one place where the money is[1]. However, that doesn't mean there isn't also room for innovation, and it certainly doesn't mean there's no money in doing things better than what you can achieve with Bootstrap, Angular, and a couple of junior developers who don't know much else. In an increasingly monotone and commoditised technology field, more interesting and/or effective presentation can certainly be a USP.
[1] I might question how sustainable that productivity proves to be over the longer term with many framework-heavy projects, but that's a separate issue and probably not worth getting distracted here.
So, what you really want to do is just build some apps, not learn CSS. See the difference?
However, we were talking about knowing HTML and CSS vs. knowing abstractions built on top of them. In that context I didn't interpret the post I replied to the same way that you did.
WebGL, WebAssembly, emscripten
Asking a pop quiz of arbitrary tools / techniques that you happen to have remember really isn't a good way to evaluate if someone is a good developer. I am a good developer and I only just remember what clearfix is, I most certainly couldnt explain how it works.
My instant reaction was, "You keep using that word, I do not think it means, what you think it means."
"Well, you told me I have a plethora. And I just would like to know if you know what a plethora is. I would not like to think that a person would tell someone he has a plethora, and then find out that that person has no idea what it means to have a plethora".
If this post were phrased as "web developers don't know accessibility" it would be obviously true and uncontroversial. Unfortunately.
Then my scraper that reads headlines on your website with `//(h1|h2|h3)` will not work. And I will not be able to read and linearize your tabular data. And plenty of other things. (Things you probably do not care about.)
Oh, and you website will have no links (the `href` attribute of `<a>` is not simulable via CSS).
JavaScript to the rescue!
FTFY
The old trick was to set `overflow: hidden` on the element containing floated items so it would always expand to contain it - but then things like box-shadows get cut off by the containing element. To get around this, you can use an `:after` pseudo-element on the element that contains the float items. This comes after the last floated item and automatically clear the float without needing `overflow: hidden`.
Imagine markup like this:
The advantage of clearing a float this way over sticking `<div style=clear:both></div>` or a `.clearfix` class in your HTML is that when doing responsive design, my method keeps the clear in your CSS (and possibly only one @media query). With a `<div>` or class in your HTML you have to deal with that element at all widths - now do you have to specifically override your `.clearfix` class inside a @media query when doing responsive styles? How intuitive is that?Why? I haven't needed to use floats at all since moving to flexbox.
When isn't it? If you're developing for old (now unsupported) versions of Internet Explorer I'm not sure they'd be bothered about being turned down (unless they knew about that when applying). Just because something was done some way once doesn't make it right, and putting emphasis on 'clearing float' questions would show your company use old, bad practices.
What I would dismiss them for, however, is the cocky attitude that they never need to bother learning any "old, bad practices." I'd dismiss them for thinking they are "above" working for a company that supports technology that was released just 4 years ago. Further, I'd dismiss them for the attitude that their solution solves all the problems without considering potential drawbacks. These are all huge red flags that show they may technically be knowledgable, but are very difficult to work with. Not someone I want on my team.
"..technology that was released just 4 years ago" - if you haven't been keeping up with the news on IE10 then... yeah
"I'd dismiss them for the attitude that their solution solves all the problems without considering potential drawbacks." - no one said there weren't any drawbacks, just when compared with old bad-practice hacks.
"but are very difficult to work with. Not someone I want on my team." - it sounds like the kind of people who're using react would be sad about that.
This post is evidently about junior developers, just because something is old/established doesn't make it right or that it shouldn't be questioned, because there's usually a better way.
Hence the "anything but a junior candidate" from my original post.
"At the end of 2015, the combined market share for IE8 (8.95 percent), IE9 (6.67 percent), and IE10 (4.18 percent) was 19.80 percent,"
Sure, use flexbox exclusively if you want to push away nearly 20% of visitors. Also notice how the older of those browsers has the highest single percentage of use, and reflect on what that might mean about how likely those users are to upgrade.
I prefer the more customer-centric method of looking at what browsers my customers use and supporting them, rather than the more developer-centric view of "X is hard, I don't want to do X anymore and it's no longer supported anyway so there!".
By all means keep an eye on the browser usage for your audience and drop active support for older browsers once they fall below a certain percent, but don't take another company's actions as a license to screw over your (hopefully paying) customers.
If it was purely about numbers, I'd attempt to support to Opera Mini and it's 300 million users. But I don't, and I've never met anyone who does, yet some people bring up IE10 support on a React-driven, Mobile-first web app to appease managers who have always wanted support for older versions of IE "just because". Unless the clients are government/big bank I can't really see any justification for supporting them (and no one supports IE8 - even though it has double the usage IE10 has).
> Although I only had the chance to review their personal websites or github profiles and this might of course not be a full show-off of their knowledge, it assured my lately developed opinion on web developers.
Apparently because people's personal projects weren't developed with accessibility in mind he concluded that developers don't know HTML/CSS.
>Many are not able to [...] to explain why and how a clearfix works, or what ARIA roles are for
I have only had the chance to review this blog post but this person doesn't seem to be able to explain simple arithmetic, describe the difference between something that is round vs square, or tell me what a spoon is used for.
I've been planning to do a personal site for a long time and wishing i could contribute on github more but most of the time the only contribution on github ends up to be bug fixes to libraries I use at work and I still haven't gotten anywhere with my personal website.
Most of my best code will never be seen by any interviewer since it's done at work.
Now if any of my personal code was making me money that would be different but I have nothing like that at the moment.
Typically I am just trying to write something quick and dirty to accomplish some task and want to share it in case somebody else might benefit. I'd love to make time to go back and polish things, but rarely do I have the time.
I've encountered this clearfix problem and solved it independently perhaps five times over the last decade, but just had to look it up since I had no idea it was called "clearfix" ... someone's marketing term for it.
It seems like a lot of hiring managers/companies treat a job description as an afterthought when it actually has a huge effect on who applies for a position (_obviously_). People who have more options will tend to ignore the sloppy, vague postings.
The person who wrote this article seems more conscientious than this, but it's something to consider.
It seems that his gripe is more with people being unfamiliar with certain accessibility tools that he likes.
That doesn't grab headlines like claiming nobody knows basic html and css so though, so he threw that in front.
Even an easy JavaScript programming tasks can filter a lot of applications so you can concentrate on best candidates.
That way you can pick the best ones by technical merit, not be their ability to write nice resume.
I don't remember the exact price, but when my company used them it was something in range of $100-500 / month.
Because there's not a well known standard of what solid markup skills are. It's not really a surprise that people come to you without knowledge you claim as necessary when they had no idea it was necessary.
The same is basically true for any position in any area of software.
HTML 5 added the semantic tags, which are great, but there is less clear decisions for deciding section/article/div that the prior selection of just using div. There are other cases where it has introduced more confusion into the process where the semantics aren't straightforward to determine.
And progressive-enhancement is pretty much forgotten anymore. All the Javascript frameworks and pushing to work on the cutting edge of what's available, have forced a huge portion of effort to be spent on graceful-degradation instead. And working at the edge means that everyone is already working off any adopted standard, and just shimming everything to do what they want.
The front-end development out there is just kind of dumb at the moment in those regards.
I love this site as a crutch for most of these kind of specific things: http://learnlayout.com/
It finally got me to understand where I was screwing up my understanding of things.
This has been discussed many times, both here on Hacker News as well as elsewhere. To recap that argument, HTML started life with 2 competing and conflicting goals. One goal was to become a GUI for TCP/IP packets. The other was to provide structured information, as SGML had done for publishing.
The conflict was obvious by the late 90s, and then for awhile the good folks at W3 thought that XML would provide the answer. And XML did work at providing structured data, much as SGML had for printing (though the criticism arose that attributes should have been left out of XML, as they were only useful for printing). But when XML was stretched to again try to be a GUI for TCP/IP, the system broke.
Somewhere around 2006, Sam Ruby (W3C working group co-chair) shared a wonderful anecdote on his blog that revealed how broken XHTML was. He said that he had sent his daughter an SVG image, and she wanted to share it with her friends on MySpace. But she couldn't. Because MySpace was not XHTML compliant, and SVG could only render on XHTML compliant pages. And yet if he had sent her a gif or a jpeg, she would have been able to share it. Draconian error checking might be great for an information exchange system such as XML, but it did not work for a GUI that had to be somewhat informal.
In 2004 Mark Pilgrim wrote the great piece "XML on the Web Has Failed":
http://www.xml.com/pub/a/2004/07/21/dive.html
Now it is 2016. We are looking back at 25 years of failed experience. We can clearly see that HTML and XML both failed, completely, as GUIs for TCP/IP packets.
So developers are being rational. They are "voting with their feet" (actually their minds). They don't learn HTML because they know HTML has failed.
What is the best way to create a GUI for TCP/IP packets? I don't know, but nearly all developers agree that Javascript is a better way to get there than HTML.
There might be something even better than Javascript, and we should all keep experimenting and learning and trying new things.
But HTML has failed, and it is good that developers recognize that.
If you think HTML can be used to send structured information, I would urge to read the essay that Mark Pilgrim wrote in 2004. I posted the link before.
Also, please consider all the many arguments that Sam Ruby has made against HTML-as-structured-data. From 2005 forward, there were many people who wanted HTML5 to be an extension of XHTML, but as Sam Ruby kept asking "Why should we call something XML if it is clearly not XML?" Over the years, in his role as co-Chair of the W3C working group, he kept making the point that "draconian error checking" is part of the XML spec, and it can not be reconciled to people's actual use of the Web. That is why HTML5 relaxed all the rules regarding validation and structure.
This is Sam Ruby in 2009:
"So, while I doubt that I will ever understand why there are people who insist on calling their pages they produce with the intention of being processed as HTML by the name “XHTML”, I can’t deny that there clearly is something that such people want. (By way of comparison, I am quite happy to say that this page is served as XHTML to browsers that support such, and as HTML to browsers that don’t). From my experience, this is tricky stuff, and not something that should be recommended lightly.)"
http://intertwingly.net/blog/2009/07/19/Humpty-Dumpty
You reap what you sow...
Kinda like i18n for "internationalization."
< 162
162 results, but I'm going with "aboriginality" skills.
Hiring people, don't confuse route memorization with job performance. It's an absolute ridiculous requirement.
Thankfully not one of those applicaments would have wanted to work there.
It sounds like these applicants wasted their time to help the Author write some bait click article to attract traffic.
Alternatively it seems like a good case for putting some sort of earlier filtering mechanism, like giving a short quiz or coding exercise to see if they know what you want them to know. I remember reading an article by TripleByte on how their quiz actually was a better filtering mechanism than a coding exercise though.
> After reviewing a lot of applications in the past days, I can only agree with Kristian Glass here and say: “If you get the chance, always send a cover letter”. It’s your opportunity to say something about yourself and make clear why you apply for the job.
I can understand why employers feel this way, but from an applicant's perspective, the reason someone applies to your company most likely is that they need to make a living. Frankly I don't think there's anything wrong with that and it's not something I would think stops people from being good employees. After all, it's difficult to know how much you'd like to work somewhere unless you've actually been there.
You want to talk about incompetence, and your "application review" consists of browsing the web.