fantasai wrote:
> The earliest revisions of this feature didn't have any automatic
> composition, and so the property did not inherit -- because it
> indicated that the entire contents of this element should be
> composed.
>
> However, doing automatic composition requires an inherited property.
> Although we first had only the manual composition ability, Koji and
> I had sketched out the idea of in the future, expanding
> 'text-combine' be a shorthand setting 'text-combine-all' and
> 'text-combine-auto', which would introduce the auto- composition
> abilities.
>
> Since we're combining both abilities in the spec right now, I think
> we need to make this property split now. (We will still encourage
> authors to use the shorthand, since that will give correct behavior.)
I'm somewhat confused, the primary use case of tatechuyoko in Japanese
vertical text is for simple combinations of digits. Why is there a
need for more complex composition? Wouldn't an inline block using a
different writing mode be equivalent?
I'm not at all clear as to what the "auto" vs. "manual" distinction is
here. You're distinguishing the behavior of the 'all' value from the
'digits' value?
I think if what you're talking about is a complex set of properties to
deal with simple two or three character runs that are auto-squished
into 1em, then I think this is probably overkill. But I guess we
really need to understand clearly what the use case is for this before
evaluating it.
> Note, we also have an open renaming issue on this property. I think
> the top contender was 'force-horizontal'.
I'm not a huge fan of the 'text-combine-horizontal' name but I don't
see 'force-horizontal' as a better name. Given the late nature of
the spec cycle and given that IE is already planning to ship something
called 'text-combine-horizontal' I don't think we should rename this
property unless there's a *very* strong reason. Right now I don't see
that strong reason.
We really, really, really need to stop doing property name changes
close to LC.
~fantasai