Using the HTML Meta Topper, Topper-Major, and Topper-Minor Tags
- Specification we’re talking about:
- > Topper, Topper-Major, and Topper-Minor
Users need a quick way to stay up to date on website pages that change. At the same time, the users are busy and creative and don’t want to have to visit the same whole long list of pages every day. While RSS and Atom have their places, they are too cumbersome for smaller website operators to support. Website authors need a simpler way of notifying users of any updates, and sometimes just of major updates.
RSS and Atom require the creation and frequent updating of an additional file, or files, often in a computer language authors don’t use for anything else. Maintaining in another language generally requires learning that language, requiring an investment in time that is lost to content creation. So, it’s no surprise that many authors don’t support RSS or Atom.
An easier way would use coding already provided in the head element of an HTML page. Several elements already indicate a page date or version. The data usually could not be stored at the website that this is about, but a browser or other user agent could copy and store the page URL along with that historical data and, in the future, could invisibly check the website to see if that data has changed. Only if it has changed would the user be notified that there is something new.
And major and minor changes could be differentiated. The website author could code if the change is major or minor in the author’s judgment. The rules for figuring out whether a change is minor or major is whatever rules the author makes up. The specification becomes easier to read when we don’t micromanage the author. Many changes are so minor most users would not see a change at all; and some may be meaningless. A major change might be so major as to represent a complete break with the past for that page. The user could limit visits, to see just major changes. Minor changes in a series even without any major change could be interpreted as adding up over time to a major change the user might want to see. If a user has not used their browser in a long time, changes older than some threshold duration and not yet seen could be treated as one major change.
If a page specifies an automatic refreshment or redirection time (such as with <meta http-equiv="refresh" content="89640; http://example.com" />), the user agent could decline to visit more often than that specifies (unless the user manually visits) and then could automatically visit after every automatic refreshment or redirection time, regardless of a lack of other data changes.
If one URL represents different pages, that’s a problem. For instance, a page with interactivity or timed refreshment might be one where the user desires current awareness for a noninitial state of the page or for initial embedded content. The latter might include a page that has embedded a file named "video.swf" and the embedded file has been changed but without a change to the file name and the page does not reveal that any change occurred. In those cases, a solution, less satisfactory but still somewhat useful, is for the user to schedule the URL for regular visits for current awareness even if no change has been reported.
If one computer with one user agent supports several users with separate accounts, as on Linux systems, the user agent should separate the data storage for each user or account. In this way, privacy should be supported.
A complication this would leave would be for users who maintain lists in multiple browsers. A local server or website could solve that by supporting the sharing of one list for all of one user’s devices, much as Delicious does for bookmarks. An institution could set up a server to share a user’s lists across all devices to save its own employees time or as a membership benefit. A commercial website might offer the public the service of cross-device support, either for a fee or as an inducement to visit advertising-supported content. A user could enter a storage URL into the user agent, and that’s where the historical data for a URL being visited would be kept for comparison.
One design decision was to offer authors the convenience of a choice of ways of coding in conformance with the specification. This increases the number of ways that user agents must recognize compliance with the specification, but there are more website authors than user agent programmers and the purpose of the specification is to lower the burden on website authors in order to increase users’ current awareness of page changes, so the balance was struck.
More advanced options within a user agent might include letting users annotate the URLs. Users might also group the URLs, such as by subject, so that if browser tabs open for several pages due to recent changes, tabs for the same subject (or whatever) would be next to each other.
Even absent such possibilities being implemented, this alternative to RSS and Atom would still work with a user agent that supports it, would save authors time, would leave more time for authors to create more content over time, and would help keep users up to date.