/irc-logs / w3c / #css / 2010-11-01 / end

Options:

# Session Start: Mon Nov 01 00:00:00 2010
# Session Ident: #css
# [00:16] * Quits: anne (annevk@80.14.101.159) (Quit: anne)
# [00:22] * Quits: arron (Arron@24.17.123.244) (Quit: arron)
# [00:38] * Joins: shepazu (schepers@128.30.52.169)
# [01:45] * Quits: TabAtkinsTPAC (chatzilla@212.180.75.100) (Ping timeout)
# [03:25] * Joins: nimbupani (nimbupani@24.22.131.46)
# [04:57] * Joins: MURATA (makoto@110.4.213.2)
# [04:59] * Joins: arron (Arron@24.17.123.244)
# [05:05] * Quits: arron (Arron@24.17.123.244) (Quit: arron)
# [05:42] * Joins: arron (Arron@24.17.123.244)
# [05:44] * Quits: arron (Arron@24.17.123.244) (Quit: arron)
# [05:47] * Joins: arron (Arron@24.17.123.244)
# [05:57] * Quits: arron (Arron@24.17.123.244) (Quit: arron)
# [06:42] * Quits: shepazu (schepers@128.30.52.169) (Ping timeout)
# [07:09] * Quits: nimbupani (nimbupani@24.22.131.46) (Quit: nimbupani)
# [07:31] * Quits: kennyluck (kennyluck@128.30.52.28) (Quit: kennyluck)
# [07:49] * Joins: TabAtkinsTPAC (chatzilla@212.180.75.100)
# [08:19] * Joins: TabAtkinsTPAC_ (chatzilla@212.180.75.100)
# [08:19] * Quits: TabAtkinsTPAC (chatzilla@212.180.75.100) (Connection reset by peer)
# [08:20] * TabAtkinsTPAC_ is now known as TabAtkinsTPAC
# [08:20] * Quits: timeless_mbp (timeless@81.255.204.171) (Quit: Leaving.)
# [08:35] * Quits: TabAtkinsTPAC (chatzilla@212.180.75.100) (Ping timeout)
# [08:35] * Joins: sylvaing (sylvaing@84.14.50.82)
# [08:44] * Joins: myakura (myakura@84.14.50.82)
# [08:44] * Joins: mgylling (mgylling@84.14.50.82)
# [08:54] * Joins: plinss_ (plinss@84.14.50.82)
# [08:55] * Joins: kojiishi (kojiishi@222.158.227.129)
# [08:56] * myakura yawns
# [08:56] * Joins: johnjan (qw3birc@128.30.52.28)
# [08:57] * Joins: dsinger (dsinger@84.14.50.82)
# [08:57] * Joins: glazou (glazou@84.14.50.82)
# [08:57] * dsinger gooooood morning
# [08:58] * Joins: dbaron (dbaron@63.245.220.11)
# [08:58] <sylvaing> http://wiki.csswg.org/planning/tpac-2010
# [09:00] * Joins: mjs (mjs@84.14.50.82)
# [09:00] * Joins: mmielke (mmielke@84.14.50.82)
# [09:03] * Joins: jun (jun@84.14.50.82)
# [09:04] * Joins: jdaggett (jdaggett@84.14.50.82)
# [09:06] * Joins: tabatkins (tabatkins@84.14.50.82)
# [09:06] <tabatkins> ScribeNick: tabatkins
# [09:07] <tabatkins> glazou: First agenda is the agenda.
# [09:07] * Joins: RRSAgent (rrs-loggee@128.30.52.169)
# [09:07] <RRSAgent> logging to http://www.w3.org/2010/11/01-CSS-irc
# [09:07] * Joins: Zakim (rrs-bridgg@128.30.52.169)
# [09:08] * Joins: alexmog (qw3birc@128.30.52.28)
# [09:08] <plinss_> rrsagent, make logs public
# [09:08] <RRSAgent> I have made the request, plinss_
# [09:08] <glazou> http://wiki.csswg.org/planning/tpac-2010
# [09:08] <tabatkins> glazou: What's mos timportant? I think we need clilley for the charter discussion.
# [09:09] <tabatkins> jdaggett: Two things I want to discuss tomorrow are Fonts and Writing Modes.
# [09:09] <tabatkins> sylvaing: We'd like to do Grid first thing tomorrow morning.
# [09:09] <tabatkins> Bert: We have a guest who wants to talk about Writing Modes, and Mike.
# [09:10] <tabatkins> glazou: Microsoft guys, wanna talk about Flexbox before Grid?
# [09:10] <tabatkins> sylvaing: Not that important, just want to talk about both.
# [09:10] <tabatkins> glazou: We can probably start this morning with css3 values.
# [09:11] * Joins: kennyluck (kennyluck@128.30.52.28)
# [09:13] <tabatkins> glazou: FXTF wants to take ownership of 2d transforms. But I want the WG to talk about it too, even if only for a little bit.
# [09:14] <tabatkins> glazou: Marcus Gelling is here, so can we talk about EPUB liaison stuff later this morning?
# [09:14] <tabatkins> Marcus Gelling: Yes.
# [09:14] <tabatkins> glazou: Slow font downloading, should it be lumped with CSS3 Fonts?
# [09:14] * Joins: anne (annevk@84.14.50.82)
# [09:14] <tabatkins> jdaggett: Yes, and hopefully Tues afternoon, because Slye will be here then.
# [09:17] <tabatkins> Attending: Soonbo Han, Tab Atkins, Markus Mielke, Peter Linss, Anne van Kesteren, David Singer, Bert Bos, John Daggett, David Baron, Alex Mogilevsky, Koji Ishii, Sylvain Galineau, John Jansen, Daniel Glazman, Steve Zilles
# [09:18] * Joins: kohei (koheiyamam@124.39.135.110)
# [09:18] <tabatkins> glazou: So I suggest we start with 2d transforms, epub, and css2.1 testing this morning.
# [09:18] * Joins: anthony (qw3birc@128.30.52.28)
# [09:19] <tabatkins> glazou: We now have 4 impls on the table: gecko, webkit, opera, and ms.
# [09:19] * Joins: sbhan (qw3birc@128.30.52.28)
# [09:19] * Quits: kohei (koheiyamam@124.39.135.110) (Quit: Leaving...)
# [09:19] <tabatkins> glazou: We need tests. If we have interop impls - I suppose we have a fairly good level of interop - I think we can move pretty quickly to REC.
# [09:20] <tabatkins> sylvaing: We have some things that need to be resolved, like the DOM interface relying on some obsolete stuff.
# [09:20] * Joins: kohei (koheiyamam@124.39.135.110)
# [09:20] <tabatkins> sylvaing: No one but Webkit implements it yet, I think.
# [09:20] <tabatkins> anne: Maybe we should drop it for now until we figure out what we want to do with the Values APIs.
# [09:20] <tabatkins> glazou: I think marking as at-risk would be better.
# [09:21] <tabatkins> dbaron: The section on Transitions has several bugs in the spec. XXX sent feedback explaining several of them, and you can see these bugs in Webkit.
# [09:21] <tabatkins> s/XXX/bzbarsky/
# [09:22] <sylvaing> CSS3 2D Transforms transition/animation section: http://www.w3.org/TR/css3-2d-transforms/#animation
# [09:22] <tabatkins> dbaron: The other issue is transforms that affect layout.
# [09:22] <tabatkins> dbaron: I could see getting a first version to REC without that, but I'd rather fix it first.
# [09:22] <tabatkins> jdaggett: Isn't that a big issue?
# [09:22] <tabatkins> dbaron: Not necessarily.
# [09:23] <tabatkins> dbaron: Some big things, but some small things.
# [09:23] <tabatkins> sylvaing: That affects things like offsetTop, etc.
# [09:23] <tabatkins> dbaron: Right, but they kind of suck without a layout-effecting transform anyway.
# [09:24] <tabatkins> sylvaing: It would definitely lengthen the time it would take to get to CR.
# [09:25] <tabatkins> dbaron: Yeah, I think it does make sense to move it to CR first without this.
# [09:25] * Joins: anthony_work (qw3birc@128.30.52.28)
# [09:25] <tabatkins> szilles: I drafted a spec for the layout-affecting Transforms 2 or 3 years ago. It's not bug-free, but it exists - we won't be starting from scratch.
# [09:25] <tabatkins> anne: The concern is that nobody's tried to ipmlement it yet.
# [09:26] * Joins: murakami (murakami@118.154.209.3)
# [09:26] <tabatkins> anne: I think that Transforms should redefine the boxes that already exist when transformed; the border box should get bigger, etc.
# [09:27] <tabatkins> anne: So I don't have to constantly reference Transforms when talking about boxes.
# [09:27] <tabatkins> dbaron: You've got 3 or 4 boxes now. 1) Element in its original coord space. 2) Element in the transformed coord space. 3) Rectangle containing the 1st in the 2nd coord space, 4) Rectangle containing the 2nd in the 1st coord space.
# [09:28] <tabatkins> anne: I think browsers act like the transform didn't happen for now.
# [09:28] <tabatkins> anne: Which works for me - if the border box doesn't change, and only alters for painting, that's easy.
# [09:29] <tabatkins> anne: At some point Dean asked me to draft an api that was aware of transforms, but I wasn't sure how to do it.
# [09:29] <tabatkins> sylvaing: We have 4 impls, is what we have enough for authors? Are we missing use-cases?
# [09:29] <tabatkins> dbaron: I think we're definitely missing use-cases, but I think we're still okay to move forward.
# [09:30] <dbaron> s/bzbarsky/bzbarsky forwarded a message from Tim Terriberry/
# [09:30] <tabatkins> glazou: I'd like to talk about canonicalization of the computed value. When you query a transform, I think all browsers respond with a matrix, which is totally unuseful for authors. Is there something we could do to ease this pain?
# [09:31] <tabatkins> anne: I think that, as a string value, having the matrix is fine and the most sane. But I think when people start prototyping the Values API, we'll get a dedicated api for transforms.
# [09:31] * Joins: homata_ (homata@84.14.50.82)
# [09:32] <tabatkins> jdaggett: Once you compose several operations, the matrix loses the state. You can't get the compounded effects anymore. So, glazou, what do you want?
# [09:32] <tabatkins> glazou: For example, if you have a rotation and want to rotate it a bit further, it's a huge pain.
# [09:32] <tabatkins> sylvaing: You can do that now through the matrix api, but it uses CSSValue, which we're not going to implement.
# [09:33] * Joins: timeless_mbp (timeless@84.14.50.82)
# [09:33] <tabatkins> jdaggett: Like, if you do a rotate, transform, rotate, you lose something. What do you want to show to authors?
# [09:33] <tabatkins> glazou: The three operations, hopefully - a stack.
# [09:33] <tabatkins> dbaron: We have to store that information and pass it through anyway to do the transforms.
# [09:34] <tabatkins> s/transforms/transitions/
# [09:34] <tabatkins> glazou: I feel that as a web author, releasing this without having a way to get the scale/rotate/etc of the transform is bad.
# [09:35] <tabatkins> dbaron: Do you really need it at the computed level? Is specified enough? You already have it on the specified level.
# [09:35] <tabatkins> glazou: Yes, but it's a string that you have to parse, which is unacceptable.
# [09:36] <tabatkins> tabatkins: So make Anne work on the Values API faster. ^_^
# [09:36] <tabatkins> szilles: What does SVG do? Also, is the matrix decomposition unique?
# [09:36] <tabatkins> dbaron: There's a reference to an algorithm for a unique decomposition, but it's buggy (I raised this earlier).
# [09:36] * Joins: Ibrahima (qw3birc@128.30.52.28)
# [09:37] <tabatkins> dbaron: I think that authors want back the order they originally specified, though, rather than some canonical transform.
# [09:37] * Quits: Martijnc (Martijnc@91.176.10.131) (Ping timeout)
# [09:38] <anne> tabatkins, the last on that is that people should start experimenting
# [09:38] <tabatkins> sylvaing: Also, SVG can do each transform from a different origin, while CSS does the whole thing from a single origin.
# [09:39] <tabatkins> Anthony (SVG): Doesn't look like SVG has a neat way of getting back the original transforms either.
# [09:39] <tabatkins> glazou: Sounds like something we can discuss in the FXTF meeting.
# [09:41] * Joins: Klaus (Klaus@128.30.52.169)
# [09:41] <tabatkins> RESOLVED: Discuss an API to parse the specified value into an author-convenient form, before pushing the spec forward.
# [09:41] <tabatkins> glazou: Next, tests. What kind of tests do we need for Transforms, who will write them, what schedule?
# [09:42] <tabatkins> glazou: Corollary - do we have enough interop that we can remove prefixes?
# [09:42] <tabatkins> dsinger: If Transitions is going to move slower than Transforms, we should move the section on Transitioning Transforms to the Transitions spec.
# [09:43] <tabatkins> anne: Can we require that this testsuite only has reftests?
# [09:43] <tabatkins> johnjan: No, we can't require it.
# [09:43] <tabatkins> anne: Why not?
# [09:43] * Joins: Martijnc (Martijnc@91.176.19.240)
# [09:44] <tabatkins> tabatkins: Can we resolve that everything that *can* be reftests, *must* be reftests?
# [09:44] <tabatkins> johnjan: Yeah, that's acceptable.
# [09:44] * timeless_mbp is now known as timeless
# [09:45] <tabatkins> dbaron: We have 107 reftests for Transforms. I'd need to ensure they're all test-suite worthy.
# [09:45] <tabatkins> glazou: We'd probably need a lead on the 2d testsuite.
# [09:46] <tabatkins> johnjan: I can do that.
# [09:46] * Quits: anne (annevk@84.14.50.82) (Quit: anne)
# [09:46] <dbaron> (also a bunch of parsing tests)
# [09:47] <tabatkins> glazou: dbaron, can you estimate how many tests we might need for the Transforms spec?
# [09:47] <tabatkins> johnjan: My gut says a few hundred. Right now we have far too few, at least. I'd like to look at SVG and Moz testcases and see how we interop.
# [09:48] <anthony> SVG test suite is here: http://dev.w3.org/cvsweb/SVG/profiles/1.1F2/test/svg/?sortby=file#dirlist
# [09:48] <fantasai> RESOLVED: Any Transforms tests that can be reftests must be reftests.
# [09:48] * Joins: anne (annevk@84.14.50.82)
# [09:48] <tabatkins> dbaron: Also, a whole lot of our Transforms tests are in our Transitions tests now, because I wrote a whole lot of tests about transitioning transforms.
# [09:49] <anthony> Transforms tests specifically: coords-transformattr-01-f.svg - coords-transformattr-05-f.svg and coords-trans-01-b.svg - coords-trans-14-f.svg
# [09:50] <tabatkins> glazou: 4 impls signals that impls are very interested in this. If we can move fast on this it would be a good signal to the w3c.
# [09:50] <tabatkins> glazou: So, maybe a CR/PR by June would be awesome.
# [09:52] <tabatkins> glazou: Are there immediate actions we can take on the spec, like removing the Transition section, mark layout as at-risk, remove the value api?
# [09:52] * Quits: timeless (timeless@84.14.50.82) (Client exited)
# [09:52] <tabatkins> RESOLVED: Remove the value API from 2d Transforms.
# [09:53] <tabatkins> shepazu: Once you've transformed, getting a point back is no longer in screen space, and there's some tricky transforms you need to do.
# [09:53] <tabatkins> shepazu: So people are going to get a point, expect it to be in one place, and it's not there.
# [09:54] <tabatkins> shepazu: It's a tricky solution but that can be exposed simply for authors.
# [09:54] * Joins: timeless_mbp (timeless@84.14.50.82)
# [09:54] <tabatkins> shepazu: smfr already has a very good idea of what's evolved there, and he'll add it to the 2d transforms spec.
# [09:55] <tabatkins> glazou: More agenda!
# [09:56] <tabatkins> glazou: howcome, we have some things for you.
# [09:56] <tabatkins> howcome: 15 minutes each, they're all easy. ^_^
# [09:56] * Joins: mielke (mmielke@84.14.50.82)
# [09:56] <tabatkins> glazou: today, beginning of afternoon?
# [09:56] <tabatkins> howcome: Yeah.
# [09:57] * Quits: mielke (mmielke@84.14.50.82) (Connection reset by peer)
# [09:57] * Quits: mmielke (mmielke@84.14.50.82) (Connection reset by peer)
# [09:57] * Joins: mmielke (mmielke@84.14.50.82)
# [09:58] <tabatkins> Gylling: I'm the AC rep of the DAISY consortium, but here today for EPUB and the IPDF.
# [09:58] <dsinger> s/Marcus Gelling/Markus Gyllling/
# [09:58] <dbaron> s/Marcus Gelling/Markus Gylling/g
# [09:58] <tabatkins> gylling: This isn't really intended to be a primer for epub, so let's move quickly through that.
# [09:58] <dbaron> s/Markus Gyllling/Markus Gylling/g
# [09:59] <tabatkins> gylling: In the current revision of epub, we have adobe, apple, google, and other organizations working with us.
# [09:59] <tabatkins> gylling: What makes epub stand out in the ebook wars is that epub uses w3c standards as the highest priority.
# [09:59] <tabatkins> gylling: epub is currently undergoing a revision; version 2 has been out for several years, and the new one started this year. We'd like to have the new one out by May 2011.
# [10:00] <tabatkins> jdaggett: What does that mean? Final spec, or impls?
# [10:00] <tabatkins> gylling: Final spec. The ipdf bylaws do not echo the w3c in requiring 2 independent impls.
# [10:00] <tabatkins> gylling: Of course, as we use existing web techs, generally there were already sufficient impls by the time we used something.
# [10:00] <tabatkins> gylling: But the situation is becoming somewhat more tricky now.
# [10:00] <tabatkins> gylling: bert, you sent a few questions earlier?
# [10:01] <tabatkins> Bert: Last time we talked about epub, we tried to discover which documents on the epub wiki were important; which dates, what schedule, etc should we look at?
# [10:01] * Joins: tantek (tantek@70.36.139.128)
# [10:02] <mgylling> http://code.google.com/p/epub-revision/wiki/ImplementationPipeline
# [10:02] <tabatkins> gylling: This is the current schedule.
# [10:02] <tantek> greetings from SF.
# [10:02] <tantek> sorry I couldn't be there in person!
# [10:02] <tabatkins> gylling: So we started out this summer collecting requirements. it was an open-ended process initially.
# [10:03] * Joins: szilles (chatzilla@84.14.50.82)
# [10:03] <tabatkins> gylling: In our SF meeting two weeks ago, we deferred/postponed a large number of our requirements.
# [10:03] <tabatkins> gylling: So we now have a smaller set of requirements that can be reviewed.
# [10:03] <tabatkins> gylling: This is what the epub wg has set out to have done by May next year.
# [10:03] <tabatkins> gylling: There are a few outstanding items, that we'll talk about tomorrow.
# [10:04] <tabatkins> gylling: But one of th emajor things we intend to do in this revision is to increase ou support for i18n.
# [10:04] <tabatkins> gylling: Writing Modes is one of th emost critical features for us right now in epub.
# [10:04] * Joins: jypark (qw3birc@128.30.52.28)
# [10:05] <tabatkins> gylling: The ipdf bylaws enumerates the process to use. Right now the ipdf doens't have an established rule that ther emust be two independent implementations of each feature.
# [10:05] * Quits: Klaus (Klaus@128.30.52.169) (Ping timeout)
# [10:05] <tabatkins> gylling: Inverting the question, though, would an implementation in an ebook device suffice to satisfy the w3c requirements?
# [10:06] <tabatkins> Bert: That's what I was trying to get at. Are your results public?
# [10:06] <tabatkins> gylling: If we can submit test results based on ebook devices, there's not a bunch of problem.
# [10:07] <tabatkins> jdaggett: There's a bit of dependency problem, where there are some drafts that haven't even reached first public draft yet. It seems like that would cause some problems fo ryou guys.
# [10:07] <dbaron> http://dbaron.org/css/test/2010/transition-negative-determinant is a testcase showing some of the issues with animation of transforms, and http://lists.w3.org/Archives/Public/www-style/2010Oct/0440.html is the post by Tim Terriberry suggesting an approach to fix that
# [10:07] * sylvaing Billy Idol just entered the room. Or Mike Smith.
# [10:07] <tabatkins> fantasai: I'm trying to stabilize the specs as fast as possible.
# [10:07] <tabatkins> fantasai: If we cannot come to any conclusion on the logical directions issue, we can just not deal with it and do it later, though I'd not like to.
# [10:08] <tabatkins> jdaggett: I just don't believe we should be making any kind of promise until there is some kind of consensus in this group.
# [10:08] <tabatkins> howcome: There seems to be some kind of consensus that epub has accepted the alternate stylesheet approach.
# [10:08] <tabatkins> fantasai: Right. I think epub is clear that Writing Modes is unclear until after TPAC.
# [10:09] <tabatkins> szilles: We shouldn't be having a discussion about what we'll do after a discussion until after the discussion.
# [10:09] * Joins: MoZ (540e3252@128.30.52.43)
# [10:09] <tabatkins> howcome: If I'm right, you're aiming for a per-document writing-mode switch, right?
# [10:10] <tabatkins> fantasai: Right, though you'll have some form of mixed content.
# [10:10] <tabatkins> fantasai: In terms of being able to switch the entire stylesheet, epub has accepted the alternate stylesheet mechanism.
# [10:11] <tabatkins> fantasai: Also, epub has their own way of handling unsupported features, so fallback isn't something we have to address *for epub*. CSS should address that for themselves, but we don't have to worry about that as much.
# [10:11] <tabatkins> howcome: CSS now has a way to do running headers and footers. Will epub adopt that as well?
# [10:11] <dbaron> But how we want implementations that don't support something to handle it is often fundamental to the design rather than something you tack on at the end.
# [10:12] <tabatkins> gylling: Our rendering stuff is generally going to be replaced by references to css 2.1. We haven't discussed running headers and footers yet, but expect that we'll be able to refer to the CSS spec.
# [10:12] <tabatkins> Bert: How does your collab/discussion process work?
# [10:12] <tabatkins> Bert: If we have a question, how do we send it?
# [10:12] <tabatkins> gylling: I think the easiest is to set up a liaison.
# [10:13] <tabatkins> gylling: They would participate in our weekly telcons and our mailing list, which is public.
# [10:13] * Joins: shepazu (schepers@128.30.52.169)
# [10:14] <tabatkins> jdaggett: The way epub is set up, different "working groups" handle different areas. One handles i18n, another handles styling, etc.
# [10:14] <tabatkins> jdaggett: I think there's a minor dependency on CSS3 Speech?
# [10:14] <tabatkins> gylling: Right - i18n and css aren't the only thing. We also need, frex, pagination.
# [10:14] <tabatkins> howcome: What do you mean by pagination?
# [10:15] <tabatkins> gylling: Dynamic reflow and pagination. Also page templates.
# [10:15] <tabatkins> gylling: The feature that overshadows everything else is Writing Modes, though.
# [10:16] <tabatkins> Bert: I'd like to have some names to follow who know what's going on.
# [10:17] <tabatkins> kojiishi: I'm fine with being the liaison for egls (?), but would like someone else that can handle the other groups.
# [10:18] <tabatkins> gylling: I think the main group is 21:00utc, and all the other groups will be re-merging, so everyone should have this as well.
# [10:19] * Joins: r12a-nb (ishida@128.30.52.28)
# [10:19] <tabatkins> MikeSmith: kennyluck has some insights into the vertical text issues as well.
# [10:20] * Quits: Ibrahima (qw3birc@128.30.52.28) (Ping timeout)
# [10:20] <tabatkins> fantasai: I can attend the epub telcon - it's at a sane time in pacific timezone.
# [10:21] * Joins: Aharon (aharon@212.179.82.69)
# [10:21] <tabatkins> gylling: So if I understand correctly, we have a liaison, we'll find out if ebook impls can serve as impls for tests.
# [10:21] <tabatkins> fantasai: ebook readers will certainly serve.
# [10:22] <tabatkins> Bert: Also a question is the test format.
# [10:22] <tabatkins> gylling: I think epub with write access could do the tests in css format and contribute the results directly.
# [10:23] * Joins: MikeSmith (MikeSmith@84.14.50.82)
# [10:23] <tabatkins> Bert: Are there resources set aside for testing purposes?
# [10:23] <tabatkins> gylling: I can't give you firm numbers, but yes, there will be resources for testing.
# [10:23] <tabatkins> Bert: Any idea how many impls you expect to exist?
# [10:24] <tabatkins> gylling: Can't say. But in terms of rendering, there are 4 separate entities, only one of which is based on webkit.
# [10:24] <tabatkins> gylling: CSS3 Speech now.
# [10:24] <tabatkins> gylling: One of the things we're doing in epub is to enhance, for a11y reasons, speech synthesizers.
# [10:25] <tabatkins> gylling: We'd like to bring new life into the css3 speech module.
# [10:25] <tabatkins> gylling: The daisy consortium has a person we'd like to submit as a new editor.
# [10:25] * Joins: ishino (qw3birc@128.30.52.28)
# [10:26] <tabatkins> glazou: No problem.
# [10:26] <tabatkins> jdaggett: As long as they're a W3C member.
# [10:26] <tabatkins> fantasai: I looked over the spec, and I think claudio (?) did a good job of cleaning it up.
# [10:27] * dbaron doesn't see css3-speech in http://www.w3.org/Style/2008/css-charter
# [10:27] <tabatkins> fantasai: I think there's a section we should keep, another we shoudl drop, but otherwise sounds good.
# [10:27] <tabatkins> glazou: Is there already interest in implementing it?
# [10:27] <tabatkins> gylling: Yes, especially from the a11y who wants to interact with epub.
# [10:29] <tabatkins> szilles: There was a point when some phone/voice companies wanted to go with a completely different approach; I don't remember the details, but it seems that we should get whatever we're doing reviewed by the mobile community.
# [10:29] * Quits: mjs (mjs@84.14.50.82) (Quit: mjs)
# [10:29] <tabatkins> gylling: The people you mentioned are currently meeting as the Speech Incubator group. I'll be meeting with them.
# [10:29] <tabatkins> glazou: Could you report to the WG after you meet with them?
# [10:29] <tabatkins> gylling: I'll try.
# [10:29] * Joins: JonR (Jon@80.195.214.28)
# [10:30] * Quits: glazou (glazou@84.14.50.82) (Quit: glazou)
# [10:30] * Quits: mgylling (mgylling@84.14.50.82) (Quit: mgylling)
# [10:30] * Quits: kennyluck (kennyluck@128.30.52.28) (Quit: kennyluck)
# [10:32] <plinss_> <br type='coffee' />
# [10:32] * Quits: tabatkins (tabatkins@84.14.50.82) (Ping timeout)
# [10:34] * Quits: mmielke (mmielke@84.14.50.82) (Ping timeout)
# [10:35] * Quits: myakura (myakura@84.14.50.82) (Ping timeout)
# [10:36] * Joins: glazou (glazou@84.14.50.82)
# [10:36] * Quits: glazou (glazou@84.14.50.82) (Quit: glazou)
# [10:41] * Quits: jun (jun@84.14.50.82) (Quit: jun)
# [10:49] * Joins: myakura (myakura@84.14.50.82)
# [10:53] <myakura> re css3-speech, WebKit implemented 'speech' property about a month ago. http://webkit.org/b/46827
# [11:01] * Joins: glazou (glazou@84.14.50.82)
# [11:02] * Joins: mgylling (mgylling@84.14.50.82)
# [11:05] * Joins: ilkka (ilkka@188.40.120.199)
# [11:05] * Joins: mjs (mjs@84.14.50.82)
# [11:06] * Joins: tabatkins (tabatkins@84.14.50.82)
# [11:07] <fantasai> Topic: CSS2.1 Testing
# [11:07] <fantasai> round of intros
# [11:07] * Joins: tabatkin1 (tabatkins@84.14.50.82)
# [11:08] <ilkka> my name is Ilkka Oksanen
# [11:08] <dbaron> Present: Ilkka Oksanen, Bert Bos, David Singer, Håkon Lie, Peter Linss, Markus Mielke, Tab Atkins, Soonbo Han, Steve Zilles, Daniel Glazman, John Jansen, Sylvain Galineau, Koji Ishii, Elika Etemad, Alex Mogilevsky, David Baron, John Daggett
# [11:08] * Parts: tabatkin1 (tabatkins@84.14.50.82)
# [11:09] <tabatkins> glazou: Test suite current status?
# [11:09] <tabatkins> fantasai: Published a snapshot last week.
# [11:09] <tabatkins> fantasai: I haven't done any work on it since then.
# [11:09] <tabatkins> dsinger: Because it's perfect?
# [11:09] * Quits: mjs (mjs@84.14.50.82) (Connection reset by peer)
# [11:09] <tabatkins> fantasai: No, I've just been working on other stuff.
# [11:09] * Joins: mjs (mjs@84.14.50.82)
# [11:09] <tabatkins> fantasai: There's still a lot of error reports that ahven't been addressed. I'm guessing a couple weeks.
# [11:10] <tabatkins> glazou: What are the IR results? How many tests that don't pass 2 impls?
# [11:11] <tabatkins> plinss: As of RC3, 135 marked as invalid that havne't been updated yet, 908 tests that are considered required that don't have 2 passes.
# [11:11] <tabatkins> tabatkins: To be clear, a lot of those tests are rc3 and haven't been tested by several browsers yet.
# [11:11] * Joins: mmielke (mmielke@84.14.50.82)
# [11:12] <tabatkins> jdaggett: Question on what versions are allowed?
# [11:13] <tabatkins> plinss: Public availability, and results must be a month old.
# [11:14] * Quits: ishino (qw3birc@128.30.52.28) (Ping timeout)
# [11:15] <tabatkins> jdaggett: I have a problem with using source-code versions, because it's hard to ensure that I run the exact same version that the test results were generated for.
# [11:16] <tabatkins> fantasai: I think we should require a public *binary*, not just source.
# [11:16] <tabatkins> tabatkins: So, we only release binaries for our public channel, every 6 weeks or so.
# [11:16] * Joins: kennyluck (kennyluck@128.30.52.28)
# [11:16] <fantasai> s/fantasai/jdaggett/
# [11:16] <tabatkins> johnjan: So, IE9 developer previews count?
# [11:17] * Joins: jun (jun@84.14.50.82)
# [11:17] <tabatkins> jdaggett: Sure, as long as we can get historical versions that the suite was run for.
# [11:17] <tabatkins> johnjan: I'll check to see if, say, when we release preview 7, if preview 6 is still available. if not, I'll stick with beta.
# [11:18] <tabatkins> dsinger: Are there tests that are failing because the spec is wrong?
# [11:18] * Quits: mjs (mjs@84.14.50.82) (Connection reset by peer)
# [11:18] * Joins: mjs (mjs@84.14.50.82)
# [11:19] <tabatkins> dbaron: There were some, yes. I marked some of them, but others I didn't feel strongly enough about to file a bug about.
# [11:19] <tabatkins> dbaron: There were some invalids where the test was requiring something the spec doesn't actually require. There were some that were actually testing the wrong thing. And then there was a third category that were testing something where I believe the spec itself was wrong.
# [11:20] <tabatkins> glazou: I'd like to see all info about that in front of the group as soon as possible.
# [11:20] <tabatkins> dsinger: I'd just like a good wiki page somewhere that lists all the tests in each of those categories.
# [11:20] <tabatkins> dsinger: And then slowly see that page empty out until we're done.
# [11:21] <tabatkins> dsinger: I've gone through every mozilla failure and figured out if it was a bug in the test or in our impl, based on what the spec currently said.
# [11:21] * Joins: dethbakin (dethbakin@84.14.50.82)
# [11:21] <tabatkins> s/dsinger/dbaron/
# [11:22] * Zakim excuses himself; his presence no longer seems to be needed
# [11:22] * Parts: Zakim (rrs-bridgg@128.30.52.169)
# [11:22] <tabatkins> dbaron: There were some places where the test was testing things the spec didn't require and I could have marked invalid, but I went ahead and marked it a mozilla fail because our actual behavior was so wrong. Like Lists numbering, frex.
# [11:23] <tabatkins> fantasai: CSS3 Lists defines list numbering, but CSS2.1 doesn't.
# [11:23] <fantasai> http://wiki.csswg.org/test/css2.1/issues
# [11:23] * Quits: Aharon (aharon@212.179.82.69) (Ping timeout)
# [11:23] <tabatkins> glazou: My problem is that I don't have any stable visibility on the status of the testsuite.
# [11:23] <tabatkins> jdaggett: So what are you proposing, daniel? A specific date?
# [11:24] <tabatkins> glazou: I propose we buckle down on CSS2.1 issues again. I think that rather than cancelling the first conf call after tpac, we have it and talk about test suite.
# [11:25] <tabatkins> johnjan: Is Nov 15th still the date for not changing the testsuite, or at least just triaging at that point?
# [11:26] <tabatkins> fantasai: That's a little early. I'll need two weeks after this for my changes.
# [11:26] <tabatkins> johnjan: Yeah, and we'll also need to do reviews of the changes.
# [11:26] <tabatkins> johnjan: So is 2 weeks enough time?
# [11:26] <tabatkins> dbaron: What I want is, when we think we have all the changes done, I want to go through and rerun/reverify. So that's a dependency there.
# [11:27] * Joins: Peter (peter@85.223.116.170)
# [11:27] <tabatkins> fantasai: I think I'm about halfway through the reported issues in my tests, and have responded to each test issue email as I completed the fix.
# [11:28] <tabatkins> fantasai: But I don't know that arronei did it to all of his, and that would make it much more difficult to judge what all has been done.
# [11:29] <tabatkins> johnjan: So we can review the changes as they come in now, and on the 22nd review what's gone on and see if we're ready or we need another 2 weeks, etc.
# [11:29] <dbaron> I just went through the list of things that I thought were "too silly to file a bug" on, and one more I noticed is the test that tests that the root element's background is propagated to the canvas even when the root element is display:none.
# [11:30] * Joins: yuma_1985 (yuma_1985@84.14.50.82)
# [11:30] <tabatkins> glazou: So we'll have IRs based on the locked version by the end of year?
# [11:30] <tabatkins> johnjan: Early december, I think.
# [11:30] * Joins: Aharon (aharon@84.14.50.82)
# [11:33] <tabatkins> plinss: [explains how results are handled in each version of the test suite harness, and how results are grandfathered over when tests don't change]
# [11:34] * Joins: joonho (joonholee@84.14.50.82)
# [11:34] <tabatkins> jdaggett: Also, could you record the useragent language? Some of the font tests are locale-specific.
# [11:34] * dbaron wants to bring up an issue with Ahem-related tests
# [11:34] <tabatkins> plinss: Yes, I have the useragent data, so I'll pull that data out.
# [11:37] <tabatkins> RESOLVED: Target Nov 22nd for test suite RC4 freeze.
# [11:37] <tabatkins> dbaron: Did you publish change lists from rc1-2, and rc2-3?
# [11:37] <tabatkins> fantasai: I think I did rc2-3.
# [11:37] <tabatkins> plinss: I have changed test data, so I can generate a list like that.
# [11:38] <fantasai> http://lists.w3.org/Archives/Public/public-css-testsuite/2010Oct/0369.html
# [11:38] <fantasai> http://lists.w3.org/Archives/Public/public-css-testsuite/2010Oct/0005.html
# [11:38] <tabatkins> johnjan: I'd like to bring up a question about a consistent place to store the impl reports - the .data files.
# [11:38] <tabatkins> johnjan: I can't find a consistent place, and I don't think attachments on the list are a good place to store them.
# [11:39] <fantasai> ACTION fantasai: update links from W3C to implementation reports and test suite releases
# [11:39] * trackbot noticed an ACTION. Trying to create it.
# [11:39] * RRSAgent records action 1
# [11:39] <trackbot> Created ACTION-272 - Update links from W3C to implementation reports and test suite releases [on Elika Etemad - due 2010-11-08].
# [11:39] <tabatkins> plinss: I've put them in the rc1 and rc2 folders as appropriate.
# [11:39] <tabatkins> dbaron: We have a larg enumber of IR bugs because of one issue with Ahem fonts where the tests are questionably valid.
# [11:40] <tabatkins> dbaron: The Ahem font has a lot of glyphs that are boxes - they are exactly 1em tall and wide.
# [11:40] <tabatkins> dbaron: The baseline of the font is 4/5ths from the top to the bottom of the font.
# [11:40] <tabatkins> dbaron: So all the ascent metrics are 80% of the em square, the descents are 20%.
# [11:41] <tabatkins> dbaron: So the issue is that if the ahem font is used at a size that is not a multiple of 5px, then the ascent/descent/x-height aren't a round number of pixels.
# [11:41] <tabatkins> dbaron: On Windows, our font metrics backend makes it okay.
# [11:41] <tabatkins> dbaron: We don't get good enough information anyway, so we just throw one out and subtract from the height.
# [11:42] <tabatkins> dbaron: But on Linux we get good info, so we use both the ascent and descent data, and both are rounded up.
# [11:42] <tabatkins> dbaron: So a pretty large amount of our test failures are because the Ahem font isn't a multiple of 5px.
# [11:42] <tabatkins> dbaron: I marked them as Moz bugs, but I could equally mark them as invalid, which could flip 50-80 tests.
# [11:43] <tabatkins> jdaggett: I think that in general we shouldn't be relying on rounding behavior.
# [11:44] <tabatkins> chrisl: And we don't have a canonical place to look for font data, since different font apis on different platforms return different data.
# [11:44] <tabatkins> alexmog: The spec doesn't say that fonts have to be round numbers of pixels.
# [11:44] <tabatkins> jdaggett: Yes, but the spec also doesn't specify how to round, so we can't rely on rounding.
# [11:46] <tabatkins> chrisl: Can we just ignore the fact that windows does weird things? We have two impls that use correct platform behavior.
# [11:46] <jdaggett> waterfall test for non-integer font sizes:
# [11:46] <jdaggett> http://people.mozilla.org/~jdaggett/tests/decimalfontwaterfalls.html
# [11:47] <jdaggett> alexmog: ^
# [11:47] <tabatkins> dbaron: The rounding behavior is part of freetype, actually. I've tried to change our rounding behavior, but it actually broke several things, like text-decorations no longer lining up exactly.
# [11:47] <MikeSmith> RRSAgent, make minutes
# [11:47] <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/01-CSS-minutes.html MikeSmith
# [11:47] <tabatkins> s/windows/windows GDI/
# [11:48] <tabatkins> glazou: We need a way to report invalid/problematic tests. Everyone should report invalid tests asap, and try to meet the guidelines we discussed today.
# [11:48] <tabatkins> dbaron: For the record, i went through all the mozilla failures. There were a small number of tests I gave up on. I havne't gotten to those yet.
# [11:49] <tabatkins> dbaron: Some were font ones, which I handed to jdaggett.
# [11:49] <tabatkins> jdaggett: I fixed the tests.
# [11:49] <dbaron> http://lists.w3.org/Archives/Public/public-css-testsuite/2010Oct/0178.html
# [11:49] <dbaron> http://lists.w3.org/Archives/Public/public-css-testsuite/2010Oct/0175.html
# [11:49] <tabatkins> jdaggett: But the metric ones we still need to look at.
# [11:51] <dbaron> And the other Moz failures I didn't analyze were margin-collapse-157, margin-collapse-clear-005 and margin-collapse-clear-011
# [11:51] <tabatkins> dbaron: And also some margin-collapse issues, which I skipped because it takes me too long to try and figure out what's intended there.
# [11:51] <tabatkins> chrisl: Perhaps that's a spec problem, if an implementor finds it too difficult to figure out from the spec what should happen.
# [11:51] <tabatkins> fantasai: We just rewrote that section of the spec.
# [11:52] <tabatkins> Topic: i18n
# [11:52] <tabatkins> richard ishida and aharon lenin introduce themselves
# [11:52] <tabatkins> also david clarke (sp?)
# [11:52] <johnjan> so 11/22 for Elika's changes to the Test Suite, 12/8 Conf Call for getting complete on reviewing those test changes and completing the IR submissions.
# [11:53] <tabatkins> also kennyluck
# [11:53] <tabatkins> fantasai: The point of i18n is to make everyone in the world happy with our technologies.
# [11:53] <tabatkins> fantasai: 2 major topics: bidi, and vertical text.
# [11:54] <tabatkins> fantasai: We're doing vertical text tomorrow.
# [11:54] <tabatkins> fantasai: aharon wanted to discuss bidi-related proposals for css3.
# [11:54] * timeless_mbp is now known as timeless
# [11:54] <tabatkins> Aharon: First thing i wanted to discuss was a couple of new proposals that I emailed to the list last night.
# [11:55] <tabatkins> Aharon: Second is to get a feeling on the acceptance level on the other bidi stuff that has been dsicussed ove rth elast year.
# [11:55] <Bert> s/lenin/lanin/
# [11:55] <tabatkins> Aharon: New stuff. (1) A small addition to Images.
# [11:55] <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Nov/0000.html
# [11:55] <tabatkins> Aharon: I'd like an ability to flip an image based on directionality.
# [11:56] <myakura> http://www.w3.org/International/docs/html-bidi-requirements/#image-flip
# [11:56] <tabatkins> Aharon: One option is an 'rtlflip' keyword, so the image would be flipped horizontally when the direction is rtl.
# [11:57] <tabatkins> jdaggett: This isn't just bidi - vertical text may want to do rotations too. So, this is a writing-mode thing.
# [11:57] <tabatkins> Aharon: The other way was to declare the directionality of the image, and then auto-flip as appropriate.
# [11:58] <tabatkins> Aharon: So if the image is ltr and the text is ltr, leave it alone. If the text is rtl, then flip the image.
# [11:59] <tabatkins> szilles: One slight modification; I think this is a much better way to go as it describes the image. I think you need to separate the idea of the image directionality from whether or not to flip it.
# [11:59] * Joins: Kai (chatzilla@84.14.50.82)
# [12:00] <tabatkins> szilles: Because an image might be neutral in horizontal, but not in vertical.
# [12:00] <tabatkins> szilles: Would this apply to any replaced element?
# [12:00] <tabatkins> fantasai: If this should apply to all replaced elements, this should be handed to the HTMLWG as this would be a content property.
# [12:02] <tabatkins> johnjan: One problem is backwards compat.
# [12:03] <tabatkins> fantasai: Not a problem in CSS, as you can count on the property being ignored in legacy and just add a fallback.
# [12:03] <tabatkins> szilles: So I'm hearing that we aren't intended to cover <img>?
# [12:04] <tabatkins> fantasai: For content images, in most cases I don't believe you'd generally want to flip those images.
# [12:04] <tabatkins> fantasai: The types of images you get in CSS are very often something you want to flip.
# [12:04] <tabatkins> fantasai: But images that belong in the content tend to be pictures, charts, etc. that you are much less likely to want to flip.
# [12:04] <tabatkins> fantasai: Now, if the use-case pops up and proves important, then at that point we'd push this back to the HTMLWG and ask them to fix the problem.
# [12:05] <tabatkins> szilles: Good, I just wanted to be clear on the scope.
# [12:05] * Quits: timeless (timeless@84.14.50.82) (Client exited)
# [12:07] * Quits: Aharon (aharon@84.14.50.82) (Ping timeout)
# [12:07] <fantasai> dbaron: should look into how this interacts with Exif orientation
# [12:08] <fantasai> http://dev.w3.org/csswg/css3-images/#image-orientation
# [12:08] <tabatkins> dbaron: We had a spec somewhere relating to EXIF transformations and similar. We might want to think about how this transformation compounds with the exif orientation.
# [12:08] <fantasai> dbaron: Didn't we have a boolean to honor the exif orientation?
# [12:08] <tabatkins> tabatkins: If honored, it should happen at a level below the rtl flipping.
# [12:09] <tabatkins> dbaron: While it's arguably correct to honor the EXIF orientation, there's probably a lot of web content that depends on EXIT not being honored.
# [12:09] * Joins: timeless_mbp (timeless@84.14.50.82)
# [12:09] * Quits: mjs (mjs@84.14.50.82) (Quit: mjs)
# [12:09] * fantasai notes that the spec there needs updating to add back that auto value
# [12:09] * Joins: Aharon (aharon@84.14.50.82)
# [12:10] <tabatkins> dsinger: Any image editor that doesn't set EXIF correctly is buggy. It's not our responsibility to fix their bugs.
# [12:11] * gsnedders notes that he can be poked on IRC if it would help for the next hour and a half or so, but can't guarantee that he knows everything about CSS :)
# [12:11] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
# [12:11] <tabatkins> tabatkins: We can't break webpages either.
# [12:12] <tabatkins> howcome: We should mandate a default behavior of not honoring, and have a property allowing honoring it.
# [12:12] <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Nov/0004.html
# [12:12] <tabatkins> dbaron: Also, theoretically attr() and Generated Content could let us handle <img>s in HTML.
# [12:12] <tabatkins> Aharon: Next topic. You have list-style-position, which lets you put the marker inside or outside.
# [12:13] <tabatkins> Aharon: I'm only talking about the outside case.
# [12:13] <tabatkins> Aharon: Currently the bullet goes on the "start" side, based on the item's directionality.
# [12:13] * Joins: mjs (mjs@84.14.50.82)
# [12:13] <tabatkins> Aharon: Which sounds reasonable, until one realizes that one often has a list where the items are mixed directionality.
# [12:13] * Quits: Kai (chatzilla@84.14.50.82) (Quit: ChatZilla 0.9.86 [Firefox 3.6.10/20100914125854])
# [12:13] <tabatkins> Aharon: For example, a bibliography where some are english and some are hebrew.
# [12:14] * Quits: mjs (mjs@84.14.50.82) (Quit: mjs)
# [12:14] <tabatkins> Aharon: The obvious answer is to put @dir on the <li>s directly, but that swaps bullets around inconsistently. so you have to instead wrap a span and tag *that* with directionality, which is suboptimal.
# [12:14] <fantasai> I would suggest the syntax list-style-direction: left | right | start | match-parent, to be parallel with text-align
# [12:14] * Quits: anne (annevk@84.14.50.82) (Quit: anne)
# [12:15] <tabatkins> Aharon: Further, the list itself creates a gutter for the bullet based on the list's direction.
# [12:15] <tabatkins> Aharon: If the bullets are mixed, then the bullets for items in the other direction are often invisible because they're off-page.
# [12:15] <tabatkins> Aharon: So my proposal is list-style-direction, which indicates the direction of the marker.
# [12:15] <tabatkins> Aharon: Four values: ltr, rtl, match-list, match-item.
# [12:16] <tabatkins> dbaron: I'm inclined to think we should instead find the right answer, and not expose this directly at all.
# [12:17] <tabatkins> Aharon: The use-case for having it match item is that in arabic, they sometimes like having markers on different sides.
# [12:18] <tabatkins> dbaron: You said that the gutter for the list is a function of the list's direction. I think that varies between browsers. In gecko it should match the child's direction.
# [12:19] <tabatkins> dbaron: Wait, maybe I've got that wrong. The gutter is always generated by the list.
# [12:19] <tabatkins> dbaron: Also, in CSS Lists, there's no concept of a "list", just list items. So you'd need match-parent, not match-list.
# [12:21] <tabatkins> dbaron: What I think is that, semantically, in the case that you have a list with differeing directionality items, the list-items themselves are all the same directionality, but the *content* has different directions.
# [12:21] <tabatkins> szilles: I'm curious why dbaron doesn't want a property there.
# [12:23] <tabatkins> dbaron: I don't think a full property is warranted to just change the behavior of a single value of anothe rproperty.
# [12:23] * Quits: Aharon (aharon@84.14.50.82) (Ping timeout)
# [12:24] <tabatkins> Aharon: Maybe we can just do this as another value on list-style-position? Currently 'outside' refers to the direction of the list-item. Maybe a 'list' value that would be like outside but use the parent's directionality?
# [12:24] <tabatkins> aharon: When you text-align anything but start, in IE the outside marker follows the text, so they don't line up.
# [12:25] <tabatkins> aharon: Webkit doesn't make the marker move, so they still all line up.
# [12:26] <tabatkins> aharon: In my opinion, the webkit behavior is more useful. You can use list-style-position:inside to make the marker follow the text.
# [12:27] <tabatkins> dbaron: We received a ton of feedback from authors that they don't like the bullet being separated from the text.
# [12:27] <tabatkins> dbaron: This is also tied somewhat to issues of floats and such. When the linebox is shortened we need to specify where the bullet goes.
# [12:27] <tabatkins> dbaron: Right now we tie the bullet to the first line box.
# [12:28] <tabatkins> tabatkins: It seems conceptually consistent to make 'outside' follow the list-item's text, but make the new value 'match-parent' or whatever line them up separate from the text.
# [12:30] * fantasai tabatkins did you catch Aharon's last set of comments?
# [12:31] <fantasai> dbaron: We still need to displace bullets from floats by match-parent
# [12:32] <tabatkins> aharon:
# [12:32] * sylvaing discussion of minutes-writing-mode ensues...
# [12:33] <tabatkins> aharon: Finally, I want to check on the status of the bidi things that I haven't been direclty working on, which fantasai has been keeping on top of.
# [12:33] <tabatkins> glazou: Tab, could you keep up a wiki or something for an issues list for Lists?
# [12:33] <tabatkins> tabatkins: Yeah.
# [12:33] <fantasai> tabatkins, you missed something Aharon said, can you put it in the minutes?
# [12:34] <dbaron> fantasai, that was <tabatkins> aharon: Finally, I want to check on the status of the bidi things that I haven't been direclty working on, which fantasai has been keeping on top of.
# [12:34] <fantasai> No, you missed it. He was describing the behavior of match-parent on both list markers and text alignment and how they interact
# [12:34] <fantasai> You did not catch any of that.
# [12:34] * Quits: mgylling (mgylling@84.14.50.82) (Quit: mgylling)
# [12:34] * Joins: mjs (mjs@84.14.50.82)
# [12:34] * Quits: dethbakin (dethbakin@84.14.50.82) (Quit: dethbakin)
# [12:34] * Quits: glazou (glazou@84.14.50.82) (Quit: glazou)
# [12:35] * Quits: jdaggett (jdaggett@84.14.50.82) (Quit: jdaggett)
# [12:35] <myakura> <br type=lunch>
# [12:35] * Quits: kennyluck (kennyluck@128.30.52.28) (Quit: kennyluck)
# [12:35] <fantasai> The entire discussion of text-align and its interaction with the list marker was not minuted.
# [12:35] * Quits: plinss_ (plinss@84.14.50.82) (Quit: plinss_)
# [12:36] <fantasai> s/marker/marker position/
# [12:36] <dbaron> Basically the idea is that with list-style-position: outside, bullets should stick to the line box (wrap for both text-align and floats), but with list-style-position: outside-parent the direction of the bullet position matches the parent, and the wrapping only accounts for floats and does not account for text-align
# [12:36] * Quits: tabatkins (tabatkins@84.14.50.82) (Ping timeout)
# [12:37] * Quits: jypark (qw3birc@128.30.52.28) (Ping timeout)
# [12:37] * Quits: mmielke (mmielke@84.14.50.82) (Ping timeout)
# [12:37] * Parts: mjs (mjs@84.14.50.82)
# [12:37] * Quits: sbhan (qw3birc@128.30.52.28) (Ping timeout)
# [12:38] * Quits: joonho (joonholee@84.14.50.82) (Ping timeout)
# [12:38] <fantasai> Yes, an Aharon was discussing how that behavior handles certain use cases that are needed
# [12:38] * Quits: myakura (myakura@84.14.50.82) (Ping timeout)
# [12:38] * Quits: jun (jun@84.14.50.82) (Quit: jun)
# [12:38] <fantasai> Because, e.g. some lists are rendered with bullets all on one side
# [12:38] * Quits: szilles (chatzilla@84.14.50.82) (Ping timeout)
# [12:38] * Quits: anthony (qw3birc@128.30.52.28) (Ping timeout)
# [12:38] <fantasai> but an item of opposite directionality might be aligned to the opposite side
# [12:39] * Quits: dsinger (dsinger@84.14.50.82) (Quit: dsinger)
# [12:39] <fantasai> while leaving the bullet aligned with the others in the list
# [12:39] * Quits: homata_ (homata@84.14.50.82) (Ping timeout)
# [12:39] <dbaron> (and with list-style-position:outside the side for the bullet matches the item, as now)
# [12:39] * Quits: dbaron (dbaron@63.245.220.11) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [12:44] * Quits: sylvaing (sylvaing@84.14.50.82) (Ping timeout)
# [12:49] * Quits: alexmog (qw3birc@128.30.52.28) (Ping timeout)
# [12:52] * Parts: JonR (Jon@80.195.214.28)
# [13:03] * Quits: johnjan (qw3birc@128.30.52.28) (Ping timeout)
# [13:07] * Quits: tantek (tantek@70.36.139.128) (Quit: tantek)
# [13:12] * Quits: kohei (koheiyamam@124.39.135.110) (Quit: Leaving...)
# [13:28] * Joins: jdaggett (jdaggett@84.14.50.82)
# [13:36] * Joins: plinss_ (plinss@84.14.50.82)
# [13:39] * Joins: joonho (joonholee@84.14.50.82)
# [13:39] * Quits: yuma_1985 (yuma_1985@84.14.50.82) (Connection reset by peer)
# [13:40] * Joins: glazou (glazou@84.14.50.82)
# [13:40] * Joins: myakura (myakura@84.14.50.82)
# [13:42] * Joins: sylvaing (sylvaing@84.14.50.82)
# [13:42] * Joins: joonho_2010 (joonholee@84.14.50.82)
# [13:42] * Quits: joonho (joonholee@84.14.50.82) (Ping timeout)
# [13:42] * Joins: mmielke (mmielke@84.14.50.82)
# [13:43] * Joins: szilles (chatzilla@84.14.50.82)
# [13:43] * Joins: dethbakin (dethbakin@84.14.50.82)
# [13:44] * Joins: anne (annevk@84.14.50.82)
# [13:45] * Joins: tabatkin1 (tabatkins@84.14.50.82)
# [13:45] * Joins: sbhan (qw3birc@128.30.52.28)
# [13:45] * Quits: joonho_2010 (joonholee@84.14.50.82) (Ping timeout)
# [13:45] * Joins: parkjy (qw3birc@128.30.52.28)
# [13:46] * Joins: joonho_2010 (joonholee@124.39.135.110)
# [13:47] * Quits: r12a-nb (ishida@128.30.52.28) (Ping timeout)
# [13:47] <fantasai> ScribeNick: fantasai
# [13:47] * Joins: Ms2ger (Ms2ger@91.181.144.192)
# [13:47] <fantasai> Topic: Accessibility
# [13:48] <fantasai> Topic: Multi-Col
# [13:48] <fantasai> howcome: I would like to confirm agreement on a few things
# [13:49] <fantasai> howcome: Implementations seem to be coming along nicely
# [13:49] <fantasai> howcome: Hopefully all of the functionality in the spec
# [13:49] <fantasai> howcome: We need some clarifications in the spec
# [13:49] <fantasai> howcome: It's all about spanning elements
# [13:49] * Joins: dbaron (dbaron@63.245.220.11)
# [13:49] <fantasai> howcome: Remember we have a multicol element here, and we lay out incolums
# [13:49] <fantasai> howcome draws on the board
# [13:49] <fantasai> howcome: The issue is overflow
# [13:50] <fantasai> howcome: There are two reasons for overflow: you could have a constrained height
# [13:50] <fantasai> howcome: or you could have forced column breaks, more breaks than you have columns
# [13:50] <fantasai> howcome: The issue is what to do if you have an element with column-span: all in one of the overflow columns
# [13:51] <fantasai> howcome: Alex proposed to do nothing, i.e. pretend column-span was not set
# [13:51] * Joins: Aharon (aharon@84.14.50.82)
# [13:51] * Parts: Aharon (aharon@84.14.50.82)
# [13:52] <fantasai> howcome: If it's in the overflow columns due to forced breaks, though, I think it makes sense to have it break the column row and render as column-span: all, with content following it filling in columns in a row below it
# [13:52] <fantasai> dbaron: What if you have both a constrained height and forced breaks?
# [13:52] <dbaron> that wasn't me
# [13:53] <fantasai> Alex: If it's due to forced breaks, you can try to put it in the main section. And if it doesn't fit and cause overflow, then you put it in an overflow column and ignore the spanning behavior
# [13:53] <fantasai> s/dbaron/?/
# [13:53] * Joins: mgylling (mgylling@212.180.75.100)
# [13:53] <fantasai> Alex: One special case: when you try to place a colspan and it itself doesn't fit, and creates overflow. That creates a circular dependency
# [13:54] <fantasai> Alex: I think we resolved that if it doesn't fit as a span, you ignore the span
# [13:54] * Joins: kennyluck (kennyluck@128.30.52.28)
# [13:54] <fantasai> howcome: So the distinction is, if it fits inside the multicol element as a span, then it does so, else the spanning behavior is ignored
# [13:55] <fantasai> dbaron: You could also ignore in all cases whether there's a constrained height
# [13:55] <fantasai> stevez: I think it should be if it fits or not
# [13:55] <dbaron> s/whether/when/
# [13:56] <fantasai> howcome: I think we should honor it in as many cases as possible, so I think we should hinge this on whether there's room or not
# [13:56] <fantasai> stevez: This might interact with the EPUB case, where they paginate in addition to doing multicol
# [13:57] * Joins: yuma_1985 (yuma_1985@84.14.50.82)
# [13:58] * Joins: homata (homata@84.14.50.82)
# [13:58] * Joins: Kai (chatzilla@84.14.50.82)
# [14:01] <fantasai> Alex: If the forced-break case is height-constrained, where does the overflow columns go?
# [14:01] * Joins: shepazu (schepers@128.30.52.169)
# [14:01] <fantasai> Alex: Do the columns overflowing from the second row have full height, or shortened height, i.e. height after the rowspan?
# [14:01] * Quits: dethbakin (dethbakin@84.14.50.82) (Connection reset by peer)
# [14:01] <fantasai> dbaron: So you're saying whether colspan works at all...
# [14:02] <fantasai> howcome: is dependent on whether there is room inside the multicol element
# [14:02] * fantasai notes that she had an issue and needs to minute it
# [14:03] <fantasai> Alex: This could create a very ugly case if you have only one line of space left at the bottom of the multicol. you would create one-line-high overflow columns off to the right
# [14:03] * Joins: johnjan (qw3birc@128.30.52.28)
# [14:03] * Joins: dethbakin (dethbakin@84.14.50.82)
# [14:04] <fantasai> Alex: As the available space after the colspan approaches zero, the number of columns for content after it approaches infinity
# [14:06] <fantasai> fantasai: From an implementation perspective, I would prefer this method.
# [14:06] <fantasai> fantasai: The main reason we simplified column-span to 1 or all instead of arbitrary numbers was to avoid a column row with columns of multiple heights
# [14:06] <fantasai> fantasai: if overflow columns were full-height columns, then we lose that simplification
# [14:07] <szilles> What Stevez was saying was that Epub wants to have pagination, expecially in the multicolumn case, because they want to avoid overflow behavior when there are mulitiple columns
# [14:07] <fantasai> fantasai: (Also, if forced-column-breaks can create overflow columns, then your full-height columns would overpaint any such overflowing columns before the column span)
# [14:08] <fantasai> [note to minutes: insert pictures]
# [14:09] <fantasai> dbaron draws some content on the board
# [14:09] <fantasai> I have a some text, then a forced break, then more content.
# [14:09] <fantasai> Then a spanning element.
# [14:10] <fantasai> tab, fantasai: Then you balance the content, which may introduce breaks in the column before the forced break or after it or both
# [14:11] <fantasai> RESOLVED: If a columnspanning element doesn't fit within the multicol element, then it doesn't span anymore
# [14:12] <fantasai> s/element/element without overflowing/
# [14:12] <fantasai> New questions:
# [14:12] <fantasai> 1. do columnspanning elements create a new block formatting context
# [14:13] <fantasai> 2. does columnspanning turn inline elements into blocks?
# [14:13] <fantasai> 3. If the answer to either of the above is yes, does that behavior apply when the columnspanning is ignored due to overflowing (as resolved above)?
# [14:15] <fantasai> 2... or does it not apply to inline elements
# [14:16] <fantasai> fantasai: I think column-span should only apply to block-level elements
# [14:17] <fantasai> Bert reads the applies-to line from the spec
# [14:17] <fantasai> RESOLVED: column-span applies to "in-flow block-level elements"
# [14:18] <fantasai> dbaron: Note in the prose that it has no effect on elements outside a multicol element
# [14:18] <dbaron> Well, really I said that maybe the in-flow aspect is the same as the doesn't-work-outside-multicol aspect, and then we got to that conclusion.
# [14:18] * Joins: freedom (freedom@84.14.50.82)
# [14:19] <dbaron> fantasai: If a column-spanning element is a BFC root, then margins don't collapse through its boundaries.
# [14:19] <tabatkin1> fantasai: I don't think that margin behavior should change based on whether a colspan is honored or not.
# [14:19] <sylvaing> CSS3 Multicolumn http://www.w3.org/TR/css3-multicol/
# [14:19] <tabatkin1> fantasai: So if it's a spanning element, it should automatically become a BFC and no longer collapse margins through its boundary.
# [14:20] <fantasai> whether or not it's triggered the overflow nonspanning case
# [14:21] * Joins: arron (Arron@24.17.123.244)
# [14:21] <fantasai> fantasai: I think we might need to distinguish whether an element is spanning one column or not spanning
# [14:22] <fantasai> dbaron: I really don't want whether something is a block formatting context root depend on layout
# [14:22] * Joins: dsinger (dsinger@84.14.50.82)
# [14:22] <fantasai> dbaron: I really want to know what floats are relative to not depend on layout
# [14:23] <fantasai> tabatkin1: So they should become BFCs regardless of whether they actually span something or not
# [14:24] <fantasai> dbaron: We shouldn't have tricky behavior for an error case
# [14:24] <fantasai> Steve: So column-span: all; would mean span the current column in the overflow case
# [14:24] <fantasai> Steve: i.e. the all in that case means the one column
# [14:25] * Joins: ChrisL (ChrisL@128.30.52.169)
# [14:25] <fantasai> RESOLVED: column-spanning elements are BFC roots always
# [14:27] <fantasai> RESOLVED: Initial value of column-span is 'none'
# [14:28] <fantasai> Bert: Last issue is, do margins between spanning elements collapse?
# [14:29] * Quits: freedom (freedom@84.14.50.82) (Quit: leaving)
# [14:29] * Joins: freedom (freedom@84.14.50.82)
# [14:29] <fantasai> Bert: e.g. if I have H2 followed by H3, can their margins collapse
# [14:29] <fantasai> fantasai: What about between the spanning element and the content of the columns above and below it?
# [14:30] <fantasai> Roughly, answers seem to be Yes, and No, but discussing...
# [14:31] <fantasai> Back to fantasai's issue
# [14:34] * Quits: mgylling (mgylling@212.180.75.100) (Quit: mgylling)
# [14:35] <fantasai> fantasai: If you get more columns than you have space for due to forced column breaks, then I think instead of overflowing to the right, I think the columns that don't fit should create a new column row rather than overflowing off to the side.
# [14:36] <fantasai> fantasai: This way we avoid an overflow case.
# [14:37] <fantasai> Alex: I'm concerned people would use this for some weird design cases that don't work well
# [14:38] <sylvaing> (that was szilles)
# [14:39] <fantasai> steve zilles echoes the concern
# [14:39] <Bert> (If the columns "wrap," i.e., the n+1st column starts underneath the 1st, then this becomes a way to make a grid in some cases. Effect is almost the same between 'display: inline-block' and 'break-after: always'...)
# [14:39] <fantasai> dbaron: I'm concerned that we're getting too far from what we're implementing
# [14:40] <fantasai> howcome: We have implementations of multicol, we have to resolve these issues
# [14:40] * Quits: glazou (glazou@84.14.50.82) (Client exited)
# [14:40] * Quits: freedom (freedom@84.14.50.82) (Ping timeout)
# [14:40] <fantasai> dbaron: We're not getting much author feedback on columns
# [14:40] * szilles aaron, the reason for column-span="none" is to be able to say that an element without an explicit column-span value does not create a Block Formattring Context
# [14:40] <fantasai> tabatkin1: They're not useful in continuous media
# [14:41] <johnjan> s /aaron /arron
# [14:41] * Joins: glazou (glazou@84.14.50.82)
# [14:43] <fantasai> more discussion of this case
# [14:44] <fantasai> steve zilles thinks this solution causes bad layout
# [14:44] <fantasai> fantasai thinks avoiding overflow is important
# [14:44] * Joins: mgylling (mgylling@84.14.50.82)
# [14:45] <fantasai> steve: People will insert forced breaks randomly in order to get the layout they want
# [14:46] * Joins: alexmog (qw3birc@128.30.52.28)
# [14:46] <tabatkin1> fantasai: [draws a multicol element overflowing, showing how block-column overflow would result in a bad overflow situation in the constrained height case]
# [14:47] <tabatkin1> fantasai: [draws another one where the multicol has an auto height and stretches to fill the content]
# [14:48] <tabatkin1> tabatkin1: Assuming overflow:visible, yeah, it looks ugly. But you only get the good overflow if you have explicit column breaks based on where you think is "good".
# [14:48] <tabatkin1> fantasai: Right, so far. Ideally we'll have in the future a "column-length" that can cause new column rows.
# [14:48] <arron> referring to the first drawing by fantasai, are the columns overflowing to the right or below?
# [14:49] * tabatkin1 arron, they're overflowing down, overlapping content in later elements.
# [14:49] * dbaron but the drawing is to say that's why they don't overflow down
# [14:50] <tabatkin1> fantasai: So if we think that column length is needed to get a sane rendering, maybe we should go ahead and just add column-length now.
# [14:50] <tabatkin1> szilles: I could live with multiple breaks overflowing to the right today.
# [14:52] <fantasai> fantasai: I'm not happy with creating overflow cases when they are not necessary
# [14:52] <fantasai> fantasai: And if we do this today, then you would have to use column-length in order to get explicit-break columns to wrap
# [14:52] <fantasai> tabatkin1: column-length is not the right trigger for wrapping overflowing explicit break columns
# [14:52] <fantasai> tabatkin1: if they're explicit breaks, they're explicit breaks
# [14:53] <fantasai> tabatkin1: If you set column-length: 40em; and your explicit breaks are at 20em, what's your column row height?
# [14:54] <fantasai> steve: Ok, I see what you're saying
# [14:55] <fantasai> Steve: Ok, I'm willing to withdraw my objection provided you add a note about this column-length property
# [14:55] <fantasai> steve: My concern is that people will start putting in explicit breaks just to get the behavior that column-length would have given
# [14:56] <fantasai> Steve: But if you at least put in the spec that this is not intended for this purpose, and how we want to proceed
# [14:56] <fantasai> Peter: Authors don't read the spec. They'll do whatever it takes to make content work the way they want it right now.
# [14:57] <fantasai> Peter: Let's just put this property in right now.
# [14:57] <fantasai> dbaron: I'm not sure this is useful
# [14:57] <fantasai> tabatkin1: This would make multicol usable for me
# [14:58] <fantasai> Peter: Fundamentally, multicol doesn't make much sense on continuous media
# [14:58] <fantasai> Peter: But let's not force people into making unusable layouts.
# [14:59] * Joins: freedom (freedom@84.14.50.82)
# [14:59] <fantasai> dbaron: I'm not sure we're addressing use cases with multicol
# [15:00] * Quits: Kai (chatzilla@84.14.50.82) (Ping timeout)
# [15:01] <fantasai> dbaron: And I don't think we would implement all this.
# [15:01] <fantasai> fantasai: column-length is a piece of cake
# [15:01] <fantasai> dbaron: But we don't implement column-spanning. And we can't balance columns with forced column breaks in our current design.
# [15:01] <fantasai> ?: We have a lot of demand for this, actually.
# [15:02] <fantasai> ?: We haven't switched from table layouts to CSS due to lack of multicol
# [15:03] <fantasai> howcome: So how would you decide the gap between the column rows?
# [15:03] <fantasai> fantasai: use column-gap
# [15:04] <fantasai> fantasai: can give it two values, just like border-spacing, if needed
# [15:04] <fantasai> Alex: I want separate properties
# [15:04] <fantasai> fantasai: Do you need them to cascade independently?
# [15:04] <fantasai> Alex: I just like having separate properties
# [15:05] <fantasai> fantasai: If we need separate properties, we can split them out later and make column-gap a shorthand.
# [15:05] <fantasai> Steve: In XSLFO, we replicated the multicol box
# [15:06] * Joins: Kai (chatzilla@84.14.50.82)
# [15:06] <fantasai> s/?/Kai/
# [15:07] <fantasai> various concerns raised to porting this idea to CSS
# [15:07] <Bert> (Chained regions, e.g., César's extensions to template layout, would solve most use cases as well. That, too, is an example of pagination inside a continuous display...)
# [15:08] <fantasai> Steve: I'm going back to my position of putting a note that this doesn't solve the following problems.
# [15:09] <fantasai> howcome: We go back to the issue of where the overflowing forced-break column goes: off to the right, or wrap under?
# [15:09] <fantasai> howcome: I'm in favor of wrapping under, quite stronger.
# [15:10] <fantasai> Alex: You need gap and rules, though.
# [15:12] <fantasai> fantasai thinks we should just use the column-gap and deal with customized gaps and rules later
# [15:13] * Joins: Kai_ (chatzilla@84.14.50.82)
# [15:14] * Quits: Kai (chatzilla@84.14.50.82) (Ping timeout)
# [15:14] * Kai_ is now known as Kai
# [15:15] <fantasai> steve: But I don't think column-gap is good enough.
# [15:15] <Kai> q+ to say that currently control over layout is key
# [15:15] <fantasai> fantasai: I'm not saying it's good enough, I'm saying it's adequate as a default even in the future when we have all these controls
# [15:15] * glazou let's use the axiomatic proof....
# [15:16] <fantasai> fantasai: The only other reasonable default is a zero gap. I don't see how that's better
# [15:16] <fantasai> ...
# [15:16] <fantasai> tabatkin1 doesn't want to half-ass this
# [15:16] <fantasai> ...
# [15:16] * sylvaing we should add half-ass to RFC2119
# [15:16] <fantasai> Kai: Web page layout is very precise right now.
# [15:16] <fantasai> Kai: Automatically wrapping columns loses precision
# [15:18] <fantasai> Kai: It's easier to control if it always overflows to the right
# [15:19] <Kai> it would be good to have this as default and have the ability to have it wrap
# [15:20] <fantasai> howcome takes a straw poll on behavior
# [15:20] <fantasai> A - overflow to the right
# [15:20] <fantasai> B - wrap under
# [15:20] <fantasai> Bert: A
# [15:20] <fantasai> Kai: A
# [15:20] <fantasai> Steve: A
# [15:20] <fantasai> Peter: B
# [15:20] <fantasai> Markus: A
# [15:20] <fantasai> Tab: A
# [15:20] <fantasai> beth: A
# [15:20] <fantasai> ?: A
# [15:20] <fantasai> ??: B
# [15:20] <fantasai> Chris: A
# [15:21] <fantasai> Daniel: A
# [15:21] <fantasai> John: A
# [15:21] <fantasai> Sylvain: A
# [15:21] <fantasai> Koji: A
# [15:21] <arron> Arron: A assuming right is actually end
# [15:21] <fantasai> fantasai: B
# [15:21] <fantasai> arron, :)
# [15:21] <fantasai> Alex: A
# [15:21] <fantasai> dbaron: A
# [15:21] <fantasai> jdaggett: A
# [15:21] <fantasai> no comment from the peanut gallery
# [15:22] <dbaron> howcome: B
# [15:23] <glazou> s/peanut gallery/other observers
# [15:23] * Quits: glazou (glazou@84.14.50.82) (Client exited)
# [15:23] * timeless_mbp is now known as timeless
# [15:24] * Joins: glazou (glazou@84.14.50.82)
# [15:24] * Quits: mgylling (mgylling@84.14.50.82) (Quit: mgylling)
# [15:24] * dsinger dave: D
# [15:24] <fantasai> Peter: I think it's unfortunate that we're choosing a behavior for multicol that doesn't work well for print
# [15:24] * Quits: glazou (glazou@84.14.50.82) (Quit: glazou)
# [15:24] <fantasai> RESOLVED: overflow to the right
# [15:25] * Quits: dethbakin (dethbakin@84.14.50.82) (Quit: dethbakin)
# [15:26] * Peter is now known as beverloo
# [15:26] * Quits: tabatkin1 (tabatkins@84.14.50.82) (Ping timeout)
# [15:28] * Quits: sbhan (qw3birc@128.30.52.28) (Ping timeout)
# [15:30] * Quits: joonho_2010 (joonholee@124.39.135.110) (Ping timeout)
# [15:30] * Quits: timeless (timeless@84.14.50.82) (Client exited)
# [15:32] * Joins: timeless_mbp (timeless@84.14.50.82)
# [15:32] * Joins: nimbupani (nimbupani@24.22.131.46)
# [15:32] * Quits: Kai (chatzilla@84.14.50.82) (Quit: ChatZilla 0.9.86 [Firefox 3.6.10/20100914125854])
# [15:34] * Quits: freedom (freedom@84.14.50.82) (Connection reset by peer)
# [15:37] * Joins: tantek (tantek@70.36.139.128)
# [15:38] * Joins: tabatkins (tabatkins@84.14.50.82)
# [15:39] * Joins: yuma_1986 (yuma_1985@84.14.50.82)
# [15:39] * Quits: yuma_1985 (yuma_1985@84.14.50.82) (Connection reset by peer)
# [15:41] <kennyluck> RRSAgent, make minutes
# [15:41] <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/01-CSS-minutes.html kennyluck
# [15:42] * Quits: homata (homata@84.14.50.82) (Ping timeout)
# [15:42] * Joins: sbhan (qw3birc@128.30.52.28)
# [15:44] * Quits: johnjan (qw3birc@128.30.52.28) (Quit: Page closed)
# [15:45] * Joins: johnjan (qw3birc@128.30.52.28)
# [15:47] * Joins: mgylling (mgylling@84.14.50.82)
# [15:49] * Joins: homata (homata@84.14.50.82)
# [15:54] * Quits: yuma_1986 (yuma_1985@84.14.50.82) (Ping timeout)
# [15:54] * Quits: homata (homata@84.14.50.82) (Ping timeout)
# [16:00] * Joins: glazou (glazou@84.14.50.82)
# [16:00] * Joins: yuma_1986 (yuma_1985@84.14.50.82)
# [16:04] * Joins: Kai (chatzilla@84.14.50.82)
# [16:09] * Joins: homata (homata@84.14.50.82)
# [16:10] * timeless_mbp is now known as timeless
# [16:11] * Joins: dethbakin (dethbakin@84.14.50.82)
# [16:11] * Quits: dethbakin (dethbakin@84.14.50.82) (Quit: dethbakin)
# [16:12] * Joins: joonho (joonholee@124.39.135.110)
# [16:12] * Quits: timeless (timeless@84.14.50.82) (Client exited)
# [16:12] <tabatkins> http://www.xanthir.com/blog/b48Z0
# [16:12] <fantasai> tabatkins: I put up a list of all the new changes that Alex and I have agreed on for the flexbox draft
# [16:13] <fantasai> fantasai suggests putting that on the mailing list
# [16:13] <fantasai> tabatkins: Most are pretty small; syntax-level changes
# [16:14] <fantasai> tabatkins: Major one is that we're changing the prefix from box- to flex-
# [16:14] <fantasai> tabatkins: Because box is overloaded in CSS
# [16:14] <fantasai> tabatkins: The next is determining the direction
# [16:14] * Joins: dethbakin (dethbakin@84.14.50.82)
# [16:14] <fantasai> tabatkins: We used to have two properties for that
# [16:14] <fantasai> tabatkins: Don't believe they need to cascade independently, so merged them into one that has all combinations
# [16:15] <fantasai> dbaron: That probably makes sense
# [16:16] <fantasai> tabatkins: At the last F2F sorta decided that things should flex differently when they're growing from when they're shrinking
# [16:16] * Joins: mollydotcom (mollyh@68.225.52.230)
# [16:16] <fantasai> tabatkins: e.g. having the biggest flex, which normally becomes the biggest, become the smallest when shrinking
# [16:16] <fantasai> tabatkins: Split into flex-grow and flex-shrink
# [16:17] <fantasai> tabatkins: Also margins participate in flexing
# [16:17] <fantasai> tabatkins: 'auto' flexes as 1
# [16:17] <fantasai> tabatkins: Very common use case was splitting things to align half items on left, half on right
# [16:17] <fantasai> tabatkins: previously had to add a dummy element
# [16:17] <fantasai> tabatkins: now can do that with margins
# [16:18] <fantasai> tabatkins: Keeping box-ordinal-group, renamed to something shorter
# [16:18] <fantasai> tabatkins: Multiple lines, not super-sure about
# [16:18] * Joins: timeless_mbp (timeless@84.14.50.82)
# [16:18] <fantasai> tabatkins: Seems like a large enough topic that it should be addressed more thoroughly
# [16:18] * Joins: freedom (freedom@84.14.50.82)
# [16:18] * timeless_mbp is now known as timeless
# [16:18] <fantasai> Alex: There are no current implementations right now of multiple lines
# [16:18] <fantasai> tabatkins: so thinking we might push that for the next level
# [16:19] <fantasai> Alex: What was the motivation for multiple lines?
# [16:19] <fantasai> dbaron: You'd have to ask hyatt. Not sure he'd know either
# [16:19] <fantasai> Alex: We had some use cases that seemed interesting, but not sure any of them are really important.
# [16:19] <fantasai> Alex: One example of multi-line box is a dialog box with a lot of tabs
# [16:19] <fantasai> Alex: But that's not a good design to begin
# [16:20] <fantasai> with
# [16:20] * Quits: freedom (freedom@84.14.50.82) (Connection reset by peer)
# [16:21] <fantasai> Alex: The biggest problem with multicol is how to handle the last line
# [16:21] <fantasai> Alex: Sometimes there's only one item on the last line
# [16:21] <fantasai> Alex: I'm not sure I've seen any good design for this
# [16:21] * Joins: smfr (smfr@68.183.26.22)
# [16:21] <fantasai> Alex: So multiline is only useful in combination with max width or something like that
# [16:22] <fantasai> fantasai had a use case of a catalog, with tiles representing each item;
# [16:22] <fantasai> fantasai: But pushing multiline flexbox to a next level makes sense to me
# [16:22] <fantasai> tabatkins: The major change is alignment in the transverse direction
# [16:22] <fantasai> tabatkins: Previously handled with box-align, which would align the box to the top, bottom, or centered
# [16:23] <fantasai> tabatkins: or could stretch the box
# [16:23] <fantasai> tabatkins: I expressed some unhappiness about that design
# [16:23] <fantasai> tabatkins: I spent some time looking at it and realized you can do every case except baseline with margins
# [16:23] * Bert (Talking about tab cards: I'd still like some way to turn a UL, or a sequence of SECTIONs, into a stack of cards with tabs... But that's unrelated to flexbox.)
# [16:23] <fantasai> tabatkins: Current proposal is to have one keyword that makes the box shrink
# [16:24] <fantasai> tabatkins: Can align that box with margins
# [16:24] <fantasai> tabatkins: ...
# [16:24] <fantasai> dbaron: The thing that seems weird to me is if the child is itself a flexbox with the alignment in the other direction
# [16:25] <fantasai> dbaron: It's unclear whether to throw out box-align or throw out box-pack
# [16:25] <fantasai> dbaron: normally the child is in the orthogonal direction
# [16:25] <fantasai> dbaron: The control was for the alignment in the axis direction
# [16:25] * fantasai is not understanding
# [16:25] <fantasai> dbaron: With your new proposal, if the child is a flexbox with an orthogonal direction
# [16:25] <fantasai> dbaron: which do you use?
# [16:26] <fantasai> dbaron: because you have two different things telling you how to align stuff
# [16:26] <fantasai> tabatkins: depends what the child wants to be
# [16:26] * Joins: freedom (freedom@84.14.50.82)
# [16:26] <fantasai> fantasai: I'm getting confused here
# [16:27] <fantasai> Alex: I think it's a good point. What we're trying to do here is require that the child layout has certain capabilities
# [16:27] <fantasai> Alex: So far there is only one precedent of requirement for nested layout, ability to declare its own baseline
# [16:27] <fantasai> Alex: We're adding requirement of declaring vertical alignment
# [16:27] <fantasai> Tab draws a big box with two small boxes inside
# [16:27] <fantasai> one on the left one on the right
# [16:28] <fantasai> right child has three boxes stacked vertically and is a flexbox
# [16:28] <fantasai> left child has squiggles aligned to the top
# [16:28] <fantasai> align: before assigned to big box
# [16:28] <fantasai> pack: end assigned to right child
# [16:29] <fantasai> Tab: Hm, I see what your'e talking about. Yes, this explicitly resolved somehow
# [16:29] <fantasai> dbaron: I think you'd want the thing on the child to beat the one on the parent
# [16:29] * Joins: ibrahima_ (qw3birc@128.30.52.28)
# [16:29] <fantasai> fantasai: Maybe make it not apply to flexboxes
# [16:30] <fantasai> Alex: What if the left one is a table?
# [16:30] <fantasai> dbaron: I think you want these differentiations to apply to non-flexbox children
# [16:31] <fantasai> Alex: Could define this alignment to only apply to block containers
# [16:31] <fantasai> dbaron: baseline has its own problems with vertical-axis flexboxes. That's it's own problem
# [16:32] <fantasai> Alex: We're making a complicated problem just to solve baseline alignment. Not sure it's worth it.
# [16:32] <fantasai> Tab: baseline alignment is very common for e.g. tab strips
# [16:33] <fantasai> Tab: Say I have <ul> with <li>, render as a horizontal flexbox tab strip
# [16:33] <fantasai> Tab: Would want different alignments, bottom aligned, baseline aligned, centered...
# [16:34] <fantasai> Alex: .. nested elements?
# [16:34] <fantasai> Tab: How would you do that with nested elements?
# [16:35] <fantasai> fantasai: You might want to align to the top baseline or to the bottom baseline
# [16:35] <fantasai> Alex: Let's step back and talk about logistics of the spec
# [16:36] <fantasai> Alex: Let's suppose hypothetically that next implementation comes out with this new syntax
# [16:36] <fantasai> Alex: Are the existing implementations going to add another new prefixed implementation for this new spec and then on the next round it will become standard which will be in three years from now? Is that the route that we are looking at?
# [16:36] <fantasai> Alex: The alternative would be to make small changes to the spec which makes Mozilla and WebKit implementations nearly compatible with the spec
# [16:37] <fantasai> Alex: Which means next release of webkit/mozilla/ie would bring us close to CR
# [16:38] <fantasai> Tab: There are some changes that are important and we definitely want, e.g. flex-grow flex-shrink split
# [16:38] * Joins: rigo (rigo@128.30.52.169)
# [16:38] <fantasai> Alex: Question is do we consider existing implementations important in validating the spec, in which case we are trying to make less changes as long as they are equivalent
# [16:38] <fantasai> Alex: Or are we taking the position that we are changing everything freely
# [16:38] <fantasai> Alex asks dbaron
# [16:39] <fantasai> dbaron: I think in the end we're going to have to rewrite a lot of it either way. Hard to say when that's going to happen.
# [16:39] <fantasai> dbaron: But I think we should try and get this right.
# [16:39] <fantasai> Alex: I'm not as concerned with complexity of implementations. I just want this to stabilize faster. Want to know if that matters.
# [16:40] <fantasai> dbaron: What are these changes relative to?
# [16:41] <fantasai> Tab: Last official WD
# [16:42] <fantasai> Tab: Dropped idea of flex units, since couldn't figure out baseline alignment with that.
# [16:44] <fantasai> discussion of stability, etc.
# [16:44] <fantasai> Markus suggests this is parallel to multicol, fantasai says it's not nearly as advanced--hasn't gone through design review, which we are doing now
# [16:46] <fantasai> more discussion of stability and implementation release schedules and interop on old syntax etc
# [16:46] <fantasai> Alex is concerned about interop on old standard
# [16:46] <fantasai> instead of on new standard
# [16:47] <fantasai> Tab: We can try to make changes to box-align more minor.
# [16:48] <fantasai> Tab: I tried to leave it unchanged and mix in vertical-align to align contents
# [16:48] <fantasai> Tab; But wasn't getting sane answers when I tried to map out how that works
# [16:49] * Quits: freedom (freedom@84.14.50.82) (Ping timeout)
# [16:50] <fantasai> ...
# [16:50] <fantasai> dbaron: I like the idea of using vertical-align. Want to know what the issues were.
# [16:51] <fantasai> Alex: If we resolve on everything except baseline, and can get those edits into the spec, that would be a great outcome of this meeting.
# [16:52] <fantasai> RESOLVED: Change prefix from box- to flex-
# [16:52] * Joins: freedom (freedom@84.14.50.82)
# [16:52] <fantasai> Next issue: combining box-orient and box-direction into flex-direction
# [16:52] <fantasai> Alex: I'm not too thrilled with changing that. think old is more intuitive
# [16:52] <fantasai> dbaron thinks the opposite: prefers Tab's proposal
# [16:53] <fantasai> RESOLVED: Combine box-orient and box-direction into flex-direction
# [16:53] <fantasai> RESOLVED: Split box-flex into flex-grow and flex-shrink
# [16:54] <fantasai> dbaron: I think what the spec said and what implementations did is different
# [16:54] <fantasai> fantasai: So maybe look into what current implementations do to determine default behavior of flex-shrink
# [16:55] <fantasai> Should auto margins flex as one?
# [16:55] <fantasai> fantasai: I'm strongly in favor
# [16:55] <fantasai> RESOLVED: 'auto' margins flex as 1
# [16:56] * Quits: szilles (chatzilla@84.14.50.82) (Ping timeout)
# [16:56] <fantasai> Tab: Drop box-flex-group? Not sure on this one
# [16:56] <fantasai> dbaron: I think splitting out flex-shrink would solve many of the use cases here
# [16:57] <fantasai> dbaron: Note we don't implement flex-group
# [16:57] <fantasai> Alex: We haven't heard any significant use cases, and it's expensive to implement
# [16:58] <fantasai> RESOLVED: Drop box-flex-group
# [16:58] <fantasai> Drop multiple-line support?
# [16:58] <fantasai> Alex: Mark at-risk?
# [16:59] <fantasai> dbaron: We should drop before CR if we're not sure that the spec is ready
# [16:59] <fantasai> dbaron: At-risk is something that is ready to be implemented, but we're not sure that it will be implemented
# [16:59] <dbaron> I'm ok with either way.
# [16:59] <fantasai> Tab: The existing behavior is well-specified, just too simplistic to be useful
# [17:00] <fantasai> RESOLVED: Mark multiline at-risk.
# [17:01] <fantasai> RESOLVED: Rename box-ordinal-group to either flex-order or flex-index (mark as issue)
# [17:01] <fantasai> Tab: Multiple lines .. current syntax is to take values of single or multiple
# [17:01] <fantasai> Tab: Suggest to change to box-wrap: wrap | nowrap
# [17:02] <fantasai> fantasai: Makes sense to me.
# [17:03] <fantasai> Alignment in transverse direction
# [17:03] <fantasai> Alex: Would it help to solve this problem if you could independently specify background on the flexbox item from the actual child?
# [17:04] * Joins: howcome (howcome@84.14.50.82)
# [17:04] <fantasai> Tab: It's weird, but would solve my use case
# [17:04] <fantasai> fantasai cringes
# [17:04] <fantasai> dbaron: Would prefer to solve it some other way than a pseudo-element
# [17:05] <fantasai> RESOLVED: Mark entire transverse alignment as an issue until further notice.
# [17:05] <fantasai> Topic: GCPM
# [17:05] <howcome> http://dev.w3.org/csswg/css3-gcpm/#page-selection-nth
# [17:05] <fantasai> howcome: Two issues I have
# [17:06] <fantasai> howcome: One thing we cut out earlier this year was named page lists
# [17:06] <fantasai> howcome: But the requirement is still there
# [17:06] <fantasai> howcome: There's a use case for being able to style pages differently.
# [17:07] <fantasai> howcome: Named page lists approach was heavyweight; not suggesting to re-add that
# [17:07] <fantasai> howcome: Suggesting :nth page selector
# [17:08] <fantasai> howcome: Here's an example *pulls up nearest book*
# [17:08] <arron> I would prefer this to be :nth-page not just :nth
# [17:10] * Joins: hsivonen (hsivonen@130.233.41.50)
# [17:10] <fantasai> howcome: You don't want headings on the spread of a chapter heading
# [17:10] * Joins: bradk (bradk@99.7.175.117)
# [17:10] <fantasai> fantasai: How about :first, :middle, :last?
# [17:11] <fantasai> howcome: Need to access 2nd page
# [17:11] <fantasai> fantasai: what for?
# [17:11] <fantasai> howcome: both pages on the spread of the chapter heading need to be selected to e.g. drop headers
# [17:13] <fantasai> discussion of how to indicate the start and end of a named series
# [17:13] * Quits: nimbupani (nimbupani@24.22.131.46) (Quit: nimbupani)
# [17:13] <dbaron> I think if you want @page chapter:nth(2), you need a new value for the 'page' property that makes a new chapter "restart" the sequence of chapter pages.
# [17:14] * Quits: anne (annevk@84.14.50.82) (Quit: anne)
# [17:14] <fantasai> Tab: You could have a :spread() that takes a page name, and is true if either side of the spread has a page with that name
# [17:15] <fantasai> fantasai: But all the pages in that book are "chapter" pages. You have to somehow distinguish the start and end of a particular chapter page series
# [17:16] <fantasai> howcome explains some use case involving widows and changing page sizes
# [17:17] <fantasai> glazou: complex selectors are very hard to present in a UI
# [17:17] <fantasai> glazou: I'm not saying the feature is not needed, just presenting a warning
# [17:20] <fantasai> dbaron: You want the nth page of that name.
# [17:20] <fantasai> dbaron: But that's actually different from the nth page
# [17:21] <fantasai> dbaron: They should be separate selectors
# [17:21] <dbaron> Some of these examples are :nth-of-name(), some are :nth-page()
# [17:21] <dbaron> or maybe :nth-of-name() should be :nth-of-sequence()
# [17:22] <dbaron> ?: maybe we don't need nth... just first-in-sequence?
# [17:22] <fantasai> fantasai: Seems to me you just need to address the first page, first spread, last page, and last spread of a named series
# [17:22] * Quits: freedom (freedom@84.14.50.82) (Connection reset by peer)
# [17:23] * Quits: smfr (smfr@68.183.26.22) (Quit: smfr)
# [17:23] * Joins: freedom (freedom@84.14.50.82)
# [17:23] <fantasai> howcome: The case I need to address an arbitrary page is to address widows and orphans
# [17:24] <fantasai> howcome: The publisher doesn't want to have a single line alone on a page
# [17:24] <fantasai> howcome: so he tweaks the size of the page before it to accommodate an extra line
# [17:25] <fantasai> Bert: TeX alters the line-height for this case
# [17:25] <fantasai> howcome: It's a spread. You want to keep the baselines even
# [17:25] <fantasai> Peter: you have this exact same problem in columns
# [17:25] <fantasai> Tab: Maybe we need more powerful orphan-widow properties
# [17:26] * Joins: mjs (mjs@84.14.50.82)
# [17:26] <fantasai> Peter: I don't like that we're targetting the page by number
# [17:27] <fantasai> Peter: You don't want to target the page with a problem.
# [17:28] <fantasai> Peter: If I edit the document: change the content, or the styling, the problem is no longer on the page I targetted.
# [17:28] <fantasai> glazou: It's a hack
# [17:30] <fantasai> Discussion returns to the 'page' property
# [17:30] * Joins: anne (annevk@84.14.50.82)
# [17:31] <tabatkins> glazou: What happens if the element that triggers a page group has a page break property. Then it's impossible to know which page is the second page he wants.
# [17:31] <tabatkins> howcome: If it's inserted before, you don't count it.
# [17:31] <tabatkins> howcome: The idea is that every chapter starts on the left of a spread.
# [17:32] <tabatkins> howcome: And you want to remove the headings on the second page of the chapter.
# [17:33] <tabatkins> glazou: No, you want to remove it on the other page of the spread that the chapter start is in.
# [17:33] <tabatkins> tabatkins: If the chapters start on the right, then you want to alter the last pag eof th eprevious chapter, instead.
# [17:34] * Bert thinks the sequence of named pages wasn't so bad...
# [17:34] <tabatkins> fantasai: [explains why chapter:first doesn't work, with analogy to p:first-child]
# [17:35] <tabatkins> fantasai: [explains :first-page(pagename), and :first-spread(pagename)]
# [17:36] <tabatkins> howcome: That doesn't solve the widows problem.
# [17:38] * Quits: homata (homata@84.14.50.82) (Ping timeout)
# [17:38] <tabatkins> plinss: It doesn't fully solve the existing problem, either. If the chapter starts on a right page, and the left page has content, you don't necessarily want to style the left page.
# [17:39] <fantasai> :first(pagename) selects the page on which an element with page: pagename; starts
# [17:39] <tabatkins> howcome: Yeah, you don't want to select backwards. Just select the second page, if the chapter starts on a left page.
# [17:39] <fantasai> :first-spread(pagename) selects that page and potentially the next page if they are part of the same spread
# [17:39] <fantasai> similarly for :last-page(pagename) and :last-spread(pagename)
# [17:40] <tabatkins> tabatkins: Okay, if that's the case then I don't have a problem with selecting the second page explicitly.
# [17:41] <tabatkins> glazou: I think that this offers too much power - it will be abused.
# [17:42] <fantasai> and you can combine with :left or :right for styling as needed
# [17:42] <Kai> Wondering about workflows. As discussed now a piece of text to be printed will have to be styled after all textual changes have been made. Any changes to the text before that might change the layout and leave the author to re-style the whole text.
# [17:43] <fantasai> Peter: Whether you have left and right pages or just right pages is a print-time decision
# [17:43] <fantasai> fantasai: not in CSS. All pages are classified as left or right
# [17:43] <fantasai> howcome: Right, suppose you're printing to PDF
# [17:43] <fantasai> Peter: If I print this document in non-duplex mode, I don't want left and right pages
# [17:44] <fantasai> Alex: could you have a media query for whether you have facing pages?
# [17:46] <fantasai> unminuted discussion
# [17:47] <fantasai> howcome: I want to suppress the headings on the pages in both page on the spread to be suppressed
# [17:48] <fantasai> peter: You want controls for spreads, not for numbered pages
# [17:48] <fantasai> Topic: Other
# [17:48] <fantasai> Bert: We can talk to XSLFO people. They've done this before
# [17:49] <fantasai> Bert: It might be more involved than just headers and footers.
# [17:49] <howcome> http://dev.w3.org/csswg/css3-gcpm/#the-hyphenate-last-line-avoid-property
# [17:49] * dbaron wonders if this is the one-more--hyphen---property
# [17:50] * Quits: ibrahima_ (qw3birc@128.30.52.28) (Ping timeout)
# [17:52] * Quits: parkjy (qw3birc@128.30.52.28) (Ping timeout)
# [17:52] <fantasai> Alex: Do we need a control for this property?
# [17:52] * Quits: rigo (rigo@128.30.52.169) (Client exited)
# [17:52] <fantasai> Alex: Couldn't we just always avoid it?
# [17:52] * dbaron thinks Antarctica should be Ant-arc-ti-ca
# [17:53] <fantasai> fantasai: Do we need a control for this, or can we just have the UAs be smart about it?
# [17:55] <fantasai> jdaggett: Do we need different values?
# [17:55] <fantasai> howcome: There are different policies among publishers. This is a control that's been asked for.
# [17:55] <dbaron> howcome: We can drop the 'always' value; it's not as important.
# [17:55] <fantasai> glazou: What happens if the last word is wider than the column?
# [17:56] <fantasai> howcome: It's an avoid, not a requirement
# [17:56] * Quits: myakura (myakura@84.14.50.82) (Ping timeout)
# [17:57] <fantasai> I think auto should be asking the UA to be smart and do something reasonable, not allowing anything....
# [17:58] <fantasai> Alex: spread should be on by default. Or maybe more than spread
# [17:58] * Quits: MoZ (540e3252@128.30.52.43) (Quit: CGI:IRC (Ping timeout))
# [17:58] * Joins: smfr (smfr@17.203.14.12)
# [18:00] <fantasai> Peter: Publishers do manual tweaking to avoid awkward breaks. Reset breaking for one particular word on one particular page
# [18:00] <fantasai> Peter: We're not going to do that in CSS
# [18:00] * sylvaing next topic: text-replace: "100" "1e2";
# [18:02] <fantasai> Peter describes some of the difficult aspects of pagination
# [18:02] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
# [18:02] * Quits: anne (annevk@84.14.50.82) (Quit: anne)
# [18:02] <fantasai> Peter: But if you tweak things at that level, you only satisfy layout for that particular output instance
# [18:03] <Bert> (Another way to reduce the ugliness in the example: This is just a / simple ex- / ample to show / Antarctica.)
# [18:03] * Quits: kennyluck (kennyluck@128.30.52.28) (Quit: kennyluck)
# [18:03] <fantasai> Peter: It doesn't apply if you change any of the output environment parameters
# [18:03] <fantasai> Peter: By flipping this switch, it'll help some of the time and hurt some of the time.
# [18:03] <Kai> isn't it exactly the ability to output on different output environments that makes this feature necessary?
# [18:04] * Quits: mjs (mjs@84.14.50.82) (Quit: mjs)
# [18:04] * tabatkins Bert, that requires more adaptive hyphenation, which is almost certainly too expensive for the web. Fine for print, though.
# [18:04] <fantasai> Peter: I read e-documents on this thing (iphone) all the time. And I change the font size all the time.
# [18:05] <fantasai> Peter: The author isn't thinking of that
# [18:05] * Joins: mjs (mjs@84.14.50.82)
# [18:05] * Quits: mjs (mjs@84.14.50.82) (Quit: mjs)
# [18:06] <fantasai> Peter: I don't want us to target the weird thing that happens on my computer. I want to target the general problem.
# [18:07] * Quits: johnjan (qw3birc@128.30.52.28) (Quit: Page closed)
# [18:07] <fantasai> Meeting closed.
# [18:07] * Quits: dethbakin (dethbakin@84.14.50.82) (Quit: dethbakin)
# [18:07] * Quits: Kai (chatzilla@84.14.50.82) (Quit: ChatZilla 0.9.86 [Firefox 3.6.10/20100914125854])
# [18:07] * Quits: mgylling (mgylling@84.14.50.82) (Quit: mgylling)
# [18:07] * Quits: yuma_1986 (yuma_1985@84.14.50.82) (Quit: TakIRC)
# [18:08] * Quits: glazou (glazou@84.14.50.82) (Quit: glazou)
# [18:08] * Quits: dsinger (dsinger@84.14.50.82) (Quit: dsinger)
# [18:09] * Quits: jdaggett (jdaggett@84.14.50.82) (Quit: jdaggett)
# [18:09] * Quits: joonho (joonholee@124.39.135.110) (Ping timeout)
# [18:09] * Quits: sylvaing (sylvaing@84.14.50.82) (Quit: sylvaing)
# [18:10] * Quits: alexmog (qw3birc@128.30.52.28) (Ping timeout)
# [18:10] * Quits: MikeSmith (MikeSmith@84.14.50.82) (Ping timeout)
# [18:11] * Quits: mmielke (mmielke@84.14.50.82) (Ping timeout)
# [18:11] * Quits: tabatkins (tabatkins@84.14.50.82) (Ping timeout)
# [18:12] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
# [18:13] * Quits: sbhan (qw3birc@128.30.52.28) (Quit: Page closed)
# [18:15] * Quits: timeless (timeless@84.14.50.82) (Quit: Leaving.)
# [18:15] <smfr> fantasai: is there any chance of getting minutes published at the end of each day?
# [18:16] * Joins: dsinger (dsinger@84.14.50.82)
# [18:16] <fantasai> smfr: I suppose I could do it if you really really really need it
# [18:16] <fantasai> smfr: It will take me probably around 4 hours
# [18:17] * Quits: freedom (freedom@84.14.50.82) (Ping timeout)
# [18:17] <smfr> fantasai: i'm curious about some of the discussion in the morning.
# [18:17] <fantasai> RRSAgent: pointer
# [18:17] <RRSAgent> See http://www.w3.org/2010/11/01-CSS-irc#T17-14-09
# [18:17] <fantasai> The IRC logs are available
# [18:17] <fantasai> see above
# [18:17] <smfr> ah excellent, thanks!
# [18:17] <smfr> that's fine
# [18:17] <fantasai> cool
# [18:18] * Quits: dbaron (dbaron@63.245.220.11) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [18:19] * Parts: mollydotcom (mollyh@68.225.52.230)
# [18:21] * Joins: bradk_ (bradk@166.205.139.77)
# [18:21] * Quits: plinss_ (plinss@84.14.50.82) (Quit: plinss_)
# [18:22] * Quits: dsinger (dsinger@84.14.50.82) (Quit: dsinger)
# [18:22] * Joins: TabAtkinsTPAC (chatzilla@212.180.75.100)
# [18:22] <bradk_> Hello
# [18:23] * Quits: howcome (howcome@84.14.50.82) (Ping timeout)
# [18:23] <TabAtkinsTPAC> brad!
# [18:24] <bradk_> Howdee. Do you know where I can find the schedule of what you'll be discussing? And raw irrc log of discussion so far?
# [18:25] <smfr> RRSAgent: pointer
# [18:25] <RRSAgent> See http://www.w3.org/2010/11/01-CSS-irc#T17-22-43
# [18:26] <smfr> bradk_: ^^ irc log
# [18:27] <bradk_> Thanks
# [18:29] * Joins: jdaggett (jdaggett@93.158.28.68)
# [18:30] <bradk_> I also could not find the link to agenda wiki in my email. I know it must be there somewhere, but I must be searching for the wrong terms.
# [18:30] * Joins: mgylling (mgylling@212.180.75.100)
# [18:35] * Joins: mmielke (mmielke@93.158.30.183)
# [18:35] <smfr> TabAtkinsTPAC: i think a big unresolved transform issue is how they apply to inlines
# [18:36] <TabAtkinsTPAC> bradk_: the link to the agenda should be at the very beginning of the irc logs.
# [18:36] <TabAtkinsTPAC> smfr: Yes, indeed. Should we talk about that during the FXTF meeting on Thursday, or what?
# [18:37] <smfr> TabAtkinsTPAC: i think the css-wg is more likely to have useful input
# [18:37] <TabAtkinsTPAC> Ok. I'll push it on the agenda tomorrow.
# [18:37] <smfr> if it's later afternoon i could join
# [18:37] <TabAtkinsTPAC> The question is between transform-each-box or transform-bounding-box, right?
# [18:37] <TabAtkinsTPAC> kk
# [18:37] <smfr> options are:
# [18:38] <smfr> 1. disallow transforms on inlines
# [18:38] <smfr> 2. transform the bounding box
# [18:38] <smfr> 3. transform line boxes somehow
# [18:38] <TabAtkinsTPAC> kk
# [18:38] <smfr> 4. transform each bit like gecko does
# [18:38] <smfr> 5. maybe others
# [18:38] <TabAtkinsTPAC> Oh, right, (4) is different because of, frex, bidi mixes within a line?
# [18:39] <smfr> right
# [18:39] <smfr> i'm tempted to suggest `
# [18:39] <smfr> er, 1
# [18:39] <TabAtkinsTPAC> Yeah, that might be the best.
# [18:39] <smfr> authors can use inline-box if they have to
# [18:39] <arron> I think 1 would be best too
# [18:39] <TabAtkinsTPAC> We resolved on "just don't allow it on inline" for column spans in multicol, so it seems like we're comfortable with that.
# [18:40] <smfr> sweet
# [18:40] <TabAtkinsTPAC> smfr: Any thought on radial gradient canonical forms, while I have you here?
# [18:40] <smfr> no, i haven't studied the radial gradients spec yet
# [18:41] <smfr> saw your emails tho
# [18:41] <TabAtkinsTPAC> Did you read my email from yesterday?
# [18:41] <smfr> i saw it, then saw the second one so didn't read the first one entirely ;)
# [18:41] * Quits: arron (Arron@24.17.123.244) (Quit: arron)
# [18:42] <smfr> TabAtkinsTPAC: i don't quite grok the start point + angle form
# [18:43] <TabAtkinsTPAC> Okay, so here's how it works.
# [18:43] <smfr> you say the end point is the start rotated around the middle, but that's not true if there's an angle
# [18:43] <TabAtkinsTPAC> Right. What you do is, first, draw the reference line from the start point to the rotated end point.
# [18:43] * Joins: arron (arronei@166.205.141.3)
# [18:43] <TabAtkinsTPAC> Then, rotate the reference line *around the center of the box* by the angle.
# [18:43] <smfr> ok, so 2 things affect the final slant
# [18:43] <smfr> the points, and the angle
# [18:44] <TabAtkinsTPAC> Then the gradient start is the "point on the reference line where a line drawn perpeendicular intersects X cornere", etc.
# [18:44] <TabAtkinsTPAC> Yes, they work together, and have good behavior for their defaults.
# [18:44] <smfr> hmm, that sounds more complicated
# [18:45] <smfr> and it doesn't address the use of the explicit start/end points which places the gradient over some sub-rect
# [18:45] <TabAtkinsTPAC> Only because the combination of both a ref-line and an angle is strictly unnecessary. It's only specced that way so that the two cases are specific instances of a general case, and can be transitioneed together.
# [18:46] <TabAtkinsTPAC> smfr: I don't know if that's actually a use-case. I've never had to do that.
# [18:46] <TabAtkinsTPAC> And I made myself a gradient-image generator in PHP, so I used gradients pretty freely in designs.
# [18:48] * Joins: plinss_ (plinss@212.180.75.100)
# [18:48] <TabAtkinsTPAC> 95% of use-cases, I think, can be addressed solely with either an angle, or a box-cardinal direction.
# [18:48] <TabAtkinsTPAC> I'd be fine with just speccing both of those as separate functions, but if I can make a single function do them both without a lot of hassle, then I'd prefer to.
# [18:49] <TabAtkinsTPAC> I'd like to align whatever solution I do for linear gradients with a similar solution for radials, though. Radials are a much harder problem.
# [18:49] <TabAtkinsTPAC> Anyway, let me post that email to the list.
# [18:49] <smfr> k
# [18:53] * Quits: murakami (murakami@118.154.209.3) (Quit: Leaving...)
# [18:54] <TabAtkinsTPAC> k, sent. now, off to dinner for a few hours.
# [18:55] <TabAtkinsTPAC> bradk_: Check out the email too. I think the model I propose for linear gradients has roughly equivalent power to yours, but more continuous behavior and less abstraction.
# [18:56] <TabAtkinsTPAC> bradk_: I still don't like the mode where you pretend that the angle is relative to a unit box and then transform it. But this one, where a bare angle is relative to a horizontal line and thus gives us the algebra-inspired behavior, still seems cool.
# [18:58] * Quits: tantek (tantek@70.36.139.128) (Quit: tantek)
# [18:58] * Quits: mmielke (mmielke@93.158.30.183) (Quit: mmielke)
# [19:07] * Joins: plinss__ (plinss@212.180.75.100)
# [19:07] * Quits: plinss__ (plinss@212.180.75.100) (Connection reset by peer)
# [19:07] * Joins: plinss__ (plinss@212.180.75.100)
# [19:07] * Quits: plinss_ (plinss@212.180.75.100) (Connection reset by peer)
# [19:34] * Quits: plinss__ (plinss@212.180.75.100) (Ping timeout)
# [19:42] * Joins: nimbupani (nimbupani@24.22.131.46)
# [19:42] * Quits: nimbupani (nimbupani@24.22.131.46) (Quit: nimbupani)
# [19:56] * Quits: arron (arronei@166.205.141.3) (Quit: Colloquy for iPhone)
# [19:56] * Quits: arronei (arronei@131.107.0.83) (Ping timeout)
# [20:02] * Joins: arronei (arronei@131.107.0.91)
# [20:03] * Quits: jdaggett (jdaggett@93.158.28.68) (Ping timeout)
# [20:15] * Joins: bradk__ (bradk@166.205.138.206)
# [20:16] * Quits: bradk_ (bradk@166.205.139.77) (Ping timeout)
# [20:18] * Joins: tantek (tantek@67.218.98.105)
# [20:20] * Quits: tantek (tantek@67.218.98.105) (Quit: tantek)
# [20:21] * Joins: jdaggett (jdaggett@93.158.29.217)
# [20:21] * Quits: jdaggett (jdaggett@93.158.29.217) (Quit: jdaggett)
# [20:25] * Quits: bradk__ (bradk@166.205.138.206) (Quit: Signing Off. Buh-bye. )
# [20:28] * Parts: mgylling (mgylling@212.180.75.100)
# [20:44] * Joins: nimbupani (nimbupani@24.22.131.46)
# [20:46] * Quits: nimbupani (nimbupani@24.22.131.46) (Quit: nimbupani)
# [21:25] * Joins: bradk_ (bradk@166.205.138.206)
# [21:49] * Joins: Peter` (peter@85.223.116.170)
# [21:50] * Quits: beverloo (peter@85.223.116.170) (Ping timeout)
# [21:54] <bradk_> Tab, I see it the other way around, where the keyword just turns off the bit that prevents the angle from stretching as the box stretches.
# [22:13] * Quits: bradk_ (bradk@166.205.138.206) (Quit: Signing Off. Buh-bye. )
# [22:25] * Quits: Ms2ger (Ms2ger@91.181.144.192) (Quit: nn)
# [22:32] * Quits: smfr (smfr@17.203.14.12) (Client exited)
# [23:31] * Quits: arronei (arronei@131.107.0.91) (Quit: arronei)
# [23:34] * Joins: arronei (arronei@131.107.0.94)
# Session Close: Tue Nov 02 00:00:00 2010

The end :)