[minutes] Internationalization telecon 2013-12-15


Text version follows:

Internationalization Working Group Teleconference

12 Dec 2013



    See also: [3]IRC log

       [3] http://www.w3.org/2013/12/12-i18n-irc


           aphillip, matial, JcK, David_Clarke, Richard, Jan


           Addison Phillips

           Addison Phillips


      * [4]Topics
          1. [5]Agenda
          2. [6]Action Items
          3. [7]Info Share
          4. [8]RADAR
          5. [9]CSS Text
          6. [10]Charmod
          7. [11]CSS Text
          8. [12]AOB?
      * [13]Summary of Action Items


Action Items


      [14] http://www.w3.org/International/track/actions/open

    close ACTION-274

    <trackbot> Closed ACTION-274.

    close action-273

    <trackbot> Closed action-273.

    close action-272

    <trackbot> Closed action-272.

Info Share



      [15] http://www.w3.org/International/wiki/Review_radar

CSS Text

    addison: start to forward comments that are not objected to





      [17] http://www.w3.org/International/docs/charmod-norm/

    1) In 1.3 "Background", we find: "Use of control codes for
    various purposes (e.g. bidirectionality control, symmetric
    swapping, etc.)" I am not sure what control codes are meant for
    symmetric swapping. The ones I know of are deprecated (U+206A
    and U+206B) and as far as I know are not supported by any
    implementation, so maybe they are not a good example.

    addison: will remove mention of symmetric swapping

    richard: that section will be significantly edtied

    13) Ibidem, the paragraph starting with " Unicode defines two
    types of equivalence " then mentions "canonical decomposition"
    without defining this term. I think that some explanation or a
    reference would be helpful.

    mati: needs a definition here

    16) In the table of Compatibility Equivalence, I don't
    understand the examples for Breaking Differences (I only see an
    hyphen), Circled (there should be 2 glyphs, one circled and one
    not circled), Squared characters (I don't distinguish 2
    characters), fractions (only one glyph), Others (only one
    combination). It seems to me that each example should present
    at least 2 glyphs or sets of glyphs which are deemed

    addison: need to clean up that table: it's not clear

    20) I would like to see some justification for Req 6
    "Implementations must not normalize any wildebeest during
    processing, storage, or exchange except with explicit
    permission from the user.", especially as processing is
    concerned (how can we mandate what an implementation does for
    processing?). All the more since the preceding req praises the
    use of NFC.

    addison: doesn't say "don't use NFC", it says "don't alter the
    normalizaiton form of a document"

    mati: needs more explanation

    23) In Req 18, like in Req 6, I have difficulty seeing how we
    can forbid an implementation to (de)normalize for processing.
    Only the app knows what it wants to achieve. Note that this req
    does not mention storage, while req 6 does. Is it intentional?

    [I] Implementations MUST NOT alter the normalization form of
    content being exchanged, read, parsed, or processed except when
    required to do so as a side-effect of transcoding the content
    to a Unicode character encoding, as content might depend on the
    de-normalized representation.

    mati: add a few sentences defining the requirements

