Clarify text combination.

[cconcolato]

1. The spec says:
   "For the purpose of determining applicability of this style property, each character child of a p element is considered to be enclosed in an anonymous span."
   I know this is common text used plenty of times, but I find it nevertheless confusing and possibly wrong in this case. I checked how the following paragraphs would render in TTPE and the results are different.

セミ25の鳴き声

セミ25の鳴き声

I think we should change the text (throughout the spec) to say:
"For the purpose of determining applicability of this style property, the [construct anonymous spans] procedure applies."
because the anonymous span construction procedure is clearer, creates on span per text node and removes unnecessary ones (nested spans).
This relates to #784.

2. The spec says"
   "If the specified value of this attribute is digits, then all affected characters should be combined if they are a sequence of a digits which length is equal to or less than a specified count, or two (2) if no count is specified."

This seems to be contradictory to the example:
AB34
Here all the affected characters do not form a sequence of digits.
(Note: I tested in TTPE and it does not seem to be supported)

Also it is not clear what would happen if multiple sequences of digits would be present like in:
AB34AB34
or
AB3434AB343434

I think it should say:
"If the specified value of this attribute is digits, then among all affected characters, the longest sequences of consecutive digits of length L or less (where L is the specified count or two (2) if no count is specified) are formed; and within each such sequence the characters are combined."

3. CSS limits the range: "Integers outside the range 2-4 are invalid."
   We should do the same.

4. The spec says:
   "Combination applies after all affected characters have been processed as if a horizontal writing mode applied."
   Are we clear that the horizontal mode only applies for combination and not for other features such as shear (See Add support for block level shear. #784).

[skynavga]

Regarding

The spec says:
"For the purpose of determining applicability of this style property, each character child of a p element is considered to be enclosed in an anonymous span."
I know this is common text used plenty of times, but I find it nevertheless confusing and possibly wrong in this case.

I think we should change the text (throughout the spec) to say:
"For the purpose of determining applicability of this style property, the [construct anonymous spans] procedure applies."
because the anonymous span construction procedure is clearer, creates on span per text node and removes unnecessary ones (nested spans).

I do not agree with this proposed change, and believe it actually makes the text more difficult to read. The paragraph you are questioning is intended to describe the special case of applicability when it comes to character (text node) children of a p element. Without this text, a reader may think that the property applies only to explicit span elements, but not anonymous spans.

Furthermore, the [construct anonymous spans] procedure operates independently from these statements, and, moreover, it is not the intent of the (existing) language to define an alternative interpretation of anonymous span construction.

Nonetheless, I am willing to add an informative note in the prologue of 10.2 that refers the reader to the [construct anonymous spans] procedure when interpreting the details of anonymous spans.

[skynavga]

Regarding your second point

The spec says"
"If the specified value of this attribute is digits, then all affected characters should be combined if they are a sequence of a digits which length is equal to or less than a specified count, or two (2) if no count is specified."

I think it should say:
"If the specified value of this attribute is digits, then among all affected characters, the longest sequences of consecutive digits of length L or less (where L is the specified count or two (2) if no count is specified) are formed; and within each such sequence the characters are combined."

The use and definition of digits came from an earlier CR of CSS3 WM [1]. It appears that this keyword has now been removed entirely [2], leaving only none and all.

To resolve this point, I suggest we remove the digits keyword. This would also address your third point.

[1] https://www.w3.org/TR/2015/CR-css-writing-modes-3-20151215/#text-combine-upright
[2] https://www.w3.org/TR/css-writing-modes-3/#text-combine-upright

[skynavga]

I do not understand your fourth point:

The spec says:
"Combination applies after all affected characters have been processed as if a horizontal writing mode applied."
Are we clear that the horizontal mode only applies for combination and not for other features such as shear (See #784).

Please elaborate what you mean by "not ... shear". In the current specification, shear applies to individual (spacing) glyph areas irregardless of whether text combination applies.

[cconcolato]

On the first point, the question is: should each character be enclosed in an anonymous span or are sibling anonymous spans merged and nested anonymous spans removed?

I'm concerned that that sentence gives a different result from the [create anonymous span] procedure. I don't understand why you say this "operates independently", the [create anonymous span] procedure is referenced from [flow transformation].

Also clearly enclosing each character in a span does not give the correct result.

[cconcolato]

On the 4th point, assuming the fontShear property is applied to individual glyph areas, the shear transform depends on the inline progression direction:

If the inline progression direction corresponds to the [X/Y] axis, then the 2D shear transformation is described ...

which in turns depends on the writing mode:

[inline progression direction]
The direction taken by the progression of inline areas in some formatting context. In the context of horizontal writing modes, the inline progression direction is typically left-to-right or right-to-left; whereas, in the context of vertical writing modes, it is typically top-to-bottom.

defines by the tts:writingMode

The tts:writingMode attribute is used to specify a style property that defines the block and inline progression directions to be used for the purpose of stacking block and inline areas within a region area.

In the case of vertical text with tate-chu-yoko, given that tts:writingMode sets a vertical writing mode, the shear transform is the one corresponding to the Y axis.

[skynavga]

This thread is somewhat overtaken by events (see #803).

As for the 4th point above, even though a vertical writing mode applies to the primary line areas, the use of tate-chu-yoko causes the effective creation of an inline block set in horizontal writing mode. Therefore, when shear is applied to individual glyphs contained within the inline block, the shear direction is different from shear applied to individual glyphs in the same line outside the inline block.

[cconcolato]

causes the effective creation of an inline block set in horizontal writing mode

At the very least, this should be said explicitly in the spec. The current text can be interpreted differently.
Then, that seems to be another reason for #784

[skynavga]

All of the issues discussed above have been addressed by a combination of #803, #807, #818. Therefore, I am marking this for no spec change and closing.