IRC log of CSS on 2010-07-14

Timestamps are in UTC.

15:53:59 [RRSAgent]
RRSAgent has joined #CSS
15:53:59 [RRSAgent]
logging to
15:54:13 [plinss_]
rrsagent, make logs public
15:54:20 [plinss_]
zakim, this will be style
15:54:20 [Zakim]
ok, plinss_; I see Style_CSS FP()12:00PM scheduled to start in 6 minutes
15:57:54 [lhnz]
lhnz has joined #css
15:58:10 [dethbakin]
dethbakin has joined #css
15:58:44 [arronei]
arronei has joined #css
15:59:31 [smfr]
smfr has joined #css
15:59:36 [Zakim]
Style_CSS FP()12:00PM has now started
15:59:44 [Zakim]
+ +1.408.636.aaaa
15:59:58 [smfr]
Zakim, aaaa is me
16:00:00 [Zakim]
+smfr; got it
16:00:26 [Zakim]
+ +1.617.650.aabb
16:00:32 [bradk]
bradk has joined #css
16:00:34 [dethbakin]
Zakim, aabb is me
16:00:34 [Zakim]
+dethbakin; got it
16:01:17 [Zakim]
+ +1.858.216.aacc
16:01:24 [plinss_]
zakim, aacc is me
16:01:24 [Zakim]
+plinss_; got it
16:01:46 [bradk]
great. Google Voice page doesn't work now....
16:02:06 [Zakim]
+ +1.206.324.aadd
16:02:21 [Zakim]
+ +1.650.214.aaee
16:02:25 [TabAtkins_]
Zakim, aaee is me
16:02:26 [Zakim]
+TabAtkins_; got it
16:03:11 [plinss_]
zakim, aadd is sylvaing
16:03:11 [Zakim]
+sylvaing; got it
16:03:33 [CesarAcebal]
CesarAcebal has joined #css
16:05:05 [Zakim]
16:05:07 [bradk]
!@#$!! Even in Chrome it won't call me! Tab, what's with Google Voice today?
16:05:43 [fantasai]
bradk, if you need a phone card I can send you my info
16:05:59 [Zakim]
+ +1.650.275.aaff
16:06:09 [bradk]
Zakim, aaff is me
16:06:09 [Zakim]
+bradk; got it
16:06:43 [bradk]
Thanks, I finally got in though.
16:07:43 [CesarAcebal]
I'm having problems trying to call with Skype. I'll keep trying it... (I'm sorry)
16:07:49 [TabAtkins_]
ScribeNick: TabAtkins_
16:08:34 [TabAtkins_]
plinss_: No additions to the agenda.
16:08:46 [TabAtkins_]
plinss_: Issue 53, spent a lot of time on it last week, not sure if anything got resolved.
16:09:01 [plinss_]
16:09:27 [fantasai]
I remember why pre-wrap isn't justified in MOzilla
16:09:29 [fantasai]
It's because of tabs
16:09:44 [Zakim]
+ +
16:10:00 [Curt`]
Curt` has joined #css
16:10:10 [CesarAcebal]
Zakim, aagg it's me.
16:10:10 [Zakim]
I don't understand 'aagg it's me', CesarAcebal
16:10:10 [TabAtkins_]
tabatkins: Conclusion from browser testing - anything with collapsed whitespace can be justified, anything with preserved whitespace can't be.
16:10:11 [fantasai]
So I would suggest adopting Proposal A
16:11:03 [fantasai]
plinss_, I would like to add the CSS Snapshot and the Styling Attributes spec to the agenda
16:11:04 [CesarAcebal]
Zakim, aagg is me.
16:11:04 [Zakim]
+CesarAcebal; got it
16:11:26 [TabAtkins_]
bradk: How do the tabs come into it, fantasai?
16:11:38 [fantasai]
How do you justify tabs?
16:11:45 [fantasai]
They're supposed to push text to the next tab stop
16:11:50 [fantasai]
but if spaces stretch or shrink
16:11:53 [fantasai]
then the text moves around
16:12:03 [fantasai]
and the tabs might need to push to the *next* tab stop
16:12:25 [fantasai]
so they have to be recalculated
16:12:31 [fantasai]
and the text *has* to be rebroken
16:12:45 [fantasai]
without the tabs problem, you never *need* to alter line breaks due to justification
16:12:49 [arronei]
arronei has joined #CSS
16:12:54 [fantasai]
it's just an option that can sometimes make the results better
16:13:04 [plinss_]
you can lay out the text with tabs, then justify from the last tab stop to the end of the line
16:13:28 [bradk]
I thought a tab was just a seres of spaces in HTML
16:13:46 [fantasai]
plinss, that makes sense. I like that definition.
16:14:00 [fantasai]
plinss, seems like it would handle most cases
16:14:14 [fantasai]
bradk: no, it aligns to a tab stop
16:14:23 [fantasai]
bradk: the tab stops are a multiple of 8 spaces apart
16:14:27 [TabAtkins_]
tabatkins: What plinss_ just suggested appears to be exactly what word processors do.
16:14:32 [fantasai]
bradk: starting from the containing block edge
16:15:04 [bradk]
Thanks, I didn't realize that.
16:15:27 [fantasai]
I'll note that SteveZ was concerned about CR exit, so if we go with this then we should mark justification of pre-wrap text as at-risk
16:15:36 [arronei]
zakim, microsoft is me
16:15:36 [Zakim]
sorry, arronei, I do not recognize a party named 'microsoft'
16:15:38 [Zakim]
16:15:39 [arronei]
zakim, microsoft is me
16:15:40 [Zakim]
+arronei; got it
16:16:03 [TabAtkins_]
tabatkins: Going with plinss_'s definition, we'll still have no implementations. Is that ok?
16:16:27 [TabAtkins_]
smfr: This question is specifically about CSS 2.1. What are we going to do right now?
16:17:28 [fantasai]
smfr, I don't think we have implementations to exit CR with pre-wrap justification right now, and given the implications with tabs, it's not as simple as throwing a few switches
16:17:35 [TabAtkins_]
bradk: We could say "Not justified" right now, and then change it in the future.
16:17:52 [fantasai]
bradk, that works as long as we are clear about our future plans
16:17:59 [fantasai]
bradk: we'd have to say thatt this may change in CSS3
16:18:16 [TabAtkins_]
plinss_: [talks about new mode that collapses spaces but not tabs]
16:18:18 [fantasai]
bradk: And probably remark that justification is allowed if the UA supports it
16:18:39 [TabAtkins_]
tabatkins: Fine with just going with current behavior for CSS2.1 and fixing it in the future.
16:18:43 [smfr]
16:18:53 [TabAtkins_]
RESOLVED: Accept proposal A for issue 53.
16:19:15 [plinss_]
16:19:20 [fantasai]
If the intention is to allow justification in the future, then we need a resolution to allow for that
16:19:39 [fantasai]
If the intention is not to allow justification in the future, then I'd like a resoluttion for /that/
16:20:18 [TabAtkins_]
RESOLVED: Look into allowing justification combined with white-space values in the future, but go with Proposal A for CSS 2.1.
16:20:24 [fantasai]
16:21:07 [TabAtkins_]
plinss_: dbaron, you have any idea when you'll be able to look at 101?
16:21:10 [TabAtkins_]
dbaron: Not sure.
16:21:19 [plinss_]
16:22:20 [TabAtkins_]
tabatkins: I pointed last week to the proposal that I was happy with making. I need to edit the wiki and resend to the list so people actually know what it is.
16:22:31 [bradk]
does centering text with tabs in it also change the white space?
16:22:46 [bradk]
Sorry, still thinking of last issue.
16:22:53 [fantasai]
bradk, good question, I don't know what happens
16:22:59 [fantasai]
bradk, it's a similar problem
16:23:22 [TabAtkins_]
It does something odd here in OOo Writer.
16:23:28 [TabAtkins_]
Not sure what the behavior is exactly.
16:23:43 [bradk]
If so, then we should treat centering and justifying the same way...
16:24:49 [plinss_]
16:26:11 [fantasai]
bradk, well, we don't have implementations to do it in 2.1, but since we're leaving it open for CSS3 we can do that in CSS3
16:26:29 [Curt`]
Curt` has joined #css
16:27:07 [TabAtkins_]
tabatkins: For dbaron's response on the list, I think the "float in inline" was precisely what we were testing.
16:27:17 [bradk]
fantasai, OK, I can live with that
16:27:38 [TabAtkins_]
dbaron: The actual discussion on the list was about different things; only some of them were about floats, and I think all of them involved a float in a block in an inline.
16:28:22 [TabAtkins_]
dbaron: For the testcase I posted yesterday, it appears that floats directly inside inlines are agreed by browsers to not relpos along with the inline.
16:29:35 [TabAtkins_]
dbaron: If we want to say that relposing moves a float inside the content tree but not in the containing block, we should say that in general, not just in the case you have a block-in-inline split.
16:29:40 [dbaron]
... but I don't think we should.
16:29:58 [dbaron]
16:30:20 [TabAtkins_]
dbaron: What I see in Gecko and Chrome is that the first line isn't offset, but the second one is.
16:31:36 [TabAtkins_]
tabatkins: So in the block-in-inline case, the block is the containing block for float?
16:31:39 [TabAtkins_]
dbaron: Yes.
16:31:56 [dbaron]
I'm also not sure if there's anything in the spec that says exactly what relative positioning affects...
16:32:24 [TabAtkins_]
tabatkins: That makes sense. I'd be fine with revising my proposal to say that floats move with their containing block. Then somehow making it clear that, in the block-in-inline case, the block is what moves with the inline's relpos, even though officially the inline is broken around the block.
16:33:41 [TabAtkins_]
sylvaing: In IE8 and IE9, both of them move 200px away from the edge.
16:33:51 [dethbakin]
dethbakin has joined #css
16:35:17 [TabAtkins_]
tabatkins: If IE is moving the float, I'm a bit scared to change it, just because I know that we authors count on floats doing really odd things.
16:36:40 [dbaron]
So I'd note that we should probably have a separate 2.1 issue on nothing in the spec saying which descendants of an element are affected by relative positioning.
16:38:27 [TabAtkins_]
tabatkins: So, I need to (a) change the proposal to make floats only care about their containing blocks getting relpos, (b) ensure that the block-in-inline case appropriately moves the block if the inline is relposed, and (c) build some confidence that this won't break IE.
16:38:55 [TabAtkins_]
tabatkins: My only solace is that Firefox does something substantially different, so as long as an author tests in both FF and IE they won't depend on this behavior.
16:39:04 [TabAtkins_]
bradk: Unless it somehow fixes a separate IE bug.
16:39:07 [TabAtkins_]
tabatkins: Right.
16:39:20 [TabAtkins_]
plinss_: IE guys, are you theoretically okay with this change?
16:39:45 [TabAtkins_]
sylvaing: It makes sense to me to make floats move with their containing blocks only, but I'd have to check with Alex to see what he thinks re: compat.
16:39:58 [TabAtkins_]
sylvaing: Alex is in Moscow right now, so we'll probably have to catch him on email.
16:40:28 [TabAtkins_]
ACTION Sylvain: Contact AlexMog to see if changing things for Issue 138 will hurt web compat for IE.
16:40:28 [trackbot]
Created ACTION-245 - Contact AlexMog to see if changing things for Issue 138 will hurt web compat for IE. [on Sylvain Galineau - due 2010-07-21].
16:40:56 [plinss_]
16:41:50 [TabAtkins_]
Same as last week, the proposal is linked on the wiki and just needs someone to review it for acceptability.
16:42:06 [TabAtkins_]
plinss_: Anyone reviewed it?
16:42:12 [TabAtkins_]
16:43:00 [TabAtkins_]
plinss_: Everyone, read the proposal for Issue 158, and we'll discuss it next week.
16:43:25 [plinss_]
16:44:17 [TabAtkins_]
tabatkins: I have not reviewed this yet, though I like how few changes there had to be.
16:45:20 [TabAtkins_]
tabatkins: Looks good at first blush, I just need about 10 minutes to read it in depth.
16:45:27 [plinss_]
16:45:35 [TabAtkins_]
plinss_: Good. Everyone take a look at it so we can quickly resolve on it next week.
16:47:00 [TabAtkins_]
tabatkins: Latest action on it is dbaron's feedback, but Zack hasn't responded to it yet. I think dbaron needs to poke Zack to respond.
16:47:03 [TabAtkins_]
dbaron: Ok.
16:47:57 [TabAtkins_]
plinss_: We also had a note to get better testcases on this. Are our testcases okay right now?
16:48:06 [TabAtkins_]
arronei: We have a couple. I'll look around and add them to the wiki.
16:48:51 [TabAtkins_]
plinss_: Would be good to get together an idea of what we're doing and what we want to do.
16:49:14 [plinss_]
16:50:03 [dbaron]
16:50:09 [TabAtkins_]
dbaron: I think this is a straightforward case of the prose disagreeing with the grammar, and everyone following the grammar.
16:50:58 [TabAtkins_]
dbaron: I checked Gecko and Chrome.
16:51:00 [smfr]
i confirm
16:51:37 [fantasai]
Opera and Konqueror match FF
16:52:16 [TabAtkins_]
arronei: IE and Opera show the testcase
16:52:21 [TabAtkins_]
bradk: Safari too.
16:52:46 [TabAtkins_]
RESOLVED: Accept dbaron's proposed change to resolve issue 174.
16:53:21 [fantasai]
If we're done with CSS2.1 issues, I'd like to propose adding the CSS Styling Attributes spec to the 2007 Snapshot
16:54:20 [fantasai]
Also, I'd like some guidance on what to do with that spec, since it's in LC, and all issues were addressed, but the SVGWG never confirmed whether they were happy with my responses.
16:54:23 [fantasai]
16:54:40 [TabAtkins_]
tabatkins: Did that one just describe reality, or was it the one that tried to allow scope and MQ and such inside of @style?
16:54:49 [fantasai]
Just describes reality
16:54:50 [fantasai]
no new features
16:54:55 [TabAtkins_]
kk, then I'm cool with i.
16:55:15 [fantasai]
otherwise I wouldn't suggest backporting it to 2007 :)
16:55:46 [TabAtkins_]
plinss_: I'm fine with it. Objections?
16:55:48 [TabAtkins_]
[no objections]
16:56:07 [TabAtkins_]
RESOLVED: Add CSS Styling Attributes spec to the 2007 snapshot
16:56:15 [plinss_]
16:56:31 [fantasai]
Second question then is, should we move to CR or action someone to pester the SVGWG again for a response?
16:56:53 [fantasai]
plinss, For the writing-mode question, I suggest waiting until end of September
16:57:07 [fantasai]
plinss, because I won't have time to work on it until then
16:57:14 [fantasai]
plinss, but I do intend to sync with SVG
16:57:26 [TabAtkins_]
fantasai, that's just an issue of whether to accept SVG's shorthands, right?
16:57:42 [TabAtkins_]
fantasai, since we don't want to drop our bt-* ones.
16:57:43 [fantasai]
it might be, it might mean other things
16:57:51 [fantasai]
right, we'd make a superset
16:58:04 [fantasai]
but there might be some changes to behavior also required
16:58:20 [shepazu]
[the SVG WG intends to match CSS for SVG 2]
16:58:54 [TabAtkins_]
plinss_: You okay with deferring this, Sylvain?
16:58:56 [shepazu]
[please let us know if there are changes to behavior, of course... but we're open to changes, if they make sense]
16:59:10 [TabAtkins_]
sylvaing: yeah.
16:59:25 [TabAtkins_]
shepazu, should we bug SVGWG more about Styling Attribute?
16:59:30 [Zakim]
16:59:33 [Zakim]
16:59:36 [Zakim]
16:59:37 [Zakim]
16:59:38 [Zakim]
16:59:39 [Zakim]
16:59:39 [Zakim]
16:59:49 [Zakim]
17:00:02 [shepazu]
TabAtkins_: what's the issue?
17:00:26 [TabAtkins_]
SVGWG never confirmed if they were okay with the resolutions to the CSS Styling Attributes spec LC issues.
17:00:58 [fantasai]
17:01:01 [fantasai]
issues list is there ^
17:04:39 [shepazu]
hmmm. I thought we'd resolved that... I think Chris has the ball. IF you would be so kind, write us another follow-up email about the remaining issues, and we will resolve on it for our next telcon
17:04:50 [shepazu]
and send a clear response
17:05:01 [Zakim]
disconnecting the lone participant, TabAtkins_, in Style_CSS FP()12:00PM
17:05:07 [Zakim]
Style_CSS FP()12:00PM has ended
17:05:08 [Zakim]
Attendees were +1.408.636.aaaa, smfr, +1.617.650.aabb, dethbakin, +1.858.216.aacc, plinss_, +1.206.324.aadd, +1.650.214.aaee, TabAtkins_, sylvaing, David_Baron, +1.650.275.aaff,
17:05:11 [Zakim]
... bradk, +, CesarAcebal, arronei
17:05:51 [fantasai]
shepazu: if you'd resolved that, then a reference to those minutes is all I'd need to mark the case closed
17:06:50 [shepazu]
right, but I don't know where that would be, off the top of my head... I don't feel confident speaking for the SVG WG here, because I don't recall what we decided
17:09:29 [fantasai]
ok, I have to go, but I'll follow up with that
17:09:55 [fantasai]
actions to me -- try to find SVGWG minutes discussing Styling Attributes spec, else email svgwg asking for response
17:10:04 [fantasai]
also, update the css2.1 issues list with the resolution above
17:10:06 [fantasai]
make the minutes
17:10:10 [fantasai]
and update the snapshot
17:10:50 [TabAtkins_]
later, fantasai
18:20:35 [sylvaing]
sylvaing has joined #css
18:20:59 [plinss_]
plinss_ has joined #css
18:29:49 [Zakim]
Zakim has left #CSS
18:32:45 [dbaron]
dbaron has joined #css
19:04:52 [dethbakin]
dethbakin has joined #css
19:05:05 [dethbakin]
dethbakin has left #css
19:48:54 [fantasai]
fantasai has joined #css
20:04:03 [nimbupani]
nimbupani has joined #css
20:59:42 [sylvaing]
sylvaing has joined #css
21:11:25 [dbaron]
dbaron has joined #css
23:20:29 [karl]
karl has joined #CSS