Obligatory xkcd Comic
Standards are one of the things which makes writing software a bit of a pain, but also allows the pleasure of writing a system which integrates, uses and enhances other systems. Indeed the Internet Browser you are reading this blog post on works using a multitude of standards, from the Internet Protocol and Transmission Control Protocol used to deliver the information to you, to the HTML and CSS used to render this web page on your screen.
For those people who are not entirely familiar with the term standards, a technical standard is — according to wikipedia — a “formal document that establishes uniform engineering or technical criteria, methods, processes and practices”. In laymans terms it’s a document that tells you how something works and how to implement it so that your implementation is compatible with other peoples. An example is RFC 2616, The W3C Standard for the HTTP/1.1 protocol.
Standards, in theory and most of the time in practice are fantastic, why invent a new way of guaranteeing the delivery of a packet over internet protocol if there’s already a standard written by a group of intelligent people who have tried to find and fix every edge case and is compatible with everyone elses system? There is no point.
The only time real issues do occur is when there is an edge case that hasn’t been thought of by the author of the RFC, or the standard is implemented incorrectly — either on purpose or by accident.
How strictly should we adhere to a standard?
The motivation behind for blog post was found when doing my coursework for the “Simulation and 3D Graphics” module in an API called OpenGL. I had written a program using OpenGL 3.0 on the computers in the Fenner Computer Laboratory in the University. However, when I went to the ITMB Computer Lab in the next building my code produced a completely different result. You can see the stark difference below.
The image on the left hand side is what I had been seeing as I engineered my code in the fenner laboratory. A column — textured with some “Epic Faces” — with a spotlight-lit sphere inside it. I’ll explain what the purpose of all this is in another blog post. On the right hand you can see what appeared using exactly the same code in the ITMB Lab, precisely nothing.
After many excruciating hours of searching — with some help from one of my housemates — I discovered the bug was being caused by me attempting to call the “glEnableVertexAttribArray()” method on a uniform member of a shader, something which you’re not meant to do, or indeed allowed to do in OpenGL. I had made a programming error, as every Software Engineer does many times a day. What is especially bad here however is that I wasn’t informed of my accident, either by error or by the thing simply not working.
Looking at the above image you may think that the Fenner Computer, using its Intel Graphics card, was “right” because it displayed the 3D objects I wanted it to. However, I would disagree. The AMD Graphics card on the ITMB Computer actually produced, according to the standard, the correct result. Nothing. Had I been working in ITMB when I produced the code I would have noticed that adding the glEnableVertexAttribArray() line broke everything, and would have immediately removed it, working in Fenner gave me a false sense of security that my code was in fact OK.
So, as far as I can tell this leaves us with a few options.
- We should say that in order to claim to implement the OpenGL standard, Graphics Card Manufacturers will have to write a, and work with a standard of how strict their implementations are, I would suggest that all graphics card manufacturers stick directly to the specification and throw exceptions or GL.ErrorCodes or display nothing on screen if there is an issue
- We write into the specification exactly what should happen in every possible edge case involved with the specification (this is obviously impossible)
- We don’t agree on a level of strictness and we waste countless hours of programming time, as we do at the moment
I sincerely hope that eventually number 1 happens, but I’m not sure how likely it is.
Should we ever add proprietary elements to a standard?
Another issue with standards its that sometimes they don’t fulfill everyone’s use cases, in other words they don’t allow everybody to do everything they would like. For example the body of standards used to make up web pages don’t allow websites to run executable code, such as c++ binaries, natively. This lead to things such as the much despised ActiveX control and the slightly less despised Java Web Applet.
The issues associated with this are many
- Users have to install an additional piece of software before they can enjoy certain functionality
- Users then have to ensure this software is up-to-date and manage it properly to avoid security failures
- The fact these downloads exist allow other people to fake them, allowing easier drive-by-download attacks.
I would argue that if we are ever using a standard, or claiming to use a standard we should endeavour to never add to it ourselves. Instead, the correct course of action would be to write a Request for Comment (RFC) and implement the feature in your browser or program, but have it turned off by default. This way develops can turn it on to test it and play around with it, but they won’t become reliant on a proprietary features to implement their solution. Everyone wins. Thankfully most of the browser makers are going this way, so the HTML5 and associated specifications shouldn’t be too fragmented.
Worried about the future
As mobile browsing is becoming more and more popular at a tremendous rate more and more websites are aiming to make mobile friendly sites, either by making completely separate sites such as http://m.bbc.co.uk/sport or by using responsive designs such as the brilliant one which is used at https://www.gov.uk/. Whilst I can do nothing but encourage the development of mobile sites, especially if they have feature parity with the desktop sites and have a great touch-centric UI, I am worried that history is repeating itself.
Sites famously used to have landing pages which said “Works best in Internet Explorer” or “Works best in Netscape”, this is because often those websites would use proprietary features from either browser, for example gradient backgrounds. Unfortunately, because the two major mobile operating systems, Android and iOS, both use WebKit rendering engines to render HTML, CSS etc content mobile website developers are not only utilizing proprietary features , but actually relying on them.
Though the sites don’t show annoying images that say “This site works best in webkit” the result is equally annoying — a substandard browsing experience for anyone who uses a browser which doesn’t use a WebKit rendering engine, examples include Opera Mobile and Internet Explorer.
Developers, learn from the past, and if you can at your organisation have a standard for implementing true standards!