See also: IRC log
<trackbot> Closed ACTION-176 Ping anne about encoding spec.
<trackbot> Closed ACTION-186 Add floating times to pipeline.
ACTION-187: contacted most browsers (all but mozilla, but have contact)
<trackbot> Notes added to ACTION-187 Provide darobin with contacts in browser vendors.
zakim +1.617 is John_C_Klensin
<trackbot> Closed ACTION-187 Provide darobin with contacts in browser vendors.
<trackbot> Closed ACTION-188 Merge ruby documents for publication as a WG Note.
richard: noticed Leif Havard Silli is now editor of polyglot
richard: put a lot of Leif's
comments in (simplfying headings and such)
... added a snapshot of other document I produced as appendix
... other changes made are change marked
... also converted to html5
<scribe> chair: review for next week publication as note status
<scribe> ACTION: richard: announce ruby note will be published as note, last call for next week [recorded in http://www.w3.org/2013/02/28-i18n-minutes.html#action01]
<trackbot> Created ACTION-189 - Announce ruby note will be published as note, last call for next week [on Richard Ishida - due 2013-03-07].
richard: elika may want to look at that... some embedding improvements?
addison: above thread about bopomofo support
richard: (describing various issues for zhuyin ruby and layout)
fantasai: concern that there are
... what happens when writing bopomofo just as plain text
... not as ruby, just as the base text
... what happens to the tone marks?
richard: wrote the above
fantasai: kenny might know?
richard: talked to kenny. put
that info into above?
... only have horizontal example
... tone mark following
... not sure of vertical, might have seen something
... very rare
... mostly used with the Chinese characters
addison: any effect on note?
richard: not really??
fantasai: agree. issue is how to
handle writing system in general or is this only when drawing
... in which case tie it into ruby specs
<scribe> ACTION: richard: write to contacts and cjk list about bopomofo handling as base and as ruby text [recorded in http://www.w3.org/2013/02/28-i18n-minutes.html#action02]
<trackbot> Created ACTION-190 - Write to contacts and cjk list about bopomofo handling as base and as ruby text [on Richard Ishida - due 2013-03-07].
richard: had a discussion with aharon and elika and tab last night
richard: tab sent me a writeup
and more info that I integrated to wiki as "proposal B" for the
... upshot basically is that new values for @dir may have benefits
... in that 1) may be easier to manage after the transition and wouldn't leave so much baggage around
... 2) would be easy to implement
... this is predicated on the expectation that the transition period would be small-ish
... so what is proposed is instead of rli/lri
... use an 'r' and an 'l' value
... don't have to think about isolation
... more familiar
... and don't have to deprecate the @dir
... easier to type
... key thing is the transition period
addison: has some feedback at my IMUG talk.. think better to migrate @dir
johnK: a lot of people will get it wrong the other way and this is simple... less interop problems
richard: if you use @dir and
@direction then you get fallback behavior in unaware
... but transition is short because implementation is straightforward
... use CSS-hack mentioned previously
... otherwise use <bdi> for inline
... and this is as currently described in our bidi article
addison: don't really like 'r' and 'l' as values, non-mnemonic
richard: key issue is transition period
addison: transition period may be somewhat long because of IE and android on mobile devices
<fantasai> discussion of including the appropriate style rules into reset stylesheets / polyfill libraries
richard: put out for discussion
... www-international or html or...?
addison: winter at least, html too?
fantasai: unsure of names?
addison: new tokens or new attribute is the question and we're back to tokens?
richard: bidi list, robin also
<scribe> ACTION: richard: request comments on wiki page about bidi change proposal to robin, bidi list, winter list, and html [recorded in http://www.w3.org/2013/02/28-i18n-minutes.html#action03]
<trackbot> Created ACTION-191 - Request comments on wiki page about bidi change proposal to robin, bidi list, winter list, and html [on Richard Ishida - due 2013-03-07].
johnk: no strong thoughts on 'r' or 'l', except that single characters are generally a bad idea because too short and error prone
fantasai: (aside) planning to
wrap up comments on text-decoration
... open issue about underlining style skip spaces... do we skip ethopic
<fantasai> ethiopic word space
<fantasai> tibetan tsek
<scribe> ACTION: addison: solicit from input Unicode on skipping spaces in css3 text-decoration specifically ethiopic word sep, etc. [recorded in http://www.w3.org/2013/02/28-i18n-minutes.html#action04]
<trackbot> Created ACTION-192 - Solicit from input Unicode on skipping spaces in css3 text-decoration specifically ethiopic word sep, etc. [on Addison Phillips - due 2013-03-07].
<fantasai> if spaces are skipped when underlining, should we skip those?
richard: underline can be broken by descender?
fantasai: yes, in particular style
richard: in like tibetan, descenders can be generated by combinations
fantasai: there is a skip-ink value to allow for that?
richard: but tibetan or khmer, you have some characters that conditionally poke through baseline
addison: happens on the rendered glyphs, not based on character
<scribe> ACTION: richard: supply CSS3 with pictures of skip-ink for tibetan or khmer [recorded in http://www.w3.org/2013/02/28-i18n-minutes.html#action05]
<trackbot> Created ACTION-193 - Supply CSS3 with pictures of skip-ink for tibetan or khmer [on Richard Ishida - due 2013-03-07].
<r12a> addison: started calling it charmod 1.1 - is that a good idea?
<r12a> ... history of character model as a whole is significantly about early n11n - this may point up the change in concepts
<r12a> johnO: might be good idea
<r12a> johnK: there are references all around, so if numbers are cheap let do it
<r12a> addison: will will change the number then - tbd in what way
<r12a> ... so far i kept most ot he examples and definitions intact
<r12a> ... partly because we have specs that have specified those (full-, etc-n11n)
<r12a> ... took out all the requirements and put in wiki
<r12a> ... sensing that the focus of the doc is string matching now
<r12a> ... split into 3 chunks:
<r12a> ... 1. how to do string matching and normalization
<r12a> ... 2. unicode normalization, for people who used these recommendations before
<r12a> ... 3. non-normalizing specifications, what you need to know
<r12a> ... there are a couple that are obsolete or don't fit neatly, like security issues, etc
<r12a> ... next step is to pull section 4 into the document and position as the main focus
<r12a> ... also bring in materials on case folding as part of that
<r12a> ... terse statements (dos and donts) are in the wiki for review
<r12a> ... key ones at the top, and others nearer the bottom
<r12a> norbert: so you want to move away from unicode n11n?
<r12a> adddison: you can't require it or depend on it for string matching, but the first req is that NFC makes life easier
<r12a> norbert: first should be not to assume that text is normalized
<r12a> ... but user text probably should be normalised
<r12a> ... such as the find command in a browser
<r12a> ... maybe thats a should rather than a may
<joconner> will have to drop off call, will stay on irc
<r12a> johnK: if you don't require for searches users will be crazy
<r12a> addison: but also it makes them crazy if it looks the same but their css selector doesn't work
<r12a> norbert: that's why i distinguish between user and code
<r12a> r12a: you should modify only in the actual matching process - don't break an author's text
<matial> have to leave
addison: I'll update charmod norm reqs
norbert: annotate what C I and S mean in the wiki
<jan> I had t odrop off the call to attend another one
norbert: propose Unicode must be supported (other encodings may be supported)
addison: will make topic for next week (lost audience)