See also: IRC log
action-252: done but will ping again as got no answer
<trackbot> Notes added to action-252 Ping dita folks about contacting html5 about ruby progress.
<trackbot> Closed action-264.
richard: multilingual web...
felix: (mumbles something
... hoping that there will be another MLWeb Workshop
felix: will try to continue
... and also promote Linked Open Data
... and a new WG connected to it
richard: also bringing
multilingualweb.eu inside W3C
... will notice that there is an MLWeb logo on /International home page
... (activity home page)
<scribe> ACTION: addison: ping CSS about Shapes issues [recorded in http://www.w3.org/2013/12/05-i18n-minutes.html#action01]
<trackbot> Created ACTION-272 - Ping css about shapes issues [on Addison Phillips - due 2013-12-12].
JcK: URNbis not quite ready
... currently passing bottlenecks around
... could happen quickly if things work out
addison: need shepherds for
HRTime2 and Shapes
... will shepherd shapes
JcK: about 1/3 through
... particularly concerned about character/code point/grapheme/etc. terminology
... also about case distinctions
addison: we are quite late with comments, would like to start feeding them comments back
richard: also reviewing but still
in paper mode
... raise tracker comments and then review via email?
<scribe> ACTION: addison: update CSS on our ETA for CSS Text comments [recorded in http://www.w3.org/2013/12/05-i18n-minutes.html#action02]
<trackbot> Created ACTION-273 - Update css on our eta for css text comments [on Addison Phillips - due 2013-12-12].
quote: At risk features that concern me: text-justify and the full-width value of text-transform.
Text-align "start end" keyword (*not* to be confused with "start" and "end" keywords) is at risk, but does not represent a break with bidi support I think.
koji: at risk features need implementers and that's the reason for being at risk
1. Section 1.3: The description of "grapheme cluster" feels abbreviated and terse. Of particular concern to me is this sentence: -- The UA may further tailor the definition as required by typographical tradition. -- I think this could be clearer, perhaps by saying: -- The UA may tailor grapheme cluster boundaries as required by typographical tradition or based on additional linguistic requirements. --
JcK: not completely clear, even
with this edit?
... "completely optional if you feel you need to ignore it"
<fsasaki> [apologies, have to leave now, talk to you next week or before]
richard: wondering if what is
meant here is: use grapheme clusters where defined
... but certain languages where need to extend
addison: UTR talks about that
JcK: strange example of classic Mayan
richard: needs the word "further" or "there are units bigger than grapheme clusters"
addison: that makes sense
"The UA may extend grapheme cluster boundaries as required by typographical tradition (see [example needed]).
richard: ".... based on language requirements"?
addison: problem is there is no way to markup "typographic tradition", just relies on language markup
quote: Within this specification, the ambiguous term character is used as a friendlier synonym for grapheme cluster. See Characters and Properties for how to determine the Unicode properties of a character.
richard: let's ask why
... tend to think it's a bad idea
koji: not clear where preference came from, good to get feedback from I18N
JcK; already ranted a bit: pretty certain is a Bad Idea as very confusing
scribe: if "every time we say 'character' read as 'grapheme cluster'" would be less unhappy, but not the case
koji: concern is not about use of term, but about inconsistency?
richard: probably both
addison: understand that we are more "in tune" with Unicode terminology than most spec users but in this case the need is strong for both terms as distinct
richard: add specific cases to comment
3. Section 2.1: There is no corresponding "half-width" transformation.
... problem is with katakana
... but then name not consistent if we make an exception
JcK: unfortunately same problem to the case transforms
probably dropping this one
4. Section 2.1: Example 3 discusses Turkish upper and lower case mappings, which illustrates that the 'capitalize', 'uppercase', and 'lowercase'. More specificity about the language tailoring is wanted here. Also a discussion of case mapping
Jck: case mapping does affect the
underlying content in some languages
... just a bit muddled here
... not meaningful without language identification
... why no 'titlecase' instad of 'capitalize'?
... why UA dependent?
addison: UAs implement casing differently
koji: what do you suggest?
as defined in Default Case Algorithm section
If (and only if) the content language of the element is, according to the rules of the document language, known, then any appropriate language-specific rules must be applied as well. These minimally include, but are not limited to, the language-specific rules in Unicode's SpecialCasing.txt.
richard: add proposal to have informative link to CLDR if that's what you think should happen
7. Section 6.1: The Arabic hyphenation shaping example isn't clear. The segments should be shown separately?
For example, if the word “نوشتنن” were hyphenated, it would appear as “ﻧﻮﺷ-ﺘﻦ” not as “ﻧﻮﺵ-ﺗﻦ”.
9. Section 7.3: The tasmeem example of "cursively justified" Arabic text may not be clear to outside observers unfamiliar with kashida. In addition, no mention is made of kashida or the kashida/tatweel character. This is probably called for here.
koji: john daggett again having kashida unless clearly defined
richard: does he mean "defineding the rules for adding baseline extension characters" or just "explaining what it is"?
koji: a developer who doesn't know arabic can implement
richard: there are other cases where the spec is hand-wavy like this, would need a spec on its own to well-define kashida rules
koji: msft had low and high kashida or something like that
richard: there was or was not a kashida property value?
koji: yes, that's correct
‘kashida’ Justification primarily stretches cursive scripts through the use of kashida or other calligraphic elongation. This value is optional for conformance to CSS3 Text. (UAs that do not support cursive elongation must treat the value as invalid.)
addison: need a complete
definition of kashida?
... and "ALREQ" is needed :-(
richard: next point you made is important too: is kashida off when you say 'inter-word'? how about 'distribute' (sounds like you turn it on, actually)?
addison: expect inter-word to
... but not sure about distribute
<matial> Yes, I have to leave.
11. Section 8.2: The section on "tracking" ('letter-spacing') should probably reiterate that tracking does not break cursive/ligating scripts like Arabic. Mention of the "bar" in scripts such as Devanagari is also probably warranted.
richard: kashida also used for
emphasis and not evenly between all letters
... also might be appropriate in 'justify' section
addison: don't know about bar in Devanagari
<scribe> ACTION: richard: ask Indic task force about handling of tracking in CSSText, pariticulary whether the bar "breaks" in scripts that use one [recorded in http://www.w3.org/2013/12/05-i18n-minutes.html#action03]
<trackbot> Created ACTION-274 - Ask indic task force about handling of tracking in csstext, pariticulary whether the bar "breaks" in scripts that use one [on Richard Ishida - due 2013-12-12].
richard: have a whole ton of
tests for this document (line breaking, hyph, etc.)
... so when you get to CR, don't reinvent it, okay?
<r12a> also white-space tests below and some more hyphenation
<scribe> chair: HOMEWORK: CSS3 Text and Syntax