IRC log of css on 2012-06-20

Timestamps are in UTC.

15:17:39 [RRSAgent]
RRSAgent has joined #css
15:17:39 [RRSAgent]
logging to http://www.w3.org/2012/06/20-css-irc
15:17:44 [glazou]
Zakim, this will be Style
15:17:44 [Zakim]
ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 43 minutes
15:17:48 [glazou]
RRSAgent, make logs public
15:23:43 [evanli]
evanli has joined #css
15:29:36 [glazou]
glazou has left #css
15:34:19 [bradk]
bradk has joined #css
15:49:37 [glazou]
glazou has joined #css
15:54:17 [koji]
koji has joined #css
15:55:08 [glazou]
koji: see my last tweet cc:ed to you
15:55:39 [glazou]
koji: https://twitter.com/glazou/status/215467984704126977
15:56:46 [Zakim]
Style_CSS FP()12:00PM has now started
15:56:47 [oyvind]
oyvind has joined #css
15:56:53 [Zakim]
+plinss
15:57:49 [glazou]
Zakim, code?
15:57:49 [Zakim]
the conference code is 78953 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), glazou
15:57:56 [Zakim]
+??P42
15:58:02 [glazou]
Zakim, ??P42 is me
15:58:02 [Zakim]
+glazou; got it
15:59:12 [antonp]
antonp has joined #css
16:00:10 [florian]
florian has joined #css
16:00:25 [Zakim]
+[Microsoft]
16:00:28 [arronei]
zakim, microsoft has me
16:00:39 [Zakim]
+arronei; got it
16:00:44 [Zakim]
+??P46
16:00:48 [florian]
Zakim, I am ??P46
16:00:48 [Zakim]
+florian; got it
16:01:08 [Zakim]
+ +93550aaaa
16:01:17 [antonp]
Zakim, aaaa is me
16:01:18 [Zakim]
+[Microsoft.a]
16:01:26 [Zakim]
+antonp; got it
16:01:29 [koji]
glazou:thx
16:01:31 [smfr]
smfr has joined #css
16:01:32 [florian]
florian has left #css
16:01:42 [florian]
florian has joined #css
16:01:50 [JohnJansen]
JohnJansen has joined #css
16:01:59 [Zakim]
+??P50
16:02:02 [Zakim]
+ +1.206.324.aabb
16:02:12 [sylvaing]
Zakim, aabb is sylvaing
16:02:12 [Zakim]
+sylvaing; got it
16:02:14 [Zakim]
+ +1.408.636.aacc
16:02:16 [nimbu]
nimbu has joined #css
16:02:23 [smfr]
Zakim: aacc is me
16:02:32 [smfr]
i guess Zakim forgot everyone again
16:02:44 [Zakim]
+ +1.650.275.aadd
16:02:50 [smfr]
Zakim, aacc is me
16:02:52 [Zakim]
+smfr; got it
16:02:57 [smfr]
Zakim: why you hate colons?
16:03:36 [Zakim]
+fantasai
16:03:49 [bradk]
zakim, aadd is me
16:03:49 [Zakim]
+bradk; got it
16:03:55 [bradk]
I think
16:04:08 [Zakim]
+ +1.415.832.aaee
16:04:30 [krit]
zakim, aaee is me
16:04:30 [Zakim]
+krit; got it
16:04:32 [JohnJansen]
Zakim, Microsoft has JohnJansen
16:04:32 [Zakim]
+JohnJansen; got it
16:04:48 [JohnJansen]
is the phone working for anyone?
16:05:15 [smfr]
JohnJansen: say something
16:05:24 [nimbu]
how do I tell zakim i am in same conferencing phone systam as krit
16:05:37 [JohnJansen]
so, I guess you didn't hear me :-)
16:05:48 [Zakim]
+??P18
16:06:07 [antonp]
I'm not really hearing anyone, just tiny bursts of phone activity
16:06:18 [fantasai]
zakim, krit has nimub
16:06:18 [Zakim]
+nimub; got it
16:06:22 [krit]
hober: what does w3c meme say?
16:06:27 [fantasai]
zakim, nimub is nimbu
16:06:27 [Zakim]
sorry, fantasai, I do not recognize a party named 'nimub'
16:06:32 [fantasai]
:/
16:07:12 [fantasai]
ScribeNick: fantasai
16:07:18 [fantasai]
plinss: additions to agenda?
16:07:27 [fantasai]
smfr: transforms and fixed backgrounds
16:07:47 [fantasai]
florian: at bottom of agenda, leftovers from f2f, some have been addressed and should be removed
16:08:23 [fantasai]
fantasai: an issue on counter style case-sensitivity
16:08:31 [fantasai]
Topic: CSS2.1
16:08:38 [fantasai]
http://wiki.csswg.org/topics/overflow-formatting-context
16:08:45 [fantasai]
plinss: everyone had an action item to review this
16:09:16 [glazou]
ROFL
16:09:25 [fantasai]
antonp: So, this is an issue about introducing a new term "formatting context" which will cover things like BFC but also be used to cover things like "flexbox FC" and "table FC"
16:09:38 [glazou]
#antonp { speech-rate: slower; }
16:09:43 [fantasai]
antonp: It came up in the Flexbox spec, because its children are not formatted as blocks
16:09:59 [fantasai]
antonp: Realized it would be useful to have a term simply "formatting context"
16:10:21 [fantasai]
antonp: would solve problem in specs currently, e.g. for overflow it should apply to a wider class of items than just block formatting contexts
16:10:37 [fantasai]
antonp: similar issue with containing block
16:10:50 [fantasai]
antonp: answer here is an element that establishes a formatting context, not just a block formatting context
16:10:56 [fantasai]
antonp: this also speaks to some bugs we have on 2.1
16:11:14 [fantasai]
antonp: related to the fact that currently we have problems with definitions of overflow and containing block because they do forget to handle tables
16:11:26 [fantasai]
antonp: These edits would fix those bugs and give us a nice editorial hook for future specs
16:11:43 [fantasai]
florian: after reading what was written and listening to what was said, I think the logic makes sense
16:11:58 [fantasai]
florian: I don't feel comfortable enought that I know enough details to be sure this all works
16:12:15 [fantasai]
florian: I therefore hesitate to vote for it
16:12:57 [fantasai]
fantasai: I think these edits are correct (I wrote some of them). Would like to hear from dbaron too though
16:13:14 [fantasai]
arronei: I think these changes are fine, but wondering why we're editing 2.1 here
16:14:22 [fantasai]
arronei: 2.1 isn't completely clear here, but it's not obviously wrong
16:14:40 [fantasai]
arronei: why not just start a CSS3 spec
16:15:02 [fantasai]
fantasai: Our current specs depend on 2.1 right now, not on non-existent or early-draft specs
16:15:37 [fantasai]
plinss: I'm also concerned about editing 2.1, but also see the problem with not having equivalent text in level 3
16:16:01 [Rossen]
Rossen has joined #css
16:16:32 [fantasai]
proposal - resolve pending dbaron's approval
16:18:42 [fantasai]
Rossen: Is this going to have any changes to the behavior of tables? Or is it just editorial?
16:19:11 [fantasai]
antonp: When there was a lot of rewriting of blocks and boxes and things, there were some thing that were broken as part of that
16:19:24 [fantasai]
antonp: e.g. overflow used to a pply to tables, but doesn't as a result of that
16:19:41 [fantasai]
antonp: basically the edit there is taking the spec back to what it was supposed to be saying
16:19:58 [fantasai]
antonp: we can fix those two bugs by being very explicit, and just say exactly which boxes are affected
16:20:09 [fantasai]
antonp: but the primary motivation for using this term is that CSS3 specs need to use it
16:20:23 [fantasai]
antonp: since it's useful to 2.1 and 3, better to make these edits
16:20:55 [fantasai]
Rossen: just concerned about introducing any implementation changes to 2.1
16:21:13 [fantasai]
sylvaing: the question is, do we need to change testcases. If yes, then we need to take a closer look at this
16:21:20 [fantasai]
sylvaing: If there are testcases, should be part of the proposal
16:21:37 [fantasai]
antonp: I believe there are testcases, part of the reason these bugs were filed was because they didn't match the testcases
16:22:14 [sylvaing]
bringing the spec in line with the test suite is fine imo
16:22:56 [fantasai]
http://test.csswg.org/shepherd/testcase/overflow-applies-to-013/name/overflow/title/table/
16:23:18 [fantasai]
RESOLVED: Proposal accepted pending dbaron's review and acceptance
16:23:41 [Zakim]
-??P18
16:23:43 [Zakim]
+[Microsoft.aa]
16:23:52 [fantasai]
Topic: Flexbox
16:23:59 [Rossen]
Zakim, [Microsoft.aa] is me
16:23:59 [Zakim]
+Rossen; got it
16:24:33 [fantasai]
fantasai: First issue is, does the order property have an effect on the z-order/ painting order
16:25:09 [fantasai]
fantasai: do you follow document order when painting, or do you follow the order-modified order
16:25:12 [fantasai]
alexmog: also tab-order
16:25:15 [fantasai]
fantasai: that's a separate question
16:26:07 [fantasai]
fantasai sez stuff
16:26:22 [fantasai]
smfr: From implementation perspective, would prefer if flex order didn't affect painting order
16:26:44 [fantasai]
alexmog: I think these are related, if we make tab-order change, then z-order should also change
16:27:07 [fantasai]
alexmog: from accessibility pov, whole point of changing order is that you don't change your tree, you only change little bit in cells, it looks like the order is different
16:27:17 [jet]
jet has joined #CSS
16:27:19 [fantasai]
alexmog: tab dialogs, one item's bring to front
16:27:24 [fantasai]
alexmog: you still read stuff in original source order
16:27:59 [fantasai]
smfr: if you have flex order affect painting order, the author puts in z-index, what happens?
16:28:08 [fantasai]
smfr: what stacking context are you using to paint the flex items
16:28:51 [fantasai]
smfr: can items interleave with flex items
16:29:00 [fantasai]
fantasai: z-index still works as usual
16:29:29 [fantasai]
fantasai: but if z-index has same number or auto, you use document order
16:29:52 [fantasai]
fantasai: question is, does 'order' affect the document order fallback for painting, or do you just you striaght-up document order
16:29:58 [alexmog_]
alexmog_ has joined #css
16:30:25 [dbaron]
dbaron has joined #css
16:30:37 [glazou]
who flushed the toilets?
16:30:47 [fantasai]
alexmog: the last time we discussed this, a couple years ago, we concluded at that point that reordering is a major enough change that everything looks as if it really was in a different order, and it makes sense to actually render in this new order
16:30:57 [Zakim]
+ +1.415.766.aaff
16:31:06 [fantasai]
alexmog: nobody could come up with use cases where it's important to preserve source order for painting
16:31:32 [fantasai]
alexmog: if there is any overlap of items, if it is ever intentional, painting order that matches order in flexbox would make sense
16:31:49 [miketayl_r]
miketayl_r has joined #css
16:32:07 [fantasai]
alexmog: IE reorders by order, and it does simplify implementation
16:32:32 [fantasai]
fantasai^: IIRC, webkit prefers painting order to be affected; for Mozilla, we can go either way, but I think simplifies our implementation somewhat
16:32:43 [fantasai]
smfr: if webkit impl is ok with it, then fine with me
16:32:52 [fantasai]
antonp: [...]
16:33:14 [fantasai]
antonp: if you make 3-column layout, you probably want each column to be stacking context anyway, would use z-index anyway
16:33:29 [fantasai]
florian: I think I'm hearing most people wanting painting order following order
16:33:52 [fantasai]
plinss: Yes, though I'm hearing some concerns about tab-order
16:33:53 [miketaylr]
miketaylr has joined #css
16:34:12 [fantasai]
fantasai would like to tackle that as a separate issue, since it affects other things
16:34:19 [fantasai]
Rossen: do we have a similar thing for grid?
16:34:35 [fantasai]
alexmog: Discussed in grid, in grid there is no order, everything is explicitly placed into its slot
16:34:43 [fantasai]
alexmog: no sequence in grid, so not applicable there
16:35:09 [fantasai]
alexmog: if at some point order is universally applicable, then it should be treated same way wherever it's applicable
16:35:18 [fantasai]
plinss: proposal is for order to affect painting order. Any objections?
16:35:27 [fantasai]
RESOLVED: order affects painting order
16:35:48 [fantasai]
http://wiki.csswg.org/topics/css3-flexbox-flexbox-replaced-children
16:36:14 [fantasai]
http://www.w3.org/TR/2012/WD-css3-flexbox-20120612/#flex-items
16:36:21 [fantasai]
Current spec text goes with Proposal A
16:36:58 [fantasai]
fantasai: proposal A can be recast in terms of proposal B at a later point
16:37:11 [fantasai]
alexmog: I would prefer to revert to the old wording
16:37:41 [fantasai]
alexmog: Someone said it's a problem with replaced elements vs. non-replaced elements having different styling during loading
16:37:50 [fantasai]
alexmog: whatever browser does this cannot pass Acid2
16:38:01 [fantasai]
...
16:38:05 [fantasai]
florian: for me that's not the motivation
16:38:17 [fantasai]
florian: we're doing this because these elements have the wrong display type
16:38:30 [fantasai]
florian: for other things the user can change the display type to whatever they want
16:38:36 [fantasai]
florian: Proposal B lets you opt out
16:40:01 [fantasai]
fantasai clarifies that Alex is asking for previous WD's behavior
16:40:11 [fantasai]
dbaron: what happens if an element is replaced due to CSS3 'content' property?
16:40:21 [fantasai]
florian: I like proposal B best
16:40:33 [fantasai]
florian: I would not like to be stuck with Proposal A forever
16:40:40 [fantasai]
florian: what Alex is saying sounds suboptimal to me but is acceptable
16:41:05 [fantasai]
alexmog: I can live with any of those, just seems inconsistent that replaced inline elements have special behavior that's already defined an known
16:41:10 [fantasai]
alexmog: and object fallback depends on those
16:41:15 [dbaron]
alex (in response to dbaron): the same (follow the rules for whether 'width' and 'height' apply)
16:42:39 [fantasai]
fantasai: One complication here is that Mozilla falls back to inline when <img> elements don't load, but some other browsers treat them as inline-block
16:42:55 [fantasai]
fantasai: whereas I believe some other impls don't
16:43:00 [fantasai]
fantasai: so you'll get different results
16:43:45 [fantasai]
antonp: I think it make sense for these elements to have special behavior
16:43:53 [dbaron]
I don't see anything in html5 saying img should be anything other than display:inline when there's no resource
16:43:59 [fantasai]
plinss: have 3 proposals on table, not hearing consensus
16:44:10 [fantasai]
florian: To me Proposal A is only acceptable because we can later switch to B
16:44:18 [dbaron]
same for canvas
16:44:20 [fantasai]
florian: To me it doesn't make sense to have A in the list because what I want is B
16:45:25 [fantasai]
fantasai: I think I'd like to summarize the situation and resolve when Tab's back
16:45:32 [fantasai]
florian: Does anyone disagree that B is better than A
16:45:42 [fantasai]
antonp: I think A should be followed by B, but not sure it should be instantly
16:46:25 [fantasai]
florian: concerned that we might be stuck with A if it takes too long to do B
16:46:33 [fantasai]
fantasai: ...
16:46:38 [fantasai]
alexmog: if A or B, would rather do B
16:47:03 [fantasai]
alexmog: yet another thing to do would be to treat any element that is a direct child of flexbox as a flex items
16:47:13 [fantasai]
alexmog: from all usecase we have, plaintext in flexbox is not a use case
16:47:23 [fantasai]
alexmog: just do something to not lose content when it's there
16:47:37 [fantasai]
alexmog: could just have any element, e.g. <b> or <i>, be a flex item
16:47:47 [fantasai]
alexmog: you'd get weird results if you have formatted text in a flexbox, but that's not a use case
16:48:20 [fantasai]
ACTION: fantasai summarize discussion
16:48:20 [trackbot]
Created ACTION-476 - Summarize discussion [on Elika Etemad - due 2012-06-27].
16:48:22 [bradk]
* { display: flex; }
16:48:46 [fantasai]
fantasai^: don't think we'll get stuck with A, B just has A implemented as ua.css rules
16:49:01 [fantasai]
fantasai^: Have a bigger problem that might get stuck with flex items returning 'display: block'
16:49:09 [fantasai]
fantasai^: and can't change to returning 'display: flex-item'
16:49:15 [fantasai]
Topic: Background Attachment and Transforms
16:49:16 [plinss]
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17521
16:49:23 [smfr]
http://www.w3.org/TR/css3-transforms/
16:49:29 [fantasai]
smfr: In CSS transforms spec there's a sentence that says
16:49:36 [fantasai]
smfr: [quotes spec]
16:49:56 [fantasai]
smfr: and there's a note that this behaves like a porthole -- you see the background through the porthole
16:50:10 [fantasai]
smfr: this kindof makes sense for 2D transforms, butfor 3D it's extremely hard to implement
16:50:22 [fantasai]
smfr: Making that element behave like a porthole where you see an untransformed background
16:50:40 [smfr]
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17521
16:50:44 [fantasai]
smfr: one possible amendment to the spec owuld be to say that bg-attach: fixed affected by trasnform treated like scroll
16:51:19 [Zakim]
-antonp
16:51:28 [antonp]
antonp has left #css
16:51:44 [fantasai]
fantasai: Would it make sense to have the fixed background be transformed with the rest of the element? Rather than just ignoring fixedness
16:51:56 [fantasai]
florian: would make sense, why would you do that as an author?
16:52:13 [fantasai]
smfr: Your suggestion is tricky because how you render that background before applying that transformed
16:52:33 [fantasai]
smfr: so, you render the element as if screen-aligned, then transform
16:52:38 [fantasai]
smfr: not sure what left/top offset you'd use
16:52:49 [fantasai]
smfr: when you scroll page you'll have this shifting of that background
16:53:12 [fantasai]
krit: background should transform with the element
16:53:35 [fantasai]
smfr: dbaron gave us some history, that bg-attach fixed was only intended for root element.
16:53:50 [fantasai]
smfr: sortof crept into applying to other elements
16:54:02 [fantasai]
smfr: any other implementers with feedback? IE?
16:54:18 [dbaron]
I'm sure Gecko does something, but I don't know what, and it's hard to work out what's hard off the top of my head.
16:54:21 [fantasai]
arronei: Not sure, have to look that up and check
16:54:42 [fantasai]
florian: I don't know for Opera
16:54:53 [fantasai]
smfr: maybe get action items from other vendors to investigate
16:55:06 [fantasai]
florian: from our POV, probably too early to tell
16:55:17 [fantasai]
sylvaing: pretty sure we don't do porthole thing, but I'll check what we do
16:55:28 [fantasai]
krit: are there test files?
16:55:42 [fantasai]
ACTION: smfr make a testcase
16:55:42 [trackbot]
Created ACTION-477 - Make a testcase [on Simon Fraser - due 2012-06-27].
16:55:46 [fantasai]
ACTION: florian ask Opera
16:55:47 [trackbot]
Created ACTION-478 - Ask Opera [on Florian Rivoal - due 2012-06-27].
16:55:59 [fantasai]
ACTION: dbaron check Gecko wrt bg-attach and transforms
16:56:00 [trackbot]
Created ACTION-479 - Check Gecko wrt bg-attach and transforms [on David Baron - due 2012-06-27].
16:56:12 [fantasai]
ACTION: sylvaing check bg-attach with transforms
16:56:12 [trackbot]
Created ACTION-480 - Check bg-attach with transforms [on Sylvain Galineau - due 2012-06-27].
16:56:22 [fantasai]
plinss: should also give some thought to what the right thing to do is
16:56:42 [fantasai]
bradk: Sounds like if the bg was large enough, and coordinates ok, could have something look good
16:56:47 [fantasai]
s/something/portal
16:56:58 [fantasai]
deferred to next week
16:57:05 [fantasai]
Topic: page-break: recto/verso
16:58:32 [fantasai]
fantasai summarizes
16:58:49 [fantasai]
glazou: These will be easy to understand in Europe
16:58:56 [fantasai]
plinss: these are industry standard terms going back ages
16:58:58 [fantasai]
http://en.wikipedia.org/wiki/Recto_and_verso
16:59:16 [fantasai]
florian: sounds good to me
16:59:28 [fantasai]
RESOLVED: add recto/verso values to page-break-before/page-break-after in css3-break
16:59:37 [Zakim]
-krit
16:59:39 [Zakim]
-glazou
16:59:40 [Zakim]
-Rossen
16:59:42 [Zakim]
-[Microsoft]
16:59:44 [Zakim]
-dbaron
16:59:46 [Zakim]
-fantasai
16:59:49 [Zakim]
-sylvaing
16:59:50 [Zakim]
-smfr
16:59:52 [Zakim]
-plinss
16:59:54 [Zakim]
-[Microsoft.a]
16:59:57 [Zakim]
-bradk
17:00:23 [Zakim]
-??P50
17:00:52 [Zakim]
-florian
17:00:53 [Zakim]
Style_CSS FP()12:00PM has ended
17:00:53 [Zakim]
Attendees were plinss, glazou, arronei, florian, +93550aaaa, [Microsoft], antonp, +1.206.324.aabb, sylvaing, +1.408.636.aacc, +1.650.275.aadd, smfr, fantasai, bradk,
17:00:53 [Zakim]
... +1.415.832.aaee, JohnJansen, nimub, Rossen, +1.415.766.aaff, dbaron
17:01:04 [florian]
florian has left #css
17:04:15 [smfr]
smfr has left #css
17:05:01 [oyvind]
oyvind has left #css
17:06:01 [nimbu]
nimbu has joined #css
17:16:30 [evanli]
evanli has left #css
17:46:57 [fantasai]
sylvaing: didn't you have a note you wanted to add to css3-background?
17:47:05 [sylvaing]
yes, it's on www-style
17:47:34 [sylvaing]
http://lists.w3.org/Archives/Public/www-style/2012Jun/0445.html
17:47:59 [sylvaing]
rewordings welcome, I didn't spend much time on it but hopefully the goal is clear
17:48:28 [fantasai]
cool, thanks :)
17:49:13 [sylvaing]
I can't think of other things myself
17:49:54 [sylvaing]
I do want to spend more time reviewing css3-background testcases though
18:08:48 [jacobg]
jacobg has joined #css
18:11:07 [krit]
krit has joined #css
18:32:53 [jet]
jet has joined #CSS
18:52:29 [Zakim]
Zakim has left #css
18:56:44 [krit]
krit has joined #css
19:08:48 [stearns]
stearns has joined #css
19:12:12 [dbaron]
dbaron has joined #css
19:13:40 [ksweeney1]
ksweeney1 has joined #css
19:25:22 [logbot]
logbot has joined #css
19:34:04 [nimbu]
nimbu has joined #css
20:09:06 [tantek]
tantek has joined #css
20:26:08 [ksweeney]
ksweeney has joined #css
20:26:22 [krit]
krit has joined #css
20:29:09 [ksweeney]
ksweeney has left #css
20:42:18 [tantek]
tantek has joined #css
20:47:42 [tantek]
tantek has joined #css
21:03:33 [nimbu]
nimbu has left #css
21:11:29 [krit]
krit has joined #css
21:12:11 [krit1]
krit1 has joined #css
21:13:27 [miketayl_r]
miketayl_r has joined #css
22:01:45 [jacobg1]
jacobg1 has joined #css
22:04:48 [jacobg]
jacobg has joined #css
22:06:39 [jacobg]
jacobg has left #css
22:51:51 [myakura]
myakura has joined #css
22:52:49 [myakura_]
myakura_ has joined #css
22:58:46 [stearns]
stearns has joined #css
23:42:52 [nimbu]
nimbu has joined #css
23:57:19 [myakura]
myakura has joined #css
23:57:32 [myakura_]
myakura_ has joined #css
23:57:53 [myakura]
myakura has joined #css