15:37:03 <RRSAgent> RRSAgent has joined #CSS
15:37:03 <RRSAgent> logging to http://www.w3.org/2010/07/07-CSS-irc
15:37:11 <plinss_> zakim, this will be style
15:37:11 <Zakim> ok, plinss_; I see Style_CSS FP()12:00PM scheduled to start in 23 minutes
15:37:19 <plinss_> rrsagent make logs public
15:37:32 <plinss_> rrsagent, make logs public
15:50:24 <sylvaing> sylvaing has joined #css
15:51:40 <bradk> bradk has joined #css
15:56:03 <Zakim> Style_CSS FP()12:00PM has now started
15:56:10 <Zakim> +dsinger
15:56:35 <oyvind> oyvind has joined #css
15:56:38 <dsinger> dsinger has joined #css
15:56:59 <dsinger> zakim, mute dsinger
15:56:59 <Zakim> sorry, dsinger, muting is not permitted when only one person is present
15:57:02 <Zakim> +[plinss]
15:57:29 <dsinger> zakim, mute dsinger
15:57:29 <Zakim> dsinger should now be muted
15:59:18 <dethbakin> dethbakin has joined #css
15:59:34 <dsinger> Zakim, who is here on time?
15:59:34 <Zakim> I don't understand your question, dsinger.
15:59:54 <dsinger> Zakim, who is here?
15:59:54 <Zakim> On the phone I see dsinger (muted), [plinss]
15:59:55 <Zakim> On IRC I see dethbakin, dsinger, oyvind, bradk, sylvaing, RRSAgent, Zakim, Curt`, miketaylr, darkangel, lhnz, karl, arronei, shepazu, Bert, krijn, fantasai, anne, plinss_, plinss,
15:59:57 <Zakim> ... trackbot, tabatkins, Hixie, jgraham
16:00:16 <Zakim> +[Microsoft]
16:00:23 <Zakim> +bradk
16:00:48 <Zakim> + +1.650.214.aaaa
16:01:11 <plinss_> zakim, aaaa is tabakins
16:01:13 <Zakim> +tabakins; got it
16:01:46 <Zakim> +[Apple]
16:01:55 <dethbakin> Zakim, Apple has dethbakin 
16:01:56 <Zakim> +dethbakin; got it
16:02:33 <Zakim> +smfr
16:02:39 <smfr> smfr has joined #css
16:02:39 <arron> arron has joined #css
16:02:46 <TabAtkins_> TabAtkins_ has joined #css
16:02:54 <smfr> Zakim, who's here
16:02:54 <Zakim> smfr, you need to end that query with '?'
16:02:58 <smfr> Zakim, who's here?
16:02:58 <Zakim> On the phone I see dsinger (muted), [plinss], [Microsoft], bradk, tabakins, [Apple], smfr
16:03:01 <Zakim> [Apple] has dethbakin
16:03:02 <Zakim> On IRC I see TabAtkins_, arron, smfr, dethbakin, dsinger, oyvind, bradk, sylvaing, RRSAgent, Zakim, Curt`, miketaylr, darkangel, lhnz, karl, arronei, shepazu, Bert, krijn,
16:03:04 <Zakim> ... fantasai, anne, plinss_, plinss, trackbot, tabatkins, Hixie, jgraham
16:03:10 <Zakim> +SteveZ
16:03:16 <TabAtkins_> ScribeNick: TabAtkins_
16:03:57 <bradk> If Z knew it was a query, why require a question mark?
16:04:06 <smfr> indeed
16:04:15 <Zakim> +sylvaing
16:04:33 <plinss_> z has very picky and somewhat pointless syntax
16:04:34 <smfr> also, why does the bridge need to tell me it's a customized computex something conferencing system every time I dial in?
16:04:45 <TabAtkins_> The bridge is very vain.
16:04:52 <szilles> szilles has joined #css
16:04:53 <Zakim> +Bert
16:06:14 <Zakim> -sylvaing
16:06:31 <Zakim> +sylvaing
16:06:40 <TabAtkins_> plinss_: Any new agenda items?
16:06:45 <TabAtkins_> plinss_: Seems like no.
16:06:51 <TabAtkins_> plinss_: Test suite updates?
16:07:18 <fantasai> I am not able to call in
16:08:12 <TabAtkins_> TabAtkins_: I was able to get a contractor hired to help out elika with reviewing tests.
16:08:19 <TabAtkins_> plinss_: Okay, open issues.
16:08:25 <TabAtkins_> plinss_: 53 is still open
16:08:25 <plinss_> http://wiki.csswg.org/spec/css2.1#issue-53
16:08:34 <arronei> I'm only on IRC today. But on my end I am getting a list of test cases that are invalid.
16:08:45 <arronei> I will send out that list by the end of the week.
16:09:07 <TabAtkins_> plinss_: Daniel was getting feedback from Thunderbird people, I believe he did.
16:09:26 <TabAtkins_> plinss_: They said they were okay with ignoring justification in preformatted text, I believe.
16:09:53 <fantasai> I'm not ok with ignoring justification
16:10:05 <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Jul/0055.html
16:11:14 <TabAtkins_> Elika's suggestion is that we respect justification everywhere (even preformatted), but not on lines that end in a hard wrap.
16:11:28 <TabAtkins_> TabAtkins_: Bonus of that is that it's a pretty nice simplification.
16:12:12 <TabAtkins_> bradk: Elika's suggestion makes sense.
16:12:42 <TabAtkins_> plinss_: But if you're preformatted, differing numbers of spaces may not be the proper width anymore.
16:12:59 <fantasai> Because that's what you asked for
16:13:04 <fantasai> you asked for preformatted, not monospace
16:13:14 <fantasai> you didn't ask for grid layout
16:13:28 <fantasai> you asked to preserve whitespace and to justify
16:13:40 <fantasai> if you didn't mean justify, then don't ask for it
16:15:06 <TabAtkins_> plinss_: My concern is that justification is inherited, so the justification might come up from further in the chian.
16:15:26 <TabAtkins_> bradk: What about word-spacing?  Different fonts are formatting too.
16:15:36 <fantasai> Then add pre { text-align: initial; } to the defualt UA style sheet
16:15:57 <dsinger> dsinger has joined #css
16:16:10 <Zakim> +[Apple.a]
16:16:21 <dsinger> zakim, [Apple] has dsinger
16:16:21 <Zakim> +dsinger; got it
16:16:24 <TabAtkins_> plinss_: word-spacing applies to every character individually, so I think that's okay.
16:16:38 <Zakim> -dsinger
16:16:42 <fantasai> no it doesn't it only applies to spaces
16:16:53 <TabAtkins_> TabAtkins_: I don't think that distinction is justified.  You can use fonts with varying ratios of character to space widths in pre text, and get all sorts of differing renderings.
16:16:54 <fantasai> letter-spacing applies to every grapheme cluster individually
16:17:25 <fantasai> word-spacing only applies to spaces
16:18:13 <TabAtkins_> szilles: So the question is what properties should apply in pre text?
16:18:17 <TabAtkins_> TabAtkins_: I think they all should.
16:19:24 <matiassingers> matiassingers has joined #CSS
16:20:24 <fantasai> pre should mean "preserve white space", not "turn off random features to more closely approximate plaintext sans formatting"
16:20:27 <fantasai> imo
16:20:39 <TabAtkins_> Bert: Justification can move linebreaks around, which isn't compatible with preformatted text.
16:20:51 <fantasai> Bert: how can it move linebreaks around?
16:20:58 <TabAtkins_> TabAtkins_: Elika's suggestion is to only justify soft-wrapped lines.  A preformatted text block with only hard breaks won't justify.
16:21:04 <fantasai> Bert, justification happens *after* linebreaking
16:22:01 <TabAtkins_> plinss_: So we've talked about this for a while.  Anyone being convinced?
16:22:06 <fantasai> Ok, true, but if you're soft-wrapping, you're already handing over line-breaking to the layout engine anyway
16:22:22 <fantasai> hard line breaks don't move
16:22:36 <Bert> (Fantasai, if you are allowed to stretch/compress word spaces, you may want to chose your line breaks such that adjoining lines both stretch or both shrink. TeX does that. Also to avoid "rivers" of white.)
16:23:12 <TabAtkins_> TabAtkins_: I like Elika's suggestion.  It seems to respect the restrictions of preformatted text while still letting authors do things complex if they want.
16:23:18 <fantasai> (Bert, that's cool, but as I said, hard line breaks don't move, and soft ones are UA-determined anyway)
16:23:59 <fantasai> (The UA may choose breaks to reduce the raggedness of a ragged edge, too, for example)
16:24:11 <TabAtkins_> plinss_: I guess I'm okay with it.  I'm slightly concerned if this changes anything in existing preformatted text.
16:24:17 <fantasai> (In which case a different UA with the same fonts and containing block width won't give the same soft breaks)
16:24:30 <fantasai> peter, then I recommend to add the pre rule to the default UA stylesheet
16:24:30 <Bert> (Yes, and so I agree with your proposal. :-) )
16:24:46 <nimbupani> nimbupani has joined #css
16:24:48 <fantasai> peter, because most pre text in the wild is probably in <pre> elements
16:24:58 <TabAtkins_> smfr: Webkit doesn't do text-align:start in <pre> by default.
16:26:01 <TabAtkins_> szilles: Can someone make some tests and find out what is actually used?  Because there might be a lot of files out there that depend on the current behavior (e.g. no justification in preformatted text).
16:26:30 <jSepia> jSepia has joined #css
16:26:32 <jSepia> jSepia has left #css
16:26:32 <fantasai> szilles: preformatted text does not wrap
16:26:45 <fantasai> szilles: it's only pre-wrap that you'd have to check
16:32:12 <TabAtkins_> szilles: Since hittin pre-wrap is such an edge case any way, I don't know if it's worth making it act weird with justification.
16:33:50 <TabAtkins_> [discussion about letter-spacing, and whether or not it preserves formatting - it only does so in monospace text]
16:34:30 <TabAtkins_> bradk: If we punt, there's a chance we could be locked in by implimentations.
16:35:30 <TabAtkins_> plinss_: Thunderbird was "okay" with preventing justification in pre-wrap text (which they use in composing mail messages).
16:36:03 <TabAtkins_> plinss_: I like Elika's proposal, I just don't know if we want to bring up a new behavior for 2.1.
16:36:57 <TabAtkins_> szilles: The way we usually fix these is to spec what is done today, and later come up with a new value for the new behavior if we still want it.
16:37:06 <fantasai> What's done today doesn't match the spec anyway
16:37:16 <fantasai> Also, if we lock ourselves in here, the author has no control
16:37:35 <fantasai> szilles, What new control do you want to introduce in CSS3? text-align: justify-no-I-really-mean-it?
16:38:23 <szilles> Elika, no I would introduce a "pre-wrap-justify" value
16:38:35 <TabAtkins_> plinss_: Maybe someone could write up a matrix of a text-align, whitespace, and point out where we've got gaps in either the spec or reality?
16:38:50 <TabAtkins_> s/plinss_/dsinger/
16:38:53 <dsinger> that was me
16:38:53 <fantasai> szilles: That's ridiculous. It mixes up white-space with text-alignment and justification in addition to it's already mixed up text-wrap and ws-collapse behavior.
16:38:59 <TabAtkins_> TabAtkins_: I can do that.
16:39:12 <fantasai> szilles: We coudl define different behavior for values of text-justify
16:39:24 <fantasai> szilles: auto means pre doesn't justify, anything else means it does
16:39:25 <TabAtkins_> plinss_: Next is 101 on dbaron, he's not here.
16:39:49 <plinss_> http://wiki.csswg.org/spec/css2.1#issue-110
16:40:00 <bradk> \me deferring to mailing list for pre issue
16:40:17 <bradk> doh
16:42:23 <szilles> Elicka, I would agree that your argument about justify and pre-wrap makes sense. My argument is that, currently, this is so much an edge case that requiring changes in all implementations is not reasonable at this time and could inhibit getting out of CR. 
16:42:26 <TabAtkins_> http://lists.w3.org/Archives/Public/www-style/2010May/0483.html
16:42:52 <TabAtkins_> TabAtkins_: After talking with Elika, I'm happy with presenting my last proposal to the list, from May. ^^^
16:43:07 <TabAtkins_> TabAtkins_: Module the minor changes suggested by Brad and Peter Moulder in the immediate responses.
16:43:12 <darkangel> fantasai: Thanks for your response. I just don't like the idea that different vendors may implement the transition differently, leading to inconsistent appearance. That, and the current implementation is rather ugly. Is it technically difficult to render a gradient in this position? Say for example, a linear diagonal gradient from the one end of the arc to the other?
16:44:07 <fantasai> darkangel: you really don't want a linear gradient. You want a conical one. And that's apparently hard to get in current APIs
16:44:39 <TabAtkins_> TabAtkins_: i think boris is the only implementor who has given the issue 110 proposal serious feedback so far, so anyone else who would be working on table-stuff that could look at it would be great.
16:45:07 <plinss_> http://wiki.csswg.org/spec/css2.1#issue-138
16:45:35 <TabAtkins_> plinss_: Anyone reviewed this?
16:45:48 <Zakim> -smfr
16:46:13 <Zakim> +smfr
16:49:48 <TabAtkins_> TabAtkins_: Summary is that floats will follow the relpos of their parent, even if their parent is an inline that is officially broken around it.
16:50:09 <TabAtkins_> szilles: I'm somewhat concerned about floats being treated as part of the content as a general principle.
16:50:38 <fantasai> What does 'opacity' do?
16:50:41 <TabAtkins_> szilles: That is, what about things like footnotes?
16:50:51 <fantasai> If 'opacity' affects the float, then I think relpos should also affect the float
16:50:58 <fantasai> They're both filtery effects
16:51:14 <fantasai> graphical transformations, whatever
16:53:48 <TabAtkins_> TabAtkins_: Floats are a weird half-space, where they are out-of-flow for some things and in-flow for some things.  It's a different space entirely from abspos and footnotes, which move completely independently of the "surrounding content".
16:53:56 <TabAtkins_> plinss_: Who has to change for this?
16:54:14 <TabAtkins_> TabAtkins_: IE8 appears to use the suggested behavior.  Gecko is close.  Opera and Webkit are substantially different.
16:54:25 <TabAtkins_> TabAtkins_: I'll bug Hyatt and try to bug Opera people about the feasability of this today.
16:54:40 <plinss_> http://wiki.csswg.org/spec/css2.1#issue-140
16:54:56 <TabAtkins_> Bert: I haven't managed to do #140 yet.
16:55:06 <TabAtkins_> Bert: Next week seems possible.
16:56:02 <TabAtkins_> http://wiki.csswg.org/spec/css2.1#issue-140
16:56:22 <TabAtkins_> http://wiki.csswg.org/spec/css2.1#issue-142
16:56:42 <TabAtkins_> Bert: Same thing.  But I think maybe Elika was supposed to do this one?  I can't remember if it was this one or another that she said she would do.
16:57:27 <TabAtkins_> plinss_: 158, I don't think we'll do that in 4 minutes.
16:57:41 <fantasai> Bert, I'm doing 120 for you
16:57:43 <TabAtkins_> TabAtkins_: Plus, there was a *lot* of feedback on that over the weekend which I haven't been able to process yet.
16:57:46 <plinss_> http://wiki.csswg.org/spec/css2.1#issue-167
17:00:04 <TabAtkins_> [summary of the proposal]
17:00:48 <dsinger> dsinger has left #css
17:01:06 <dsinger> dsinger has joined #css
17:02:01 <TabAtkins_> plinss_: Any testcases on what implementations do on this one?
17:03:17 <Zakim> -sylvaing
17:03:49 <Zakim> -[Microsoft]
17:03:51 <Zakim> -smfr
17:03:57 <Zakim> -[Apple]
17:03:58 <Zakim> -[plinss]
17:03:58 <Zakim> -tabakins
17:04:02 <Zakim> -SteveZ
17:04:03 <Zakim> -[Apple.a]
17:04:07 <Zakim> -bradk
17:04:09 <Zakim> -Bert
17:04:10 <Zakim> Style_CSS FP()12:00PM has ended
17:04:13 <Zakim> Attendees were dsinger, [plinss], [Microsoft], bradk, +1.650.214.aaaa, tabakins, dethbakin, smfr, SteveZ, sylvaing, Bert, [Apple]
17:05:04 <dethbakin> dethbakin has left #css
17:51:25 <darkangel> fantasai: A diagonal linear gradient looks pretty good (mockup in Photoshop) – why not use it, at least until the graphics libraries are improved?
18:19:48 <arron> arron has joined #css
18:21:24 <smfr> smfr has joined #css
18:21:43 <smfr> can anyone point me to the css wg's bugzilla?
18:47:02 <Zakim> Zakim has left #CSS
20:40:36 <arron> arron has joined #css
21:04:53 <fantasai> tabatkins: Did you want to track flexbox issues in Tracker or the wiki? 'Cuz Alex seems to be very interested in sorting that out, and it's probably a good idea now that you're actively working on the spec
21:05:55 <tabatkins> I have no idea how to use the Tracker, but I do know how to use the wiki.  So, based solely on that, wiki.
21:09:39 <fantasai> Tracker is pretty straightforward. If you look around, I'm sure you can figure it out. Its main advantages are integration with IRC and the mailing lists. It's main disadvantages are sub-optimal web interface and only editable by WG members.
21:14:09 <fantasai> Another advantage is a better archiving story: issues each have their own page, so the URL is stable even when they're purged from the currently active list
21:15:20 <fantasai> I think I tend to use Tracker for pre-LCWD issues
21:16:47 <fantasai> for that very reason. They let me focus on what's open and ignore what's closed
21:17:14 <fantasai> But for LC comments, I track those in a plaintext file, since I want the whole list, open and closed, available.
21:22:59 <nimbupani> nimbupani has joined #css
22:04:21 <tabatkins> fantasai: Sorry, I have this room set to not ping me unless my name is mentioned, so I didn't realize you'd said more.  ^_^  Tracker's fine, then.