Re: [css-text] comments from DPub IG (Fwd)

On 11/11/2013 11:20 PM, fantasai wrote:
>
> Dear Digital Publishing IG,
> Please in the future just send a message to the www-style
> mailing list and CC yourselves. This will let us respond
> directly and thread a cross-posted discussion with you. :)
>
>> 2. In section 1.3, after the example:
>> "Within this specification, the ambiguous term character is used
>> as a friendlier synonym for grapheme cluster. See Characters and
>> Properties for how to determine the Unicode properties of a
>> character."
>> "A letter for the purpose of this specification is a character
>> belonging to one of the Letter or Number general categories in
>> Unicode. [UAX44]"
>> If I replace 'character' in the second paragraph with 'grapheme
>> cluster', I am not sure I get a reasonable answer. For instance,
>> is U+0067  + U+0308 a letter? I don't think U+0308 is, does that
>> disqualify the whole cluster? Or is this a different use of the
>> term character? Does Unicode define such clusters as belonging
>> to all the groups all the code points belong to?
>
> Ah, that's referring to some text that was recently removed from
> Writing Modes. Here's the old version:
>    http://www.w3.org/TR/2012/WD-css3-writing-modes-20121115/#character-properties
>    #  For the purposes of CSS Writing Modes, the properties of a
>    #  grapheme cluster are given by its base character—except [...]
>
> I'll have to restore that text, will follow-up on that with a link...

Link:
   http://dev.w3.org/csswg/css-text/#character-properties

Note, we also rewrote the section on grapheme clusters as follows:
   http://dev.w3.org/csswg/css-text/#characters

>> 3. The only place the spec mentions that text-transform should
>> affect line breaking is in an informative example (#2), at least
>> that I saw. Should this be mentioned in a normative section? Some
>> line breaking changes are obvious (for instance, changing the
>> width of the glyphs will alter line breaking), but others are
>> more obscure (for instance, transformation to full width).
>
> This is implied by the ordering in Appendix A:
>    http://dev.w3.org/csswg/css-text/#order
>
> However I can add a note to clarify that point to the text-transform
> section.

This is done:

   # Note that, as defined in Text Processing Order of Operations,
   # text transformation affects line-breaking and other formatting
   # operations.

>> 4. From 5.1, last bullet point:
>> "For line breaking in/around ruby, [...]
>> However, I would expect the correct breaking would be neither of those, but rather:
>> だ[1]大分[3]日数[5]が
>> I am not certain how I can interpret the spec to generate those line breaks.
>
> Good point. This sentence was written before we had a reasonable
> draft of the ruby spec to refer to, so I will replace this with
> a pointer to that spec, which has a much more involved discussion
> of ruby line-breaking:
>    http://www.w3.org/TR/css-ruby-1/#line-breaks
>
> I'll drop a link to the updated text once I get in the edits. :)

(Fwiw, this is done.)

>> 9. In "7.1. Text Alignment", "text-align: start end" sounds a
>> lot like "text-align-last: *", giving special treatment to the
>> first line instead of the last line, with less control. Perhaps
>> there should be a separate property for controlling the first
>> line alignment, just like there is for controlling the last line.
>> Then text-align could become a shorthand. For example:
>>
>> text-align: center == text-align-first: center,
>> text-align-middle: center, text-align-last: auto
>> [...]
>
> I think I will re-raise this to the WG, will reply with an update.

The CSSWG discussed this at the Seoul F2F and decided
  1. To make text-align a shorthand, as you suggest.
  2. to defer 'text-align-first' to the next level
See http://lists.w3.org/Archives/Public/www-style/2014Jun/0167.html

Please let us know if you have further comments on this or anything else!

~fantasai

Received on Monday, 21 July 2014 16:14:01 UTC