CSS Text



    (1) In this type of document, where very fine distinctions are
    important to reader understanding, the use of "character"
    should be avoided, not used informally in some places to mean
    "grapheme cluster" and in other places to mean other things.
    This is adequately flagged in Addison's comments, but I posibly
    feel more strongly about it than he does.

    (2) A number of requirements or suggstions in the document
    require knowing the language in which the document is intended
    to be interpreted, sometimes down to a level of granularity
    that includes locale information. Since it is possible to have
    a document for which the language is unknown, the document
    should be very clear that those actions are not possible and
    should probably not be guessed at. There is a hint of this in
    the statements in Section 2.1 [CUT]

    jck: lots of places where there is very close detail for fairly
    narrow cases or contexts, but the generalized cases are more

    addison: corner cases don't generalize

    (3) Contrary to the assertion in the text, case distinctions
    can affect content, meaning, or at least document correctness.
    As a trivial example, consider the possibility of accidentally
    lower-casing sentences of German text that contain embedded
    nouns. In part as a consequence, the discussion in Section 2.1
    about case distinctions and operations should clearly be
    identified as dependent on language information and impossible
    (or at least unwise) to appl[CUT]

    addison: don't agree that the operations shouldn't work, but
    the tailoring (or lack thereof) when no or limited language
    informatoin needs to be explicit in the document

    jck: yes

    (4) "Anonymous inline" is not defined. "Inline" really isn't
    either and is extensively used in places where its precise
    meaning is important. Similar issues occur with "Out-of-flow"
    in Section 5.1 and with other terms elsewhere. If the
    expectatation is that no one will try to read this document
    without having read and internalized all of the terminology in
    [CSS21] and [CSS3-WRITING-MODES], that should probably be made
    a lot more clear in Section 1.3 an[CUT]

    addison: agree should link to CSS doucments; these terms are
    meaningful to the CSS illuminati

    (5) The discussion of line termination is very hard to follow.
    It isn't clear from reading it whether CSS prefers CRLF, LF, or
    other forms in output or whether it intends to provide a
    suggestion. The document itself appears to prefer CRLF in some
    places and LF only in others (e.g., 4.1.2). If nothing else, I
    hope we can agree that switching conventions in a single
    document or rendering is probably a bad idea.

    jck: probably should prefer a line break form
    ... they assume one understands CSS

    addison: syntax document should define these, no?
    ... can do via reference

    (6) Tabs are used for two quite different things in document
    formatting. One is simple intention from the reference margin,
    for which a tab length is sufficient. The other is table
    layouts, for which column positions are far more relevant than
    a nominal width (and for which widths may not work or may
    require significant interpretation). The current text appears
    to ignore that second case.

    UAX #14 is not particularly helpful in that regard.
    Incidentally, the reference given is to a different version of
    UAX #14, with different authorship, than the document to which
    the link in that reference points. That would normally be
    trivial but, since the CSS text document says that the line
    breaking classes of UAX #14 must be honored and UAX #14
    continues to change and (I infer from comparisons) become more
    specific, there is potential for the two d[CUT]

    jck: needs to be stable reference to a specific UAX14

    addison: needs to at least be looked at to ensure that
    intention isn't changed or that it doesn't break CSS conformity

    jck: also check UAX44 conformity

    (6) Tabs are used for two quite different things in document
    formatting. One is simple intention from the reference margin,
    for which a tab length is sufficient. The other is table
    layouts, for which column positions are far more relevant than
    a nominal width (and for which widths may not work or may
    require significant interpretation). The current text appears
    to ignore that second case.

    This property determines the tab size used to render preserved
    tab characters (U+0009). Integers represent the measure as
    multiples of the space character's advance width (U+0020).
    Negative values are not allowed.

    addison: suggest alternate wording?

    (7) Using 5.2 as an example (the problem seems to occur
    elsewhere), "this property is, at least in this version,
    applicable only to CJK text" should be stated right after the
    property is introduced in the heading, not placed in a note at
    the end of the section. That situation also probably makes
    "Applies to" in the colored box under the title misleading if
    not wrong: apparently, while the property can be applied to any
    element, it is meaningless for most[CUT]

    <matial> I have to leave. Bye.

    jck: needs to be explicit about what the line-break
    applicability is

    (8) In the introduction to Section 6, it may be just my
    ignorance or fuzzy-headed-ness, but "...hyphenation may also
    alter the spelling of a word" and "...it must have no effect on
    ... text selection or searching" seem contradictory to me
    unless the intent is really to say "don't even think about
    searching a document after CSS rules have been been applied".
    The latter is a strong restriction especially given the
    tendency to render documents into page-imag[CUT]

    (9) Section 6.2 states that overflow wrapping "only has an
    effect when 'white-space' allows wrapping". Unless the negative
    was intended, that confuses me -- one would normally want
    overflow wrapping to be available to specify exactly those
    situations in which more conventional wrapping, such as that
    which 'white-space" would allow, is not helpful or available
    and most of the text in the section seems consistent with that

    It would probably be good to have some discussion of what is
    supposed to happen in the case of overflow if all forms of
    wrapping are prohibited. Is text truncation acceptable?

    (10) The discussion of Justification in Section 7 appears to be
    missing a rule / property that reflects the policies of many
    publishers that line text is not to be expanded past the point
    of ugliness in order to preserve justification. Those rules are
    often expressed as a percentage of expanded white space or
    equivalent. As an example, many publishers would consider

    jck: need some qualifying words or some substantive text about
    bad breaks

    addison: agree

    (11) I last sat in on a typography class around 40 years ago,
    but I believe that the opposite of tracking (as described in
    Section 8.2) is kerning. Kerning narrows letter space rather
    than increasing it. It is usually letter-pair-specific and may
    be type style specific as well. Should it be mentioned?

    addison: (discusses)

    (12) Is there some intention and value to the centered column
    in "stops and commas"in Section 9.2? I find it distracting and
    hard to read.

    addison: make sense to me

    (14) Note that it is _very_ common to hang various members of
    the bullet and digit families, the latter sometimes punctuated
    with stops or parentheses. Those symbols and numerals are not
    listed in Section 9.2 and seem to not be covered in Section 9
    at all.

    addison: "light" on the documentation
    ... not about "bullet hang", but not clear about that?


Summary of Action Items

    [End of minutes]

Received on Monday, 16 December 2013 17:30:37 UTC