IRC log of css on 2012-10-24

Timestamps are in UTC.

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