See also: IRC log
<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
<r12a> http://www.w3.org/TR/css3-ruby/
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
<kawabata4> <kawabata.taichi_at_gmail.com>
<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 ]
<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>it<sup>1</sup></rt>代<rt>tai<sup>7</sup></rt>儉<rt>khiam<sup>7</sup></rt>腸<rt>tng<sup>5</sup></rt>凹<rt>neh<sup>4</sup></rt>肚<rt>too<sup>7</sup></rt>,<rt> </rt>二<rt>ji<sup>7</sup></rt>代<rt>tai<sup>7</sup></rt>看<rt>khuann<sup>3</sup></rt>錢<rt>tsinn<sup>5</sup></rt>若<rt>na<sup>2</sup></rt>塗<rt>thoo<sup>5</sup></rt>,<rt> </rt>三<rt>sann<sup>1</sup></rt>代<rt>tai<sup>7</sup></rt>當<rt>tng<sup>3</sup></rt>囝<rt>kiann<sup>2[CUT]
<bobby> /rt>賣<rt>be<sup>7</sup></rt>某<rt>boo<sup>2</sup></rt></ruby>
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/ahs/has/ FAILED: s/Would recommend that we focus on markup requirements/Would recommend that we separate markup and CSS styling/ Succeeded: s/ryosuke/rniwa/ No ScribeNick specified. Guessing ScribeNick: fantasai Inferring Scribes: fantasai WARNING: No "Topic:" lines found. WARNING: No "Present: ... " found! Possibly Present: Jirka Jirka2 Kiyoshi MK SteveZ birtles bobby darobin fantasai glenn hayato hober https jcverdie_ jet joined kawabata3 kawabata4 kaz kazutaka koji masatakayakura myakura r12a rniwa ruby You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 13 Nov 2013 Guessing minutes URL: http://www.w3.org/2013/11/13-ruby-minutes.html People with action items: robin WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]