Like any large project, creating a high-quality on-line presence requires attention to some technical details. These un-glamorous considerations are easily overlooked, especially during the initial excitement of getting a new project on-line when attention is focused on visual appeal and features. However, mistakes here can severely impact basic functionality and reliability, and by extension, erode business credibility.

HTML is the markup language used to turn plain text documents into the sort of content you see on webpages, with links, paragraphs, in-line images, and so on. Like any computer programming language, there are sets of rules that define how it should be written. Breaking those rules results in behaviour that is, by definition, undefined, meaning that a browser can potentially interpret your code in absolutely any way it wants to. Web pages published on the public internet shouldn’t contain errors in their HTML. But a very large number of pages do.

Putting aside for a moment some definite technical reasons why validation does in fact matter very much, we find ourselves asking exactly why anybody who is capable of writing standards-compliant code would purposely create something that doesn’t validate? HTML that doesn’t comply with the published standards is by definition buggy, and delivering any IT project with known bugs simply isn’t professional. Even if the content renders acceptably in a selection of modern web browsers, using other browsers or an updated version of one that the buggy HTML has been tested against could break the design completely at any time. Even worse, it could break the functionality of your page in subtle and frustrating ways, leaving customers unable to login, unable to complete an ordering process, and more. Finding subtle breaks in functionality caused by non-validating HTML can be difficult. Do you really want to pay to update your site each time this kind of breakage happens? Standard compliance will likely save you time and effort in the future.

Many years ago, back when HTML was still an immature standard, there were visual effects that were difficult or even impossible to create without using unofficial tricks that broke standards compliance. For the most part these techniques just worked on the handful of browsers in common use at the time, but the world wide web was a much simpler place back then. Users’ expectations were lower, and a visually broken website wouldn’t necessarily impact their opinion of your business. These days are long gone, and this has not been the case for well over 15 years. Just about any layout and visual effect can be created with compliant HTML and CSS. You’re looking at a fully standards compliant webpage right now, just like all of the pages hosted at exoticsilicon.com.

In our experience the most common reason that developers create HTML that doesn’t validate is because they have built a website using pre-written, off the shelf modules that they do not fully understand and lack the ability to customise. This in itself should make the paying customer suspicious.

Additionally, some developers simply lack the ability to produce work of a high technical quality. Their work might look nice visually, but a developer who passes off work that doesn’t comply with published standards by covering it up with glitzy visual effects, is demonstrating a lack of discipline and aptitude.

We occasionally hear claims that validation against published standards is simply not necessary. Our response to that is this entire design studio article explaining why it is.

From a technical point of view, valid markup is the best assurance that your website will work correctly across a wide range of current and future web browsers, not only on computers, but on mobile phones and tablets, too. Responsive designs - those which adapt to different devices and screen sizes - are especially difficult to make work reliably without valid HTML and CSS.

Sadly, here at Exotic Silicon, we’ve come to hold the opinion that the official HTML standard has now developed into a sprawling mess. This process started around the time when it became a ‘living document’, and turned from a series of neatly versioned published standards into a continuing development effort without any more distinct freezing and versioning. The people and organisations responsible for this process should feel absolutely ashamed at feeding the desires of those calling for more and more features to be added as quickly as possible, with insufficient thought to the long-term practicality and manageability of the implementation of the standard, as well as the effect it has had on those who actually care about writing quality code with a high degree of standards compliance and interoperability.

This stupid, lazy, and slap-dash approach towards standards development simply encourages lackluster implementation of the published standard. This is most noticeable in webpages themselves, which are almost always full of technical errors nowadays, but it’s also visible in browsers, which may or may not implement any particular feature, or may even decide to ‘partially’ implement them as they please, leaving everybody involved somewhat clueless as to what to expect.

Of course, browser non-compliance has always been a problem since the early days of HTML, but at least then it was possible to point a finger and direct valid criticism at the programmers responsible, because at that time the HTML standard was, with a few exceptions, strictly defined. Either an implementation was compliant or it wasn’t.

Strictly speaking, it is no longer technically possible to write HTML that can be 100% guaranteed to validate against ‘the standard’, as the standard itself is now a moving target. Code that correctly validates today, might not validate tomorrow. The best we can hope to achieve is to write code that validates against the standard as published at the time of writing, and then update it as required.

Thankfully, HTML itself has been somewhat mature for a number of years, and little of what has been added since about 2017 seems to be of much value. Most of the interesting development seems to have happened in CSS which, whilst it has also unfortunately been turned into a ‘living standard’, doesn’t seem to have suffered quite so much from an overload of dubious feature additions at the expense of clarity and implementability.

