TL;DR: A standard for profiled Web Content would be helpful for a lot of things.
There is a long history of profiling HTML. In some cases these are quite “niche”, in others they are pretty general.
Many of these have been “mobile-oriented” - WML, iMode HTML, cHTML, XHTML basic, AMP, and various others, where performance is often an important motive.
Other use cases for restricted content include web-based email services and other user-generated content such as blog posts or comments, where security is generally the major concern.
There was also the effort to standardise a modularisation of HTML / XHTML. That seems to have been a learning experience rather than a big long-term success, although it is clearly in the same general lines as the current crop.
Rendering efficiently in “mainstream” services - which now includes most of the above scenarios - is part of the motivation for a current group, including AMP, Facebook’s Instant Articles, Telegram’s Telegraph, and so on.
In many respects these seem to be a modern and more effective approach to modularisation - taking advantage of better standards and the “extensible web” to actually work.
A standard way to work with profiles should
- improve performance and security
- give third-party developers confidence to build tools
- help authors to build content that works on multiple platforms
- reduce the amount of work required for accessibility
- help decentralise innovation
The goal of a standard would be to let different forks be built from an agreed baseline, with a framework for incorporating innovations that lets implementations develop independently, but work interoperably.
It’s also, obviously, critical to have something that is actually useful. Maybe one reason the old modularisation effort failed was that it didn’t offer much to content authors or tool developers (including browsers), so there wasn’t an obvious motive for adoption except a top-down directive from some industry, which didn’t really happen.
AMP seems to be sufficiently mature, well-known enough, and appropriately licensed to be a basis for further development. It also seems to be a practical starting point, with a path for extending it in various directions, and people who have been working with it enough to think about it.
But it is an implementation not a standard itself, and there are a couple of problems in making another implementation of it.
As an example, the requirement for sites to declare a CORS policy makes it very difficult to effectively create a new implementation, since by default it will be blocked from the ecosystem. This is a pretty serious limitation for something to become a general standard.
To move from a piece of code to a standard that lets people make interoperable code, we need to document how to make extensions, work out the difference between things that are fundamental and need coordination, and things that can be done in implementations without any real impact on other implementations, …
…and of course people who are interested enough in the idea to work on it.