Meeting minutes
discuss detecting readiness for browser fallback, issue: w3c/IFT#223
Discussed the implications of adding a per codepoint readiness check. There's concerns if that readiness check is used to drive loading decisions. Came to the conclusion that if we add readiness check we should say it doesn't drive loading. Loading (ie. the subset definition used for loading) should be based on shaping boundaries, such as words or
higher depending on what the user agent is using.
Readiness is an approximation of correctness used to make fallback decisions, not necessarily completely correct.
Therefore in some cases there may be flashing.
effect of readiness and added support for UVS sequences (w3c/IFT#222 )
Discussion of how readiness and the proposed UVS mechanism interact. Readiness at the codepoint level won't always be correct in this case. Readiness can be accurately assessed at the word/shaping boundary, but that may cause fallbacks for previously rendered parts of the word when new characters are introduced.
Skef suggested a model where you assess readiness in across the word in the direction of the writing script and stop when it the check first fails.
This is not always correct (eg. editing a word in the middle), but works for most common cases.
Garret suggested next steps would be to talk to some browser people to see what they consider acceptable or not.
Discussed implications of patch ordering. We currently don't recommend a specific ordering for dependent patches, clients will likely use a heuristic to make a good selection here. Need to decide if we want to provide harder guidance in the spec for this.
<Vlad> We'll continue the discussion next week on Tuesday, Oct. 29.