Probably the easiest way to check a webpage for valid HTML markup is by using the on-line validation tool of the W3C, the organisation originally responsible for overseeing the creation and management of the published HTML standards.

The HTML validator can be found at this address:

Simply visit that page, type in the address of the page you would like to check, and click the validation button. Within a few seconds you will receive a report back telling you that the page is valid HTML, or alternatively, detailing any errors that the validator discovered.

An on-line CSS validation service is also available from the W3C, at the following address:

All of our own webpages should report no errors or warnings whatsoever in their HTML and CSS, and validate as HTML 5 documents.

You will likely see various errors and warnings from time to time when checking other peoples’ pages. Obviously an occasional error may be due to an oversight, or because of an update in progress - it’s not necessarily an indication of truly bad workmanship. However, the inability of a developer to fix such errors when brought to their attention, or excuses and claims that it doesn’t matter, should be considered as red warning flags for anyone planning a serious webpage design project.

Unfortunately, real names, telephone numbers, e-mail addresses and other things often contain spaces or hyphens that are not adequate places for a line break. Correctly authored webpages have these characters specially marked up to avoid such ugly line breaks.

If this is not done, it might not be at all obvious at first as it likely won’t show up straight away in testing. Only when the browser window is resized in such a way that a line break happens to occur in an undesired place does the problem reveal itself. Competent webpage designers should be aware of the markup requirements and insert them everywhere where they are approprite, without waiting to see breakage first.

Being aware and pro-active in implementing these non-breaking spaces and hyphens is important, because the problem only becomes visible when the browser happens to break text at that particular point.

On the other hand, if the content contains multiple long lines and requires them to be maintained in order to be unambiguous, (for example, console output), then it can be more effective to allow the element to scroll horizontally.

Most digital photographic imagery is represented by rows of pixels, so called raster images. However, graphics such as logos and icons that are made up of lines, curves, and solid blocks of color, can be represented in a very different way known as vector graphics.

The magnifying glass image above uses a mere 366 bytes to represent as vector graphics. As a raster image the file sizes are larger at 723, 744, 978 and 4504 bytes, depending on the format, (arithmetic jpeg, huffman table jpeg, lossless webp, or png), yet the quality is obviously inferior.

Vector graphics have enjoyed support in all mainstream web browsers for a very long time now. They are used to good effect on a fair number of webpages, including our own, but some developers still shun them and continue using inferior raster images in their place, losing you the benefits described above.

In extreme cases, this can mean a webpage designer writing invalid HTML that doesn't even validate against the specifications, but just 'happens to work' in their browser of choice.

Alternatively, it can mean mis-using features of CSS that allow us to design responsive pages by trying to second-guess the exact specifications of a specific subset of browsers or devices, and force a particular rendering on them. The code might, (or might not), be valid HTML and CSS, but this is still very bad practice.

In the worst cases, the page design breaks completely if the user changes any of the browser settings, such as font size, from their default values.

Even if this doesn't happen, new mobile devices are constantly entering the market. Pages designed to target a specific selection of current models can easily become obsolete within a year, requiring them to be updated or redesigned, which in turn creates an on-going administrative burden.

In contrast, pages which are designed around generic device capabilities usually have a much higher likelihood of working correctly unchanged on a browser where the user has changed the settings from their default, and on future devices that haven’t even been released yet.

Elements on webpages can not only be made to react to mouse clicks, but also to the fact that the user is hoving the mouse pointer over them. This can be seen in the simple demonstration above.

Most users of desktop computers will be able to do both actions using a mouse without any difficulty.

Users of touchscreens, though, which includes just about all users browsing on a mobile phone or tablet, generally don’t have any easy way to hover the mouse pointer without clicking. Exceptions exist, such as tablets operated with a stylus instead of finger gestures, but in the vast majority of cases a tap on the touchscreen is usually interpreted as a click, and may even trigger two actions - that for hovering, and that for clicking.

Some users can’t hover, and other users can’t click on anything other than a link or a form button.

A website may be completely unusable for these users if it is programmed to do different things to the same element when it is clicked or hovered over, or if non-link elements need to be clicked.

Common culprits include drop-down menus, as well as buttons and links that have been badly implemented with Javascript.

The first situation arises when the developer just didn’t bother to set the tabindex attribute on an element such as a div which is not automatically focusable. It’s perfectly operable using a mouse or other pointing device, but there is no way to reach it purely using keyboard controls.

In the second case, it’s usually that the visual positioning of the page elements in the HTML has been changed using CSS, making the order they appear on-screen different to that which they appear in the page source code. Moving the focus from one element to the next with keyboard controls will by default follow the order that the elements appear in the source, unless they have a tabindex attribute to change this behaviour. It can also happen if the tabindex attribute has been set incorrectly.

