15:51:16 RRSAgent has joined #i18n 15:51:16 logging to http://www.w3.org/2013/12/12-i18n-irc 15:51:26 trackbot, prepare teleconference 15:51:28 RRSAgent, make logs world 15:51:30 Zakim, this will be 4186 15:51:30 ok, trackbot; I see I18N_CoreWG()11:00AM scheduled to start in 9 minutes 15:51:31 Meeting: Internationalization Working Group Teleconference 15:51:31 Date: 12 December 2013 15:51:40 Agenda: https://lists.w3.org/Archives/Member/member-i18n-core/2013Dec/0008.html 15:51:46 Chair: Addison Phillips 15:51:51 Scribe: Addison Phillips 15:51:55 ScribeNick: aphillip 15:52:03 agenda+ RADAR 15:52:07 agenda+ CSS Text 15:52:13 agenda+ CSS Syntax 15:52:17 agenda+ Charmod 15:52:24 rrsagent, draft minutes 15:52:24 I have made the request to generate http://www.w3.org/2013/12/12-i18n-minutes.html aphillip 16:00:03 matial has joined #i18n 16:00:19 I18N_CoreWG()11:00AM has now started 16:00:27 +aphillip 16:00:31 zakim, who is here? 16:00:31 On the phone I see aphillip 16:00:33 On IRC I see matial, RRSAgent, Zakim, aphillip, r12a, trackbot 16:00:42 agenda? 16:01:01 David has joined #i18n 16:01:04 JcK has joined #i18n 16:01:17 +??P22 16:01:26 zakim, ??p22 is me 16:01:26 +matial; got it 16:01:39 +JcK 16:02:11 +David_Clarke 16:02:20 zakim, who is here? 16:02:20 On the phone I see aphillip, matial, JcK, David_Clarke 16:02:21 On IRC I see JcK, David, matial, RRSAgent, Zakim, aphillip, r12a, trackbot 16:02:30 zakim, dial richard 16:02:30 ok, r12a; the call is being made 16:02:32 +Richard 16:03:39 Topic: Agenda 16:04:01 Topic: Action Items 16:04:08 http://www.w3.org/International/track/actions/open 16:04:27 close ACTION-274 16:04:27 Closed ACTION-274. 16:04:39 close action-273 16:04:39 Closed action-273. 16:04:44 close action-272 16:04:44 Closed action-272. 16:05:00 Topic: Info Share 16:05:08 I have made the request to generate http://www.w3.org/2013/12/12-i18n-minutes.html aphillip 16:05:27 agenda? 16:05:32 zakim, take up agendum 1 16:05:32 agendum 1. "RADAR" taken up [from aphillip] 16:05:36 + +1.253.302.aaaa 16:06:24 http://www.w3.org/International/wiki/Review_radar 16:06:50 zakim, +1.253 is Jan 16:06:50 +Jan; got it 16:07:43 agenda? 16:08:02 zakim, take up agendum 2 16:08:02 agendum 2. "CSS Text" taken up [from aphillip] 16:09:43 addison: start to forward comments that are not objected to 16:10:23 zakim, take up agendum 4 16:10:23 agendum 4. "Charmod" taken up [from aphillip] 16:10:32 https://lists.w3.org/Archives/Member/member-i18n-core/2013Dec/0006.html 16:10:42 http://www.w3.org/International/docs/charmod-norm/ 16:11:36 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. 16:12:31 addison: will remove mention of symmetric swapping 16:12:59 richard: that section will be significantly edtied 16:14:31 Zakim, mute me 16:14:31 David_Clarke should now be muted 16:14:45 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. 16:15:00 mati: needs a definition here 16:15:50 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 equivalent. 16:17:14 addison: need to clean up that table: it's not clear 16:17:26 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. 16:20:36 I have made the request to generate http://www.w3.org/2013/12/12-i18n-minutes.html aphillip 16:21:18 addison: doesn't say "don't use NFC", it says "don't alter the normalizaiton form of a document" 16:21:34 mati: needs more explanation 16:21:48 zakim, drop richard 16:21:48 Richard is being disconnected 16:21:49 -Richard 16:21:55 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? 16:22:24 [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. 16:23:27 mati: add a few sentences defining the requirements 16:26:10 agenda? 16:26:20 zakim, take up agendum 2 16:26:20 agendum 2. "CSS Text" taken up [from aphillip] 16:26:46 https://lists.w3.org/Archives/Member/member-i18n-core/2013Dec/0009.html 16:26:56 (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. 16:27:37 (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] 16:29:57 jck: lots of places where there is very close detail for fairly narrow cases or contexts, but the generalized cases are more "hand-wavy" 16:30:35 addison: corner cases don't generalize 16:31:14 (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] 16:32:56 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 16:32:58 jck: yes 16:33:09 (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] 16:34:29 addison: agree should link to CSS doucments; these terms are meaningful to the CSS illuminati 16:34:49 (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. 16:37:53 jck: probably should prefer a line break form 16:38:11 ... they assume one understands CSS 16:38:55 addison: syntax document should define these, no? 16:39:11 ... can do via reference 16:39:36 (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. 16:40:49 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] 16:42:18 jck: needs to be stable reference to a specific UAX14 16:43:01 addison: needs to at least be looked at to ensure that intention isn't changed or that it doesn't break CSS conformity 16:43:39 jck: also check UAX44 conformity 16:44:09 (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. 16:47:32 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. 16:49:22 addison: suggest alternate wording? 16:49:37 (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] 16:50:57 I have to leave. Bye. 16:51:08 -matial 16:55:15 jck: needs to be explicit about what the line-break applicability is 16:55:43 (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] 16:58:00 (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 assumption. 16:58:45 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? 17:00:10 (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 17:01:41 jck: need some qualifying words or some substantive text about bad breaks 17:01:44 addison: agree 17:02:12 (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? 17:03:48 addison: (discusses) 17:05:20 -David_Clarke 17:05:34 (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. 17:07:54 addison: make sense to me 17:08:04 (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. 17:11:22 addison: "light" on the documentation 17:11:54 ... not about "bullet hang", but not clear about that? 17:12:46 Topic: AOB? 17:13:36 -JcK 17:13:37 -Jan 17:13:37 I18N_CoreWG()11:00AM has ended 17:13:37 Attendees were aphillip, matial, JcK, David_Clarke, Richard, +1.253.302.aaaa, Jan 17:13:45 rrsagent, make minutes 17:13:45 I have made the request to generate http://www.w3.org/2013/12/12-i18n-minutes.html aphillip 17:13:53 zakim, bye 17:13:53 Zakim has left #i18n 17:14:11 rrsagent, bye 17:14:11 I see no action items