- From: Richard Ishida <ishida@w3.org>
- Date: Mon, 16 Dec 2013 17:32:58 +0000
- To: "public-i18n-core@w3.org" <public-i18n-core@w3.org>
Chaps, From the minutes I don't see the status wrt sending comments to the CSS WG. Were any decisions taken in that respect? RI On 16/12/2013 17:30, Richard Ishida wrote: > http://www.w3.org/2013/12/12-i18n-minutes.html > > > > > Text version follows: > > > > Internationalization Working Group Teleconference > > 12 Dec 2013 > > [2]Agenda > > [2] > https://lists.w3.org/Archives/Member/member-i18n-core/2013Dec/0008.html > > See also: [3]IRC log > > [3] http://www.w3.org/2013/12/12-i18n-irc > > Attendees > > Present > aphillip, matial, JcK, David_Clarke, Richard, Jan > > Regrets > felix > > Chair > Addison Phillips > > Scribe > Addison Phillips > > Contents > > * [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 > __________________________________________________________ > > Agenda > > Action Items > > [14]http://www.w3.org/International/track/actions/open > > [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 > > RADAR > > [15]http://www.w3.org/International/wiki/Review_radar > > [15] http://www.w3.org/International/wiki/Review_radar > > CSS Text > > addison: start to forward comments that are not objected to > > Charmod > > [16]https://lists.w3.org/Archives/Member/member-i18n-core/2013D > ec/0006.html > > [16] > https://lists.w3.org/Archives/Member/member-i18n-core/2013Dec/0006.html > > [17]http://www.w3.org/International/docs/charmod-norm/ > > [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 > equivalent. > > 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 > > [18]https://lists.w3.org/Archives/Member/member-i18n-core/2013D > ec/0009.html > > [18] > https://lists.w3.org/Archives/Member/member-i18n-core/2013Dec/0009.html > > (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 > "hand-wavy" > > 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 > assumption. > > 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? > > AOB? > > Summary of Action Items > > [End of minutes] > >
Received on Monday, 16 December 2013 17:33:28 UTC