Miscellaneous editorial improvements.

[skynavga]

• section 8.1.[3456]

• remove "such as div, p, span and br" from notes

• section 9.1.{1,5}

• add note indicating that no text node descendant
  is significant for the purpose of performing [construct anonymous
  span]

• section 10.4.2.1

• change "is not associated with" to "does not specify" in note

• section 10.4.3.2

• add note (or text) indicating that computed value may be
  further resolved at either layout or rendering time when (1)
  such resolution is required by the semantics of a specific property
  or the information required to perform the resolution is not
  available until layout or rendering;

• section 10.4.3.2

• add termdef of "resolved computed value"; add termrefs
  at reference points (see tts:lineHeight and possibly elsewhere);

• section 10.4.4.2

• step (3), change "for each nested style element" to "for each
  conditionally included nested style element" or add note to this
  effect;

• section 10.4.4.2

• step (5), use inline animation term to refer to animate and set
  elements;

• section 10.4.4.2

• step (5), change "for each immediate animation element" to "for
  each conditionally included immediate animation element" or add note
  to this effect;

• section 10.4.4.3

• add "if possible" to step (4)(a); add note indicating possible cases where it is
  not possible, and that further value resolution may occur;

• section 11.3.2.1

• change "requires use" to "requires support or use";

[nigelmegitt]

If you're adding a note about the mandatory semantics of presentation processing including ISD construction and synchronic flow processing then please do also mention something equivalent to the text in §11.3.1:

Any implementation is permitted provided that the externally observable results are consistent with the results produced by this model.

[nigelmegitt]

• section 10.4.2.1

  • change "is not associated with" to "does not specify" in note

I think this needs to say "neither specifies itself nor references a style that specifies" - presumably the "associated" wording was intended to accommodate either direct or referential specification of the tts:fontFamily attribute.

[nigelmegitt]

• section 10.4.4.2
  ...
  - step (5), remove "(set)" parenthetical;

We should disambiguate "animation element" from "animation element". I suggest creating a term definition for "animation element" and referencing it wherever that term is used.

[nigelmegitt]

• section 10.4.4.3
  • change "following sub-steps:" to "following sub-steps(if possible):"; add note indicating possible cases where it is not possible, and that further value resolution may occur;

The "if not possible" presumably applies to both sub-steps, not each individually. That is, if the first sub-step fails, do not go on and attempt the second sub-step. In that case, though, some of the _P_s will end up with a category that is not "computed". This needs to be noted, and I am not sure how a processor is supposed to deal with them. Does that mean those properties must be ignored for downstream presentation processing? Can they be used in transformation processing?

It also means that the definition of the term "computed style set" now includes some styles that are not in fact computed, which is non-intuitive to say the least.

Also, the wording is "the following ordered sub-steps".

[skynavga]

@nigelmegitt re:

If you're adding a note about the mandatory semantics of presentation processing including ISD construction and synchronic flow processing then please do also mention something equivalent to the text in §11.3.1:

Moved this task into #905.

I think this needs to say "neither specifies itself nor references a style that specifies" - presumably the "associated" wording was intended to accommodate either direct or referential specification of the tts:fontFamily attribute.

No. It means does not specify (in this specific example code).

We should disambiguate "animation element" from "animation element". I suggest creating a term definition for "animation element" and referencing it wherever that term is used.

I've dealt with this specific issue (in context) by employing references to the [inline animation] term.

The "if not possible" presumably applies to both sub-steps, not each individually. That is, if the first sub-step fails, do not go on and attempt the second sub-step. In that case, though, some of the _P_s will end up with a category that is not "computed". This needs to be noted, and I am not sure how a processor is supposed to deal with them. Does that mean those properties must be ignored for downstream presentation processing? Can they be used in transformation processing?

It also means that the definition of the term "computed style set" now includes some styles that are not in fact computed, which is non-intuitive to say the least.

Also, the wording is "the following ordered sub-steps".

Actually, what I mean is do (a) if possible, then do (b) regardless of whether (a) was possible. The result will still be called a computed value, but if it were not possible to resolve (during this procedure) then it will be subject to further resolved computed value processing, about which see improvements to 10.4.3.2.