00:00:11 sgalineau has joined #css 00:00:14 szilles has joined #css 00:00:56 plinss has joined #css 00:01:55 florian has joined #css 00:02:45 Zakim has joined #css 00:04:10 hober has joined #css 00:04:41 danield has joined #css 00:04:58 macpherson has joined #css 00:04:59 shans has joined #css 00:05:34 alexmog has joined #css 00:06:31 kojiishi has joined #css 00:06:58 jdaggett has joined #css 00:07:08 vhardy has joined #css 00:07:11 ScribeNick: jdaggett 00:07:23 topic: Transitions and Animations 00:07:52 myakura has joined #css 00:08:21 hi Arron 00:09:19 konaya has joined #css 00:09:56 I'll be here most of the day. 00:10:19 TabAtkins: talking about new directions for anim and transitions 00:10:37 TabAtkins: current spec has limitations 00:11:06 TabAtkins: transitions are only state-to-state 00:11:07 smfr has joined #css 00:11:26 TabAtkins: that's different from the animations spec 00:12:06 shans: i've been messing around with ideas in js 00:12:06 murakami has joined #css 00:12:15 shans: shows demo 00:12:52 TabAtkins: note the weird interactions when hovering 00:13:39 TabAtkins: want animations of all properties 00:13:48 TabAtkins: make @transition rule 00:14:15 TabAtkins: with over, from, to, and animation 00:15:36 TabAtkins: syntax is at-rule with selector to identify the elements that the animation applies to 00:15:52 alexmog: shouldn't that be the other way around 00:15:54 ? 00:16:21 TabAtkins: current property is just simple syntax 00:16:28 TabAtkins: this is the advanced version 00:16:45 nmccully has joined #css 00:17:18 TabAtkins: we have some issues 00:17:23 is there a url for what's being discussed? 00:17:31 TabAtkins: with complex animations, multiple states 00:18:21 00:18:27 florian has left #css 00:18:30 florian has joined #css 00:18:48 jammering about www.archive 00:19:33 green on black? 00:19:49 comic book ninjas 00:20:22 more mumbling 00:20:42 these folks need more coffee, much too slow 00:20:52 arno has joined #css 00:21:00 cmon, going at web speed, blah, blah, blah... 00:21:47 danield: there are just four states? 00:22:01 TabAtkins: ... talking about various states... 00:23:01 aw that's cute, screen sharing by pushing two pc's together 00:23:42 TabAtkins: talking about states 00:24:03 TabAtkins: back to the button example 00:24:13 TabAtkins: number of states you go through 00:25:37 TabAtkins: going through a to c you can still go through b 00:26:11 florian: will non-defined paths be synthesized? 00:26:23 TabAtkins: normal transition is just a jump 00:26:32 TabAtkins: should be able to synthesize 00:26:35 TabAtkins: it runs a shortest path algorithm on the graph 00:26:54 TabAtkins: discussing missing legs 00:27:44 TabAtkins: describes how the path graph is defined 00:29:03 TabAtkins: wanted something that tells you what to do going between two states 00:29:13 TabAtkins: similar to the data attributes in html 00:29:20 TabAtkins: we can define a state family 00:30:30 szilles has joined #css 00:30:36 TabAtkins: should be able to define keyframe animations over transitions 00:30:52 TabAtkins: everybody wanted something less weird but doesn't work 00:31:09 TabAtkins: showing same example with condensed syntax 00:31:24 @transition-graph #animateMe { over: state-path; @edge(A, B) {animation: transition(left, top, background-color, -webkit-border-radius, color) 0.5s; direction: both; } @edge(B, C) {animation: transition(left, top, background-color, -webkit-border-radius, color) 1.0s; direction: both; } } 00:32:19 sylvaing: hmmm, complicated... 00:32:56 vhardy: why "state path" and not the property 00:32:58 ? 00:33:28 TabAtkins: doesn't work well when defining multiple animations 00:33:47 wondering about the wisdom of overloading attribute selectors 00:33:54 TabAtkins: problem of additive properties 00:34:18 dbaron: need to adjust the way the cascade to fix 00:34:28 dbaron: why should these be properties at all 00:34:43 dbaron: rather than something that you match with selectors 00:35:00 TabAtkins: working with selectors is hard to define 00:35:10 nmccully has joined #css 00:35:24 dbaron: work selectors and declarations within the at-rule 00:35:56 dbaron: put the selectors into the @transition-graph rule 00:36:14 dbaron: then the cascade just works things out 00:37:00 dbaron and TabAtkins discussing alternate syntax 00:37:15 vhardy: seems to me you're defining a graph 00:37:37 vhardy: the edges seem to be between paths which feels weird 00:37:51 TabAtkins: we have a state called path 00:38:09 chrome guys confess to abusing the use of 'path' 00:38:45 TabAtkins: showing an even more complex example because complexity is my middle name 00:39:46 TabAtkins: showing click-animate-click-animate-click-animate 00:40:54 shans has joined #css 00:40:57 TabAtkins: you don't associate state with styles that apply to that state 00:41:01 @transition-graph #animateMe { over: state-path; @edge(A, B) { animation: transition(left, top) 0.5s; } @edge(B, C) { animation: transition(left, top) 1.0s; } @edge(C, D) { animation: transition(left, top) 1.0s; } @edge(D, A) { animation: transition(left, top) 1.0s; } } 00:41:16 TabAtkins: multiple selectors could set the state to D 00:41:46 TabAtkins: not sure what the correct answer is here 00:41:58 TabAtkins: these are useful for UI's 00:43:19 TabAtkins: people are trying to do complex things 00:43:28 TabAtkins: this is simpler for those cases 00:44:00 dbaron: weird that property values defined in one place and transitions in another place 00:44:07 i agree with dbaron 00:44:15 dbaron: should be more like keyframes 00:44:46 TabAtkins: defined by mixins 00:45:10 TabAtkins shows example using @node 00:45:29 @transition-graph #animateMe { over: state-path; @edge(A, B) { animation: transition(left, top) 0.5s; } @edge(B, C) { animation: transition(left, top) 1.0s; } @edge(C, D) { animation: transition(left, top) 1.0s; } @edge(D, A) { animation: transition(left, top) 1.0s; } @node(D) properties-for-D; } 00:45:55 TabAtkins: this creates a property bag in the transition graph 00:47:05 TabAtkins shows demo passing through D node 00:47:26 TabAtkins: this gives us a unified model 00:47:32 TabAtkins: there are some issues 00:47:39 TabAtkins: fertile ground 00:48:17 smfr: tricky to talk about this in F2f format 00:48:31 TabAtkins: will post examples to wiki 00:48:49 vhardy: should we do this with the FX task force 00:48:57 TabAtkins: not doing anything incompatible yet 00:49:15 vhardy talking about state transition model 00:49:34 vhardy: lots of animation models when include things like SMIL 00:50:05 vhardy: i'm interested if we can more of the timing model of SMIL 00:50:18 vhardy: sophisticated effects require better sync 00:50:26 TabAtkins: we've thought about this a lot 00:50:43 TabAtkins: we probably don't want to go too crazy in css 00:51:18 TabAtkins: complex stuff should be done via a rich js api 00:51:46 TabAtkins: dean is working on css om apis 00:51:53 TabAtkins: go through there 00:52:05 TabAtkins: this allows more powerful things 00:52:22 TabAtkins: that's probably a better direction 00:52:42 vhardy: may need some declarative syntax for that 00:52:59 TabAtkins: hard to do with css model 00:53:22 vhardy: how to deal with multiple animations 00:53:29 TabAtkins: css model is that one animation wins 00:54:24 TabAtkins: we know smil does that 00:54:32 stearns has joined #css 00:54:37 jdaggett: i'm worried about referring to smil 00:55:11 the complexity of smil scares me 00:55:23 vhardy: it's complex but it's doable 00:55:43 I'm worried that this is complicating CSS too much. 00:55:45 sylvaing: the lack of an api is painful 00:56:07 arronei, +1 00:56:22 sylvaing: for developers 00:56:46 ScribeNick: fantasai 00:57:36 sylvaing has joined #css 00:57:39 We used to have a behaviors spec for CSS this might be worth moving in that direction. 00:57:47 Topic: IVS 00:58:24 http://lists.w3.org/Archives/Member/w3c-css-wg/2011AprJun/0427.html 00:58:54 fantasai: I think we should send a comment to Unicode saying that their policy of allowing different people to register different IVS's for the same exact glyph is a problem. 00:58:55 http://itpro.nikkeibp.co.jp/article/COLUMN/20110124/356398/ 00:59:57 jdaggett points to example in that page 01:00:14 jdaggett: This is one single codepoint. The second codepoint listed is the IVS, which says which variant to use. 01:00:21 jdaggett: If you look carefully, you can see he variations 01:00:30 looking at variants of 邊 01:00:32 jdaggett: There's a whole range of variations 01:01:06 jdaggett: But what you'll start to notice is that if you look at fonts that support some of these variations, they map several IVSes to the same glyph 01:01:08 fonts map E0100 and E0108 variantns to same glyph, etc. 01:01:18 jdaggett: The way this work is that different vendors can come to Unicode and register variants 01:01:40 jdaggett: But there's no process that requires them to go through the existing registration to see which of their variations already exist 01:01:53 jdaggett: That whole problem is foisted onto users and font developers 01:02:37 jdaggett: the NTT guy said it's a lot of work to figure this out, but that's just foisting the job onto all the font developers 01:02:44 Nat: It's in his interests to keep up the silos. 01:03:18 jdaggett: They don't realize that the way in which they've done ths, they're creating interop problems for authors and for implementers like us 01:03:23 jdaggett: So there's that problem 01:03:32 jdaggett: What fantasai has written up is a letter .. 01:03:51 jdaggett: There are proposed changes to the process that would encourage vendors to share IVSes. 01:04:02 szilles has joined #css 01:04:16 jdaggett: fantasai's proposal is to make that stronger, that registrants must say what the differences are and write it in text in order to register a new IVS 01:05:16 jdaggett: The differences can be very subtle. It's hard to tell, without prose, what differences are being registered, and which differences are being registered or whether this is just a duplicate 01:05:32 konaya has joined #css 01:05:38 Steve is concerned about being tactful 01:06:01 jdaggett: Interop isn't something that exists only outside of Japan. 01:06:20 Nat: THis comes partly because of the silo issue, but also because it isn't articulated clearly enough what the main thing is you're trying to solve. 01:06:44 Nat: I think what they saw with IVS was that they could encode all these incompatibilities in glyph shape into Unicode 01:07:08 Nat: They see it as the opposite of what it's for, it's not your responsibility anymore, you can register any IVD registration 01:07:21 Nat: what should have happened when the second IVD collection was registered was to say, No, that's not what this is for. 01:07:43 Nat: To have more than one collection means that you have a body that needs to determine the interactions between the collecitons. 01:07:51 Nat: Why have more than one collection? Why not have only one collection? 01:08:00 Nat: And have new glyphs interoperate with existing set 01:08:11 Nat: If you're not having a flat model, then what are you trying to do? 01:08:24 Nat: If I'm right and the original purpose was to solve interop, then we really need strong language 01:08:58 Nat: Saying that itnerop is the main problem we're trying to solve, and explaining all the new problems, will help convince Japanese that this is the right way to go. 01:09:41 Yamamoto: They tried to .. set of glyph, but they couldn't because the granularity changed. 01:10:01 Yamamoto: For example, government needs more granularity for people's names 01:10:17 Yamamoto: ... 01:10:27 Yamamoto: So they reached conclusion that it's impossible to have one universal list of glyphs 01:10:50 konaya has joined #css 01:10:51 Yamamoto: So this was born, and that allows different parties to submit different IVD collections 01:11:12 Yamamoto: But they're currently planning to amend the process to encourage sharing and coordination between groups with similar glyphs 01:11:20 Yamamoto: That is the historical description. 01:11:37 jdaggett: It's that proposal that we're suggesting to comment on 01:12:03 jdaggett: Unless it's written more strongly, they won't bother. They should cooperate, but it takes too much time. 01:12:21 jdaggett: I think the language is good, 01:12:43 jdaggett: I think we should take Steve's suggestion and also focus on the problem of interop within Japan 01:13:25 Yamamoto talks about some committee about discussing IVS interop 01:13:34 Yamamoto: At that meeting we will discuss ways to improve the current situation. 01:13:44 Yamamoto: Such as having a mapping table between different IVD collections 01:13:53 Yamamoto: Or more documentation on granularity. 01:16:53 fantasai: ... 01:17:16 jdaggett: One issue here is is, look at these two differences -- this glyph has a concave stroke, the other one has a convex stroke 01:17:25 jdaggett: These differences are erased in a gothic style 01:18:27 Nat gives a history of a glyph diverging and merging and diverging 01:18:50 jdaggett: This starts to get involved into font fallback 01:19:03 jdaggett: A lot of gothic faces won't implement these differences 01:19:46 konaya has joined #css 01:20:05 jdaggett: In most web pages, if the font is a gothic style face, if you require fallback to that selector, you're going to see a run of text that's going to hit Mincho, and that difference is going to be far greater than any of the subtleties in these variations 01:20:52 Nat: The gothic face will just unify the glyphs, have the same glyph for both codepoints 01:21:14 jdaggett: There will be UAs that try to do the right thing and show the variant. That will look worse than UA that does the wrong thing 01:22:47 RESOLVED: Send comment to Unicode on behalf of CSSWG requesting stronger requirements for sharing IVSes across IVD collections. 01:22:54 Topic: font fallback with IVS 01:23:26 jdaggett: My standpoint isn't that I want one way or another, but that there's a tension between doing the right thing and showing the correct variant, and keeping a consistent style of text. 01:23:43 jdaggett: For a lot of users, the distinction is too subtle, which they won't notice, but they will pick up the style change. 01:23:53 Yamamoto: There can be 2 different views on this issue. 01:24:02 Yamamoto: If we have theoretical character model 01:24:19 Yamamoto: Yes, there are exceptional cases such as Gothic and display faces, where such subtle details are gone 01:24:40 Yamamoto: But there are a variety of typefaces in Mincho style, there are many different designs of Mincho categorized in Mincho style 01:24:56 Yamamoto: In that scope, I think it is possible to notice the differences in these glyph shapes. 01:25:30 Yamamoto: For example when the govt wants to use differences in glyph shapes for purposes of their database for people's names or place names, if they want to use IVSes to distinguish subtle differences based on Mincho style 01:26:13 Yamamoto: They may think that oh, if one IVS and its glyph can be represented by different Mincho typeface, they may think this single IVS is slightly abstract nature as a glyph, abstracted glyph, and not the lowerlevel typeface-dependent glyph images 01:26:53 Yamamoto: I think understanding of most ppl in govt and financial org where they need to distinguish such subtle differences, seems to be limited to scope of Mincho style. So important govt docs printed in Mincho typeface. 01:27:02 Yamamoto: So I can agree with you, but there is another way of looking at this. 01:27:17 Nat: One point you may want ot emphasize, is when doing fallback, when doing catastrophic fail of the system ... 01:27:35 jdaggett: You said this yesterday, and I want to say this again -- on the Web, fallback is the normal thing. 01:28:03 jdaggett: If you bring up Facebook, you'll see a bunch of languages. the only reason those are ever displayed is because UAs search through the system for a font to use to display them 01:28:19 Koji: Even within Japanese, authors tend to want to show glyphs while designers want to use consistent typefaces. So it splits. 01:28:36 jdaggett: I think that's not true. I think authors would like things displayed nicely, too. 01:28:52 jdaggett: Kobayashi-san wants it one way, and person working at Magazine wants it another way 01:29:11 Koji: If author things the difference is subtle, they shouldn't use IVS. It shouldn't be asked to decide, it should be author's ... 01:29:29 Koji: if author cares, the difference is important to him. 01:29:45 Florian: It says the author cares. Doesn't say whether author cares enough to switch font. 01:30:23 Nat: I'm concerned about author knowing so much about the encoding. They'd just pick from a glyph palette. 01:30:54 Nat: When developing content that might involve font fallback, we should give the author ability to choose whether they care about the exact glyph shape or the font consistency. 01:31:11 Nat: Because of the tension you menion, I think there should be infrastructure to support a preference of some kind. 01:31:22 Nat: Author should know that UA might not be able to display things as desired 01:31:36 Nat: All fo these combine to make situation. 01:31:50 Nat: When there's a conflict, we should give them a choice. 01:32:26 Yamamoto: govt or police or CIA may want abstract glyph instead of typeface consistency. But graphic designer or commercial advertisement, yeah, abstract glyph shape can be less important. 01:33:07 Nat: I think also if we make that choice explicit, it will help ppl registering in the IVD to realize whether their variant is purely stylistic or whether it is more semantic. 01:33:25 Nat: This font fallback scenario helps people understand that. 01:33:36 jdaggett: One problem we have in CSS is, font fallback, we have a couple different flavors. 01:33:44 jdaggett: A lot of discussion has been simplified or oversimplified. 01:34:00 jdagget writes: 01:34:05 font-family: fontA, fontB; 01:34:14 jdaggett: So if I have a base character and a selector 01:34:42 jdaggett: in an ideal world, you would ask if the sequence is in fontA, if in fontB, and then go into system fallback 01:34:50 jdaggett: system fallback is a black box. 01:34:56 jdaggett: That's not something that is explicitly specified. 01:35:01 jdaggett: This is currently a one-pass process 01:35:21 jdaggett: We haven't defined how to match clusters as opposed to single characters, but it's a character-based model, and it's a one-pass model 01:35:29 jdaggett: You go through font list, and then you hit system fallback 01:35:42 jdaggett: When you consider IVS, need to think maybe there's a 2-pass process tha needs to happen 01:36:01 jdaggett: So, in many mailings that have been posted, appear to describe as 2 options 01:36:23 1. You take the combination of base character and selector, go through the list looking for a match. 01:36:46 If you don't find one, you use base character and look for a match again 01:37:23 2. Go got to first font and check for char + IVS, then check for base character, then go to second font and ask for base+IVS, etc. 01:37:35 jdaggett: Those are just 2 of several options. Because you have this black box here. 01:37:37 konaya has joined #css 01:37:41 jdaggett: Question is, when do you hit the black box. 01:38:04 jdaggett: In 1, do you hit the black box with the combo before going back with the base character? 01:38:21 jdaggett: Or do you only hit system fallback if you can't find either the sequence or the base? 01:38:39 Florian: Not sure this helps with having a choice 01:39:02 jdaggett: ... 01:39:57 jdaggett: This problem (points at IVS example) makes things even worse, do you look at interrelations between variants? 01:40:08 Koji: I would like to show an example of how I would choose glyphs. 01:40:16 Koji: It's not about IVS, but even before IVS we have some variants 01:40:26 Koji: I'm going to show how I would type user name today. 01:40:47 Koji: I'm typing watanabe, and this is the IME conversion. 01:40:55 Koji: It's picking up from my Outlook contacts 01:41:13 Koji: Different Watanabe's in my outlook contact have different glyph differences 01:41:21 Koji: I don't remember which glyph, but it's in my contacts 01:41:27 shepazu has joined #css 01:41:32 Koji: But it's important to get it correct for people names 01:41:39 Koji: So this is built into IME. 01:42:30 Florian: I think the point is that the person authoring the document might not realize that they're picking a very particular glyph 01:42:43 jdaggett: So you're saying you don't know whether this is using an IVS or not 01:43:08 Koji: Right. If this displays different on his computer, I would be very disappointed. 01:43:49 jdaggett: ... 01:44:22 jdaggett: I think what Nat is suggesting is interesting, for example in a name list you would choose to show the correct glyph, but in a more general context you would choose to preserve the font style 01:44:52 Yamamoto: ... family name distinction is done by subtle distinctions at abstract level, and that is important. For large group of ppl in Japan, they require what Ishii-san said. 01:45:18 jdaggett: So the problem is, if the policeman has the Hanyo-Denshi font, and your system doesn't have it, what happens? 01:45:19 szilles has joined #css 01:45:29 jdaggett: There's a subtle point here wrt how UAs evolve. 01:45:40 jdaggett: We all know that features have a way of going beyond what's in the spec very often 01:46:08 jdaggett: My concern with this is that there' be a natural temptation to do improvements, such as incorporating mappings between Hanyo-Denshi and Adobe Japan 1 and default glyph 01:46:18 jdaggett: If one UA does that, then all UAs have to do that. 01:46:27 jdaggett: So my idea is to disallow that in the spec. 01:46:54 Nat: Same problem exists today with mobile phones 01:47:15 Nat: When you send from NTT Docomo phone to ??, the SMS gets translated to something that will work. 01:47:38 jdaggett: I want to put in that cmap tables are used, only. 01:47:50 jdaggett: I don't want all implementations to cart around a mapping table. 01:48:00 Steve: If the problem get solved at the registry level 01:48:13 Steve: Then it's easy fo rpeople to be consistent because there is in theory only one sequence for each 01:48:35 Steve: The next suggestion is to require font vendors to have mapping tables 01:48:40 Steve: Then the user doesn't need to do it 01:48:53 Steve: It could also be solved at the UA level 01:49:20 jdaggett: For this version, those tables don't exist, and we create an interop problem if different UAs use different tables 01:49:42 Steve: My final point is that somewhere some group should create that table 01:49:50 Steve: Which will be copied everywhere. 01:50:06 Nat: Fonts are a notoriously unreliable place to put such mapping table.s 01:50:16 Nat: We are constantly updating our stupid Unicode tables in these fonts. 01:50:23 Nat: There are so many inaccuracies in our font tables. 01:50:34 Steve: Moving the solution to a different place doesn't solve the problem of building the table. 01:51:02 jdaggett: My point is that it would be unfortunate for everyone if we tried to do the right thing, incorporating some complicated algorithm, and then that complicated algorithm, by user demand, gets foisted on other people. 01:51:54 ... 01:52:05 Nat: I think clear wording in the spec is good. 01:52:18 Nat: With this issue, but there's a conflict between ppl wanting to use Adobe Japan 1 and Hanyo-Denshi 01:52:28 Nat: I think there will be resistance for font vendors to use both mappings. 01:52:38 Nat: Hanyo-Denshi variations are built for a certain user set in mind. 01:52:56 Nat: And some of these variations are so subtle, that they are almost stylistic variations. 01:53:15 Nat: They're provied for govt use or whatever 01:53:41 Nat: Adobe-Japan 1 is not a government use table 01:54:04 Nat: I think it'll be difficult for each font vendor to map to the govt glyph shape database 01:54:13 Nat: Which is what it's becoming, instead of semantic-meaning database. 01:54:38 Nat: So we need this table, maybe it goes in the black box, but then everyone has different black box 01:54:53 jdaggett: I wanted to point out one thing Kawabata san put up on the board. 01:55:14 jdaggett: One thing he put up was [base char][IVSx][IVSy] 01:55:24 jdaggett: so that was fallback in the character stream 01:55:38 jdaggett: This.. if you look at how this was defined, there's a single selector. You can't have multiple selectors. 01:55:47 jdaggett: We should explicitly put in text saying the second selector is malformed. 01:56:08 Nat: It's interesting thing he's decided is necessary. Points out that fallback.. becaus eof hte way IVD colections came about, fallback will have to be customizable 01:56:35 Nat: Could be more fuel for your letter. Here is someone who wants to customize fallback. Obviously there's a problem here. 01:56:44 Koji: I think there were two issues mixed. 01:56:50 Koji: One is whether to fall back IVS first or font first 01:56:59 Koji: Other is mapping between different IVD collections. 01:57:15 Koji: For the latter, I don't think it's necessary. It's not application's responsibility 01:57:32 jdaggett: I'm saying it's not just unnecessary, but we have to say it's not allowed. OTherwise some applications will includde it in their black box. 01:57:47 jdaggett: This table doesn't even exist, so ... 01:57:53 Florian: Can we address separately the two issues? 01:58:06 Koji: What I care is first one. 01:58:39 jdaggett: I hadn't considered Nat's proposal to allow a choice 01:59:14 Florian: We have a switch in CSS, and give an algorithm for each option. 01:59:28 Florian: I think it's only possible to pick the best algorithm for each priority 01:59:59 Florian: Not hard to decide on the algorithm once you have priority 02:00:19 jdaggett: So my proposal would be to look for the correct sequence first, all the way to system fallback. Then go back and do base character. 02:00:42 jdaggett: And have a switch for preferring font consistency. 02:01:26 jdaggett: Keep in mind that the text includes the IVS, so if you cut and paste it you preserve this info 02:01:34 Nat: Imagine a publishing-proofing system. 02:01:52 Nat: In desktop systems, we want to make it really obvious when a glyph is missing. 02:02:17 Nat: This way the proofer could immediately see that this character was missing or wrong 02:03:12 Steve: You could use a font that maps every Unicode codepoint to the geta character (missing glyph thing) 02:03:55 jdaggett: So, first point is, that's not a general feature. It's a user-agent level feature. 02:04:05 Nat: ... 02:04:15 jdaggett: Oh, you're talking about a Web-based authoring environment 02:04:45 Steve: Just hijack it by using the fail-character font 02:04:52 Nat: Ok, that works. 02:05:57 Nat: U+3013 02:06:07 jdaggett: Ok, so that's all I have to say. I'll work on adding the wording here. 02:06:21 jdaggett: Unfortunate that this complicates font fallback, but that's par for the course. 02:07:19 RESOLUTION: font fallback goes all the way to system fallback with the IVS before repeating with base, will add a property to switch between that and font-consistency-priority matching 02:07:23 Zakim has left #css 02:08:16 Nat brings up compatibility chars 02:08:40 Koji: I think that's a separate topic, and not CSSWG responsibility 02:08:50 Nat: No, but add to Unicode feedback from CSSWG. 02:09:23 ACTION: fantasai mention compat characters in mapping table request 02:09:23 Created ACTION-322 - Mention compat characters in mapping table request [on Elika Etemad - due 2011-06-10]. 02:19:35 RRSAgent: pointer 02:19:35 See http://www.w3.org/2011/06/03-css-irc#T02-19-35 02:24:42 boblet has joined #css 02:28:22 ScribeNick: TabAtkins 02:28:44 murakami: I think 'white-space-collapse' is a good name for the property. 02:29:02 murakami: It's not a big problem for XSL-FO to have a property of the same name but different values, I think. 02:29:08 murakami: They're sufficiently different. 02:29:17 szilles: So what happens if I embed SVG in both? 02:29:29 szilles: It makes sense for SVG to do whitespace collapsing. 02:29:36 Note: Murakami-san is an implementer for Antenna House Formatter, which supports both CSS and XSLFO 02:29:53 szilles: The agreement we had was that if we were going to change the property value, we should change the name. 02:30:26 murakami: With 'white-space-collapsing', is the "ing" a big problem? 02:30:40 fantasai: Just clumsy, especially with 'border-collapse' already existing. 02:30:59 jdaggett: Why not just call it 'white-space-collapse' for now, mark an issue, and look at it later? 02:31:18 fantasai: That just puts us in the same boat. 02:31:54 jdaggett: Just to have it not be "bikeshedding". 02:32:19 "whollapse-c-space" 02:32:20 dbaron: 'collapse-white-space'? 02:32:40 szilles: 'text-space-collapse' 02:32:56 RESOLVED: Change to 'collapse-white-space'. 02:33:16 RESOLVED: Strike last resolution 02:33:29 RESOLVED: Change 'bikeshedding' to 'text-space-collapse' 02:34:40 fantasai: Let's look at the ToC and go through issues. 02:35:25 Nat: My main priority is things to do with japanese punctuation adjustment. 02:36:44 jdaggett: [explains the standard model of pruning specs after experimental impls start] 02:38:11 fantasai: Let's start with linebreaking, then spacing, then text-justify. 02:38:44 fantasai: ie6 implements line-break:normal and strict, and then we added another level, and an 'auto' value so the UA can pick whatever's appropriate (mobile phones want looser, probably) 02:39:03 fantasai: The definition is fairly vague - lots of UA freedom. 02:39:37 fantasai: In strict breaks are forbidden before small kana and some other marks. 02:39:45 fantasai: [more description of the property in the spec] 02:40:12 jdaggett: Is there stuff in the jltf recs that give you character classes for this info? 02:40:23 fantasai: We do point to the jlreq document for recomendations, but... 02:40:35 jdaggett: I'm looking for something more detailed. 02:41:01 jdaggett: I'm fine with codepoints being listed as a character class in a normative appendix, so then we can just refer to character classes in the normal spec descriptions. 02:41:10 fantasai: Ok. 02:41:21 Nat: I don't htink the jlreq character classes are used for linebreaking. 02:41:27 szilles: They sometimes are, and sometimes aren't. 02:42:44 kojiishi: Topan said that they wanted to specify individual characters for "kinsoku rules" (characters you can't break on). 02:43:21 florian: General interoperability concern - while this helps for cj, it potentially makes the interop bad for other types of languages. 02:43:30 florian: Because there aren't any details other than the cj stuff. 02:43:45 fantasai: Unfortunately, the rules for linebreaking are very specific to the language... 02:44:11 fantasai: We're not trying to solve this, and exactly specify it, but in Japanese they care about having different levels of linebreaking. 02:44:31 fantasai: We could specify that in languages other than cj, the property has no effect, or has no effect *right now*. 02:44:36 jdaggett: Is this tied to the language tag? 02:44:46 fantasai: Somewhat - there are several breaks that are based on the language. 02:44:54 jdaggett: I ask becuase you can have mixed-language documents. 02:45:23 jdaggett: So you shouldn't be using the japanese rules. And there are english-breaking rules, where in japanese you'd instead do some relatively odd things (like breaking in the middl eof an english word). 02:45:31 fantasai: That's handled by the next property. 02:45:36