00:14:59 cabanier has joined #css 00:17:13 jdaggett has joined #css 00:31:05 lmclister has joined #css 00:32:13 rhauck has joined #css 01:26:02 jdaggett has joined #css 03:28:46 jdaggett has joined #css 03:37:35 lmclister has joined #css 04:41:02 shepazu has joined #css 05:29:32 teoli has joined #css 05:48:33 krit has joined #css 06:22:49 projector has joined #css 06:22:58 trackbot, start telecon 06:23:00 RRSAgent, make logs member 06:23:00 Zakim has joined #css 06:23:02 Zakim, this will be Style_CSS FP 06:23:02 I do not see a conference matching that name scheduled within the next hour, trackbot 06:23:03 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 06:23:04 Date: 13 September 2013 06:23:11 RRSAgent, make logs public 06:23:22 Zakim, remind us in 10 hours to go home 06:23:22 ok, projector 06:30:59 dbaron has joined #css 06:46:43 zcorpan has joined #css 06:47:23 zcorpan has joined #css 06:48:01 zcorpan_ has joined #css 06:48:37 glazou has joined #css 06:49:03 astearns has joined #css 07:06:45 sgalineau has joined #css 07:11:19 yamamoto has joined #CSS 07:11:55 oyvind has joined #css 07:13:18 krit has joined #css 07:16:46 jet has joined #css 07:18:13 krit, ok 07:18:23 that's just a review request right ? 5mins ? 07:18:39 yes, nothing more 07:18:43 cool, np 07:19:08 florian has joined #css 07:19:50 teoli has joined #css 07:20:58 shans__ has joined #css 07:24:58 darobin has joined #css 07:29:33 michou has joined #css 07:30:43 israelh has joined #CSS 07:31:41 kawabata has joined #css 07:31:48 scribenick: sgalineau 07:31:51 http://wiki.csswg.org/planning/paris-2013 07:31:59 Rossen_ has joined #css 07:32:22 Topic: CSS Masking - review request 07:32:32 krit: I incorporated yesterday's feedback in the spec 07:32:42 krit: we will only support one layer of masking 07:33:04 krit: also I updated the initial values we discussed 07:33:21 krit: I have no issues in the spec at the moment and would like to ask for review 07:33:33 tobie has joined #css 07:33:48 krit: child selector for the mask image would be at-risk 07:34:02 glazou: how much time do you need for review 07:34:04 krit: 3 weeks? 07:34:17 glazou: ok so 2nd telco from now 07:34:23 http://dev.w3.org/fxtf/masking/ 07:35:10 fantasai: I'd prefer 4 weeks 07:35:22 so that's October 9 07:35:36 RESOLVED The WG will review Masking LC transition on 10/9 telcon 07:36:00 Topic: Any interest in working out selection/editing based on display tree rather than DOM? 07:36:20 astearns: selection/editing only work on the DOM tree 07:36:41 astearns: when certain positioning modes/layouts get used, selection start looking funny 07:37:23 astearns: how much interest is there in making selection/editing work on table columns, or select what is inside an abspos and what is next to it vs selecting DOM ranges 07:39:14 +q 07:39:18 glazou: the problem is selecting visually contiguous areas regardless of whether there are floats or whatever 07:39:34 astearns: yes. you start selecting inside a float and drag outside, a lot of stuff comes in 07:39:50 michou: this gets fun with flex box and grids as well, especially when the content has been reordered 07:40:19 fantasai: my understanding was that the DOM APIs for selection allowed for discontinuous ranges and it was up to the UAs to do the right thing 07:40:34 astearns: is this WG interested in coming up with an intelligent way to deal with this? 07:40:54 glazou: I think there are two question 1) is the problem interesting? yes 2) is it a CSS problem? I'm not sure it belong to this WG 07:41:27 glazou: this seems more a description of visual selection behavior in the UA 07:42:00 astearns: right. as michou pointed out this is left to UAs 07:42:32 fantasai: what is the interop we're looking for? 07:42:52 glazou: I've gotten blue griffon bug reports due to surprises related to caret management 07:43:16 glazou: WYSIWYG editors behave one way, browser-based editing surprises users 07:43:57 krit: it's not only selection, it's also accessibility, isn't it? 07:44:20 fantasai: this can be intentional though 07:44:56 glazou: I'm really interested in the topic but I do not think this is a CSSWG work item 07:45:27 plinss: maybe we need APIs that produce ranges based on a geometry 07:47:08 astearns: the Region spec has APIs to get DOM ranges for a named flow so we're kind of going in that direction 07:47:48 glazou: would you like to move this to a new ED? 07:48:01 astearns: not at this time; there doesn't seem to be enough interest in this area at the moment 07:49:16 Topic: flexbox 07:49:53 tabatkins: a handful of clarifications and tweaks to the layout algorithm are needed 07:50:23 http://dev.w3.org/csswg/css-flexbox/#issue-dd911971 07:50:24 leif has joined #css 07:50:36 http://dev.w3.org/csswg/css-flexbox/issues-cr-2012#issue-3 07:50:56 tabatkins: there is a request to make percentages work well even if the flex item is auto height 07:51:41 tabatkins: if a flex item is stretched, the fixed container is a fixed height and a child of the flex item uses % the % is resolved against the stretched height of the flex item 07:51:56 dbaron: is this horizontal only? 07:53:05 fantasai: apparently IE already implements this; if there is a flex row container and it's auto height, and an item inside it has a % height child…. 07:53:05 SteveZ has joined #css 07:53:36 tabatkins: we used to not resolve this. we'll do layout as if it was auto and then resolve those percentage children 07:54:13 dbaron: what is it that the height applies to? 07:54:27 dbaron: then I have to relayout 07:54:37 tabatkins: you relayout the flex item but not the flexbox 07:54:56 dbaron: small incremental updates may require another pass 07:55:05 (tabatkins draws a picture) 07:55:48 dbaron: does the flex box has a fixed height? 07:55:51 tabatkins: no 07:56:10 tabatkins: this works well if the item in question is not the tallest 07:56:30 tabatkins: it's not ideal when the flex item in question is the tallest but it's still better 07:56:45 dbaron: it sounds a bit like table row sizing 07:57:28 dbaron: in tables, % sizing of table cell children appears to be random... 07:57:37 tabatkins: in this case, it's not hard to depend on 07:57:57 tabatkins: if you have a fixed height, it just works. otherwise, it does its best attempt and it's workable in most cases 07:58:18 dbaron: I'd guess I'd be OK. What does dholbert and other implementors think? 07:58:23 rossen: we're OK with it 07:58:57 rossen: I thought we had agreed to this at TPAC 08:00:21 (short exchange ending with tabatkins: oh yeah, I'm making stuff up) 08:00:36 tantek has joined #css 08:01:04 RESOLVED: use 2-pass algorithm to resolve % height children of flex stretched items pending dholbert's feedback 08:01:36 tabatkins: issue-3 is the proposed text for issue-2 08:03:03 tabatkins: next is issue-1 about respecting the intrinsic aspect ratio of flex items 08:03:26 tabatkins: you don't want to abandon this ratio unless absolutely necessary 08:03:37 tabatkins: we never resolved the proposed edits 08:04:29 tabatkins: during the initial sizing, if it is stretched and auto in both dimensions, and the container has a definite cross-size and is single line….then we go ahead and pre-stretch the item and use its ration to figure what its main size 08:05:42 (tabatkins clarifies the steps for dbaron) 08:06:13 tabatkins: I don't recall any objections; IE already does something close to this 08:06:27 RESOLVED: proposed issue-1 edits are approved 08:07:37 tabatkins: that's it for now; one issue left we need to discuss later. 08:07:46 fantasai: and then we'll make diffs and move to LC 08:08:04 Topic: Color module 08:08:19 tabatkins: a few weeks ago we approved to take my new Color draft 08:08:34 tabatkins: this is a quick yay/nay on features we'll move to the ED 08:09:00 glazou: Chris might have input on this but he's not here yet 08:09:37 http://tabatkins.github.io/specs/css-color/Overview.html 08:10:16 tabatkins: http://tabatkins.github.io/specs/css-color/Overview.html#changes-from-3 08:11:03 tabatkins: I could use help defining what device-cmyk() means 08:11:17 howcome: if you want CMYK to go into a PDF this is what you use 08:11:25 simonsapin: is this supported on screen? 08:11:42 howcome: no. the way people are using it this is just an addition. 08:11:52 bert: how do you know it's PDF output or not? 08:12:03 howcome: you just have two declarations. browsers will ignore it. 08:12:15 tabatkins: I hope we could define it for screen 08:12:50 tabatkins: when do we do this translation? 08:13:18 szilles: the normal meaning is that you don't transform it in any way; you don't translate to the screen because it wasn't set up for that 08:13:34 tabatkins: so you can't interpolate this with other colors 08:13:56 krit: blending and filter used a unified RGB color space; how do you translate to that color space? 08:14:13 tabatkins: in those cases I think we can just do a trivial transform; there will be some loss but that cannot be avoided 08:14:43 tabatkins: i think we should treat device-cmyk as a specific color type that only interpolates with itself. 08:15:00 tabatkins: and if you use CMYK on a screen I'd like to still be able to show it 08:15:21 tabatkins: this will take care of blending and compositing 08:17:00 szilles: PDF predates ICC; there were no profiles. I'm not convinced adobe would advocate using device-cmyk since you're no longer portable... 08:18:55 .... 08:21:39 (back and forth, followed by drawing on whiteboard about resolving the color of an overlay scenario) 08:22:51 (unminutable exchange follows) 08:23:23 (unminutable design discussion that is) 08:23:44 Håkon: you just dump all the colors into PDF, and the PDF readers figure it out 08:23:53 tantek: But we are a PDF reader. How do we composit this? 08:23:56 http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs/PDF32000_2008.pdf PDF spec 08:23:58 howcome: It's in the PDF spec 08:24:04 um I didn't say that 08:24:13 s/tantek/Tab 08:24:17 thank you 08:24:27 TabAtkins: ... sending straight to printer 08:24:38 howcome: Printer knows how to draw cmyk 08:24:50 TabAtkins: But it doesn't know how to composit 08:25:01 ScribeNick: fantasai 08:25:14 koji: ... compositing cmyk is different from rgb 08:25:32 TabAtkins: If you need a cmyk color for interpolating or compositing, or whatever, calc closest rgb color, and use that 08:25:41 dbaron: Then you are presuming non-dvice-specific cmyk 08:25:48 TabAtkins: There's a simplistic one we can use, yes 08:25:59 howcome mumbles 08:26:03 so if we have a formula for non-device-specific cmyk, why would we not want to use that? 08:26:17 howcome: Sometimes you do want two different colors 08:26:28 Florian: that's what media queries are for 08:26:59 jet has joined #css 08:27:06 Discussion of device-cmyk taking an optional fifth param, which is a fallback rgb color 08:27:43 howcome prefers browsers don't recognize device-cmky 08:27:54 plinss: Wnat to be able to load into browser and print and get the right color 08:28:03 TabAtkins: all of our color math is specified in rgb space 08:28:10 Florian: We need author of doc to not mix colors 08:28:23 TabAtkins: Or to give us a profile , so we can translate properly 08:28:52 someting about not knowing the actual color until it's sent to the printer 08:29:07 Florian: 5th fallback param seems way to go for me 08:29:47 TabAtkins: Want to make sure that, from impl perspective, use cmyk for doc but when compositing with rgb, have 08:29:54 koji has joined #css 08:29:54 ??? 08:30:15 plinss: Wanting to use fallback color from cmyk() on pixel by pixel basis, when compositing 08:30:29 Florian/Tab note that have to do this when compsiting images anyway 08:30:58 SteveZ: There are rules in PDF for device-cmyk to rgb and vice versa 08:31:11 SteveZ: one suggestion is that you convert device-cmyk to device-rgb, and then treat it as if it were sRGBA 08:31:16 SteveZ: That's a fairly simple thing 08:31:29 SteveZ: Won't give you "right" answer, but it's well-defined, and solves all the problems, without having to do fallback or sometihng like that 08:31:35 SteveZ: Should highlight what's happening 08:31:58 fantasai: Let me see if I understand what you're talking about 08:32:31 fantasai: So you, Tab, were saying that .... 08:32:47 fantasai: If you have a document where everything is opaque, some things in cmyk and some in rgb 08:32:58 fantasai: no problem with sending to printer 08:33:00 TabAtkins: Right 08:33:10 fantasai: So you send to printer cmyk colors and rgb colors 08:33:11 TabAtkins: Yes 08:33:24 fantasai: If you have compositing, you do what? 08:33:46 TabAtkins: For pixels that are being composited, if any of the argumjents are cmyk, turn them into rgb fallback 08:34:12 SteveZ: My suggesiton was to use the PDF rules to turn cmyk to rgb 08:34:38 plinss: Say you have one element, device-cmyk, another element on top of it, partly covered and using rgba 08:35:01 plinss: Don't want the clear parts of the element to be using a different color than the parts of the element that are over the cmyk elekment 08:35:16 plinss: ... 08:35:31 plinss: If you have 1% opacity, don't want to jump into new color space 08:35:50 plinss: If you have one element next to other element, vs. just barely overlapping, also don't want slightly different colors 08:36:58 peter says something important 08:37:31 florian: Being ugly at this point isn't that important; the author messed up. If they don't want it to be ugly, specify colors right 08:37:40 plinss: Just don't want [discontinuities mentioned above] 08:38:18 fantasai: Can you just tain the entire doc if using device-cmyk? 08:38:28 TabAtkins: Would also have to taint it if there is any use of opacity or compsiting... 08:38:48 TabAtkins: Anything other than entirely opaque 08:39:17 florian: PDF printing already has a pre-print checker, so maybe it's ok 08:39:39 In http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/PDF32000_2008.pdf 08:39:47 dbaron: This doesn't feel like a feature we want in browsers 08:39:56 dbaron: I feel like we should specify it in a way that the print processors can have it 08:40:01 dbaron: In some restricted set of cases 08:40:09 dbaron: Do AH implement things like opacity and blending? 08:40:20 Section 10.3 describes the rules for converting among device color spaces 08:40:26 howcome: I don't know 08:40:31 howcome: I believe they support opacity 08:40:42 howcome: Print processors, it's easy, they just toss to PDF 08:40:47 howcome: They always print to PDF 08:41:00 TabAtkins: Chrome *is* a PDF viewer 08:41:26 fantasai: Then go to what PDF spec ays 08:41:49 koji: Says that if PDF file has device-cmyk() then it must have mapping, so that you can do interpolation 08:42:16 TabAtkins: Coudl we do that? Assume some default ICC profile, possibly implementation-defined, possibly by inspecting device, but also have a way of specifying specific profile 08:42:25 SteveZ: I would like to go ask color guys at Adobe 08:42:53 fantasai: So plan should be, copy cmyk text from gcpm, add an issue explaining the problem 08:43:00 +ChrisL 08:43:07 ChrisL: Sorry to be late, but you're all wrong. 08:43:36 [...] 08:44:08 ChrisL: If it's in device-cmkyk and you want rgb, you do classic ? with absolutely zero idnication that it will be what you want 08:44:15 SteveZ: ... 08:44:29 TabAtkins: So we assume a probably UA-dependent translation rule 08:44:35 TabAtkins: provide way to give an explicit mapping 08:44:53 TabAtkins: and then treat device-cmyk as plain color for all purposes, because we have a mapping 08:45:23 TabAtkins: Default translation should be specified 08:45:34 SteveZ: It's a page and a half in the PDF spec. Just point to it 08:45:42 dbaron: Want to go back that we don't want this in specs 08:45:51 s/specs/browsers/ 08:45:54 SteveZ: Why not? 08:46:10 SimonSapin: 2 issues, first one is whether it's supported at all in browsers or more generally, on screen 08:46:27 SimonSapin: 2nd issue is, when we are printing, how does cmyk interact with rgb when we do interpolation , gradient,s compsiting, etc. 08:46:42 ChrisL: depends on whether device-cmyk or ?? standard cmyk 08:46:59 s/??/ICC-profile/ 08:47:07 ChrisL: If you have an ICC profile you know how to convert it to the profile connection space 08:47:34 ChrisL: The profile connection space is either CIE-xyz or CIE-lab 08:47:37 ChrisL: the profile connection space is either CIE XYZ or CIE LAB 08:47:44 ChrisL: Both of these have property that there's no damage, effectively 08:47:48 s/LAB/Lab/ 08:48:03 TabAtkins: They have no gamma, so can put any other space into it 08:48:24 ChrisL: Having done that, you then have to transform it down to sRGB just to do interpolation, because that's the only color space you have 08:48:35 ChrisL: SVG2 had ability to specify interpolation color space 08:49:07 ChrisL: So if you had graident with stops in [lists various prifles], no problem, do your interpolation, then spit out the result into the output color space 08:49:28 s/interpolation/interpolation in the profile color space/ 08:49:35 s/color space/connection space/ 08:50:10 SimonSapin: What you just explained is all with ICC profiles. 08:50:17 SimonSapin: But the feature in GCPM is device-cmyk() 08:50:30 ChrisL: Means we can come up with a fallback rendering on screen 08:50:40 ChrisL: Could use this in print 08:50:44 Florian: That's the issue here 08:51:01 Florian: this is what we were discussing before ChrisL arrived 08:51:20 Florian: When it's about gradients or animations / transitions, can decide not to interpolate. But for compsiting doesn't have an option. Can't return an error, have to draw something. 08:51:44 ChrisL: As side effect of all that, use exact same method for [...?] 08:52:05 ChrisL: Don't have to say, oh, this is RGBY, whatdo I do with that. 08:52:11 ChrisL: So, shoudl we discuss... 08:52:15 ChrisL: SVG2 has a chapter on this 08:53:07 ChrisL: Would much rather see this in CSS 08:53:17 ChrisL: would rather see this in CSS rather than SVG 08:53:30 ChrisL: Previously, dbaron was concerned that it was a lot of syntax for helping photographers 08:53:36 dbaron: What's "this"? 08:53:55 ChrisL: All of the color chapter in SVG2 08:54:13 dbaron: Don't remember exactly what was in there. Some of it was about prioritization 08:54:52 [we were trying to ship css3-color] 08:55:08 ChrisL: would prefer to put this in CSS4 color, and have the discussion there 08:55:18 ChrisL: Don't want to put things in there and then ... ? 08:55:29 ChrisL: as long as doesn't get screwed up, fine 08:55:35 howcome: Works perfectly right now. 08:56:17 krit: Current implementations in browser it doesn't make sense to differ between SVG colors vs. CSS colors because unified there anyway 08:56:21 dbaron: I agree that it makes more sense in CSS 08:56:50 TabAtkins: OK, resolution, do we want to try for the full gamut of colors right now? Or say that we do simple thing for device-cmyk and just make sure we're compat with full extent 08:56:55 https://svgwg.org/svg2-draft/color.html 08:57:21 ChrisL: People who want CMYK will ignore that it's device-cspecific-cmyk, and forget that they don't get what they really wanted 08:57:39 ChrisL: we should give peopel what they really want 08:57:49 ChrisL: They can use common conversion softwares 08:58:13 teoli has joined #css 08:58:26 ... 08:58:33
08:59:20 RESOLVED: add ChrisL as co-editor on css4-color 09:00:04 AREOLVED: pull in SVG2 color section into CSS4 color 09:00:12 s/AREOLVED/RESOLVED/ 09:01:20 (I think we should have rendering intent, yes, but why color profiles? That's just adding complexity without functionality.) 09:15:47 Rossen_ has joined #css 09:19:25 TabAtkins: Going to go through changes I've intorudced in css4-color, give a short description of each, then want show of hands for "yes or no", whether wnat it in the draft 09:19:36 TabAtkins: Want to get a feel for what-all we should do at this level 09:19:41 TabAtkins: Will do arbitrary order 09:20:11 #4 - hex with alpha 09:20:29 http://tabatkins.github.io/specs/css-color/Overview.html#changes-from-3 09:20:37 TabAtkins: right now to add alpha you have to convert to rgba() 09:20:54 liam has joined #css 09:20:58 dbaron: I'm a little iffy about the first four, though nmore the others than this one, 09:21:14 dbaron: Because once you add multiple syntactic ways of doing the same thing, whn preivously only some of them worked, 09:21:26 dbaron: laying a transitional period trap for authors 09:21:39 dbaron: Things will work in the browsers they develop in, but not others 09:21:51 dbaron: when could have been backwards-compatible 09:22:15 ChrisL: I see your point, but don't think it'll be too long of a transitional period 09:22:28 Florian: But what aobut e.g. iphone 3S 09:22:36 dbaron: I'm ok with them, but hesitant for that reason 09:22:43 SteveZ: Other problem is serializing 09:22:52 TabAtkins: That's a general problem 09:23:07 dbaron: I think in general we should serialize to the most broadly-compatible syntax 09:23:24 ChrisL: Disagree, because number has finer granularity 09:23:38 TabAtkins: But you can convert to percentage, which has that granularity 09:24:09 tobie has joined #css 09:24:17 ChrisL: Does that mean that if you provide hsl using angle units, and then serialize it, you'll get back something that was some other syntax? 09:24:20 TabAtkins: yes 09:24:26 TabAtkins: Should be defined already, or we need to define it 09:24:34 TabAtkins: In order of these things, the only ones are Feel strongly about 09:24:46 TabAtkins: 4 because common request (hex colors) 09:25:08 TabAtkins: and #1 because of script-based color manipulation. forget to round, get weird results -- fails to parse sometimes, sometimes not 09:25:16 TabAtkins: Other two are less important, just like them for consistency 09:25:30 TabAtkins: But if compat period pain is sufficinetly large vs benefit, I'm ok with leaving those out 09:25:35 TabAtkins: On that note, can we get some votes? 09:26:22 #1 - number inside rgb/rgba functions 09:26:30 bunch of raised hands for yes, none for no 09:26:47 RESOLVED: rgb() and rgba() will accent rather than 09:26:49 jet has joined #css 09:27:12 #2 - hgs() and hgsla() now accept in place of for hues 09:27:28 s/bunch/ 09:27:35 s/bunch/most/ 09:27:41 bunch of raised hands for yes, none for no 09:27:51 RESOLVED: Allow in place of for hues 09:28:40 #3 - All uses of now accept as well as 09:29:42 RESOLVED: Accept as 09:29:50 #4- rgba hex colors 09:29:58 RESOLVED: Accept rgba hex colors 09:30:27 zcorpan asks about compat impact 09:30:42 TabAtkins: Did compat research 3 years ago, compat issues are with HTML, not in CSS 09:31:07 zcorpan: If it's been researched and conclusion is that it's safe, then I'm fine 09:32:36 It looks like there was about half a no for #4. 09:32:51 that half a no is mine 09:32:57 TabAtkins: another one .. allowing rgb/hsl to take optional 4th argument so don't have to switch to rgba/hsla 09:33:36 #6 - give rgb/hsl ability to take 4th argument 09:33:46 ChrisL: We wanted the function name to represent the arguments 09:33:54 4-ish yes 09:33:57 5-ish no 09:34:02 TabAtkins: Ok, I'll leave it out 09:34:21 RESOLVED: No change to number of arguments to rgb/hsl 09:34:30 Discussing now, at #5 09:34:35 'color-correction' property 09:34:38 ChrisL: hate it 09:34:52 ChrisL: This was somewhat more relvant when Apple had slightly differnet gamma than everyon eelse 09:35:13 ChrisL: If you known what the color means, throwing it at the screen is reasonable to do if your device has smaller gamut than sRGB 09:35:30 ChrisL: once Apple changed to match everyone else, less of a problem 09:35:33 ChrisL:... 09:36:12 s/.../but if you have an AdobeRGB monitor you get really garish colors if the browser just throws sRGB at the screen/ 09:36:43 dbaron: Are browsers currently displaying colors correctly? 09:36:55 ChrisL: Yes, as long as ... ICC profiles 09:37:03 dbaron: You're saying we do it right for images. Do the CSS colors match the images 09:37:06 ChrisL: no 09:37:17 dbaron: Right, and that's the problem this was designed to give a migration path for 09:37:26 ChrisL: It's the wrong way to solve the compatibility issue 09:37:38 TabAtkins: This only applies to untagged images. If you have a color space specified, then you use that. 09:37:49 TabAtkins: It's only untagged images and CSS colors, because theyr'e essentially untagged 09:38:00 ChrisL: CSS colors do have a profile, you just don't have to specify it 09:38:17 dbaron: They're supposed to be sRGB, but not how it has been implemented correctly 09:38:23 dbaron: ... plugins... 09:38:31 dbaron: But that's improved more recently 09:38:41 ChrisL: yes, e.g. flash is color-managed now 09:39:00 dbaron: How do we get flash and css and images to match across devices with different color profiles/ 09:39:18 dbaron: The problem is that a lot of web pages expect colors to match flash 09:39:45 dbaron: but if we make CSS colors sRGB, tand flash is not, then get lines in pages where should be seamless 09:40:04 ChrisL: ... 09:40:32 dbaron: I agree with your desired end shtate, but don't understand how to get there from here, without users being mad at their brosers 09:40:47 ChrisL: Theyr'e getting what they want without that property, so how is adding itgoing to change it? 09:40:55 dbaron: They're not getting consistent color across devices 09:41:06 dbaron: This lets authors at least opt-in to saying they want the correct behavior 09:41:33 ChrisL: ... 09:41:51 dbaron: The behavior you're talking about, that CSS is color-managed, is not reality right now. 09:41:55 koji has joined #css 09:42:01 TabAtkins: Spec says colors are in sRGB, but in practice they're not. 09:42:20 TabAtkins: Things match because they're handled the same 09:42:36 TabAtkins: This property codifies that default is not color managed 09:42:43 TabAtkins: But allows people to opt into the spec behavior 09:43:00 dbaron: Would like to change default behavior eventually, but need to solve plugin problem. 09:43:22 dbaron: Want API for browser (not content) to tell flash how to color-manage 09:43:40 ChrisL: you're saying that colors match seamlessly already 09:44:00 ChrisL: author can tell Flash to treat colors as sRGB to match sRGB of CSS 09:44:16 dbaron: If someone has the resources to take on adding something to NPAPI, so we can tell plugins to do that, that would be great 09:44:26 dbaron: But barring that, this is an alternative solution 09:44:34 ChrisL: Doesn't seem that hard. 09:44:51 Jet: Not going to happen. People at Adobe that could do this have other things to do 09:45:10 Jet: 2 ppl who can do it that I know, don't work on that anymore 09:45:26 SteveZ: My estimate was that it would be difficult because it takes both sides to make the change: browsers have to ask, and flash has to respond 09:45:40 TabAtkins: At least on our side, it's both sides, because we have our own implementation of flash in Chrome 09:46:11 SteveZ: At least with Google, relationship has been pretty good, but that's only one of the players that has to do it 09:46:30 SteveZ: One comment is that, basically, area of plugins is sensitive, and people don't like playing in that area for various and sundry reasons, more political than technical perhaps 09:46:57 SteveZ: My initial gut feeling is agreeing with Jet, sounds like a good technical solution, but suspect the gods are not in favor of it 09:47:07 ChrisL: We might do better if we ask 09:47:24 SteveZ: If all of the browser vendors asked for it, that would significantly increase the chances of it happening 09:47:33 TabAtkins: Kills the coordination issue 09:47:53 TabAtkins: So, to wrap up. Yay or nay for having it in the draft. Can always cut out later, add appropriately scary issues around it 09:48:13 SteveZ: I'm ok to put in draft, but issue should describe the problem and say that this is *a* possible solution, but there may be others. 09:49:02 dbaron: When you copied my text, did you copy the introduction bits? Becaue that did try to explain the problem. 09:49:22 krit: Is this mainly for flash, or other content that could benefit? 09:49:58 TabAtkins: In other words, is this mostly a browsers vs. Flash issue? 09:50:08 krit: So, do we really want to add a property that will be deprecated in 2-3 years? 09:50:11 dbaron: I don't know 09:50:20 TabAtkins: Ok, so big issue about this. 09:50:39 RESOLVED: Add 'color-correction' property to Colors 4 draft, with issue about the problem it's trying to solve and consideration that it might not be the right solution. 09:50:51 Bert: I'm not ok with putting in this property 09:51:01 Bert: The property just says "dwim", and shouldn't have to do that. 09:51:12 Bert: The problem is in the implementations. 09:51:31 Florian: Property says which of things I could mean I mean 09:53:06 Liam is also not pleased. 09:53:14 Liam: Lots of changes here in OS support, too 09:54:41 Bert wants the issue to be very conspiciuous 09:54:48 Topic: Charter 09:55:18 http://wiki.csswg.org/planning/charter-2013 09:56:18 I disagree with the "what people expect to see in the charter". 09:57:37 Florian: It's easy to say as an editor that will make progress, hard to say def will make it to transition to next status 09:58:02 I don't think this exercise is useful. 09:58:10 Bert: This was starting point for discussion 09:58:27 fantasai: What are we trying to come up with to put in the charter? 09:58:57 Bert: most charter's say how long it'll take to get x to y status 09:59:03 dbaron: do you have an alternative exercise in mind for preparing our charter? 09:59:21 astearns, not listing fake deadlines for specs? 09:59:26 Bert: Our charter has traditionally just listed what status we expect to have at the end of the charter period 09:59:28 q+ 09:59:41 q+ ChrisL 09:59:48 q- 10:00:00 ack ChrisL 10:00:04 fantasai: I think we should just go with the format we used last time 10:00:21 ChrisL: I did a team-internal study on why specs were late 10:00:34 q+ 10:00:42 ChrisL: And found out that it was largely because people were pressured to put deadlines of 6- months to 2 years 10:00:57 ChrisL: tbecause of afraid ocharter will be rejected 10:01:05 ChrisL: if they gave the real answer 10:01:14 glazou: We have 2 AB members in the room 10:01:19 glazou: Want to say something 10:01:30 glazou: CSSWG is the oldest WG, rechartered every 2-3 yers 10:01:38 glazou: I think system of chartering and rechartering is wrong for such a group 10:01:53 glazou: Charter's are great for group that is to do a specific thing and then close 10:02:04 glazou: But we don't do that, we start things that go one, and star tmore things that contineua fter 10:02:27 glazou: We spend a lot of time on chartering and rechartering 10:02:44 glazou: So I'm ready to take an action, this is something I'm saying ot AB members, want to send message to AC forum describing the issue 10:03:00 glazou: And asking if W3C staff would be willing to find a better solution 10:03:04 SteveZ: 3 answers 10:03:12 SteveZ: It's already under AB agenda under title Super-groups 10:03:30 SteveZ: that is, groups iwht multiple work items progressing largely independently. E.g. webapps has similar concerns 10:03:35 SteveZ: We don't have a good solution t problem yet 10:03:43 SteveZ: The problem you just described is recognized and on the agenda 10:03:48 glazou: Do you think email describing issue can helP? 10:03:51 Tantek, Steve: yes 10:04:00 SteveZ: Fly in the ointment is basically the patent policy 10:04:15 SteveZ: That's because what's on the charte ris what ppl are comitting to potentially make IPR commitments to 10:04:23 SteveZ: So for that reason updating charter on regular basis is not a bad thing, I think. 10:04:26 SteveZ: It's every 2 years 10:04:32 SteveZ: Yes, takes a lot of time, but not all that frequent. 10:04:56 SteveZ: But forces us to do the evaulation, whcihwe maybe ought to be doing more frequently, of are we making the progress we thought we'd make 2 years ago, and if not, why not 10:05:00 SteveZ: Useful excercise in that respect 10:05:05 SteveZ: Most companies do it every eyar 10:05:11 Florian: I think putting dates on things is sometimes useful. 10:05:29 florian: But if we do it for everything, even when not useful, wil confuse things 10:05:53 Florian: For exampl,e, if we had charter that said IE 10 will releas by date X, and want Flexbox must be done before that, useful to say so in charter 10:06:05 q+ 10:06:08 ack florian 10:06:09 Florian: Useufl to say we want to put in date because the date is important, 10:06:25 ack florian 10:06:28 Florian: But if there's no reason for the date to be important, then shouldn't put it down. 10:06:50 tantek: Would it help to send an email, short answer is yes. If you're ok with it, would also ask to CC www-archive, because I think this is areasonable discusison to stay public 10:07:09 tantek: On specifics of what youraised, I think you'll find as someone who also likes less process and less bureacracy, would agree with mos tof what you said. 10:07:33 tantek: Act of rechartering, for CSSWG, here are list of things we want t owork on, with approximate prieority for next N years, I think that's useful. 10:07:52 tantek: I thin that helps communicate to outside world what WG considers improtant, and gives outside ability to communicate back if they disagree 10:08:06 darobin has joined #css 10:08:07 tantek: so I think that's useful 10:08:18 tantek: Sometimes we may wnat to update that more often than just every -23 years 10:08:36 s/-23/2-3/ 10:08:44 gtantek: About the dates of delivery, I think evidence has shown that any prediction is futile, have yet to sany of them hit by anyaone 10:09:02 tante: So I will counter florian's assertion about dates 10:09:14 s/tante/tantek 10:09:17 tantek: with saying that if any editor wnats to promis a date by which they will deliver a certain draft level, welcome to do so 10:09:30 tantek: But to ask the WG as a whole to do so, is ridiculous and bordering on dishonest 10:09:35 tantek: based on how none of that has ever worked 10:09:46 tantek: But if there are editors who feel confident in their ability to predict deadlines, go for it 10:09:54 Florian: not sure we're actually disagreeing 10:09:56 was a *promise* requested? or an *estimate*? those are very different things 10:09:57 glazou: I agree entirely 10:10:07 glazou: I'm making this dicussion diverge a bit to meta-problem 10:10:17 glazou i really feel we have an issue. This is 3rd time we are rechartering 10:10:22 glazou: Every time it took a few months 10:10:29 glazou: Once took 6 months 10:10:33 glazou: Sucks our time 10:10:38 glazou: Since AB works on that, I didn't know that 10:10:42 glazou: Could we serve an experiment? 10:10:55 glazou: If you're looking for an example if we can make an example, coudl the CSSWG be that example? 10:11:05 glazou: And could we write a charter that lasts a long time, and be amendable in a very simpler way 10:11:12 glazou: Amendabel by note 10:11:14 s/coudl/could/ 10:11:24 glazou: I agree that the deliverable sections and milestones sections, we never meet them, they are crazy 10:11:34 glazou: The potentialy expected deliverable,s and milestones are just [[ 10:11:48 glazou: We can reach the CR status, CR and rec is in between impelmenters an writers ouof tests suite, not fully in our hands 10:12:06 glazou: If the AB is interested, for this rechartering, in anotehr way of, doing a charter and managing a working group, even with the patnets issues and everything 10:12:13 glazou: I woild really be glad 10:12:34 tantek: I think that's somehwat in your hands. AB is meeting soson 10:12:39 ack glazou 10:12:51 q+ SteveZ florian 10:12:55 tantek: and make a proposal per email as said earlier 10:13:02 ChrisL: Another thing that used to happen, the AC would worry about how many groups work working at one time 10:13:11 ChrisL: So they would charter group to do specific thing, an dcease to exit 10:13:22 ChrisL: Then we had idea of adding 6 moths to the end to do maintenance work 10:13:43 ChrisL; then we also found down later that if you closed down a wg, and then reopened to do second version later, you lost all the patent commitements 10:13:51 ChrisL: didn't work for short WGs so much 10:13:59 ack ChrisL 10:14:04 ChrisL: MathWG oscillates between doing something, and then sits there for 2-3 years so it doens't go away 10:14:20 ChrisL: whether multiple specs or one, the assumption should be that to keep all of the IP commitments alive, the group must not close 10:14:26 q+ hober 10:14:30 ack SteveZ 10:14:32 SteveZ: Daniel, your comments you hit on the key point, which is management 10:14:35 SteveZ: of the wg 10:14:47 SteveZ: There's 2 organizations at least that care about that, one is W3C Team, and other is AC 10:15:11 SteveZ: I agree with Tantek's comentns and Florian's comment,s that falue of date sin the short term and not the long toerm 10:15:20 SteveZ: But those were what the team was trying to use to see if progress is being made 10:15:33 SteveZ: So any proposal to eliminate them has to come up with a way of indiciting progres 10:15:36 glazou: Yes, I understand fully 10:15:45 glazou: It's a way of simplyfing things, not eliminating control 10:15:48 ack florian 10:15:58 Florian: I think I was disagreeing a lot less with Tantek than he thought. 10:16:27 florian: If we have a commitment for a date, and I expec this to be almost never or never happen, useful to state 10:16:35 florian: E.g. in Flexbox case, there was sense of time period 10:16:45 florian: If gorup not commited to that time, then it works ot put that date 10:16:56 tantek: I think time urgency should be driven by implementers 10:17:21 hober: So, Chris described previous model of spinnning up and shutting down groups, evolved into hybrid of hibernating rejufinating groups 10:17:27 hober: For core platform work, that model is fiction 10:17:29 ack hober 10:17:34 hober: We have to be conitnuously working on core platform 10:17:47 hober: Steve described effort of rechartering as like annual reviews in a company 10:17:54 hober: I think it's useful to have annual review 10:17:59 hober: Would like to decouple that from rechartering 10:18:08 hober: HTML, CSS, WebPapps need indefinite charters 10:18:23 hober: Said going from CR to REC not in WG hand 10:18:49 hober: Now that we have core testing effort happening at W3C, I think one suggestion we can make at AB/AC is to make these CR transitions to be joint effor tof testing effor tnad that WG 10:18:55 hober: It's partially out of our hands 10:19:00 hober: let's acknowledge that 10:19:23 plinss: Having been in core testing group, they really don't give a shit about advancing specs along REC track. 10:19:44 plinss: The folks involved in web platform testing effort are not interested in advancing REC. Just interested in improving quality in general. 10:19:55 plinss: There is a very small subset that does care about moving to REC. Not my experience that that has any core priority. 10:20:11 plinss: "If we can do both great, but we're not going to worry about." 10:20:22 q+ 10:20:43 q+ 10:21:03 plinss: That's kept me form committing to working with their infrastructure, because if I say "we need this to advance specs to rec" they say "we dont' care about that" 10:21:26 hober: Going from CR to REC shoudl be joint effort, and apparently feedback from testing effort is not interested in that 10:21:53 hober: Unitalteral option is that it stillk is a joint effort, and just make our primary goal reaching CR. 10:21:56 ack liam 10:21:56 liam, you wanted to separate possible procedural changes in the future and the next rechartering, and to note the charter does not commit dates 10:22:16 Liam: Any change to W3C chartering process is not overnight, will tae year or two. So be prepared to do current recharting as perivously 10:22:52 Liam: However, common misconception among WGs, including Team people, is that dates in charter are a commitment. They're not. Just have to document deviations in charter will be documented on homepage 10:23:07 glazou: Kind of thing in W3C Proces sthat nobody reads/cares about 10:23:10 ack dbaron 10:23:10 dbaron, you wanted to say that it's worth discussing relative priority of specs, but agree the deadlines are silly 10:23:36 dbaron: i think it's worth discussing relative priorities of specs, and don't think it's worth discussing dates 10:23:43 dbaron: If we need to put dates, someone should just make them up 10:23:51 ack glazou 10:23:51 Zakim, q? 10:23:53 I see zcorpan_ on the speaker queue 10:23:56 dbaron: I hope that it doesn't, and can just be left out 10:24:01 plinss suggests 12-sided dice 10:24:24 glazou: Wrt changing process, I'm happy to just ask for a charter extension. if experiment in 6 months is feasible, willing to try that 10:24:32 glazou: Every time we recharter, has been long and painful effort. 10:24:42 glazou: If there's a better way to do it, I'm willing to try 10:24:43 ack zcorpan_ 10:25:08 zcorpan: Different people have different goals. Some people wnat to advance to REC, and some people wnat to find as many bugs in browser sand get them fixed. 10:25:19 zcorpan_: The testcases in those two goals, have different incentives for writing tests 10:25:28 q+ chrisl 10:25:47 zcorpan_: REC people look at t a test and incentive is that it not finds bugs because it blocks the spec 10:26:02 ack chrisl 10:26:21 q+ glazou 10:26:25 ChrisL; Anothe difference is that platform tests tend to test interactions among tests, whereas REC tests focus on single spec. Deifnite need for interactions 10:26:35 ChrisL: We also need interaction tests within this group 10:26:40 ChrisL: We're not testing that, bu tit's important 10:26:51 ChrisL: thta could show us problems in the specs, that you could only see in combination of things 10:27:02 q+ 10:27:14 glazou: So I think we're agreed that first of our priorirites in rechartering is defining list of priorities 10:27:31 glazou: Figure out what we want to work on. MIlestone section is lower priority, work on list of documents first. 10:27:34 qack glazou florian 10:27:38 ack glazou florian 10:27:44 grr 10:27:45 ack glazou 10:27:47 ack glazou 10:27:50 q+ tabtek 10:27:56 ack florian 10:28:00 florian: Topic of tests, I think behavior zcorpan talks about is something we did 10:28:28 plinss: I always describe our testing as 2-phas. Spec testing and conformance testing 10:28:38 plinss: no reaosn why we shouldn't build both test suites in parallel 10:28:51 Florian: If you go for one goal, not going fo other 10:28:56 plinss: Want to buld both test suites in parallel 10:29:05 plinss: Say these are aour spec tests, and these are our conformance tests 10:29:21 ack tabtek 10:29:31 tantek: I agree with prioritizing the prioritizing, in general 10:29:49 tantek: But I think if something is not important to us, we should dorp it regardless of what's required by process and charter 10:29:58 tantek: Drop sections of charte rthat we don't care about 10:30:02 tantek: and move forward with that 10:30:26 tantek: make that proposal, and I'll argue for that before AB 10:30:37 glazou: History of WG has shown that we're realy bad at estimating time for a spec, but we eventually finish it 10:30:52 glazou: So there are usually specs on the wg radar, stay on radar ountil they're done. 10:31:08 SteveZ: Requirement is expected milestones, emaning we don't expect any, then we don't need to record any 10:31:39 ChrisL: One reaosn for this scrutiny because some groups, including in the past this one, have spent 10 years not producing any RECs 10:31:49 ChrisL: Since then have been producing things regularly 10:31:56 The group wasn't "sleeping". 10:32:02 q+ to say if it's only "expected milestones" then allow individual editors of documents to offer "expected milestones" for their drafts, and nothing "as a group" 10:32:03 ChrisL: So we can point to that track record. 10:32:07 dbaron: The group wasn't sleeping 10:32:13 ChrisL: from outside, couldn't tell that it was doing anything 10:32:25 glazou: WEb designers community was really mad at us, because we *seemed* to be doing nothing. 10:32:33 ChrisL: Doing a lot of detailed work on CSS2.1 10:32:41 ChrisL: But from management POV, seemd like we weren't producing anything 10:32:57 and this kids, is why not to create monolithing unmmaintainable specs :p 10:33:33
10:45:06 astearns has joined #css 10:45:41 ian has joined #css 10:55:42 astearns has joined #css 10:57:31 darktears has joined #css 11:02:38 tobie has joined #css 11:16:46 jet has joined #css 11:24:46 q? 11:31:56 koji has joined #css 11:32:21 q? 11:32:28 glazou: Discussion diverged a bit from original goal, but meta-discussion probably is over. 11:32:34 glazou: We need to reach a list of priorities 11:32:51 glazou: Still have option of doing what we did few years ago, asking vendors to send list of priorities 11:33:17 fantasai: Did a poll recently, no? 11:33:20 glazou: Kindof old 11:33:28 glazou: Or could review list of documents now 11:33:41 jet has joined #css 11:34:01 fantasai: Don't think it would be too bad to put together a list right now, based on the old data 11:34:17 fantasai: Doesn't seem like there's anything controversial in the group right now 11:34:46 glazou: So maybe we take an action to draw up a list and ask for group's feedback 11:34:54 glazou: So what do we do with milestones section? 11:34:54 q? 11:34:58 shans__ has joined #css 11:34:59 ack tantek 11:34:59 tantek, you wanted to say if it's only "expected milestones" then allow individual editors of documents to offer "expected milestones" for their drafts, and nothing "as a group" 11:35:10 fantasai: Suggest we follow Tantek's suggestion and leave them out. Replace with pointer to current-work page. 11:35:31 tantek: Since this group has gotten better at keeping list of priorities for specs, maybe not worth group's time to discuss in person 11:35:54 tantek: Would trust the chairs to take existing list, make any small adjustments as they see needed, and send that to group for review 11:36:11 tantek: Think it doesn' need to be discussed f2f, fairly uncontroversial and doubt we'll see much controversy 11:36:21 tantek: So let's move forward with that optimistically 11:36:31 glazou: Other opinions? Or +1? or -1? 11:36:36 +1 11:36:43 glazou: Ok, we'll do that. 11:36:48 +1 11:36:52 glazou: Related is EPUB interest group 11:36:59 Bert: Think less important than list of priorities 11:37:12 Bert: But need to write something in liaison section. 11:37:30 Bert: Do we want to have any closer cooperation with this group? 11:37:39 glazou: Anyone from interest group that is member of this group? 11:37:44 Bert: Hachete 11:37:48 Bert: Peter 11:37:50 Bert: Bloomberg 11:37:59 Bert: Don't think anyone in room, aside from Peter 11:38:20 fantasai: I think we can figure out logistics of it later, not necessary to put in charter 11:38:35 fantasai: Just put that we will have liaison 11:38:43 ChrisL has joined #css 11:39:02 ACTION Peter, glazou: List priorities in charter, submit to WG for review and approval, then submit to staff contact for proposed charter 11:39:02 Error finding 'Peter,'. You can review and register nicknames at . 11:39:14 ACTION glazou: Email AB wrt rechartering woes 11:39:15 Created ACTION-584 - Email ab wrt rechartering woes [on Daniel Glazman - due 2013-09-20]. 11:39:23 and CC www-archive 11:39:46 glazou: Ok, we still need jdaggett for Text 11:39:49 Topic: CSS Ruby 11:40:11 ScribeNick: dbaron 11:40:23 http://dev.w3.org/csswg/css-ruby/ 11:40:37 fantasai: koji and I went through entire document. problem with previous ruby draft was had properties but didn't describe layout model. 11:40:46 previous: http://www.w3.org/TR/css3-ruby/ 11:40:56 fantasai: previous draft has nice pictures 11:41:01 fantasai: previous lacked box generation rules, etc. 11:41:26 fantasai: we created 2 sections: the ruby formatting model which describes ruby-specific display props, anon boxes, ???, pairing with bases, whitespace, layout, styling, linebreaking, etc. 11:41:48 fantasai: and a handful of cnotrols: ruby-position and ruby-align from old draft, ruby-merge is new for Jukugo 11:41:52 ...ruby 11:42:06 fantasai: and removed some controls that seemed more obscure and defined default or left up to UA 11:42:11 fantasai: and added default style sheet for HTML 11:42:26 fantasai: There's an old XHTML module for complex ruby layout, css-ruby was based on that 11:42:37 fantasai: HTML5 introduced a new ruby model with less markup, only handled basic use cases 11:43:01 fantasai: ruby extension spec being worked on by Robin Berjon, in coord. with fantasai and i18n wg, to address use cases to handle various requirements 11:43:14 fantasai: this draft is written to be able to handle all the ruby markups so far proposed for HTML5 11:43:23 fantasai: and can handle most of the stuff in complex ruby as well 11:43:33 fantasai: there's a bunch of changes we made from previous ruby stuff 11:44:01 fantasai: [summarizes] http://dev.w3.org/csswg/css-ruby/#changes 11:44:48 ... (within summary) changed values of ruby-position to match values of text-emphasis-position 11:45:33 zcorpan has joined #css 11:45:47 changes section should say that those keywords being changed are values of ruby-align 11:46:18 fantasai: ruby-merge is for jukugo ruby 11:46:29 fantasai: separate: annotation centered across each base 11:46:47 fantasai: collapse: center all the annotations / bases together, but still in the markup for line breaking 11:46:55 fantasai: auto allows UA to do what it wants 11:47:26 fantasai: reason for auto value is that jukugo ruby in jlreq and JIS X 4051 is more complicated than either of these options, want to allow UAs to do that, or something else intelligent 11:47:30 fantasai: initial value is separate 11:47:36 SteveZ: why call it auto? 11:47:41 fantasai: do you have a better name? 11:47:52 ChrisL: that's the usual keyword for "magic thing" 11:47:56 SteveZ: usually it's the default 11:48:33 SteveZ: concerned at 2 levels: (1) inconsistent implementation of 'auto' value, which will make it useless and (2) I think using auto in that sense is not the normal kind of magic 11:48:53 SteveZ: the normal kind of magic is "do what most people would want without having to say anything" 11:49:06 fantasai: we want some way for the author to get the behavior that's hard to dsecribe 11:49:20 fantasai: I don't mind making that the initial value and having separate be an acceptable behavior for 'auto' 11:49:29 SteveZ: I think separate is what most people want most of the tiem 11:49:51 SteveZ: I'm looking for a little more in the way of constraints on the implementation, but I think I understand the difficulty of a full description of jukugo 11:50:03 SteveZ: but seems to me there are some constraints you can talk about that an implementation should meet 11:50:36 fantasai: we gave 2 examples for what auto might mean: one is the algo in jlreq, another is render as mono-ruby if all ruby fit within advances and switch to group ruby otherwise, which is a similar effect to jlreq but much simpler 11:50:56 SteveZ: if you give a constraint about what you do in the overflow case, saying the intent is to do grouping in case they don't fit, that seems a much more useful specification than "do anything" 11:51:08 fantasai: We can expand the description to explain what's desired 11:51:16 SteveZ: then it won't go into effect unless there's an overflow case 11:51:26 SteveZ: that suggests a name of 'overflow' 11:51:29 Rossen_ has joined #css 11:51:40 fantasai: 'overflow' not a good name; goal is not to overflow. Can mark name as issue. 11:51:46 fantasai: [back to summarizing changes section] 11:52:19 fantasai: didn't inline value of ruby-position put paretheses? 11:52:22 s/fantasai/SteveZ/ 11:52:29 plh has joined #css 11:52:34 fantasai: don't know, wsan't defined 11:52:55 fantasai: [looks at old draft] didn't do anything interesting 11:53:11 SteveZ: display:inline of the before and after to get the parentheses will do it 11:53:33 fantasai: shows UA default style sheet ("Supporting Ruby Layout" section) 11:54:14 fantasai: previous spec said not allowed to break w/i ruby base or annotation, which is fine for some typical cases in Japanese where it's just 1-3 characters, but sometimes used for much larger sections 11:54:29 fantasai: so in line breaking section of spec we talk about breaking between bases, which is going to be the default case 11:54:41 fantasai: we also talk about how to do breaking within the bases and how you do that 11:54:45 florian: can you do that reasonably? 11:55:10 fantasai: have to split annotation and base at same spot -- it's going to be an arbitrary location, valid line breaking opportunities in both base and annotations 11:55:27 ChrisL: could mean you have a word on one line and the explanation on another 11:55:50 fantasai: if you have a semantic correspondence that should be encoded in the markup -- this is for the cases where the unit of semantic correspondence is long enough to need breaking 11:55:57 ChrisL: [inaudible] 11:56:16 florian: if this works, tempting to use for cases where not appropriate, will discourage authors from using proper semantic pairing 11:56:32 fantasai: un/likely since (1) default style sheet forbids this type of breaking and (2) people using ruby should know better 11:56:41 florian, SteveZ: [skepticism about (2) but not (1)] 11:56:59 fantasai: shows 'ruby-position' property 11:57:08 s/[inaudible]/ok, its fine if two long stretches correspond that you break in the middle. Iws more concerened about when there are multiople short corresponding sections, that they be kept together when breaking/ 11:57:09 fantasai: takes values as text-emphasis-position and the inter-character value for bopomofo 11:57:23 fantasai: ruby merge property, which we discussed 11:57:34 fantasai: ruby-align: takes these values from alignment spec 11:57:45 fantasai: [shows pictures in spec] 11:58:26 fantasai: wide cell -- expansion opportunities between CJK characters but not latin, so [?] will effectively center but [?] will space out. Get behavior described in jlreq but don't have to inspect text content. 11:58:34 fantasai: those are the three properties, that's all we think is necessary 11:58:42 SteveZ: does the ruby contribute to line height? 11:58:51 fantasai: yes, I'll explain how in a bit 11:59:04 fantasai: section on anonymous ruby box generation to fill in missing boxes for when not in the markup 11:59:14 fantasai: this describes how which annotation matches to which base 11:59:23 fantasai: interesting one is nested ruby (allowed in HTML5). 12:00:00 fantasai: since ruby interacts with stuff adjacent to it, you can't just put abox inside another box. Nested ruby basically defines spanning behavior, but tree structure with multiple levels of ruby. 12:00:23 SteveZ: One example where I see wanting nested ruby is example in old spec with University on bottom and daigaku on top 12:00:30 fantasai: it will handle that case and other more pathological cases 12:00:39 steveZ: how to get different positions on different rubys? 12:00:45 jet has joined #css 12:00:45 fantasai: ruby-position property 12:01:00 fantasai: if 2 on same side, closest to base in markup ends up closest to base in rendering, stacked 12:01:55 fantasai: this section weird, if contents of ruby annotation box identical to base, it gets automatically hidden. To handle Word's furigana. So for accessibility reasons and fallback behavior we hide it. 12:01:59 Bert: is identical defined? 12:02:21 fantasai: there's an issue on that whether it's prior to whitespace collapsing. It's a DOM content string match. 12:02:27 SteveZ: which form of unicode? 12:02:43 fantasai/koji: probably codepoint-by-codepoint should be sufficient 12:02:56 fantasai: I don't know about whether before/after whitespace collapsing, happy totake implementor opinions. 12:03:06 Bert: what if content is the same but markup is different, e.g., a span with a color on it? 12:03:19 fantasai: maybe we should do comparison on text content? Good point. 12:03:49 fantasai: section on trimming whitespace. goal is so you can write ruby with appropriate indentation but have that whitespace break the correct results. 12:04:00 fantasai: typically in Japanese don't want whitespace anywhere but want to indent your code. 12:04:16 fantasai: current impls strip whitespace unilaterilly, this breaks use of ruby markup for non-CJK languages 12:04:35 fantasai: have to look at content, similar to way css3-text transforms linebreaks to whitespace or nothing 12:04:44 fantasai: this is a little more sophisticated than existing implementations 12:05:06 liam: would help if middle of that example doesn't say "However, this markup will:" 12:05:10 fantasai: yes, that needs fixing 12:05:27 liam: you mean the second will display *with* spaces 12:05:46 fantasai: nothing magic other than what's in css3-text. Just saying you trim before/after various ruby containers, and just use same rules as in css3-text. 12:05:58 liam: I understand, spec just needs wording fix. 12:06:19 [SteveZ is trademarking "normal magic" :-) ] 12:06:50 fantasai: Ruby layout section describes layout. How to deal with base vs. annotation being wider. Align. [missed a bunch here] 12:07:12 Bert: Q about that: you determine the width by measuring. No upper limit on how wide ruby can get? Unlike floats which are limited to containing block. 12:07:26 fantasai: you can wrap it, though if you have a really long word or nowrap it will get wider 12:07:32 fantasai: which is just like long words in float 12:07:42 SteveZ: recent posting of long ruby examples. Was one that just fit in the height. 12:07:52 SteveZ: so your qusetion is a reasonable one 12:08:42 fantasai: This one is interesting. In this level, I put in a section that box properties don't apply to base container or annotation container boxes. I put this in because I'm concerned about some implementations and how they store their ruby internally. May not make sense for their implementation architecture to have a concept of a ruby annotation container. Let me explain [on whiteboard]. 12:08:51 fantasai: interesting boxes in ruby are the base boxes and the annotation boxes 12:09:14 fantasai: in the CSS model we also have boxes here [around base boxes] and here [arround annotation boxes] 12:09:38 fantasai: couldn't think of a use case for styling them, and I know some implementations build boxes the other way around [draws grouping around each base/annotation pair) 12:09:58 fantasai: so easier to make those boxes not stylable (and thus undetectable), as long as inheritance and pairing works as it should 12:10:25 fantasai: so I said no margins/borders/padding/backgrounds/outlines, both for lack of use cases and to avoid constraining architecture of existing implementations 12:10:29 SteveZ: what about color? 12:10:50 SteveZ: ah, color inherits, it works 12:10:59 fantasai: rt { color: green } 12:11:12 fantasai: can just set it directly on the annotation boxes 12:11:20 fantasai: only need to style that thing is to show bounds of those boxes 12:11:32 SteveZ: [mumble mumble] 12:11:50 fantasai: I'm a little concerned about this restriction, but don't want AH to have to rewrite entire impl, given they're doing column-based apporach. 12:11:55 SteveZ: how did they handle overflow? 12:12:13 SteveZ: no reason you can't relax that in the future? 12:12:15 fantasai :right 12:12:24 SteveZ: main use case seems to be debugging 12:12:31 fantasai: then line breaking section, we looked at that 12:12:46 fantasai: I left bidi as an issue, none of previous specs talk about it, but need to say what happens for bidi text inside ruby container. 12:13:00 fantasai: a bunch of proposals in comments in the source document, but for now leaving as an open issue 12:13:13 SteveZ: so if I have ruby annotations on bidi text, is that obvious what to do? 12:13:23 fantasai: I think reordering should be controlled by bases and annotations controlled by bases 12:13:28 SteveZ: unless jukugo 12:13:52 fantasai: problem is spanning annotations. Need to make sure spanning annotations don't get broken up, since bidi reordering can make something that was contiguous be noncontiguous. 12:14:36 fantasai: can we allow bidi reordering within ruby container, but only allow reordering within a region with a spanning annotation and not outside them. Could describe as embedding or something like that, but not entirely sure what model to use to describe that. 12:14:48 fantasai: constraint is each ruby base and each spanning annotation needs to remain contiguous 12:15:01 fantasai: this section describes how line-height interacts with ruby 12:15:34 fantasai: ensures that if all lines have equal spacing and equal amounts/positioning of ruby annotation, there's enough room to avoid overlap, but ruby annotations might extend outside line box 12:15:47 fantasai: if line height varies, could get overlap; responsibility of author to avoid 12:16:15 fantasai: in the simple cases the line is at least as tall as ruby plus text, but still centered in line box as normal. Ruby doesn't affect position of base text w.r.t. bounds of line box. 12:16:29 SteveZ: the ruby itself is not affecting the line height? author has to set line-height to handle ruby? 12:16:51 Rossen: it will affect it if line-height is 1em and base+text is 1.5em; in that case line-height will extend to be 1.5em 12:17:08 Rossen: but layout of base still centered in middle and ruby text will be pushed out, half inside line and half bleeding into previous 12:18:26 fantasai: [reads relevant text] "Therefore, ordinarily, ruby annotation containers ... , none of the ruby containers would overlap." 12:18:52 fantasai: [draws] say my line height was 1, then add leading. 12:19:17 fantasai: so if we can detect the author's line spacing should be sufficient to accomodate ruby, then we don't do anything. If line-height value isn't sufficient to accomodate ruby, we add leading to accomodate ruby. 12:19:32 Rossen: [clarification question, answered] 12:20:49 dbaron: the annotations don't affect line height/positioning at all, except for this correction you do to increase the line height when it's not sufficient 12:21:15 Bert: so this rule of adding leading is based only on the 'line-height' computed value of the base and dosen't take into account the line box which might already be increased? 12:21:25 fantasai: yes 12:21:28 Rossen: I think it should be the line box. 12:21:56 fantasai: You're adding the leading to the ruby container, not to the line 12:22:56 fantasai: so if you have a 2em tall image, the extra leading won't increase the line height 12:23:02 dbaron: but what about on the other side? 12:23:18 fantasai: it only adds leading on the side the ruby is on 12:23:46 dbaron: seems wrong 12:23:59 fantasai: goal is that if author is providing enough line spacing, we don't do anything special for the ruby 12:24:17 Rossen_ has joined #css 12:24:21 fantasai: but if the author is not providing enough space, e.g., on a mobile device where they want the spacing to be tight unless there's ruby 12:24:35 fantasai: in that case we do want the line-height to adjust to make space for the ruby, just on that line 12:24:37 teoli has joined #css 12:24:59 ChrisL: so if you want consistent line spacing, set enough space to allow for ruby; if you don't and want things tight, you'll get uneven line spacing 12:25:17 SteveZ: in the first case, you don't contribute to line box calculation; in the second case, you do by putting extra leading on top. 12:25:50 fantasai: right, and the way you tell the difference between the cases is we measure the specified line-height on the ruby-container, and if it's not enough, we add more. If it is enough, assume previous line has provided half of our space. 12:26:39 SteveZ: if I'm aligning a line with ruby on it to a line grid, then I'd better ensure the line-height is of the first kind and doesn't trigger extra leading. Because if I trigger extra leading it'll force the alignment down an extra line. 12:26:49 Rossen: I think the general rule is if you have ruby set your line height big enough. 12:27:02 SteveZ: previously there was a property saying whether ruby should be included in line-height calculation or not 12:27:08 fantasai: instead, we're doing something more automatic here 12:27:15 fantasai: plus a note saying line layout module might add more control 12:27:20 fantasai: but this is a good default behavior 12:27:37 SteveZ: I think your automaticness is good, unconvinced yet it's specified in the right way, need to think more. 12:28:04 fantasai: It's possible to get overlap here. e.g., failure to detect previous line doesn't have your line spacing 12:29:03 Rossen: can avoid by baseline-aligning in this case, which you're not going to have if ... . You're essentially increasing line box height to be that of ruby container but still positioning line in middle, [I didn't follow that at all] 12:29:22 fantasai: that's not how it's done in CSS 12:29:30 fantasai: [explains] 12:30:43 Rossen: [explaining again] This was about the case where line-height is 1em. In which case you obviously don't have enough space for ruby container, which needs 1.5em. 12:30:58 Rossen: In this case, 2mins ago you said you might have overlap with previous line. 12:32:07 fantasai: [draws] 12:32:16 dbaron: if you had half the room you needed, you'd just add half? 12:32:20 fantasai: yes, and all to the top 12:32:26 Rossen: [draws] 12:33:12 tobie has joined #css 12:34:01 fantasai: alignment with other content on the line is done solely with the base text 12:35:20 dbaron: which value of vertical-align are you talking about? 12:35:36 SteveZ: center alignment is not within the line box,its wrt the baseline 12:35:51 dbaron: There ar eonly two values of vertical-align that are relative to tdhe line box, top and bottom. 12:36:01 dbaron: I suppose we have some vertical-text version of those? 12:36:05 fantasai: No, still "top" and "bottom". 12:36:12 dbaron: All the other values are relative to the parent element. 12:36:31 dbaron: So the centering you do in vertical text isn't in the linebox, it's centering with respect to some other baseline established by another element. 12:36:39 dbaron: And the linebox can be asymmetric around that line. 12:36:55 szilles: The deafult alignment of a replaced alignment is to align its bottom to the dominant baseline. 12:37:10 szilles: Which means in this case the replaced elem would stick out from the side. 12:37:20 Rossen_: And the ruby base by default has alignment on the center. 12:37:24 fantasai: The center of the ruby base. 12:37:38 fantasai: If you increase one side fo the line box, it doesn't shift with the linebox. It's not centered wrt to the line box. 12:37:48 fantasai: That's what dbaron is trying to say. 12:37:57 fantasai: Centering the chars is not centering within a container. 12:38:11 fantasai: You're taking a bunch of things that have a baseline, which happens to cut through their center, and aligning the baselines. 12:38:19 koji: Against what baseline should they be aligned? 12:38:29 koji: Against the center of the parent container, this model will serve. 12:38:37 fantasai: It won't, because it's not with respect to the size of the glyphs. 12:38:46 Rossen_: Really? For vertical text? 12:38:48 fantasai: Yes. 12:38:53 teoli has joined #css 12:38:57 fantasai: There's nothing in CSS that does centering between two lineboxes. 12:39:08 s/two lineboxes/the two sides of the linebox/ 12:39:30 szilles: There's a wonderful note by eric meyer that points out how complex the calculation of lineboxes and their relationship with baselines can get. 12:39:44 Rossen_: And when you implement it a couple times, you should know exactly how screwed up it is. 12:39:50 szilles: And the same is true for center. 12:40:12 fantasai: Remember, we're not adding leading to the line. You're adding stuff to the ruby container. 12:40:22 fantasai: The center baseline doesn't shift - it's still in the middle of the ruby base. 12:40:30 fantasai: The linebox extends as a result of the ruby getting taller. 12:41:27 SteveZ: agree with intent, not convinced that it works 12:41:31 fantasai: I'm pretty convinced it works 12:41:44 Bert: I'm more concerned about case where you don't increase the line-height. 12:41:53 fantasai: yes, then you can get overlap 12:42:05 SteveZ has joined #css 12:42:29 fantasai: but we did that because otherwise you have to inspect content before you, which gets complicated. I think this is a reasonable compromise. 12:42:40 fantasai: Some complicated cases about changing font-size or leading or using images might not get handled. 12:42:41 fantasai: It might not handle some cases automatically and you have to be careful 12:42:52 szilles: I agree with the intent. I'm less convinced that it works. 12:42:52 fantasai: I'm pretty convinced that it does. 12:42:52 fantasai: If you do things according to the CSS box model, it should work. If you're doing something slightly different as a shortcut, it might not work. 12:43:21 Bert: What about when you have a heading and a paragragh. No margin below the heading. First line of paragraph has some ruby on top. 12:43:26 Bert: There's a risk that the ruby overlaps the heading. 12:43:55 fantasai: The mitigating factor there is that you're generally designing a page with X amount of gap between lines in a paragraph, you'll generally have at least X between paragraph and heading already. 12:44:03 fantasai: If you dont' have that, it's probably ugly anyway. 12:44:10 Bert: About line-breaking. 12:44:28 Bert: It says you get a break if the ruby is ???, ??? 12:44:36 Bert: Figure 4, there's a break opporutnity inside the annotation. 12:44:46 Bert: Part of the ruby annoatation is on one line, some on the next. 12:44:53 Bert: But it also says that the annotation can be longer than the base. 12:44:55 jdaggett has joined #css 12:45:09 Bert: So maybe an annotation on one line with empty space, then on the next line is all the base with the rest of the annotation. 12:45:14 fantasai: No, you can't have that. 12:45:34 koji: Situation is one base character, and a large unbreakable annotation. 12:45:49 fantasai: Okay, yes, in that case you can get annotation on a line by itself, if you explicitly opt into annotation breaking. 12:45:57 jet has joined #css 12:46:06 fantasai: I dunno what to do there. 12:46:15 TabAtkins: Shift the whole element to the next line? 12:46:39 fantasai: In TExt 4, we'll probably have a value that say "suppress wrapping, unless there's no other opportunity on this line". 12:47:02 fantasai: And we'll probably shift ruby's default behavior to that. 12:47:30 fantasai: I'd like to publish a WD for what's on the site right now, to replace the ancient incompatible /TR version. 12:47:31 +1 12:47:47 Bert: There was a more complex case where the ruby spans into an earlier or later characters... 12:47:52 Bert: Overhang. 12:48:01 Bert: It's fine to be without, but do you ahve an idea how it would be handled? 12:48:11 fantasai: The default behavior is to allow a little bit of overhang. 12:48:24 fantasai: Currently it's UA defined; in the future we'll probably add a control. 12:48:53 fantasai: There's some detail about what character is next, which affeccts whether you can overhang, and we didn't wnat to tackle this. 12:49:04 fantasai: Current spec says that overhanging by a quarter-em is generally safe. 12:49:45 koji: Most ruby is 1/3 size, so if you overhang by at most 1/3 em you're generally safe. 12:49:55 koji: But in general overhang is complex, so we dont' want to do it in level 1. 12:50:08 fantasai: I'm going to take an action item to clarify the intention of the 'auto' keyword for ruby-merge. 12:50:46 fantasai: The reason we went with auto is that the simple implementation is to automatically choose between separate or collapse. 12:50:51 fantasai: And easiest way to do that is auto. 12:50:58 ChrisL: Can you do the clarification before publishing? 12:51:04 fantasai: I can do it in like 15 minutes or so. 12:51:16 ChrisL: Oh, so it's not really the kind of thing that needs review before getting publishing? 12:51:19 fantasai: No. 12:51:21 ChrisL: Ok. 12:51:36 kawabata has joined #css 12:52:03 RESOLVED: Publish fantasai's Ruby draft as WD. 12:52:31 jet has joined #css 12:52:56 florian1 has joined #css 12:53:21 ChrisL has joined #css 12:54:03 [agenda discussion] 12:54:23 shans__ has joined #css 12:55:21 ChrisL has joined #css 12:56:21 ChrisL has joined #css 12:57:21 ChrisL has joined #css 12:58:21 ChrisL has joined #css 13:01:21 ChrisL has joined #css 13:06:17 Topic: Text 13:06:22 fantasai: letter-spacing. 13:06:49 fantasai: CSS2.1 says that if you have non-normal letter-spacing, you can't justify between grapheme clusters, only in space characters. 13:06:58 fantasai: This is problematic in cjk, because they don't use spaces. 13:07:06 fantasai: We have several problesm with the current spec. 13:07:09 http://dev.w3.org/csswg/css-text/#letter-spacing and http://lists.w3.org/Archives/Public/www-style/2013May/0280.html 13:07:09 fantasai: One is nobody implements it. 13:07:32 fantasai: If you set letter-spacing to 0 or something else, in latin text, yes, you don't get any space. In cjk, no. 13:07:42 tantek has joined #css 13:07:43 fantasai: So the text currently thinks "0" and "normal" are the same thing. 13:07:57 fantasai: In word-spacing, "normal" *is* equal to 0. 13:08:17 fantasai: Those are the problems. 13:08:50 Bert: Piont 3 (word-spacing) is an unfortuntae mistake, but unfixable. 13:09:00 Bert: I don't think that word-spacing and letter-spacing necessarily need to inform each other. 13:09:10 Bert: line-height also has "normal", and we don't compare them. 13:09:17 fantasai^: Reason not to change: existing spec. 13:09:42 Bert: When you say "nobody implements it", you mean "..."? 13:09:46 http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%20style%3D%22width%3A%20200px%3B%20letter-spacing%3A%200%3B%20text-align%3A%20justify%22%3ELorem%20ipsum%20dolor%20sit%20amet%20blah%20blah%20blah%20blah%20blah%20blah%20ah%20blah%20aoeu%20thicuoindeu%20onuech%20ueonh%3C%2Fp%3E 13:09:50 fantasai: Implementations don't restrict cjk justification. 13:10:04 never mind my url 13:10:44 Bert: ONe change could be to change th emeaning of the existing values. 13:10:49 Bert: We could alternately add a value. 13:11:00 ChrisL has joined #css 13:11:14 fantasai: That makes it unreasonably complicated for authors in a cjk environ. They have to set justification, and also set letter-spacing to something appropriate. 13:11:28 Bert: Not necessarily letter-spacing, just text-justify. They do that already. 13:11:45 fantasai: No, "auto" (default value) just works. There's a less common justification mode for cjk which they can opt into, but it normally just works. 13:12:14 szilles: Restrict letter-spacing for a subset of scripts, and have a cjk-spacing or ideograph-spacing for their separate controls? 13:12:52 fantasai: Doesn't work. I believe there's alreayd content with letter-spacing at a positive value that expect spacing on cjk. 13:12:58 Bert: Why do people set it to 0? 13:13:15 fantasai: Because they think it's the right value, the default value. It's unobservably different if you're not justifying. 13:13:28 Bert: I think I liked steve's proposal. 13:13:41 fantasai: letter-spacing right now applies to cjk, and it must continue to do so. 13:14:16 Bert: It's not that it doesn't apply. It's just that letter-spacing:0 lets you justify between cjk. 13:15:06 fantasai: Okay, so proposal is that letter-spacing never restricts justification for cjk, but non-"normal" values restrict justification for latin and similar scripts. 13:15:16 Bert: How to define "similar scripts"? 13:15:17 fantasai: Dunno. 13:15:39 liam: If you have a passage of english text with a short passage of chinese, and have justification turned on, those characters coudl be spread apart? 13:15:41 fantasai: Yes. 13:15:49 fantasai: Spaces get priority over inter-cjk, though. 13:16:16 szilles: One way to distinguish language categories would be if they use a word space. 13:16:31 fantasai: So thai would be with chinese, but korean would be with latin? 13:16:44 szilles: Yes. If you have spaces, no need to do anything else. 13:18:03 koji: "word space" in unicode is one of the non-script-specific characters, so that doesn't tell us anything. 13:18:12 koji: We'd need to have a script-based property for this. 13:18:38 szilles: My concern is that there may be languages that use a script with word space, and another language that uses the same script without spaces. 13:18:55 fantasai: This seems overcomplicated. Already, "normal" and "0" just seem confusing for authors. 13:19:09 Bert: The fact that there are two values implies that they're different. 13:19:27 fantasai: A lot of people probably dont' even realize there's a "normal" value, and the fact that it looks the same as "0" normally doesn't help. 13:19:38 fantasai: I think having sccript-specific behavior tied to "nromal" vs "0" is also confusing. 13:19:51 Bert: The best solution is to have some other feature to turn on flexible letter-spacing. 13:20:02 fantasai: Things should work by default, and you're proposing that justifcation doesn't work by default for cjk. 13:20:18 Bert: The spec already doesn't work for cjk. 13:20:29 Bert: So don't break latin, just add something for cjk. 13:20:41 fantasai: We're not getting anywhere, so I'm giving up for now. 13:20:51 szilles: Well, we at least came up with several possible solutions. 13:21:01 Topic: text-align 13:21:51 ian has joined #css 13:22:09 dbaron: Can we get a report of which impls actually have a normal vs 0 distinction right now? 13:22:14 fantasai: That's the issue - none of them do. 13:22:22 fantasai: If we make this change to the spec we're bringing it in line with impls. 13:23:21 dbaron: I couldn't find a CJK testcase where an implementation does inter-letter spacing for CJK justification 13:24:25 fantasai: You have to set [lang] correctly... 13:24:49 http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2521 13:25:05 http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%20style%3D%22width%3A%20207px%3B%20background%3A%20lime%3B%20letter-spacing%3A%200%3B%20text-align%3A%20justify%22%20lang%3D%22zh%22%3E%E5%8C%97%E4%BA%AC%E8%88%AA%E7%A9%BA%E8%88%AA%E5%A4%A9%E5%A4%A7%E5%AD%A6%E5%8C%97%E4%BA%AC%E8%88%AA%E7%A9%BA%E8%88%AA%E5%A4%A9%E5%A4%A7%E5%AD%A6%E5%8C%97%E4%BA%AC%E8%88%AA%E7%A9%BA%E8%88%AA%E5%A4%A9%E5%A4%A7%E5%AD%A6%E5%8C%97%E4%BA%AC%E8%88%AA%E7 13:25:05 %A9%BA%E8%88%AA%E5%A4%A9%E5%A4%A7%E5%AD%A6%E5%8C%97%E4%BA%AC%E8%88%AA%E7%A9%BA%E8%88%AA%E5%A4%A9%E5%A4%A7%E5%AD%A6%E5%8C%97%E4%BA%AC%E8%88%AA%E7%A9%BA%E8%88%AA%E5%A4%A9%E5%A4%A7%E5%AD%A6%E5%8C%97%E4%BA%AC%E8%88%AA%E7%A9%BA%E8%88%AA%E5%A4%A9%E5%A4%A7%E5%AD%A6 13:25:40 dbaron: I can't get Chrome to do any inter-character justification even with [lang] 13:25:49 fantasai: I think Chrome needs you to set text-justify to something else. 13:26:41 fantasai: Even if we change text-justify, the spec says that "0" means you can't justify between letters. So we still need to change something. 13:27:55 koji: I think what STeve is askign for is to have a way to disable letter justifycation. 13:28:10 szilles: To have a way of tracking which languages use inter-letter justification. 13:28:26 koji: We want today's behavior to not change, correct? 13:28:32 szilles: Close. I'm okay with... 13:28:43 s/askign/asking/ 13:28:45 fantasai: I think what makes the most sense is to make normal compute to 0, as it does with word-spacing. 13:28:52 s/justifycation/justification/ 13:28:57 fantasai: And if we want a way to turn off inter-letter spacing, but that in text-justify. 13:29:24 dbaron: I think using "letter-spacing:0" to prevent inter-letter justification is not intuitive. 13:29:37 Bert: I think it's perfect. We don't need an extra property. 13:29:44 +1 on dbaron's statement 13:30:04 szilles: We're trying to come up with a solution that matches today, is reasonable to explain, and gives me the ability to do tracking and allow justification using letter spacing. 13:30:53 dbaron: I think we have a set of justification controls that I believe can do this already. 13:31:08 dbaron: And we have something that is not intuitive in the spec, that doesn't match impls, and that we'd like to get rid of. I don't see what the problem is. 13:31:19 szilles: Evidence seems to say it does match impls...? 13:31:25 szilles: Except for 0. 13:31:29 dbaron: That's what we're talking about. 13:31:41 dbaron: 0 vs normal 13:32:17 Bert: The problem is that once I set a letter-spacing value, it shouldn't do inter-letter justification. 13:32:33 Bert: It's nice that if you set it to 0, it also means no spacing. 13:34:41 fantasai: So proposal is that if you set letter-spacing to a , any length, you can still justify. (Plus a control on text-justify that prevent sjustification.) 13:35:15 dbaron: But the spec currently says that setting a should disable justification. The impls that do perform inter-character justification don't follow the spec, and *do* allow jsutification. 13:35:36 szilles: So right now we have one property doing both tracking and justification control... 13:35:47 fantasai: What I'd like to see is that letter-spacing has no effect on justification. 13:35:57 fantasai: If you want to disable justification, use text-justify. 13:36:12 szilles: So letter-spacing becomes tracking only. 13:36:21 szilles: And "normal" and "0" are the same. 13:36:28 Bert: Then we have a redundant value. 13:36:47 szilles: That's okay. 13:37:43 Bert: I dont' want to change it in the cases where it currently works. 13:38:21 dbaron: We *have* found that some brwosers do cjk inter-character justification, and they violate the spec (doing it anyway, regardless of letter-spacing). They don't do inter-character for latin, so your case still works. 13:38:44 fantasai: So my proposal is that text-justify has "auto", "inter-word", and "distribute". 13:38:54 szilles: None of those do what japanese does. 13:39:08 szilles: jl-req has a big table that does different things based on the letters. 13:39:11 fantasai: That's "auto". 13:39:17 dbaron: Does it vary based on tracking? 13:39:32 szilles: I dont' think it talks about tracking. 13:39:51 fantasai: "auto" explicitly does that jl-req stuff. 13:40:19 steveZ: fine, then I'm happy 13:40:30 ChrisL: So is "auto" testable? 13:40:41 fantasai: Still no. jl-req is an informative ref. 13:40:59 szilles: This is something where we want impls to compete for better quality. 13:41:07 hmm, 'auto' as currently define *may* do JLREQ stuff 13:41:10 fantasai: And there's a simple auto algorithm that they can do instead. 13:41:20 there's no normative requirement for such behavior 13:41:39 ChrisL: So there's no way to explicitly say "use jl-req"? 13:42:03 fantasai: No. Japanese people have been kind and obsessive enough to write down a very good algorithm, but *nobody else* does that 13:42:56 szilles: Japan has house styles that vary the jl-req table. 13:43:09 szilles: InDesign lets you control those things. 13:43:19 and no way to say 'I implement jlreq but want the fast one instead' 13:43:37 SteveZ: I'm fine with this. 13:44:05 liam: I wanted to make sure this didn't exclude arabic kashida justification. 13:44:18 fantasai: We had a specific value, but killed it. "auto" allows that, and the spec has an example. 13:44:51 liam: Also, when doing copyfitting, you often have multiple things you want to list which controls what things are allowed to vary. Maybe have multiple values here? 13:45:01 fantasai: I want to address that in the future. This doesn't block it. 13:45:03 kawabata has joined #css 13:45:51 [straw poll, the yay carries] 13:46:08 ~15 in favor, Bert against 13:46:22 Bert: I dont' understand why you change an 18-year old spec. 13:46:25 teoli has joined #css 13:46:28 plinss: To match implementations, none of which amtch the spec. 13:47:37 RESOLVED: letter-spacing: doesn't restrict justification. text-justify:inter-word; disables inter-letter justification. 13:47:59 fantasai: word-spacing:normal computes to 0. For consistency, I say we do the same thing with letter-spacing. 13:48:48 Bert: I don't think there's a strong consistency argument. 13:48:54 ChrisL has joined #css 13:48:59 TabAtkins: I think word-spacing and letter-spacing are reasonable to tie in consistency arguments. 13:49:07 fantasai: Also, this means the computed vaue is just alength, which helps. 13:49:16 RESOLVED: letter-spacing:normal; computes to 0. 13:50:24 fantasai: A new compication with ??? was found by koji. 13:50:39 fantasai: text 13:51:08 fantasai: Koji and I were discussing this,a nd right now when we evaluate how much text to turn into a tcy run, we go across the entire contents of the element. 13:51:18 fantasai: Whether or not you turn it into tcy depends on whether there's an element boundary in it. 13:51:24 fantasai: If there's a boundary, we give up. 13:51:56 glenn: Remember that TCY is a japanese word, while t-c-h is a property name. Consistency? 13:52:16 fantasai: Koji and I were thinking of changing this, so that we just split up the text into runs between boundaries, then evaluate tcy on that.d 13:52:37 fantasai: So if I set tch:all here, I'll take the whole text run and turn it into tcy. 13:52:51 fantasai: abc 13:53:12 fantasai: Here, "a" becomes a tcy (turning upright), and "by" becomes a tcy. 13:53:16 Rendered like: 13:53:17 a 13:53:17 bc 13:53:27 szilles: This isn't extensible. 13:53:35 fantasai: Right, not extensible to including markup in the future. 13:54:02 fantasai: But it's simple (no lookahead), and makes the contents of the tcy only ever be plain text. 13:54:16 fantasai: An implication of changing this is that if I have "digits" as the value... 13:54:20 kawabata` has joined #css 13:54:29 fantasai: 12345 13:54:34 we can just s/TCY/縦中横/ 13:54:44 fantasai: The first one wouldn't tcy, the second would. You'd get: 13:54:45 1 13:54:45 2 13:54:47 3 13:54:48 45 13:55:01 (with 1/2/3 being rotated) 13:55:44 szilles: I don't see what this solves. 13:56:06 koji: I think extensibility to markup should be a new value for the tch property in the future. 13:56:31 szilles: There's more likelihood of accidental markup than pruposeful markup, and this one is affected by that accidenetal markup. 13:56:45 koji: Today it'll fail entirely with accidental markup. 13:56:53 szilles: Right, and that's probably a good thing. 13:57:16 szilles: You're assuming that the has a meaning in those examples, meaningfully breaking it into 3 units. 13:57:23 s/~15 in favor/~10 in favor/, probably 13:57:39 fantasai: Current spec gives up when you see the boundary. 13:57:46 szilles: Right. Probably a better default. 13:58:08 rossen: The other option was to, if it's all inline, to take it as a single tcy run. 13:58:19 rossen: So it'll still fail on blocks 13:58:23 rossen: Which I think is reasonable. 13:58:38 rossen: I think "all" is pretty explicit and means "I want this whole thing to be combined". 13:58:45 rossen: Presumably I know what I'm doing. 13:59:13 fantasai: What happens if I have 1234abc? 13:59:26 fantasai: 1234 is expected to form a tcy. 13:59:53 fantasai: But that's combining/breaking in an element. 14:00:03 TabAtkins: That's similar to bidi fragments, no? This is a problem we already solve. 14:00:16 TabAtkins: (not saying it's a sane problem) 14:01:21 koji: We have impls for 2 years, and we found these issues just a few months ago. We already have lots of content using it. 14:01:29 koji: So we need something compatible with existing content. 14:01:56 rossen: Option C would still work in existing content. TCY together everything that's inline. 14:02:23 koji: Can we come up with some spec text? 14:02:25 rossen: Yeah. 14:02:44 szilles: We already have a notion of "inline content" in the grammar, so the spec can just say that th eocntents must be inline content. 14:03:16 koji: ??? 14:03:54 szilles: You're basically converting a float of max-contnet width, but doing some other things - turning off some variants, etc., maybe do some kernings. 14:04:05 szilles: You'll have to specify all that anyway to be consistent with impls. 14:04:19 szilles: And if it doesn't fit in an em, scale until it does. 14:04:33 szilles: Clearly not ideal, but I'm not sure we have much of a choice. 14:04:43 dbaron: I think we do have the choice to do simpler things that don't work in every edge case. 14:05:01 szilles: What do you buy? You're using code you already have. 14:05:05 dbaron: That's not always simple. 14:05:18 fantasai: Rossen and I were discussin gproblems with fragmenting the inlines. 14:05:48 fantasai: For example, if you have lgocial properties that you want to cascade and resolve, you can't do that if part of the element is horizontal and some is vertical. 14:06:02 fantasai: rossen suggested that you start forming tcy, and if there's an unclosed element at the end, you give up. 14:06:44 fantasai: here you end up with a single fragment that has 2 different writing modes, that's worse than bidi 14:07:42 TabAtkins: [doesn't understand why this is different from what happens in bidi fragments, but whatever] 14:09:07 [discussion of details] 14:09:28 (Does abc12de makes "12" horizontal) 14:10:05 (given their current suggestion, no - that's two unclosed elements.) 14:10:22 (given the earlier suggestion of just using fragments, yes, it would) 14:10:57 [more board scribbling and mumbling, too small, fast, and confusing to minute] 14:14:50 fantasai: We did decide we had an issue about "digits" having to check outside its boundaries, to make sure that a run of digits within the element isn't contiguous with a larger run of digits starting outside. 14:16:14 israelh: In "abcdef", what would happen? 14:16:44 israelh: I mean abc. 14:16:54 rossen: It woudl work - the span would both open and close within the run. 14:17:59 fantasai: We were hoping to keep this relatively simple, which is why we had a non-inherited property. 14:18:05 fantasai: Now it's getting more and more complicated. 14:18:21 dbaron: It feels like this is already the complicated appendage to the spec, which is now getting more complex. 14:18:36 dbaron: We agreed to stick on this complicated appendage because it was considered essential for some use-cases... 14:18:45 dbaron: But do we really need to address every tcy case in this level? 14:18:56 szilles: Figuring out which subset to address is where we seem to go aground. 14:19:01 fantasai: We started with just plain text... 14:19:20 dbaron: And then you said it wasn't enough. 14:19:25 koji: I'm fine with plain text with inherited values. 14:19:35 jet has joined #css 14:19:51 koji: But what I just said gives bad results for the a/bc case. 14:20:17 israelh: Do you see things like i^12, or whatever? 14:20:33 koji: I see people doing H_2O or CO_2 using horizontal writing mode in an inline-block 14:20:37 koji: I do see that, or "CO_2", etc. but you can just use writing-modes and inline-blcok for that. 14:20:57 szilles: If I put properties on an inline, do you turn it off? 14:21:14 fantasai: You inherit the all, and it takes effect on the inner span, not the outer. 14:21:28 szilles: That's no extensible. 14:21:45 fantasai: Right. You can use inline-block to do *anything* in tcy, it just doesn't do automatic compression. 14:21:51 TabAtkins: Until we do copyfitting, which'll address that. 14:21:58 ChrisL has joined #css 14:22:14 fantasai: The other solution going forward that koji said, is a new display value "character", which does try to do compression, dots, etc. 14:22:28 fantasai: That would let us do everything you want to do with this property. 14:23:02 fantasai: This lets us do all the use-cases so far. You can even do CO_2 if you use the unicode subscripts. 14:23:16 fantasai: You can use inline-blocks for anything else, and in the future we can get even better. 14:23:24 ian has joined #css 14:23:27 szilles: I don't like the fact that it's not extendable. 14:23:53 koji: We intended to do that. But designing for as simple as possible right now, and don't exclude expansion in the future. 14:24:02 kawabata2 has joined #css 14:24:32 fantasai: ...so new design is inherited property. 14:24:49 fantasai: Consistency argument is that "digits" takes a run and looks for continguous characters of a given type. 14:24:53 "digits" or "all". 14:24:58 fantasai: But only on a text run. 14:25:07 fantasai: Consistent. 14:25:16 fantasai: "all" is just like digits, but with any character. 14:25:50 szilles: It really isn't like that at all. For digits, you dont' need explicit markup; this needs explicit markup. 14:26:14 rossen: Right, you normally want to avoid markup. "all" just fills in the holes for things like CO_2. 14:27:02 ian has joined #css 14:27:09 israelh: To the extent that we keep it consistent with what we ahve right now, it'll be easier to understand. If we go beyond that... 14:27:11 israelh: ??? 14:28:03 israelh: When we go beyond what we can compress in a single line, we've already established that it fails. So it's okay to fail, from an authoring perspective. 14:28:59 rossen: So I think we converged to 2 choices. 14:29:17 rossen: 1 is to keep inheriting. Break when you see element boundaries. 14:29:30 rossen: This'll make most cases that koji says work, and the "digit" value work. 14:29:45 [howcome just left; Tantek left a few minutes ago] 14:29:55 rossen: Simpler to implement, maybe a little more confusing to understand. Potentially not extendable. 14:30:12 rossen: 2 is to go for more elaborate combining whee we allow crossing element boundaries. 14:30:20 koji has joined #css 14:30:31 rossen: But then we need more smarts to think about if there are unclosed elements, etc. 14:30:47 rossen: Likely harder to implement. Potentially more understandable to users. 14:31:02 rossen: But I"m sure with enough mucking around we can always create some element combinations that fail us. 14:32:28 rossen: So it's simple rimplementation but maybe some rarer cases not working, or more complex implementation with some exotic cases working, but we dont' even know if it's the right "working". 14:33:25 fantasai: (1) text-only, inherits 14:33:32 dbaron: are there still multiple variants of (1) ? 14:33:38 fantasai: I have one in my head that I think is good. 14:34:00 fantasai: (2) only inline content (previously C) 14:34:03 shepazu has joined #css 14:34:06 fantasai: And (1) is A+D 14:34:43 6 for 1 14:35:00 (fantasai, Rossen, Koji, Florian, dbaron, Tab) 14:35:01 6 for option 1, that is 14:35:34 2 for option 2 (Israel, SteveZ) 14:35:45 Bert abstains, can't make up his mind 14:35:47 and many, many abstentions 14:36:04 fantasai: Koji and I will spec up A+D and we'll come back to the group. 14:36:09
14:42:38 darktears has joined #css 14:52:41 koji has joined #css 15:01:04 cabanier1 has joined #css 15:01:30 astearns has joined #css 15:03:19 RESOLVED: drop digits 1 15:03:33 Topic: Animations 15:03:52 plinss: What's the status with jd? 15:04:13 plinss: We'll return to text if jdaggett appears 15:04:21 Rossen_ has joined #css 15:04:46 Shane: At F2F in Tokyo, I offered to get back to group wrt implementation progress that we made on the new T&A cascade that we resolved on 15:05:04 dbaron: just got it into the spec this week, though some bugs in that 15:05:23 shane: We don't have any problem with it, don't seem to be any major issues. 15:05:26 Shane: Some questions, though 15:05:33 Shane: One part of implementation that was sub-optimal 15:06:21 Shane: The issue is we've said that when you specify a transition on a property that is inherited and the inherited value is changing due to transitioning, child transition should not start 15:06:27 dbaron: I thought we resolved the opposite 15:06:35 dbaron: My understanding was that we resolved... 15:06:39 dbaron: Resolution I have is 15:06:48 in minutes at http://lists.w3.org/Archives/Public/www-style/2013Jun/0682.html 15:07:01 ChrisL has joined #css 15:07:07 A, C, D, E from http://lists.w3.org/Archives/Public/www-style/2013Mar/0297.html with modified part B 15:07:08 dbaron: Resolved to accept A, C, D, and E from this with a modified part B 15:07:28 dbaron: That's the edits I tried to make this past weekend 15:08:07 dbaron: Part D, I guess, is where I said that, although it falls out of the way I specified part A, or something else 15:08:32 dbaron: Idea there was that if you have an inherited property that's inheriting through a tree and you have multiple places in that tree 15:08:36 dbaron: that specify transitions 15:08:40 dbaron: then you will get all of the transitions 15:08:48 dbaron: It may produce undesirable results, but it's what you asked for 15:09:06 Shane: We're happy with that approach, a lot easier to implement that than suppress child transitions 15:09:21 dbaron: One conclusion from that discussion was to give up on suppressing transitions there 15:09:41 krit: If you have inherit from ?, though tit was already specified from beginnning that we resolved values before staring animations or transitions 15:10:13 krit: We resovled all the inheritance values before we start the transition, so you don't have 'inherit' keyword 15:10:21 dbaron: 'inherit' isn't a computed value, so that's not a problem 15:10:36 Shane: List of 5 questions, don't have to go through those now 15:10:52 dbaron: Anything likely to benefit from discussion 15:10:57 Shane: ??? something events ??? 15:11:02 dbaron: When transition events fire? 15:11:43 dbaron: I don't know that we have a resolution on it, but I think it's important that the script that runs as a result of TransitionEnd event run before the Refresh that would have the "no transition running anymore" style data 15:11:47 dbaron: don't do a screen refresh 15:11:54 dbaron: Can't avoid scrip tgetting access to styles 15:11:55 s/??? something events ???/When do we fire events? Are events asynchronous?/ 15:12:09 dbaron: But really want to avoid screen refresh between update to style data and sending TransitionEnd event 15:12:23 Shane: Does a transition end on the screen refrsh that first ... 15:12:27 dbaron: Asking > or >=? 15:12:32 dbaron: I don't think we've actually defined that 15:13:01 Shane: Couple that question with timing statement you just made, then if you were to say that TransitionEnd on the first frame in which the final property value has been displayed, and the transition effect mus tahppenbefroe the next round 15:13:10 dbaron: Final property value is tricky with step transition functions 15:13:33 dbaron: Could we say perhaps that, talk about that hypotehtical transition you'd have if your timing funciton was step-end? 15:13:40 dbaron: Makes a change only at end of transition 15:13:40 ChrisL has joined #css 15:13:56 dbaron: Think that in Gecko we will fire the TransitionEnd event essentially while we're doing the style updates 15:14:06 dbaron: in order to do the refresh for that value 15:14:31 dbaron: If you have a step-end() timing function, and have TransitionEnd on it, and use TransitionEnd to set it to some other value, think you should never see the end value of that transition. I would hope 15:14:35 Shane: No, I think you should 15:14:57 Shane: Otherwise, taking the step-end, if you chain based on TransitionEnd, you'll never see any value until the last transition ends 15:15:04 dbaron: I was using "see" too loosely... 15:15:21 dbaron: We would fire the TransitionEnd event at a point where the script will see the end value, but we haven't yet repainted the screen for that value 15:15:38 dbaron: So if you make another style change right hten, it'll take effect before we do any repaints. Not 100% sure about that 15:15:45 krit: Might be desired in this cas 15:16:16 Shane: If you want to time two animations... to be perfectly smooth, then you... I guess it also ties into whether we consider transitions end-exclusive or not 15:16:21 dbaron: Spec is not very clear on this stuff 15:16:31 dbaron: Not entirely sure on this stuff. Not sure we should make it clear for this version or not. 15:16:37 dbaron: If we figure out something we can agree on 15:16:44 dbaron: Worht writingsome tests for this stuff and seeing what happens 15:17:21 Shane: We would be quit ehappy to not tie these questions down now and wait until WebAnimations spec has been reviewed, and then in the next level of CSS Transitions and Animations, adopt whatever conventions Web Animations has provided 15:17:30 dbaron: I'm certainly ok with waiting 15:17:37 dbaron: Don't necessarily want to commit to waiting for web Animations 15:17:39 hober: right 15:17:49 dbaron: Not all that concerned that this will be a critical issue for interop 15:17:57 Shane: ... 15:18:03 dbaron: It's probably worth seeing how itneroperable things are 15:18:14 dbaron: Definitely had mental model of what boundary conditions are 15:18:28 dbaron: dont' know if that agrees with your model, and spec doesn't have a model 15:18:56 Shane: Web Animations model is ... that a sample only belongs to one animation or another ... 15:19:05 dbaron: That is the model I used in implementing CSS Animations, I abelive. 15:19:12 dbaron: For repeating animations.. though not entirely I think 15:19:36 dbaron: Think what I did for repeating animations, I considered all the repetition cycles, if right at boundary, would use start state of next repetition than end state of lastanimations 15:19:51 dbaron: But for last cycle, would still use value from animation 15:19:57 dbaron: Don't remember if there was a good reason for that 15:20:06 dbaron: Essentially what I did for animations, it included both end points 15:20:13 dbaron: Picked second iteration over first 15:20:23 Shane: Given that model, when do the events fire? 15:20:29 dbaron: At the boundary point 15:20:39 Shane: After style has bene calculated, but before screen refresh? 15:20:51 dbaron: In Gecko only fire events as part of our refresh cycle 15:20:56 dbaron: It would fire after style cacl 15:21:09 dbaron: Would need to look more closely at code to see what changes would take effect in observer 15:21:26 Shane: Does that mean another style updat ecould be trigered? 15:21:40 krit: Looking at SVG animations, it is always end-exclusive. 15:22:05 dbaron: Ok, I will make note to myself to see what happens if we make ours end-excluseive completely, and see what that breaks 15:22:13 krit: A little concerned about that approach 15:22:17 s/krit/Shane/ 15:22:25 Shane: If an event fires such that ... 15:22:32 Shane: interrupted, then we can't really do chaining properly 15:22:41 dbaron: if an event fires when? 15:22:48 Shane: ... 15:22:51 Shane: step-end 15:22:59 Shane: no change, no change, no change, then jump 15:23:11 dino has joined #css 15:23:22 Shane: nevermind 15:24:01 florian has joined #css 15:25:07 Shane: We currently coalesnce iteration events if there are multiple between frames. 15:25:13 koji_ has joined #css 15:25:14 Shane: You okay with that behavior? 15:25:56 ScribeNick: krit 15:26:16 dbaron: as implementer I would not really care 15:26:27 dbaron: maybe we can discuss over email 15:26:29 shans: sure 15:26:37 shans: one other thing 15:26:50 shans: provide a negative animation delay and pause 15:26:51 michou has joined #css 15:27:10 shans: so that we can hit particular points and test these 15:27:25 shans: I think we can build a nice conformance suite 15:27:33 shans: think Gecko passes our test suite 15:27:44 shans: is there anything missing that we should test? 15:29:25 Topic: text 15:29:41 fantasai: text-align and text-align-last; last issue on text-combine-horizontal (if we have a better name) 15:30:03 ScribeNick: dbaron 15:30:49 fantasai: issue is interaction of text-align and text-align-last, and whether one should be a shorthand of the othe 15:30:56 Bert: and whether there should be a text-align-first 15:30:58 michou has joined #css 15:31:15 fantasai: or could just have 2 properties (text-align-all and text-align-last) and all can take 2 values to say what the first line should do, but I don't have a strong opinion on that 15:31:29 fantasai: I think we've discussed this a couple of times, don't have a super good answer. 15:32:16 fantasai: the main difference in behavior is if you set 'text-align: justify; text-align-last: justify' and then later in the cascade want a particular paragraph to be 'text-align: center', the last line will stilll end up being justified. 15:32:38 fantasai: Then could do what IE does, text-align-last only takes effect when have text-align:justify 15:33:11 fantasai: if you go from center back to justify, then the first text-align-last is still taking effect. Do you want that, or do you want these text-align declarations to clear out the first one? 15:33:16 fantasai: That's the main interaction issue. 15:33:37 fantasai: There's also -- jdaggett wanted to be able to specify text-align: justify-all and have that just work instead of having text-align-last 15:33:40 yamamoto_ has joined #CSS 15:33:43 fantasai: but for back compat we still need text-align-last 15:33:50 fantasai: so if we want to make this work we need it connected -- a shorthand 15:34:09 zakim, enough with the hand fetish already 15:34:09 I don't understand 'enough with the hand fetish already', ChrisL 15:34:25 krit1 has joined #css 15:34:26 fantasai: last consideration: somebody on the mailing list wanted to say last line alignment matches the rest, without caring what it is 15:34:55 fantasai: if you want justify-all to work it needs to be a shorthand; if you want ability to explicitly defer last to match others, it needs to not be a shorthand 15:35:18 Bert: if we have just one property, just text-align, and no text-align-last 15:35:23 zakim, who is here? 15:35:23 sorry, ChrisL, I don't know what conference this is 15:35:24 On IRC I see krit1, yamamoto_, michou, dino, ChrisL, Rossen_, astearns, cabanier1, darktears, ian, jet, teoli, shans__, tobie, plh, darobin, liam, leif, oyvind, glazou, dbaron, 15:35:24 ... Zakim, projector, GPHemsley, krijnh, gsnedders, dauwhe, RRSAgent, renoirb 15:35:27 koji has joined #css 15:35:28 zakim, bye 15:35:28 Zakim has left #css 15:35:35 ChrisL has joined #css 15:35:39 fantasai: we have back compat issue because people are using text-align-last. In IE6, and old CR. 15:35:45 Rossen: at least 15:36:00 kawabata has joined #css 15:36:01 fantasai: We know MS is going to continue to implement text-align-last, but seems like we're not going to have the shorthand option. 15:36:15 fantasai: ... if we want to be compatible with ??? 15:36:23 fantasai: Have 2 implementations, Microsoft and Mozilla. 15:36:35 Bert: Seems like what IE is doing is the best, just honoring last when text-align is justify 15:36:45 Rossen: what word also supports 15:36:52 ChrisL: Put it in the "Applies To" line 15:36:57 fantasai: thought word used something else 15:37:12 Alan, Rossen: Word gives you the option, only applies to the last line if justified 15:37:23 applies to the last line of elements where text-align has the value justify 15:37:48 fantasai: considerations are: cascading behavior - both solutions handle 'text-align: center' overriding -- but if elsewhere set text-align:justify does it resurrect the old text-align-last? 15:38:41 fantasai: Can't have justify-all value vs. can't have value for matching the rest 15:38:48 fantasai: and expectation of shorthand behavior from property names 15:38:55 fantasai: Comments? 15:39:07 Tab: no opinion 15:39:45 fantasai: if we add first line justification, then it would probably be a keyword on text-align 15:39:54 15:40:27 I'm for option B - text-align-last only applies if text-align is justify 15:40:35 fantasai: if text-align-last is not shorthanded we probably wouldn't do a text-align-first property because it would have horrible cascading (and if we had a shorthand they should both be in the shorthand) 15:40:58 fantasai: Bert and jdaggett prefer not having text-align-last and just using text-align for everything 15:41:02 fantasai: that would have been better 15:41:23 peterl: can we deprecate text-align-last? 15:41:31 Bert: maybe I'm inconsistent, but in this case... 15:41:45 Bert: but I don't think we should do that; it's been in a CR. One of those mistakes we make once in a while. 15:41:55 peterl: I'm not saying take out of spec; leave it in spec and mark as deprecated. 15:42:04 cabanier has joined #css 15:42:58 ?: have a use case for ??? ? 15:43:27 s/???/text-align-last with anything else than text-align: justify/ 15:44:10 fantasai: I don't have a strong opinion right now, although before I was pretty convinced we should do the shorthanding. 15:44:39 peterl: I'm not happy about the legacy issue, but that's life. 15:45:05 alan: Since we don't have a ??? use case for doing the right thing, but we don't have anything ???. Leave it as it is with MS's behavior until somebody gives us a reason to make a change? 15:45:17 peterl: Will need to change if we want text-align-first, would make sense to have shorthand. 15:45:21 Alan: planning to do that now? 15:45:25 peterl: no, but should at some point 15:45:57 cabanier has joined #css 15:46:10 [nobody seems to feel strongly] 15:46:21 ?: defer to jdaggett? 15:47:01 Rossen: when we discussed this a couple months back, the query we did over roughly 2 million documents came back with ... something between 3-5% used text-align-last. 15:47:01 kawabata` has joined #css 15:47:29 peterl: any tests for value of the property, or just presence? 15:47:46 Rossen: I don't remember how I wrote the query... maybe checking for value other than inherit. 15:47:54 peterl: so included some cases where value had no real effect 15:47:57 Rossen: I think so. 15:48:19 Rossen: wanted to see if <1% 15:48:37 peterl: but could also potentially drop if most were setting to initial value or something that has no effect 15:48:54 peterl: if no strong opinions, leave as is? 15:48:58 dbaron: how is it? 15:49:08 fantasai: spec says totally independent properties 15:49:16 peterl: what does Gecko do 15:49:26 fantasai: completely independent 15:49:33 fantasai: AntennaHouse also implements 15:50:23 astearns_ has joined #css 15:50:27 fantasai: Spec the IE behavior, and if somebody prefers shorthand they can raise an LC comment and explain why. 15:51:30 RESOLVED: spec the dependence of text-align-last on text-align:justify and mark issue for feedback on shorthanding vs. not 15:51:34 fantasai: I'm out of issues on css3-text. 15:52:04 Bert: can we add the poetry behavior keywords to text-align: first-left first-right 15:52:18 fantasai: A little concerned about doing that ... I'd do it as start-first. 15:52:23 Bert: Too difficult for users. 15:52:33 fantasai: Always correct. 15:52:47 fantasai: The only use case is start-first 15:53:01 fantasai: I think it's obvious 15:53:13 Bert: those are words only people in the WG understand. 15:53:21 Bert: maybe 'poetry', not 'start end' 15:53:41 Koji: If people don't understand 'start end' then we need to discuss 15:53:46 Florian: ... Beating them looks hard. 15:54:03 Bert: I'm not sure if it's only based on the direction. If that's indeed the case than a single keyword would be enough. 15:54:12 fantasai: Actually, 2 things I want to drop from the spec currently: 15:54:17 fantasai: (1) 'text-align: start end' 15:54:41 fantasai: (2) word-spacing can take up to 3 values defining minimum optimum maximum; don't have any implementations and would prefer to drop and figure out justification limits in level 4 15:54:55 Bert: do we want to have limits or do we want to allow other algorithms as well? 15:55:04 Bert: I'm ok with dropping it, not sure we should add it back in afterwards. 15:55:15 fantasai: I think we should drop it until we have a clear idea what we want for that. 15:55:27 Koji: seems like consensus to drop 15:56:02 RESOLVED: drop minimum/optimum/maximum values for word-spacing 15:56:11 Bert: not sure about dropping 'start end' value from text-align 15:56:18 ChrisL has joined #css 15:56:45 fantasai: Main reason I want to drop is not because I don't want to handle poetry case, but because I want to figure out clearest syntax. 15:56:53 fantasai: This is just putting two keywords, not super-obvious what that means. 15:57:00 fantasai: maybe it makes sense to have some other keyword to express that 15:57:07 Bert: I'd like it to be a single keyword, not two keywords. 15:57:12 Bert: 'poetry' would work for me 15:57:15 lmclister has joined #css 15:57:21 fantasai: I think that's too specific; I might use it for code 15:57:33 [discussion] 15:57:39 fantasai: Poetry in general not aligned like that. 15:57:47 peterl: Maybe research to see if there's a name for that? 15:58:08 fantasai: Want to drop largely because don't have good syntax for it that's obvious. 15:58:14 Bert: two-sided, continuation? 15:58:40 Alan: any implementations? 15:58:42 fantasai: no 15:58:47 Alan: I think we should drop it. 15:58:53 Peterl: trying to go to last call soon 15:59:00 fantasai: unless there are objections 15:59:03 ChrisL has joined #css 15:59:12 peterl: not alone a reason to drop because not implemented -- could mark at risk 15:59:24 (I think alan was talking about min and max on word-spacing, wasn't he?) 15:59:45 Alan: to play devil's advocate, ... 15:59:55 peterl: keep in, put issue about naming, mark at risk? 16:00:07 bert: I was talking about dropping the poetry thing 16:00:14 fantasai: "this needs to be renamed at last call or it gets dropped" 16:00:32 Bert: At some point I want the feature that inserts an > on every line but the first. 16:00:46 fantasai: I want to check with jdaggett, and check with him on text-align stuff. 16:01:11 fantasai: so I will make edits and do the write-up and if people here are happy w/ it we can go to LC unless jdaggett wants more changes 16:01:27 (left square bracket is actually more likely than angle bracket) 16:01:28 RESOLVED: keep 'text-align: start end' in, add an issue about naming, and mark it at risk 16:02:13 peterl: do we want to resolve for LC now, or wait for edits and jdaggett's feedback? 16:02:28 fantasai: Would prefer resolution, even if it takes another cycle, so we can publish if things are ok. 16:02:48 bata has joined #css 16:03:33 RESOLVED: take css3-text to last call pending resolving issues from jdaggett 16:05:04 fantasai: open issues on writing modes? 16:05:10 Koji: text-combine-horizontal naming only 16:05:43 ChrisL has joined #css 16:06:15 fantasai: Plan is for writing modes to go to last call once we have all the edits done. 16:06:20 Topic: writing modes 16:06:27 peterl: any concerns with that? 16:06:34 florian: maybe not the last last call? 16:06:48 hober: but we want the feedback, thus ok with doing it now 16:07:42 peterl: are people comfortable going to LC without seeing edits? 16:07:56 RESOLVED: css3-writing-modes to Last Call when edits agreed in this meeting are completed 16:08:13 fantasai: I'll post to www-style with the edits so people can look and give a week or so, and then publish. 16:08:20 peterl: Meeting closed. 16:08:43 ChrisL has joined #css 16:23:23 projector, you asked to be reminded at this time to go home 16:45:12 rhauck has joined #css 16:52:12 Rossen_ has joined #css 17:00:46 shans__ has joined #css 17:04:46 myakura has joined #css 17:13:26 cabanier has joined #css 17:26:31 glazou has joined #css 17:36:07 jet has joined #css 17:56:01 liam has joined #css 18:12:20 teoli has joined #css 18:53:37 teoli has joined #css 19:00:26 lmclister has joined #css 19:18:19 tobie has joined #css 19:47:03 krit has joined #css 19:56:09 krit1 has joined #css 20:07:32 leif has joined #css 20:15:07 leif1 has joined #css 20:23:26 krit has joined #css 20:28:00 leif has joined #css 20:35:45 leif1 has joined #css 20:35:46 rhauck1 has joined #css 20:38:10 leif has joined #css 20:43:28 leif1 has joined #css 20:53:06 shans__ has joined #css 20:55:39 leif has joined #css 21:00:45 teoli has joined #css 21:05:49 teoli_ has joined #css 21:09:36 jet has joined #css 21:19:28 tobie has joined #css 21:20:01 leif has left #css 23:15:03 dauwhe_ has joined #css 23:28:14 lmclister has joined #css 23:52:49 tobie has joined #css