06:09:00 RRSAgent has joined #ruby 06:09:00 logging to http://www.w3.org/2013/11/13-ruby-irc 06:09:01 Jirka2 has joined #ruby 06:09:06 Kiyoshi has joined #ruby 06:09:07 r12a has joined #ruby 06:09:10 fantasai has changed the topic to: Ruby Breakout TPAC 2013 06:09:10 who should I op ? 06:09:23 koji has joined #ruby 06:09:44 darobin: Want markup to represent semantics we need 06:09:58 http://www.w3.org/TR/html-ruby-extensions/ 06:10:08 darobin: Other side is CSS, where new draft rewrites to improve things, align with markup 06:10:18 darobin: 2 things important 06:10:24 http://www.w3.org/TR/css3-ruby/ 06:10:33 darobin: Want to make sure we are correctly handling the use cases 06:10:39 http://www.w3.org/TR/ruby-use-cases/ 06:10:39 kazutaka has joined #ruby 06:10:39 darobin: Not missing out on any use cases 06:11:04 darobin: Other is implementations -- want impl feedback on feasibility/usefulness etc. 06:11:22 r12a: testing will also be important 06:11:30 darobin has joined #ruby 06:11:41 glenn: Would like to hear plans for resolving differences between 5.0 and extension spec 06:11:46 glenn: and how to make sure that they're compatible 06:12:07 darobin: Just for background, current HTML5 CR draft ahs a model for ruby which has good bits and bits we're not happy with 06:12:16 darobin: Has a model for double-sided ruby which is suboptimal 06:12:23 darobin: Extension spec has model which is better 06:12:23 s/ahs/has/ 06:12:46 darobin: Current status of play is that implementations are a not great subset of both 06:12:51 darobin: It's a very limited subset 06:12:56 darobin: most basic annotations possible 06:13:00 darobin: what would happen going forward is 06:13:15 darobin: either we can get better impl momentum behind either model, preferably extension model 06:13:22 darobin: in whcih case that's what will ship as HTML5 ruby model 06:13:25 darobin: Or we can't 06:13:32 darobin: And we will instead ship a subset 06:13:41 darobin: and then extend in 5.1 06:13:53 kawabata3 has joined #ruby 06:14:01 glenn notes that we have various copies of the specs 06:14:18 HTML5.0, HTML5.1, Ruby Extension 06:14:21 r12a: and old XHTML Ruby 06:14:32 MK has joined #ruby 06:14:38 glenn: I suggest pulling ruby out of the spec now, just going with extension spec and fold it in later 06:14:40 kawabata4 has joined #ruby 06:14:49 glenn: Or if we have a strict subset, just kepe that subset in the spec 06:14:52 glenn: and extend later 06:14:57 nick, 06:14:58 bobby has joined #ruby 06:15:01 darobin: Taking everything out is non-starter 06:15:16 darobin: My plan is to actually build the subset into 5.0, in the coming weeks 06:15:26 darobin: then modify extension spec to just say the extensions 06:15:44 darobin: however, given what the limitations of that subset are, would really like for extension spec to be adopted 06:15:50 ... 06:16:05 darobin: Impl in 5.0 is broken, so implementations have various interpretation of broken algorithm 06:16:12 darobin: Suboptimal in terms of interop, 06:16:26 darobin: Also, it e.g. drops white space, which makes ruby unusable in non-CJK languages 06:16:33 koji: ... 06:16:42 darobin: There is a small implemented subset, will at least have that 06:16:51 darobin: But is most limited ruby support possible 06:17:11 rniwa: I haven't heard about bugs, so great if W3C could report those 06:17:24 darobin: You interested in implementing more? 06:17:28 rniwa: def fix bugs 06:17:38 glenn: So would be useful to document plan 06:17:41 ACTION: Robin to document the plan 06:18:00 https://bugs.webkit.org/enter_bug.cgi?product=WebKit 06:19:47 RESOLVED: Remove from HTML5 all but subset of ruby that is and with no double-sided features 06:19:59 + 06:20:07 and pursue additional features in extension spec 06:20:13 hayato has joined #Ruby 06:20:25 fantasai: I heard a large chunk of content uses and it's not choked on by implementations, should we pull that into 5? 06:20:34 darobin: Yeah, probably. I have to check on how things are parsed currently 06:21:10 darobin clarifies that anything in the xtension spec that is implemented can be folded into HTML5 if within timeline 06:22:30 r12a asks about ppl's familiarity with various specs 06:22:57 r12a: There's a CSS part and an HTML part. Would recommend we focus on markup requirements 06:23:10 darobin: I can only put into HTML5 things that are implemented 06:23:17 q+ to circle back to the browser issue 06:23:20 darobin: Doesn't require correct rendering -- that's a CSS issue 06:23:28 Zakim has joined #ruby 06:23:33 darobin: but must be parsed correctly and not generate UnknownElement 06:23:50 darobin: From HTML side, there is very little requirement on the browser 06:23:57 darobin: If the browser parses it correctly, ti's fine 06:24:07 darobin: The segmenting algorithm is only visible when rendered 06:24:13 darobin: So the only thing we would test is parsing 06:24:38 darobin: So what I need is browsers that support the appropriate DOM, and possibly self-closing 06:24:51 koji: Before CR, need test suite 06:24:57 koji: Does test suite just test DOM? 06:25:04 darobin: We don't test layout. That's a CSS issue 06:25:10 darobin: SO tests for ruby as HTML would be minimal 06:25:19 darobin: Would test parsing and create objects correctly in DOM 06:25:49 jet has joined #ruby 06:25:53 kawabata4: HTML test and CSS test may be different. 06:25:58 kawabata4: HTml will be checking on parsing 06:26:07 kawabata4: But we just resolved only single-sided ruby will be supported 06:26:23 darobin: We haven't resolved it will only be single-sided in REC, only just for right now. And yes, only HTML side 06:26:28 s/Would recommend that we focus on markup requirements/Would recommend that we separate markup and CSS styling/ 06:26:30 darobin: CSS draft will have far more than that 06:26:36 darobin: they're not on same kind of deadline as HTML5 06:26:47 darobin: So they can kepe these feautres in and develop them over longer time frame 06:27:40 ... 06:27:47 rniwa: Does require parser changes? 06:27:52 darobin: In my perfect world, yes. 06:27:59 q+ 06:28:18 darobin: I know that nobody wants to touch parser code, but it makes a lot of sense, especially since current parser already auto-closes and at least 06:28:41 darobin: not in the spec atm because deltas against parser are horrible 06:28:52 rniwa: But need some documentation ... 06:29:03 darobin: That's why we're talking about core bits into HTML5 06:29:23 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 06:29:50 r12a: I would much prefer if we could just implement the whole markup model straightaway 06:29:58 r12a: Because it's not very much more 06:30:12 darobin: I'm happy to put whatever into HTML5, but need browsers to be supporting it 06:30:18 darobin: It's not a lot of work on the HTMl side 06:30:35 darobin: I already have impl in JS... (which is how I found out it's broken) 06:31:39 darobin: Going to implement this plan in the next few weeks, and then we have approximately 1 year to implement this 06:32:25 darobin: We can't have more than 1 year, this is maximal deadline 06:32:47 darobin: Plan is PR in 2014 06:33:09 koji: Plan? 06:33:18 darobin: I think we've discussed markup a lot, probably need to discuss CSS 06:33:23 darobin: Summarize my plan 06:33:27 darobin: 1. Document the plan 06:33:46 darobin: 2. Integrate as much as possible into HTML5.0, and only leave the rest that has to be left out into extension spec 06:33:55 darobin: 3. Write a few tests that will allow us to check what is implemented 06:34:03 darobin: Been meaning to check what IE11 does, but haven't looked yet 06:34:19 r12a: Some additional things, 06:34:24 myakura has joined #ruby 06:34:26 r12a: Important one is finding people to do implementations 06:34:32 hober: I volunteer ryosuke 06:34:55 s/ryosuke/rniwa/ 06:35:07 rniwa: If there's a spec and doesn't require major rewrite, sure 06:35:10 darobin: Just parsing things 06:35:22 r12a: Tha'ts just WebKit 06:35:49 glenn: I'll be helping on theblink side 06:36:10 jet: What's needed? 06:36:17 fantasai: just parsing changes and OM 06:36:28 jet: I'll need to talk to others. We have wanted to do it for a long time 06:36:34 jet: Is the spec in a good shape? 06:36:40 darobin: I think it's pretyt good 06:37:24 fantasai: If hsivonen is involved, he'll know exactly what to do 06:37:50 [discussing AH model] 06:38:18 koji: Last time discussing with AH, discussing mostly about box model 06:38:33 fantasai: Good to have parsing in AH, but since they don't have OM it won't be enough for HTml5 06:39:10 kaz has joined #ruby 06:39:16 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 06:39:34 koji: If these three guys finish parser work ... test.. is it supposed to be ? 06:39:56 darobin: If thes gets finished, will have excellent support for ruby in HTMl5 06:40:26 ACTION darobin to document plan, update specs as above, write some tests 06:40:40 ACTION everyone review use cases and markup model to make sure it can handle all relevant cases 06:40:52 report any problems ASAp 06:41:30 http://www.w3.org/TR/css3-ruby/ 06:41:34 or http://dev.w3.org/csswg/css-ruby/ 06:41:35 fantasai: CSS spec has been completely rewritten 06:41:40 http://www.w3.org/TR/ruby-use-cases/ 06:41:47 http://darobin.github.io/html-ruby/ 06:41:50 http://www.w3.org/TR/2013/WD-ruby-use-cases-20130910/ 06:41:51 http://www.w3.org/TR/html-ruby-extensions/ 06:41:53 fantasai: now has details (yay) and simplified controls 06:42:00 SteveZ has joined #ruby 06:42:07 glenn: Is there a mailing list for this? 06:42:12 r12a: Was thinking the same thing 06:42:22 r12a: Might be good to find a way to communicate on this 06:42:35 masatakayakura has joined #ruby 06:42:40 r12a: public-i18n-cjk is otherwise low-traffic, might be best to just use that 06:42:57 r12a: meantime I'll get everybody's name 06:43:11 glenn: ruby can be used for non-cjk texts 06:43:34 06:43:38 Robin Berjon 06:43:46 Jirka Kosek 06:43:52 Kazutaka Yamamoto 06:43:54 Richard Ishida ishida@w3.org 06:43:55 Brian Birtles 06:43:56 Bobby Tung 06:44:00 fantasai: And it handles pretty much all of the markup models that have been proposed thus far 06:44:05 Kaz Ashimura 06:44:10 fantasai: Needs review and commenting 06:44:12 Koji Ishii 06:44:22 fantasai: Things I'm unsure of are largely around white space handling 06:44:26 Hayato Ozawa 06:44:29 Jet Villegas 06:44:38 Kiyoshi Tanaka 06:44:48 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 06:44:53 rniwa: What is ruby base container? 06:45:29 Masahito KAWAMORI 06:47:19 [fantasai explains ruby on the screen] 06:47:36 glenn: can you decorate the boxes? 06:47:47 fantasai: you can decorate the rb and rt boxes, but not the rtc box 06:48:17 rniwa: how should bopomofo tone marks be captured in ruby? 06:48:45 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 06:49:06 glenn: the font should handle this 06:49:19 fantasai: yes, this should be handled at text layout not at CSS layout 06:49:37 koji: we're still waiting on feedback for this 06:49:46 rniwa: so we need to decide who is responsible for this 06:50:03 fantasai: CSS will be able to tell you where the ruby goes, but not the text inside 06:50:34 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 06:50:45 rniwa: does the existing font system do this already 06:50:57 glenn: the font system can do it if the font designer planned for it 06:51:18 koji: we're not sure that the fonts can do it, we need to check, if possible it ought to be in the fonts 06:51:52 r12a: it's a bit more complicated than fonts, you have the light tone that can appear several characters before its occurrence in Unicode 06:52:04 rniwa: I find it hard to imagine that this would work with fonts 06:52:17 fantasai: so, we have the CSS box layout model, and below that there is the text layout model 06:52:27 fantasai: some of that is handled by the font, and some by CSS 06:52:56 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 06:53:15 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 06:53:31 fantasai: so I'm saying not necessarily at the font layer, but definitely in the text layout engine 06:53:42 fantasai: since this applies equally well to plain text for instance 06:54:13 glenn: yes, I agree completely. The decomposition feature to separate for instance combining marks in Arabic uses that mechanism. 06:54:31 q? 06:54:31 glenn: there are equivalents in the feature space to this for other languages 06:54:34 q+ 06:54:47 ack r12a 06:54:49 ack kaz 06:55:15 kaz: the issue applies to pinyin as well? 06:55:43 fantasai: no, for pinyin you have tone marks that are placed in a simpler way that does not require this 06:56:25 kaz: so for instance Chinese text [draws on the board] 06:58:06 fantasai: any other topics? 06:58:22 [ 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 ] 06:58:29 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 06:59:23 bobby: there are some cases in which layout is inconsistent due to the size of the annotation 06:59:33 [ the above is what I meant :) and also what if we specify vertical layout for that text? ] 07:00:00 Jirka has left #ruby 07:01:37 一it¹代tai⁷儉khiam⁷腸tng⁵凹neh⁴肚too⁷，　二ji⁷代tai⁷看khuann³錢tsinn⁵若na²塗thoo⁵，　三sann¹代tai⁷當tng³囝kiann^{2[CUT]
07:01:37 /rt>賣be⁷某boo²} 07:08:21 masatakayakura has joined #ruby 07:09:00 RRSAgent, make minutes 07:09:02 I have made the request to generate http://www.w3.org/2013/11/13-ruby-minutes.html masatakayakura 07:31:01 darobin has joined #ruby 07:31:20 RRSAgent, make minutes 07:31:20 I have made the request to generate http://www.w3.org/2013/11/13-ruby-minutes.html darobin 07:31:43 RRSAgent, make logs public 07:31:47 RRSAgent, make minutes 07:31:47 I have made the request to generate http://www.w3.org/2013/11/13-ruby-minutes.html darobin 07:32:41 r12a has joined #ruby 07:33:52 kaz has joined #ruby 07:37:08 rniwa has joined #ruby 07:55:25 rniwa has joined #ruby 08:02:51 r12a has joined #ruby 08:07:38 bobby has joined #ruby 08:08:52 rniwa has joined #ruby 08:10:27 koji has joined #ruby 08:29:59 rniwa has joined #ruby 08:35:08 MK has joined #ruby 08:38:28 rniwa has joined #ruby 08:40:33 join /security 08:40:47 rniwa has left #ruby 09:08:57 MK has joined #ruby 09:12:35 Zakim has left #ruby 09:24:16 MK has joined #ruby 10:14:46 fantasai has left #ruby 10:19:39 MK has joined #ruby 12:17:44 birtles has joined #ruby 13:51:12 birtles_ has joined #ruby 14:11:25 MK has joined #ruby