Browser developer tools

Browsers provide a development environment to facilitate debugging pages.

The facilities provided can really help to see how the complex interactions of the various technologies play out in the end. Until that point, it is all theory and a lot of hope. When errors occur, there are opportunities to see at which elements and what JavaScript commands are involved. There are opportunities to see what in the hierarchy of CSS statements that control what is finally shown. Plus there is the opportunity to list values using the JavaScript console.log command.

All these work quite well, though I have had Edge get confused and generate a lot of very strange and non-sensical error messages. This led to a few trips down some rabbit-holes until I restarted Edge and they all disappeared. Since I use Edge to do most of my development and viewing, I have not explored Chrome and Firefox enough to see if they do not get lost as well at times. However, it was in using them to try to verify those strange errors and not getting any that I sussed out that Edge was going rogue.

For straightforward by-the-spec detection, browser facilities are good and the various browsers all work in much the same way with results consistent with each other. However, it is when it comes to so-called best practices that the developer tools start venturing into opinion rather than specs. At this point, the usefulness of the tools comes down to which set of opinions they implement.

For example, for resources such as images, it is useful to employ what is called cache-busting by making sure that there are different URLs for each version of them. This ensures that when they are changed, previous versions in the caches along the way are not used instead. But how that is done should be up to the developer, but the Edge programmers decided that it should use the major.minor.build type of format that is typically used for programs.

The product uses a date-time format which is programmatically configured to not produce collisions, but using them is flagged with unnecessary warnings. They did not explicitly state what the actual rules they were using were, so I had to go to their reference pages and examine the regular expressions they used. Someone not used to them would have no hope of knowing how they are actually supposed to format their URLs so they do not get flagged.

Some opinions seem to be more a reflection on what the development teams thinks people do web development for, rather than what might be more useful for different scenarios. For example, while normal public pages are usually given a cache-validity duration recommendation of say three minutes, the Open Worldwide Application Security Project (OWASP) makes a recommendation of no-store for cache-control for logged in pages so that there is no chance of cache-poisoning that might leak private data. This setting gets flagged with a warning in Edge.

Some are just strange. I have had Chrome flag a warning for a page that had a canonical URL form like the home page of the site. It was the home page! Now, most site users do not look at the development pages, but if they do, but are not experienced developers, they may get the idea that some of the opinions are actual specifications and follow like sheep. The web is already filled with pages created by some newer developers that have implemented some stupid ideas thinking they must actually be useful because so many are using them.

This is not helped by the huge raft of YouTubers willing to fill their heads with such nonsense. Browsers ought to have defaults that only show specification-based information in the developer pages, and give the option to show what might be called opinions on best practices, just so casual or inexperienced explorers do not mistake them for anything more than what they are.

It is errors that need to be corrected. While warnings are usually handled by the browser without incident, they might currently be subject to deprecated standards. This means that within the next few browser versions, they might become errors as the next version of the standards is implemented, ceasing tolerance of the infringing elements. Unfortunately, such warnings are not distinguished by browsers from infringements of best-practice recommendations that have nothing to do with standards, but are just some non-standards group's ideas they implemented.

Do not look at the Google (39 errors and 123 warnings), Bing (129 and 301) or DuckDuckGo (3 and 149) search pages for guidance, except for what not to do. For comparison, a very complex test page for a Smallsite Design site has 15 warnings only, being 13 of those for cache-busting patterns, and 2 for a CSS option that is supposedly not yet implemented in Firefox for Android. All these are according to the Edge developer tools, which are radically different from what other browsers will list. Really, to use the tools for warnings without being overloaded requires a lot of experience.