Since javascript is a major vector for web-based malware, as well as other irritations such as pop-ups, many knowledgeable users and especially power users simply prefer to browse un-known and un-trusted websites with javascript turned off entirely. For these users, when your website loads with a blank screen, throbber graphic that never disappears, or broken navigation because it requires javascript, they just hit their back button. You probably don’t even know that they visited your site, or were intending to, because in your webserver logs the single entry they made probably just looks like a webcrawler. It wasn’t, it was a potential visitor that you lost. They went elsewhere and found the content they were looking for on somebody else’s website, and never came back.

Given that all modern mainstream browsers include Javascript functionality, some webpage designers take a lazy and unprofessional approach, creating pages that do not provide any fallback and become unusable when it’s disabled. Even worse is when they treat the user as if they are completely ignorant, redirecting them to a silly generic website with instructions on how to enable this technology. It’s almost certain nowadays that a user browsing with javascript disabled is doing it out of choice, and not by accident. Trying to bully them into opening their browser up to more malware is not likely to be productive, and can present a very arrogant image of your company being uncaring or unsympathetic to their freedom of choice.

If you think that this represents a minority of users, just the knowledgeable IT types who might not be your target audience anyway, be aware that avoiding malware is not the only reason that some users deliberately disable Javascript entirely. Reasons can include increased browsing speed, lower bandwidth utilization, avoiding tedious pop-up adverts and avoiding browser profiling to name just a few.

Even today, some users may be using a browser that does not even support Javascript. The text mode browser Lynx is the most common example, but some browsers designed for use with assistive technologies may either lack support, or more commonly have difficulty parsing the particular use of Javascript on your pages.

Drop-down menus implemented in Javascript, which require a mouse-pointer hover to ‘open’, followed by a ‘click’ on the chosen item are a classic design failure that can make whole websites un-usable on mobile devices or on a computer without a mouse when they provide no other method of site navigation.

Look at all of the amazing things we’ve done here on exoticsilicon.com. Not one of the website features relies on javascript to make it work. You can browse the entire exoticsilicon.com website with javascript disabled, and not miss out on anything.

Even if a particular function of your website genuinely requires the use of cookies to be practical, such as an on-line shopping cart, take the time to handle cookie-less browsers gracefully. A message advising that the site requires cookies for correct operation looks much more professional than a browser caught in a continuous loop of page re-loading.

Webpages that use excessive amounts of non-standard markup, or large third-party Javascript libraries, (so called, 'polyfills'), to make themselves function on older web browsers.

Going to great lengths to make your content work on old browsers simply encourages a culture of laziness and complatentcy in keeping the client software up to date. Unlike years ago, these days very few users are genuinely in a situation where they cannot easily upgrade the browser they are using. By making it easy to avoid doing this, you are providing a dis-service and leaving them open to many more security vulerabilities.

Making your site work on ancient browsers with the use of third-party 'polyfills' isn't professional. In fact, it's just selfish, because you are prioritising your own interests, (easy website traffic), over the user's interests, (security and reliability). Who wants to deal with a business like that?

The correct solution is to design pages that use HTML and CSS in a way that degrades appropriately on less capable browsers, rather than trying to force all of your design features to work everywhere. In this way, your site can deliver a more appropriate experience for users who happen to access it with an older browser whilst not impeding the full functionality for those accessing it with a more capable system.

A message such as, 'Your browser lacks full support for some of our website features. Upgrade for the best experience!', gently encourages users to upgrade their software at a convenient moment.

Using generic and bloated third party libraries to ensure that any ‘missing’ features in older browsers don’t break your site, harms the browsing experience to some degree for all of your visitors. Instead, take the time to choose carefully the features you use for essential functionality from those with the best native browser support, and use similar alternative fallbacks to allow the pages to render sensibly on older hardware.

We generally discourage the practice of separate ‘em-dot’ sites altogether. When the first mobile devices with real web browsers appeared on the market, there wasn’t really much choice but to implement a mobile site in this way. It even seemed logical, as WAP sites had enjoyed a brief period of popularilty, and they were implemented in WML rather than HTML, so the mobile site really was different. Sites developed in C-HTML and delivered using i-mode also effectively required a completely separate design.

This is no longer the case. All modern smartphones are designed to access regular webpages now, and creating a new ‘em-dot’ site basically makes no sense whatsoever. Decommissioning any existing separate ‘em-dot’ sites in favour of a single responsive layout neatly avoids this problem of passing links from one to the other altogether.

Validating user input is very important when the information is to be processed automatically. It can also help to ensure that users include all necessary information when completing contact forms and other actions that are to be processed manually.

