[css-text] Agenda+ Open Issues

I've updated the CSS3 Text Disposition of Comments, and there are
quite a lot of open issues that need WG discussion. Here's a bunch
that are ready for discussion:

https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-96

    CSS3 Text specifies that newlines get transformed into either a space
    or nothing depending on their context; transforming to nothing is
    useful for Chinese and Japanese, which don't use spaces -- this allows
    them to use line breaks when formatting source code.
       https://drafts.csswg.org/css-text-3/#line-break-transform

    This transformation is done based on the East Asian Width property of
    the characters immediately before and after the newline: if they are
    both “East Asian” and not Hangul (Korean) the newline disappears.
    The East Asian Width values considered “East Asian” are Fullwidth,
    Wide, and Halfwidth. Ambiguous characters are grouped with Narrow
    (non-East-Asian).

    It was proposed that when lang=zh|ja|yi (Chinese, Japanese, or Yi)
    an Ambiguous character is treated as Wide rather than Narrow.

    The question to the CSSWG is, do we want to make newline transformation
    depend on the content language in addition to EAW context?

https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-102

    The 'tab-size' property accepts an <integer> representing its length
    in multiples of the space character. Should this be animatable, and
    if so, does that mean we should change the definition to use <number>?

https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-108

    There was an issue raised on what properties should affect output
    on copy/paste, and in particular whether text-transform should
    affect it. I was actioned to contact the Editing TF... however the
    discussion seemed not to result in much of a conclusion.

    I see two options here:
      1. Adopt for plaintext copy/paste the proposal in
           https://lists.w3.org/Archives/Public/public-editing-tf/2016Apr/0005.html
         which is to account for only
           * 'display' (block vs. inline, none vs. non-none)
           * 'visibility'
           * generated content (list markers and 'content' insertion)
           * white space collapsing
         (This is analogous to what needs to be handled for speech output.)

      2. Leave it undefined.

    (In both cases, we'd leave richtext/HTML copy/paste undefined.)

https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-110

    There was some discussion on whether enclosed alphanumerics--
    which are categorized as symbols--should be case-transformed.
    Jonathan Kew and John Hudson argued they should not.

    Do we restrict case-transforms to Letters (per spec currently)
    or allow them for all characters?

https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-111

    Another case-transform discussion was what to do with digraphs
    when titlecasing. Jonathan Kew argued that digraphs already in
    upper case should not be titlecased (since this would lowercase
    the second letter).

    I'm inclined to agree, since this is how we treat uppercase
    letters in the middle of a word in general. (Also I don't see
    any other possible behavior for SS.)

https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-114

    A numeric value in 'tab-stop' effectively gives a length value
    as a multiple of the advance measure of a space character.
    The spec neglects to include 'letter-spacing' and 'word-spacing',
    which effectively increase this measure. Is there any objection
    to incorporating those into the measurement?

https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-117

    Currently an unjustifiable line of text falls back to the aligment
    specified for 'text-align-last'. However, if 'text-align-last',
    what then? Currently specified behavior makes a distinction based
    on values of 'text-justify', however it would be simpler to just
    center these cases. Thoughts?

https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-123

    Dave Hyatt would like us to switch our previous resolution on
    'hanging-punctuation' to make it behave as scrollable overflow.
    Would there be any objection to doing that?

https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-122

    How should kerning affect hanging-punctuation? Does it pull the
    kerned character out of the content bounds along with the hung
    punctuation, or do we subtract the amount of kerning from the
    amount of hanging so that the inner character stays within the
    content edge?

Please respond in the correct thread, if possible. ;) (Otherwise
here is fine--but at least split into one reply per topic.) Also,
this entire list of issues needs WG resolutions so is proposed for
the next telecon agenda.

~fantasai

Received on Saturday, 24 September 2016 22:30:16 UTC