SV_MEETING_TITLE -- 13 Nov 2013

<jcverdie_> who should I op ?

darobin: Want markup to represent semantics we need

<r12a> http://www.w3.org/TR/html-ruby-extensions/

darobin: Other side is CSS, where new draft rewrites to improve things, align with markup
... 2 things important

darobin: Want to make sure we are correctly handling the use cases

<r12a> http://www.w3.org/TR/ruby-use-cases/

darobin: Not missing out on any use cases
... Other is implementations -- want impl feedback on feasibility/usefulness etc.

r12a: testing will also be important

glenn: Would like to hear plans for resolving differences between 5.0 and extension spec
... and how to make sure that they're compatible

darobin: Just for background, current HTML5 CR draft has a model for ruby which has good bits and bits we're not happy with
... Has a model for double-sided ruby which is suboptimal
... Extension spec has model which is better
... Current status of play is that implementations are a not great subset of both
... It's a very limited subset
... most basic annotations possible
... what would happen going forward is
... either we can get better impl momentum behind either model, preferably extension model
... in whcih case that's what will ship as HTML5 ruby model
... Or we can't
... And we will instead ship a subset
... and then extend in 5.1

glenn notes that we have various copies of the specs

HTML5.0, HTML5.1, Ruby Extension

r12a: and old XHTML Ruby

glenn: I suggest pulling ruby out of the spec now, just going with extension spec and fold it in later
... Or if we have a strict subset, just kepe that subset in the spec
... and extend later

<MK> nick,

darobin: Taking everything out is non-starter
... My plan is to actually build the subset into 5.0, in the coming weeks
... then modify extension spec to just say the extensions
... however, given what the limitations of that subset are, would really like for extension spec to be adopted
...
... Impl in 5.0 is broken, so implementations have various interpretation of broken algorithm
... Suboptimal in terms of interop,
... Also, it e.g. drops white space, which makes ruby unusable in non-CJK languages

koji: ...

darobin: There is a small implemented subset, will at least have that
... But is most limited ruby support possible

rniwa: I haven't heard about bugs, so great if W3C could report those

darobin: You interested in implementing more?

rniwa: def fix bugs

glenn: So would be useful to document plan

