The current spec says:
The collection of IFT technologies utilizes a single shared opt-in mechanism. Each method does not use its own opt-in mechanism; instead, the webpage opts into the IFT technologies as a whole, and the browser and server negotiate to decide which specific method will be employed.
This, and on my reading the rest of the spec, implies that access to IFT facilities is all-or-nothing (beyond the choice between "methods").
This restriction may prevent some services from using any of the new IFT technologies. If, for example, the built-in options for caching were not sufficient for some service it would have to duplicate all of the IFT functionality, presumably with javascript-level code. This is quite restrictive and hinders experimentation that might eventually be folded into future versions of the specification. It's also not in the spirit of contemporary browser technology, which generally allows some control over what happens on the client side via the DOM interface or other Javascript APIs.
It seems as if there are three subsystems of IFT that could provide separate benefits to different implementations:
- The scanning of the document to produce a set of subset parameters (code points and features)
- The communication protocol with the server
- The code that applies an augmentation to an earlier subset or augmentation to produce a new subset font. (And, if it is different from loading a non-subset font, the code that accepts an initial subset.)
Some use cases:
A service wants to use all three subsystems but do some client-side "super-setting" as mentioned in #93. To do that it might include some Javascript that wraps-around or otherwise intervenes between the document scan and the communication protocol to modify the subset parameters.
A service has caching requirements incompatible with the IFT communication protocol. Accordingly, it reuses the document scan and augmentation subsystems but replaces the communication protocol with its own bespoke system.
To increase the likelihood of caching a system uses a coarser grain of subsets and only ever augments those subsets. When subset X has been augmented once and needs to be augmented again, it keeps a copy of X around and re-augments against it. The system therefore needs to intervene both between the document scan and the protocol (to pick the right subset/augmentation combinations) and between the receipt of the subset-or-augmentation and the augmentation code (to provide the right building blocks to the latter).
The current spec says:
This, and on my reading the rest of the spec, implies that access to IFT facilities is all-or-nothing (beyond the choice between "methods").
This restriction may prevent some services from using any of the new IFT technologies. If, for example, the built-in options for caching were not sufficient for some service it would have to duplicate all of the IFT functionality, presumably with javascript-level code. This is quite restrictive and hinders experimentation that might eventually be folded into future versions of the specification. It's also not in the spirit of contemporary browser technology, which generally allows some control over what happens on the client side via the DOM interface or other Javascript APIs.
It seems as if there are three subsystems of IFT that could provide separate benefits to different implementations:
Some use cases:
A service wants to use all three subsystems but do some client-side "super-setting" as mentioned in #93. To do that it might include some Javascript that wraps-around or otherwise intervenes between the document scan and the communication protocol to modify the subset parameters.
A service has caching requirements incompatible with the IFT communication protocol. Accordingly, it reuses the document scan and augmentation subsystems but replaces the communication protocol with its own bespoke system.
To increase the likelihood of caching a system uses a coarser grain of subsets and only ever augments those subsets. When subset X has been augmented once and needs to be augmented again, it keeps a copy of X around and re-augments against it. The system therefore needs to intervene both between the document scan and the protocol (to pick the right subset/augmentation combinations) and between the receipt of the subset-or-augmentation and the augmentation code (to provide the right building blocks to the latter).