Today we saw a new, interesting service called Does it work on Edge? which allows you to enter a URL, and get that URL rendered in Microsoft Edge. It also gives you a report in case there are issues with your HTML or CSS that are troublesome for Edge (much like Microsoft’s own service does). In most cases, this will be browser-specific code like prefixed CSS. All in all this is a great service, one of many that make our lives as developers very easy.
If you release something on the web, you get feedback. When I tweeted enthusiastically about the service, one of the answers was by @jlbruno, who was concerned about the form not being keyboard accessible.
The reason for this is simple: the form on the site itself is none insofar there is no
submit button of any kind. The button in the page is a anchor pointing nowhere and the input element itself has a
keypress event attached to it (even inline):
click for bigger
There’s also another anchor that points nowhere that is a loading message with a display of none. Once you click the first one, this one gets a display of block and replaces the original link visually. This is great UX – telling you something is going on – but it only really works when I can see it. It also gives me a link element that does nothing.
Once the complaint got heard, the developers of the site took action and added an autofocus attribute to the input field, and proudly announcing that now the form is keyboard accessible.
Now, I am not having a go here at the developers of the site. I am more concerned that this is pretty much the state of web development we have right now:
- The visual outcome of our tools is the most important aspect – make it look good across all platforms, no matter how.
- When something goes wrong, we don’t analyse what the issue is, but instead we look for a tool that solves the issue for us – the fancier that tool is, the better
How can this be keyboard accessible?
In this case, the whole construct is far too complex for the job at hand. If you want to create something like this and make it accessible to keyboard and mouse users alike, the course of action is simple:
- Use a form elment with an input element and a submit button
Use the REST URL of your service (which I very much assume this product has) as the action and re-render the page when it is done.
If you want to get fancy and not reload the page, but keep all in place assign a submit handler to the form element, call preventDefault() and do all the JS magic you want to do:
- You can still have a keypress handler on the input element if you want to interact with the entries while they happen. If you look at the code on the page now, all it does is check for the enter button. Hitting the enter button in a form with a submit button or a button element submits the form – this whole code never has to be written, simply by understanding how forms work.
- You can change the value of a submit button when the submit handler kicks in (or the innerHTML of the button) and make it inactive. This way you can show a loading message and you prevent duplicate form submissions
What’s wrong with autofocus?
The web is obese enough!
So here’s my plea in this: let’s break that pattern of working on the web. Our products don’t get better when we use fancier code. They get better when they are easier to use for everybody. The fascinating bit here is that by understanding how HTML works and what it does in browsers, we can avoid writing a lot of code that looks great but breaks very easily.
There is no shortage of articles lamenting how the web is too slow, too complex and too big on the wire compared to native apps. We can blame tools for that or we could do something about it. And maybe not looking for a readymade solution or the first result of Stackoverflow is the right way to do that.
Trust me, writing code for the web is much more rewarding when it is your code and you learned something while you implemented it.
Let’s stop adding more when doing the right thing is enough.
View full post on Christian Heilmann
One of the big questions I repeatedly got at events lately is this:
Is HTML5 ready yet?
The answer is no, because HTML5 is not a bowl of spaghetti that you know when they are ready by flinging them against the wall. HTML was never “ready” and will never be “ready”. It can be “the right choice” and it will be “an exciting opportunity”, it might also be “a dirty hack that works right now” or a “semantically valuable resource that can be converted to whatever you want”.
You see, even HTML4.01 or XHTML for that matter was never “ready”. Sure, the standard was agreed on and you could put in your project deliveries that your web site will be compatible with it, but in most cases this was a lie.
Standard compliance on the web is a means to an end. It made it easier to track mistakes and it made your work understandable by other developers but when it comes to delivering web products, it had not much impact. As web developers we were constantly asked to build interfaces and apply designs and interactions that were never defined in the standard. Which is why we had to find ways to do that which in a lot of cases meant abusing the standard.
We used spacer GIFs and
The goal was always the same: deliver the best possible experience in an unknown, always changing environment.
The big issue we have now is that with a lot of HTML5 marketing this goal has been washed out and people expect more control from HTML5. The incredibly brain-dead message of “HTML5 is the Flash killer” (yes, I said it) clouds all of our judgement and stands in the way of great web applications. In my book, Flash doesn’t need killing at all.
What needs killing is the close-minded limited way we think about web applications. Flash gave people the impression that they can control the web and define what the end user sees. This is limiting the web and does a disservice to your product. When building web applications you should focus on reaching as many people as possible and not force-feed your design or interaction to all and deliver an agreement that leaves everybody unsatisfied. The recently released Web App Field Guide by Google brings it to the point: HTML5 has enabled developers to break free of the limits they were used to when building web applications.
The main difference between HTML4 and HTML5 is the direction of innovation. In the HTML4 world we had a standard that was inadequate to what we needed to build. That’s why browser vendors build their own extensions on top of it and created a total mess for developers. In order to achieve our goal we had to write code for each of the browsers out there, rather than writing HTML. This was awful and caused a lot of people to chose the simple way out and write exclusively for one browser. In the past this was Internet Explorer 6 and this is why we now have a lot of government and enterprise IT environments that don’t upgrade to newer browsers. This holds us back.
HTML is now a living standard. This boggles the mind of a lot of people – how could a standard be living? Well, to me, this makes a lot of sense. The needs of the web are constantly changing. A few years ago nobody predicted – least of all the standards bodies – that we will consume the internet on mobile devices with touch interfaces. What will happen in the nearer future? Who knows? Face and motion recognition?
HTML5 is defined by browser makers tinkering and innovating and feeding back to the standard. Then other browser makers weigh in and we make it an agreed standard. This avoids the issue of developers having to build things for browsers and it means the standard will not fall behind. The main power of the internet is that you don’t need to write the same app several times for different environments and by agreeing amongst browser makers we make sure that there will not be a new IE6 situation.
So no, HTML5 is not ready and will never be – and that is a good thing. We have a standard for the web with all its change and adaptation and not a software standard that expects 5 year turnaround times in innovation.
Discussion on Google+ – Discussion on Facebook
View full post on Christian Heilmann