<darobin> ACTION: Robin to document the plan [recorded in http://www.w3.org/2013/11/13-ruby-minutes.html#action01]

<hober> https://bugs.webkit.org/enter_bug.cgi?product=WebKit

RESOLUTION: Remove from HTML5 all but subset of ruby that is <ruby> and <rt> with no double-sided features

+<rp>

and pursue additional features in extension spec

fantasai: I heard a large chunk of content uses <rb> and it's not choked on by implementations, should we pull that into 5?

darobin: Yeah, probably. I have to check on how things are parsed currently

darobin clarifies that anything in the xtension spec that is implemented can be folded into HTML5 if within timeline

r12a asks about ppl's familiarity with various specs

r12a: There's a CSS part and an HTML part. Would recommend we focus on markup requirements

darobin: I can only put into HTML5 things that are implemented
... Doesn't require correct rendering -- that's a CSS issue
... but must be parsed correctly and not generate UnknownElement
... From HTML side, there is very little requirement on the browser
... If the browser parses it correctly, ti's fine
... The segmenting algorithm is only visible when rendered
... So the only thing we would test is parsing
... So what I need is browsers that support the appropriate DOM, and possibly self-closing

koji: Before CR, need test suite
... Does test suite just test DOM?

darobin: We don't test layout. That's a CSS issue
... SO tests for ruby as HTML would be minimal
... Would test parsing and create objects correctly in DOM

kawabata4: HTML test and CSS test may be different.
... HTml will be checking on parsing
... But we just resolved only single-sided ruby will be supported

darobin: We haven't resolved it will only be single-sided in REC, only just for right now. And yes, only HTML side

<r12a> s/Would recommend that we focus on markup requirements/Would recommend that we separate markup and CSS styling/

darobin: CSS draft will have far more than that
... they're not on same kind of deadline as HTML5
... So they can kepe these feautres in and develop them over longer time frame
...

rniwa: Does <rb> require parser changes?

darobin: In my perfect world, yes.
... I know that nobody wants to touch parser code, but it makes a lot of sense, especially since current parser already auto-closes <rt> and <rp> at least
... not in the spec atm because deltas against parser are horrible

rniwa: But need some documentation ...

darobin: That's why we're talking about core bits into HTML5

r12a: Seems to me that we ought to do some testing sooner rather than later, b/c need to know what is supported and what's not
... I would much prefer if we could just implement the whole markup model straightaway
... Because it's not very much more

darobin: I'm happy to put whatever into HTML5, but need browsers to be supporting it
... It's not a lot of work on the HTMl side
... I already have impl in JS... (which is how I found out it's broken)
... Going to implement this plan in the next few weeks, and then we have approximately 1 year to implement this
... We can't have more than 1 year, this is maximal deadline
... Plan is PR in 2014

koji: Plan?

darobin: I think we've discussed markup a lot, probably need to discuss CSS
... Summarize my plan
... 1. Document the plan
... 2. Integrate as much as possible into HTML5.0, and only leave the rest that has to be left out into extension spec
... 3. Write a few tests that will allow us to check what is implemented
... Been meaning to check what IE11 does, but haven't looked yet

r12a: Some additional things,
... Important one is finding people to do implementations

hober: I volunteer rniwa

rniwa: If there's a spec and doesn't require major rewrite, sure

darobin: Just parsing things

r12a: Tha'ts just WebKit

glenn: I'll be helping on theblink side

jet: What's needed?

fantasai: just parsing changes and OM

jet: I'll need to talk to others. We have wanted to do it for a long time
... Is the spec in a good shape?

darobin: I think it's pretyt good

fantasai: If hsivonen is involved, he'll know exactly what to do

[discussing AH model]

koji: Last time discussing with AH, discussing mostly about box model

fantasai: Good to have parsing in AH, but since they don't have OM it won't be enough for HTml5

darobin: If you look at the proposed structure and you think it's not able to encode some aspect of ruby, please go through the use cases doc with a fine-tooth comb, and if htere's something not handled, let us know ASAP

koji: If these three guys finish parser work ... test.. is it supposed to be ?

darobin: If thes gets finished, will have excellent support for ruby in HTMl5

ACTION darobin to document plan, update specs as above, write some tests

ACTION everyone review use cases and markup model to make sure it can handle all relevant cases

report any problems ASAp

<r12a> http://www.w3.org/TR/css3-ruby/

<darobin> or http://dev.w3.org/csswg/css-ruby/

fantasai: CSS spec has been completely rewritten

<r12a> http://www.w3.org/TR/ruby-use-cases/

<darobin> http://darobin.github.io/html-ruby/

<kawabata4> http://www.w3.org/TR/2013/WD-ruby-use-cases-20130910/

<r12a> http://www.w3.org/TR/html-ruby-extensions/

fantasai: now has details (yay) and simplified controls

glenn: Is there a mailing list for this?

r12a: Was thinking the same thing
... Might be good to find a way to communicate on this
... public-i18n-cjk is otherwise low-traffic, might be best to just use that
... meantime I'll get everybody's name

glenn: ruby can be used for non-cjk texts

<darobin> Robin Berjon <robin@w3.org>

<Jirka> Jirka Kosek <jirka@kosek.cz>

<kazutaka> Kazutaka Yamamoto <yamamoto.kazutaka@po.ntts.co.jp>

<r12a> Richard Ishida ishida@w3.org

<birtles> Brian Birtles <bbirtles@mozilla.com>

<bobby> Bobby Tung <bobbytung@wanderer.tw>

fantasai: And it handles pretty much all of the markup models that have been proposed thus far

<kaz> Kaz Ashimura <ashimura@w3,org>

fantasai: Needs review and commenting

<koji> Koji Ishii <kojiishi@gluesoft.co.jp>

fantasai: Things I'm unsure of are largely around white space handling

<hayato> Hayato Ozawa <tell my address later>

<jet> Jet Villegas <jet@mozilla.com>

<Kiyoshi> Kiyoshi Tanaka<tanaka.kiyoshi@lab.ntt.co.jp>

<darobin> I reckon we can reuse the CJK list http://lists.w3.org/Archives/Public/public-i18n-cjk/ subscribe: mailto:public-i18n-cjk-request@w3.org?subject=subscribe

rniwa: What is ruby base container?

<MK> Masahito KAWAMORI <kawamori@w3.org>

<darobin> [fantasai explains ruby on the screen]

<darobin> glenn: can you decorate the boxes?

<darobin> fantasai: you can decorate the rb and rt boxes, but not the rtc box

<darobin> rniwa: how should bopomofo tone marks be captured in ruby?

<darobin> fantasai: tone marks should be positioned in the same way regardless of ruby, so this is more of a text layout issue than a ruby issue

<darobin> glenn: the font should handle this

<darobin> fantasai: yes, this should be handled at text layout not at CSS layout

<darobin> koji: we're still waiting on feedback for this

<darobin> rniwa: so we need to decide who is responsible for this

<darobin> fantasai: CSS will be able to tell you where the ruby goes, but not the text inside

<darobin> fantasai: if I'm writing bopomofo directly (because I'm in kindergarden or whatever), the tone marks should be positioned correctly even if not in ruby

<darobin> rniwa: does the existing font system do this already

<darobin> glenn: the font system can do it if the font designer planned for it

<darobin> koji: we're not sure that the fonts can do it, we need to check, if possible it ought to be in the fonts

<darobin> r12a: it's a bit more complicated than fonts, you have the light tone that can appear several characters before its occurrence in Unicode

<darobin> rniwa: I find it hard to imagine that this would work with fonts

<darobin> fantasai: so, we have the CSS box layout model, and below that there is the text layout model

<darobin> fantasai: some of that is handled by the font, and some by CSS

<darobin> fantasai: so for instance for Arabic, you have to have a layer that talks to the font to extract the right glyph to shape Arabic

<darobin> fantasai: so even if the information was not in the font, it was part of the OS's text layout system, which is beneath CSS

<darobin> fantasai: so I'm saying not necessarily at the font layer, but definitely in the text layout engine

<darobin> fantasai: since this applies equally well to plain text for instance

<darobin> glenn: yes, I agree completely. The decomposition feature to separate for instance combining marks in Arabic uses that mechanism.

<darobin> glenn: there are equivalents in the feature space to this for other languages

<darobin> kaz: the issue applies to pinyin as well?

<darobin> fantasai: no, for pinyin you have tone marks that are placed in a simpler way that does not require this

<darobin> kaz: so for instance Chinese text [draws on the board]

<darobin> fantasai: any other topics?

<kaz> [ kaz: wanted to point out that what would happen with pinyin specified as ruby for chinese text, e.g., Chinese text for Japanese people, esp. the result with vertical layout vs. horizontal layout ]

<bobby> https://www.dropbox.com/s/xz720nnue5etxwy/%E8%9E%A2%E5%B9%95%E5%BF%AB%E7%85%A7%202013-11-13%20%E4%B8%8B%E5%8D%882.57.06.png

<darobin> bobby: there are some cases in which layout is inconsistent due to the size of the annotation

<kaz> [ the above is what I meant :) and also what if we specify vertical layout for that text? ]

<bobby> <ruby>一<rt>it1</rt>代<rt>tai7</rt>儉<rt>khiam7</rt>腸<rt>tng5</rt>凹<rt>neh4</rt>肚<rt>too7</rt>，<rt>　</rt>二<rt>ji7</rt>代<rt>tai7</rt>看<rt>khuann3</rt>錢<rt>tsinn5</rt>若<rt>na2</rt>塗<rt>thoo5</rt>，<rt>　</rt>三<rt>sann1</rt>代<rt>tai7</rt>當<rt>tng3</rt>囝<rt>kiann2[CUT]

- DRAFT -

SV_MEETING_TITLE

13 Nov 2013

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output