- From: Richard Ishida <ishida@w3.org>
- Date: Mon, 16 Dec 2013 17:30:04 +0000
- To: www International <www-international@w3.org>
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:30:37 UTC