See also: IRC log
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.
http://www.w3.org/International/wiki/Review_radar
addison: start to forward comments that are not objected to
https://lists.w3.org/Archives/Member/member-i18n-core/2013Dec/0006.html
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
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?