However, it is good practice to consider cases where the user is genuinely missing certain information, but their request could still be processed without it.

In the first example above, the user has entered an international phone number complete with the country code, indicated by a leading plus sign. This may be rejected by validation code that expects phone numbers to only contain digits.

Some webbrowsers on mobile devices will interpret any sequence of numbers on a page as a potential telephone number. If the user long-taps on the number, they might be given an option to dial it, or simply be taken directly to their phone dialer screen with the number already filled in. The exact behaviour depends on the specific device.

Browsers with this feature are usually intelligent enough to ignore dashes separating groups of digits, and brackets indicating an area code. However, a common but incorrect and very bad practice is to mix both local and international dialing codes in the same number. The resulting string of digits is neither a valid national or international number, it’s simply wrong, and the browser will typically pass a truncated number to the dialer.

Telephone numbers in the North American dialing plan don’t usually cause confusion, as the leading 1 indicating a trunk call is identical to the international +1 prefix.

However, consider the international format UK phone number +44 1632 234567. This would be dialed nationally as 01632 234567, where 0 is simply a prefix to indicate trunk dialing, 1632 is the area code, and 234567 is the local number. The representation +44 (0) 1632-234567 is occasionally seen, but this is not a valid format for a UK phone number and a web browser trying to auto-detect phone numbers in a page may well end up passing just 1632234567 to the dialer, truncating the leading 0, which will result in a failed call.

Correct automatic parsing of arbitrary numbers in webpages cannot be guaranteed in any case, especially as the behaviour of this functionality is browser dependent. However, using a non-standard format to display your phone number is almost certainly going to make things worse rather than better, not to mention that it just looks wrong and un-professional anyway.

Always use a standard format and commonly accepted representation of your telephone number, preferably the full correct international dialing format including country code.

Of course, you can create explicit telephone number links with the tel: link scheme, but support for this is browser specific and in any case many of the same considerations apply.

Proof-read your pages from time to time! This will not only catch these sorts of errors, but other mistakes, broken links and outdated information too.

For several reasons. Firstly, it almost always breaks when javascript is disabled in the browser. This leaves the user looking at a collection of blurry blobs of color instead of the images, which is often more visually distracting than simply having the images missing altogether. Secondly, it doesn’t always improve page loading speed, in fact on a fast connection where the images would have come in quickly anyway, it can actually slow down the final rendering. Thirdly, a broadly similar effect can be achieved by using progressive jpeg images and ensuring that the dimensions are correctly specified in the corresponding stylesheet.

For many reasons!

Although the limitless use of different typography is potentially great for creativity, there are reasons to limit the use of web fonts and in some cases prefer use of the built-in system fonts.

In rare cases, web fonts from third party providers can actually completely break your site.

In general, and independent of the technology, using a massive array of different fonts in the same document has long been considered bad typesetting practice anyway. Unless you have a very specific effect that you want to create by doing so, it almost always looks awful.

However, web fonts bring their own specific technical problems, and these issues can show up even if you only use a single non-operating system native web font on a page.

Firstly, the browser cannot even begin rendering the final layout until the font has loaded. Either rendering is completely blocked, usually leaving the user staring at a white screen, or the text is first rendered in a system font and then changed to the downloaded font once it is available. This is visible as the text ‘snapping’ into place, unless the page uses some javascript to block the visual effect and replace it with something even more irritating, such as a throbber, a technique which has problems of it’s own.

So you can’t get away from the fact that web fonts add a lag to your page loading time. This might be acceptable if they noticeably improve the content, but it can’t be avoided, unless the particular font already happens to be in the browser cache from a previous request.

To make things worse, although web fonts can be created yourself and hosted on your own webserver just like any other content, a lazy option exists which many or even most webpage designers usually take, which is to use a third party font hosting service. So now you have to fetch render-blocking content from a separate domain. That’s not at all good for performance, but it also carries a greater risk.

We once informed an ISP of a problem with their support pages and customer service portal. Suddenly, when accessed with a certain combination of web browser and operating system that had previously worked fine, the browser crashed almost immediately on page loading. This had never happened before. The ISP denied having made any changes to the code running the support portal. Although the bug was ultimately a browser issue, the problem disappeared as soon as the link to a third party font server was removed. Clearly, changes had been made to the code served by the third party which had triggered the browser bug. The problem is, though, that these support pages were the main way for customers to get in touch, so total breakage here made it somewhat difficult for any affected customers to even report the problem. The key point to take home from this is that including any content on your pages which needs to be fetched from a server which is not under your control, is a risk. You simply don’t know when buggy third party content could make your pages inaccessible, and in the case of a support and service portal that’s obviously a very serious problem. If you want to use web fonts, hosting them on your own server is a much better approach.