Re: CSS 3 Comments

I'm not sure I would request the different indent behavior after a break
without first understanding if this different rendering is limited to just
indents. Are there other styles that might be different at a page boundary?
Could there be even/odd differences, or two-up facing page changes? While
it might be the correct solution, I think it is a bit hasty to rush one of
our use cases into a requested solution. I would argue we leave it off this
list, but defer issues about styling changes based on page to our
face-to-face discussion with the CSS wg.

+1 to the various other comments, though.


On Tue, Nov 5, 2013 at 2:03 AM, Éric Aubourg <eric@aubourg.net> wrote:

> This is great work. I have very little to add:
>
> - I fully support point 1, hanging-punctuation, and as a related topic,
> optical margin alignment options would be a plus.
>
> - In example 8, there is an extra nun in نوشتنن, at the end. I think it
> should be نوشتن.
>
> - I would add a request for a specific text indent after a page break (an
> issue that was already discussed in this list about pagination...).
>
> Cheers,
> Éric
>
>
>
> Le 31 oct. 2013 à 21:31, Brady Duga <duga@google.com> a écrit :
>
> > OK, here are my comments from a review of CSS 3 Text. If we can get any
> others added ASAP, we can try to have these sent out to the CSS WG so they
> can have time to review before TPAC.
> >
> > Comments from Brady
> >
> > 1. It would be great to keep the ‘hanging-punctuation’ property, though
> I understand it is awaiting implementations. What is the timeline here?
> That is, when would an implementation need to appear in order to preserve
> this property?
> >
> > 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?
> >
> > 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).
> >
> > 4. From 5.1, last bullet point:
> > "For line breaking in/around ruby, the base text is considered part of
> the same inline formatting context as its surrouding content, but the ruby
> text is not: i.e. line breaking opportunities between the ruby element and
> its surrounding content are determined as if the ruby base were inline and
> the ruby text were not there." [Also, note the typo: surrouding]
> > The first part of this sounds like breaks are allowed in a single run of
> base text (difficult, I assume), but the second part sounds like breaks are
> only allowed at boundaries of the ruby element. It seems like, in practice,
> breaks are allowed anywhere in a ruby element a break would be allowed if
> such a location is also a base text boundary.
> > For example, consider this snippet:
> > <p>だ<ruby>大分<rt>だいぶ</rt>日数<rt>ひかず</rt></ruby>が</p>
> > From "the base text is considered part of the same inline formatting
> context as its surrouding content, but the ruby text is not", I might
> imagine breaks as though the text were written
> > だ[1]大[2]分[3]日[4]数[5]が
> > But, this: "i.e. line breaking opportunities between the ruby element
> and its surrounding content" seems to imply this only covers line breaks at
> the boundary of the ruby element itself. In which case I would get:
> > だ[1]大分日数[5]が
> > 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.
> >
> > 5. In "5.2. Breaking Rules for Punctuation", in this sentence and the
> one below it that is similar:
> > "If the content language is Chinese or Japanese, then additionally allow
> (but otherwise forbid) for ‘normal’ and ‘loose’:"
> > It's not clear to me what the 'otherwise' applies to - is it the
> 'normal' and 'loose', so it is forbidden in strict when the language is
> Chinese or Japanese? Or does it apply to the language as well, so it is
> forbidden in strict for Chinese and Japanese, and for any value for all
> other languages? If the latter, then the implication is that in eg English,
> breaks before  U+2010 are forbidden. However, the later clarifying note
> seems to indicate that non-CJK text is only affected when the language is
> Chinese or Japanese.
> >
> > 6. In "6.1. Hyphenation Control", the sentence: "The UA is therefore
> only required to automatically hyphenate text for which [...]"
> > Is it the case that a UA is ever *required* to automatically hyphenate?
> Perhaps this should be weakened to "Therefore, if no language is specified
> or no hyphenation resource is available to the UA for a specified language,
> the UA may choose to treat 'auto' as 'manual'."
> >
> > 7. Not really wrong, but the order of property names in the title for
> 6.2 is the opposite of the order just below, in the definition,
> ‘word-wrap’/‘overflow-wrap’ vs overflow-wrap/word-wrap. Just a little weird.
> >
> > 8. "6.2. Overflow Wrapping", so sayeth Yoda:
> > "[...] and grapheme clusters must together stay as one unit." Maybe
> "stay together" instead?
> >
> > 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
> > text-align: center right == text-align-first: center, text-align-middle:
> center, text-align-last: right
> > text-align: left center right == text-align-first: left,
> text-align-middle: center, text-align-last: right
> >
> > This makes the proposed 'text-align: start end' become 'text-align:
> start end end' instead.
> > Of course, the down side is this would require two new properties
> ("text-align-first", "text-align-middle"). Not sure if this is worth
> considering at this point, but it seems odd to handle this in different
> ways for different special lines. Perhaps drop 'start end' for now and
> reconsider for level 2?
> >
> > 10. What impact do zero-width letters and zero-width word-separators
> have on the inter-word and distribute text-justify values?
> >
> > 11. I take exception to example 10 in 7.3.5. Both the greedy algorithm
> and the Knuth/Plass algorithm are O(n). What performance metrics are you
> using to determine the relative speed of these algorithms? Additionally,
> Knuth/Plass is easily adapted to other languages, so it applies equally to
> example 11. Perhaps "harder to implement" instead?
> >
> > 12. "8.1. Word Spacing": Can this property be used to make words
> overlap? That is, are values less than -100% allowed? 'letter-spacing' says
> there may be UA limitations for such things.
> >
> > 13. letter-spacing says it doesn't apply at the start/end of a line.
> Should there be similar text be in word-spacing?
> >
> > 14. At the end of word-spacing (just after example 13), the text
> "Word-separator characters include [...]" - is this considered an
> exhaustive list? If so, this should be made clear, otherwise some sort of
> guidelines for deciding what else might be a word-separator would be useful.
> >
> > 15. In "8.2. Tracking", just after example 14: "[...] to the innermost
> element element that contains the two characters [...]"
> > Just one element?
> >
> > 16. And just after example 15: "Letter-spacing ignores zero-width
> characters (such as those from the Unicode Cf category)." Does this mean
> characters that are defined to be zero-width, or characters whose width
> might be zero? For instance, given:
> >
> > span.zero { display: inline-block; width: 0; }
> > p {letter-spacing: 1em;}
> >
> > <p>a<span class="zero">b</span>c</p>
> >
> > Would this be viewed as "a bc" (1em after 'a', zero-width 'b', 1em after
> end of 'b', 'c') or as 'a' with 'b' and 'c' on top of each other 1em later?
> >
> >
> > 17. In "9.1. First Line Indentation", it is not clear to me what
> 'each-line' is doing. Does this simply make the indent of lines after hard
> line breaks indent, and they wouldn't otherwise? If so, perhaps it should
> say "In addition to the first line of a block container each line after a
> forced line break are also affected. Lines after a soft wrap break are
> still not affected." Or maybe there is something else going on I just don't
> understand.
> >
> > 18. In "9.2. Hanging Punctuation", the 'Animatable:' table entry has a
> spurious gt ('>').
> >
> > 19. Appendix A, steps 5.iv and 5.v - how do you do letter and word
> spacing without knowing the font in use? For instance, a percent value for
> letter spacing depends on the advance measure of the character, which will
> depend on the current font.
> >
> > 19. Appendix B:
> > "[...]  is to help UA developers to implement default stylesheet [...]"
> - 'a default stylesheet'? Or maybe 'the default stylesheet'? Or even
> 'default stylesheets'?
> >
> >
>
>