00:42:41 jet has joined #CSS 01:21:53 drublic has joined #css 01:42:16 jet has joined #CSS 03:54:24 benknight has joined #css 04:04:09 cabanier has joined #css 04:14:05 cabanier has joined #css 04:48:47 jdaggett has joined #css 04:51:46 jet has joined #CSS 05:22:42 drublic has joined #css 05:37:16 SamB_MacG5 has joined #css 05:57:48 arronei has joined #CSS 07:16:06 drublic has joined #css 07:25:51 Ms2ger has joined #css 07:29:21 SimonSapin has joined #css 07:49:20 dbaron has joined #css 07:50:04 dbaron has joined #css 08:37:47 logbot has joined #css 08:55:12 <{Darktears}> {Darktears} has joined #css 09:22:09 SimonSapin has joined #css 12:12:12 dbaron has joined #css 12:48:56 dbaron_ has joined #css 15:14:42 RRSAgent has joined #css 15:14:42 logging to http://www.w3.org/2012/10/24-css-irc 15:14:52 RRSAgent: make logs public 15:16:25 glazou has joined #css 15:16:38 Zakim has joined #css 15:16:46 Zakim, this will be Style 15:16:47 ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 44 minutes 15:16:50 RRSAgent, make logs public 15:22:29 hi elika 15:35:44 danielfilho|w has joined #css 15:44:05 krit has joined #css 15:49:54 SimonSapin1 has joined #css 15:50:18 florian has joined #css 15:52:40 Style_CSS FP()12:00PM has now started 15:52:47 +[IPcaller] 15:54:03 antonp has joined #css 15:54:30 +??P19 15:54:43 Zakim, ??P19 is me 15:54:43 +glazou; got it 15:55:08 Zakim, [IPcaller] is florian 15:55:08 +florian; got it 15:55:28 Zakim, mute florian 15:55:28 florian should now be muted 15:55:38 Zakim, unmute florian 15:55:38 florian should no longer be muted 15:55:56 florian has joined #css 15:56:14 benknight has joined #css 15:56:23 -florian 15:56:49 +??P4 15:56:57 Zakim, ??P4 is florian 15:56:57 +florian; got it 15:57:19 + +33.9.52.34.aaaa 15:57:36 Zakim: aaaa is me 15:58:04 dbaron has joined #css 15:58:16 Zakim, code? 15:58:16 the conference code is 78953 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), dbaron 15:58:35 lstorset has joined #css 15:59:14 + +47.23.69.aabb 15:59:16 There's a French number for zakim, isn't there? 15:59:20 Zakim, aabb is me 15:59:21 +lstorset; got it 15:59:22 not any more 15:59:26 dbaron: not any more 15:59:29 stearns has joined #css 15:59:31 + +1.858.354.aacc 15:59:52 Zakim, aacc is me 15:59:52 +plinss; got it 16:00:07 Zakim, +33.9.52.34.aaaa is me 16:00:07 +SimonSapin; got it 16:00:12 antonp: using SIP myself 16:00:13 oyvind has joined #css 16:00:16 +Stearns 16:00:31 antonp: using the US number here 16:00:34 antonp: Worked for me 16:00:37 koji has joined #css 16:00:41 antonp: stearns used the US number 16:00:48 and he's on the call now 16:00:59 + +1.415.308.aadd 16:01:01 Does anyone know any other numbers for Zakim? For me neither the London one nor Paris ones go to Zakim. (The London one goes to a company, and the Paris one goes to a private individual!) 16:01:17 zakim, aadd is me 16:01:17 +krit; got it 16:01:22 + +1.619.846.aaee 16:01:26 florian has left #css 16:01:29 florian has joined #css 16:01:36 +Lea 16:01:40 Zakim, aaee is me 16:01:41 +hober; got it 16:01:47 JohnJansen has joined #CSS 16:01:49 -florian 16:01:53 + +33.1.44.79.aaff 16:01:59 + +1.253.307.aagg 16:02:11 Zakim, aaff is [Mozilla-Paris] 16:02:11 +[Mozilla-Paris]; got it 16:02:20 Zakim, [Mozilla-Paris] has dbaron, fantasai 16:02:20 +dbaron, fantasai; got it 16:02:22 +??P28 16:02:26 antonp: iirc only the us number works; otherwise, there's sip 16:02:50 +[Microsoft] 16:02:55 smfr has joined #css 16:03:08 Zakim, I might be ??P28 16:03:08 I don't understand 'I might be ??P28', florian 16:03:15 Zakim, I am ??P28 16:03:15 +florian; got it 16:03:18 +??P8 16:03:25 Zakim, Microsoft has JohnJansen 16:03:25 +JohnJansen; got it 16:03:25 zakim, ??p8 is me 16:03:26 +koji; got it 16:03:31 + +1.408.636.aahh 16:03:33 ChrisL has joined #css 16:03:49 Zakim, you have the memory of a flea 16:03:49 I don't understand 'you have the memory of a flea', smfr 16:03:55 Zakim, aahh is me 16:03:55 +smfr; got it 16:04:45 glazou, btw, https://lists.w3.org/Archives/Member/w3c-css-wg/2012OctDec/0113.html still lists a French number, btw 16:04:51 yeah I know 16:04:54 I have to fix that 16:05:07 ScribeNick: fantasai 16:05:34 ok, I think i'm in on a different line 16:05:41 glazou: Any other items? 16:05:46 krit: [...] 16:05:57 krit: move discussion of masking to tpac 16:06:02 krit: move transforms to tpac 16:06:10 krit: ask for fpwd of ? for tpac 16:06:16 smfr has changed the topic to: http://lists.w3.org/Archives/Public/www-style/2012Oct/0680.html 16:06:21 s/?/masking/ 16:06:40 +ChrisL 16:06:44 TabAtkins_ has joined #css 16:06:52 Topic: CSS4 Backgrounds 16:06:54 http://lists.w3.org/Archives/Public/www-style/2012Oct/0313.html 16:06:56 s/move transforms/move masking/ 16:06:56 glazou: deferred from last week 16:07:30 + +1.281.305.aaii 16:07:38 zakim, aaii is me 16:07:38 +TabAtkins_; got it 16:07:44 leaverou: Where not ambiguous order shouldn't matter, since this is how most of CSS works 16:07:50 leaverou: I've been confused by this many times 16:07:53 TabAtkins_: I support this 16:08:01 glazou: I think it does make sense 16:08:15 florian: In principle I agree, but wondering if it's too late to change. 16:08:29 florian: If it's rare enough that this will flip some invalid declarations to valid an break sites, then ok 16:08:48 if the order is 'either way' then it won't break, surely 16:08:57 +Antoine 16:09:01 florian: This is always something we have to think of when we turn on things that didn't used to work 16:09:09 Zakim, Antoine is me 16:09:09 +antonp; got it 16:09:11 dbaron: I'm not too worried about this. 16:09:11 +[Microsoft.a] 16:09:25 smfr: I think it's fine to change behavior in this case 16:09:33 +Bert 16:09:43 glazou: Definition we have now is in CSS3 BG CR 16:09:43 Rossen has joined #css 16:09:52 glazou: So, if we accept such a change, when do we do it? 16:09:56 glazou: And where? 16:10:18 TabAtkins: I'm ambivalent about where we put the grammar change. Can do it now 16:11:27 fantasai: I think if we do this, we should errata the CR so it remains an accurate description of the features that are in it 16:11:54 ChrisL: you can't errata a CR, can only errata a REC. Could go through last call or ... 16:12:14 dbaron: I'm definitely supportive about the change in ordering, more tentative wrt change to allow 1 or zero lengths 16:12:34 dbaron: We'd want to keep text shadow and box shadow aligned 16:12:48 dbaron: It'd be odd to write text-shadow: red; and have nothing show up, but still show up 16:13:02 glazou: Can do the same with border: red; 16:14:21 TabAtkins: Would want at least one length 16:14:39 fantasai: I think we should defer that change to L4, to decide what the single length should mean 16:14:53 fantasai: first length is horizontal, not that useful. Discussion on list said it's common to want only one offset, but want it vertical 16:15:08 smfr: Would make sense for it to be just the blur radius 16:15:17 TabAtkins: I agree w fantasai 16:15:21 s/really/REALLY/ 16:15:30 TabAtkins: I think we should accept Lea's proposal to allow looser ordering 16:15:39 TabAtkins: Errata L3 for that 16:16:06 TabAtkins: Defer anything about omitting lengths for furrther discussion and possible inclusion in L4 16:16:16 ChrisL: :-) 16:16:20 glazou: Ok, let's edit css3-CR and call it a clarification 16:16:29 JohnJansen: I will point out that nobody does this right now 16:16:43 JohnJansen: It's strictly a superset, so I think it's ok, but we need to add testcases for it 16:16:54 Florian: [...] 16:17:12 ChrisL: Another LC wouldn't slow us down, b/c things we're held back by are testcases and implementation reports 16:17:21 TabAtkins: Unless someone pulls out a full complete test report next week :) 16:17:28 glazou: Hearing consensus here, declaring resolution 16:17:42 s/[...]/I am not interested in a lot of process for that, since it is a simple change, and it seems to me we are bending the rules, but if the rule keepers are fine, then fine/ 16:17:48 http://lists.w3.org/Archives/Public/www-style/2012Oct/0398.html 16:18:06 RESOLVED: Allow flexibility in ordering for box-shadow / text-shadow. Same requirements on what's required in the declaration (at least 2 lengths) 16:18:39 not hearing A SINGLE WORD 16:18:40 Actually, if Test The Web Forward goes as planned, we will be close to having a suite for BnB next week. I'm working on pulling the incoming tests together now. 16:18:44 Zakim, mute florian 16:18:44 florian should now be muted 16:18:49 aaah 16:18:52 TabAtkins: There's an issue on viewport length units in @page 16:19:10 TabAtkins: Since it references the viewport size, but it's defined to set the width of the first page 16:19:22 florian: was not enough, still echos ; you muted the phone, I muted the line 16:19:26 TabAtkins: Should just disallow viewport-relative units in @page sizing properties 16:19:43 This should include margin/border/padding/width/height/size 16:20:34 SimonSapin: Values module says that ? changes if the size of pages change, but ?? is supposed to be absolute 16:20:52 TabAtkins: Make sure to clarify that viewport-relative units are relative to ICB, not current page size 16:20:57 TabAtkins: Need to be a bit more careful here 16:21:06 "Note that Paged Media defines how the initial containing block transforms across varying page widths. This also affects these units. " 16:21:23 TabAtkins: If ppl want things relative to the page they're on, viewport-relative units would have to become a used-value time tihng 16:21:33 TabAtkins: Won't be super-useful for documents of varying page sizes 16:21:40 TabAtkins: But if that's ok with WG, relatively easy thing to write up. 16:22:45 fantasai: Think we should ask Simon and Antenna House about their viewpoints, since they're the ones really dealing with this kind of things 16:22:55 antonp: Wanted confirmation that ICB is only first page 16:22:57 TabAtkins: Yes, it is. 16:23:10 antonp: So if you've got abspos element on page 10, it ends up on the first page 16:23:29 TabAtkins: Gets positioned relative to the first page, though might not wind up on that page depending on where it's positioned 16:23:44 Rossen: Also keep in mind that if you find an bspos on page 10 and auto-positioned, will most likely stay on page 10 16:23:55 Rossen: But top: 0; will pull back to page 1 16:24:34 TabAtkins: Ok, me or Simon would write up an email to Prince and Antenna house explaining two options, and ask them what they think 16:24:43 krijnh has joined #css 16:24:43 Topic: CSS3 Positioning 16:24:53 s/Positioning/Conditional Rules/ 16:25:15 TabAtkins: I asked for more time to review fantasai's suggestion, and after talking with her last week agree with her position 16:25:26 TabAtkins: Not sure how to write it out, but just have to figure out how to express elegantly 16:25:46 TabAtkins: Idea was that parenthesized groups have same error-handling as an anonymous function; i.e. if you don't recognize the grammar, treat it as fals 16:25:56 TabAtkins: dbaron brought up problem that this might hide syntax errors 16:26:44 TabAtkins: But I don't think that's a huge issue, and that's kindof the point too, for future syntax we add it's good 16:26:57 dbaron: I also think it's not a huge issue. @supports is just not very typo-resilient 16:27:09 Zakim, unmute me 16:27:10 florian should no longer be muted 16:27:15 TabAtkins: We can make the reasonable edits this week or reasonably soon, and that was last remaining issue. 16:27:41 Florian: I'd like to make this change fast, b/c have implementations rolling out 16:27:45 TabAtkins: Absolutely. 16:28:20 fantasai: Suggest we make the edits, and just have a 3-minute conversation about publishing LC at TPAC (next week) 16:28:40 Leif: Haven't looked into this, but sounds fine from first look. 16:29:04 Topic: ???? 16:29:23 s/????/Anything remaining for Item 4?/ 16:29:41 http://lists.w3.org/Archives/Public/www-style/2012Oct/0513.html 16:29:51 krit: raised an issue with transforms that we have ? 16:29:53 Topic: decompos 2D matrices 16:30:01 krit: How to decompose 3D matrices 16:30:06 krit: how to decompose 2D matrices 16:30:15 krit: [breaking up] 16:30:28 krit: [something about computed value] 16:30:29 krit: _extremely_ hard to unddrstand what you say 16:30:41 krit: Interpolation algorithm 16:31:10 ok, agree 16:31:16 glazou: We cannot hear you, suggest to defer to TPAC 16:31:28 Topic: display spec 16:31:40 TabAtkins: I've been complaining about the way the dsiplay property work since I joined the WG 16:31:42 http://lists.w3.org/Archives/Public/www-style/2012Oct/0552.html 16:31:52 TabAtkins: Conflates internal/external display modes 16:31:58 TabAtkins: And display none toggling 16:32:05 TabAtkins: Went ahead to draw up first draft of new display spec 16:32:14 TabAtkins: Four properties: display-inside/display-outside 16:32:27 TabAtkins: Two other properties, bad names, 'display-box' for none behavior 16:32:36 -plinss 16:32:49 TabAtkins: Added value for displaying the contents in place of the box itself, i.e. as if the element wasn't there but its contents were 16:32:52 TabAtkins: And one for marker-box 16:33:09 TabAtkins: There's only one extra functionality, and some extra complexity from splitting things up 16:33:17 TabAtkins: Hope it will make things easier to talk about 16:33:29 TabAtkins: [gives example] 16:33:35 TabAtkins: yay/nay? Take on as official work item? 16:33:53 florian: I agree with split into at least 3, a bit more discussion if we need list-item behavior as a fourth item 16:33:59 florian: Other than that, think it's a good idea 16:34:33 Bert: This is something that we tried years ago, and I wrote it up, but it failed to become intuitive 16:34:57 Bert: It's much easier to talk about an inline or a block in a stylesheet than to talk about inside and outside independently 16:35:18 Bert: For cases where you say, sometimes you have to talk about things that are a block inside, we can solve with terminology in the spec 16:35:31 Bert: Think need to talk to authors about their perceptions 16:35:39 Bert: In my experience, it doesn't really work 16:35:49 Bert: It was easier to not talk about it 16:35:59 TabAtkins: Cited your work as prior art 16:36:12 TabAtkins: For me, I just found the names confusing, display-model/display-role 16:36:16 TabAtkins: Didn't make sense 16:36:23 TabAtkins: But I think the names might be part of the intuition problem 16:36:42 Bert: It was originally -inside/-outside, we changed it later 16:36:53 dbaron: I always liked -inside/-outside better. But not sure we ever published with them 16:37:00 dbaron: we definitely discussed them 16:37:08 TabAtkins: Also think I came up with a slightly more intuitive combination of values 16:37:26 TabAtkins: With fantasai's help, realized I only needed three display-inside values: block | table | auto 16:37:36 TabAtkins: Ended up being a really simple way to do it 16:37:46 TabAtkins: Can still use shorthand 16:37:50 TabAtkins: Think it works pretty reasonably 16:37:58 antonp: I really like the approach 16:38:19 antonp: Thought about it independently, and came up with a model similar to Tab's 16:38:24 antonp: I think it is a useful way forward 16:38:42 antonp: My concern, from discussing with Bert, is that he has a very different model 16:38:49 Inside and outside seem very clear to me 16:38:54 antonp: He felt that grid wasn't a display model, liked the multi-column model 16:39:08 antonp: where the layout changes as reflection of other properties 16:39:18 antonp: Think need to think about that different way of thinking about things 16:39:29 glazou: Your draft contains all the shorthand values and all the extensions 16:39:38 glazou: I think authors are mostly going to use shorthands 16:39:58 glazou: Seems the split is mostly theoretical 16:40:10 glazou: Not convinced we actually need the separate properties 16:41:07 TabAtkins: It's not just theoretical, for instance, we can't have a display: table-cell that has a different internal model than display: block 16:41:13 glazou: It's just a matter of new keywords for display 16:41:47 TabAtkins: New outside displays won't be possible to combine with existing internal displays unless we creat combinatorial keywords 16:41:58 TabAtkins: Yes, it's mostly about clearing up tehoretical underpinnings 16:42:11 TabAtkins: But leaves better extension story 16:42:23 TabAtkins: Also, pulling out display: none into separate property is useful 16:42:43 antonp: I would really like to understand Bert's model first before adopting this. 16:42:53 antonp: Otherwise, I'm happy to fly down this route. 16:43:05 I think this is a good face-to-face topic. 16:43:12 Florian: Seems good thing to discuss at TPAC 16:43:25 Florian: At Opera, this matches well with how our code is structured 16:43:39 glazou: What about other browsers? 16:43:58 arronei: I think IE has some of this separation internally, but not quite to the extent we're talking about here 16:44:46 dbaron: We don't really have a separation in terms of display concepts, but there are things that share the same code, e.g. blocks and inline-block both block-inside. But don't quite track the separation 16:45:04 glazou: Let's add this to list of topics for TPAC, but give it a time limit 16:45:32 Florian: I think discussion should start with Bert explaining how he thinks about it, b/c other than that I think everyone seems to align with this. 16:45:41 http://lists.w3.org/Archives/Public/www-style/2012Oct/0516.html 16:45:48 Topic: BOM precedence 16:46:19 TabAtkins: Nobody disagrees, so I will go make that change. 16:46:28 glazou: You saying nobody disagrees is not enough for me, Tab. 16:46:44 I agree 16:47:00 dbaron: Henri's proposing this, and I'm in no position to disagree with him 16:47:09 q+ fantasai 16:47:16 Leif: It would be nice to have some good tests for this. 16:47:21 BOM precedence sounds good to me, though I don’t have much experience with web compat 16:47:24 TabAtkins: Hoping Anne can help out with that. 16:47:32 ack fantasai 16:47:43 fantasai: if we're currently defining things one way, then we need to errata CSS 2.1 16:48:20 glazou: Seems we all agree on this, let's move on 16:49:02 Tab: OK, I'll investigate CSS 2.1 errata 16:49:04 RESOLVED: BOM takes precedence over HTTP. Errata CSS2.1, edit css3-syntax to fix this. 16:49:37 ChrisL: This affects UTF-16, and, if present, UTF-8 16:50:02 ChrisL: This is more in line with XML ??? [?] 16:50:13 ChrisL: Also gives same behavior from filesystem vs web 16:50:22 ChrisL: Also some parsers don't have access to HTTP headers 16:50:27 Koji: ... i18nwg? 16:50:35 TabAtkins: I didn't hear from i18nwg on this 16:51:02 [multiple people talking at once] 16:51:04 antonp: Got how far in spreadsheet of testing...? 16:51:08 antonp: you're on the call! 16:51:12 Zakim, mute anton 16:51:12 antonp should now be muted 16:51:54 TabAtkins: Even if i18nwg hasn't, I trust work that Henri and Anne have been doing, they've been extremely thorough 16:52:01 also, if the BOM and http headers are in conflict, BOM is more likely to reflect author's intentions, as ability to modify the file is more common than ability to modify http headers. 16:52:37 glazou: Anything else on this topic? 16:52:46 http://lists.w3.org/Archives/Public/www-style/2012Oct/0563.html 16:53:19 Topic: breaking inline-block 16:53:21 s/XML ???/XML charset handling in draft-lilley-xml-mediatypes/ 16:53:23 glazou: Seems to need clarification 16:54:36 koji: Nested line boxes. Spec is not clear where it actually should page-break 16:55:02 -ChrisL 16:55:04 -krit 16:55:06 zakim, who is playing really annoying video games? 16:55:06 I don't understand your question, ChrisL. 16:55:06 bye krit 16:55:24 keep this undefined? 16:55:47 fantasai: I would leave it undefined, b/c I don't have a good answer 16:56:11 -Lea 16:56:14 Rossen: Consideration we had wrt fragment breaks, predictable approach is you start laying out your line box in current fragment. I fyou happen to overflow the fragment, and this is not the first line, then you push to the next one to make sure that this is the very first line 16:56:33 Rossen: At that point your inline content should simply break as any other regular container would break, ensure you'd give the line as much space as you can 16:56:44 Rossen: This is the only kind of predictable behavior that we thought of, not sure that it's optmila 16:57:36 fantasai: The issue is happening when you're already at the top of the page 16:57:47 Rossen: It's the same as for a very large font 16:58:34 fantasai: No, it's different. With a big glyph, the size of the glyph does not change it when you slice it across pages. 16:58:44 fantasai: with an inline block, you have the option to slice it; or you can fragment it 16:59:06 fantasai: if you fragment it, the height of the inline-block changes due to the fragmentation 17:00:12 -SimonSapin 17:00:28 koji: Second behavior seems clearly better 17:00:45 fantasai: Yes, but it's complicated because of interdependencies between alignment and size of box and point of fragmentation 17:01:05 Train strike on Thursday/Friday 17:01:08 -hober 17:01:19 -[Microsoft] 17:01:24 -[Microsoft.a] 17:01:26 - +1.253.307.aagg 17:01:26 Meeting closed. 17:01:27 -glazou 17:01:27 -Stearns 17:01:29 -florian 17:01:29 -TabAtkins_ 17:01:29 -antonp 17:01:30 -smfr 17:01:31 -Bert 17:01:36 www.airfrance.us does have a "Strike action on 26 October" warning on it 17:01:40 -[Mozilla-Paris] 17:01:52 -lstorset 17:02:08 https://www.airfrance.us/US/en/local/information/news/news-air-traffic-air-france.htm 17:02:34 -koji 17:02:35 Style_CSS FP()12:00PM has ended 17:02:35 Attendees were glazou, florian, +47.23.69.aabb, lstorset, +1.858.354.aacc, plinss, SimonSapin, Stearns, +1.415.308.aadd, krit, +1.619.846.aaee, Lea, hober, +33.1.44.79.aaff, 17:02:35 ... +1.253.307.aagg, dbaron, fantasai, JohnJansen, koji, +1.408.636.aahh, smfr, ChrisL, +1.281.305.aaii, TabAtkins_, antonp, [Microsoft], Bert 17:02:54 SimonSapin has joined #css 17:03:04 One trade union announced striked on Friday for Air France, indeed. There may be delays but Air France expects to transport everybody. 17:07:02 antonp has left #css 17:10:05 glazou has joined #css 17:10:51 oyvind has left #css 17:26:52 florian has left #css 17:45:29 Ms2ger has joined #css 17:47:48 ojan_away has joined #css 18:16:43 dbaron has joined #css 18:18:32 dglazkov has joined #css 18:50:45 cabanier has joined #css 18:57:38 Zakim has left #css 19:00:33 ojan has left #css 20:25:11 krijnh has joined #css 20:36:45 dbaron has joined #css 20:52:22 benknight1 has joined #css 21:56:31 benknight has joined #css 22:19:43 antonp has joined #css 23:02:33 SamB_MacG5 has joined #css