SV_MEETING_TITLE -- 01 Nov 2010

<glazou> http://wiki.csswg.org/planning/tpac-2010

<tabatkins> glazou: What's mos timportant? I think we need clilley for the charter discussion.

<tabatkins> jdaggett: Two things I want to discuss tomorrow are Fonts and Writing Modes.

<tabatkins> sylvaing: We'd like to do Grid first thing tomorrow morning.

<tabatkins> Bert: We have a guest who wants to talk about Writing Modes, and Mike.

<tabatkins> glazou: Microsoft guys, wanna talk about Flexbox before Grid?

<tabatkins> sylvaing: Not that important, just want to talk about both.

<tabatkins> glazou: We can probably start this morning with css3 values.

<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.

<tabatkins> glazou: Markus Gylling is here, so can we talk about EPUB liaison stuff later this morning?

<tabatkins> Markus Gylling: Yes.

<tabatkins> glazou: Slow font downloading, should it be lumped with CSS3 Fonts?

<tabatkins> jdaggett: Yes, and hopefully Tues afternoon, because Slye will be here then.

<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

<tabatkins> glazou: So I suggest we start with 2d transforms, epub, and css2.1 testing this morning.

<tabatkins> glazou: We now have 4 impls on the table: gecko, webkit, opera, and ms.

<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.

<tabatkins> sylvaing: We have some things that need to be resolved, like the DOM interface relying on some obsolete stuff.

<tabatkins> sylvaing: No one but Webkit implements it yet, I think.

<tabatkins> anne: Maybe we should drop it for now until we figure out what we want to do with the Values APIs.

<tabatkins> glazou: I think marking as at-risk would be better.

<tabatkins> dbaron: The section on Transitions has several bugs in the spec. bzbarsky forwarded a message from Tim Terriberry sent feedback explaining several of them, and you can see these bugs in Webkit.

<sylvaing> CSS3 2D Transforms transition/animation section: http://www.w3.org/TR/css3-2d-transforms/#animation

<tabatkins> dbaron: The other issue is transforms that affect layout.

<tabatkins> dbaron: I could see getting a first version to REC without that, but I'd rather fix it first.

<tabatkins> jdaggett: Isn't that a big issue?

<tabatkins> dbaron: Not necessarily.

<tabatkins> dbaron: Some big things, but some small things.

<tabatkins> sylvaing: That affects things like offsetTop, etc.

<tabatkins> dbaron: Right, but they kind of suck without a layout-effecting transform anyway.

<tabatkins> sylvaing: It would definitely lengthen the time it would take to get to CR.

<tabatkins> dbaron: Yeah, I think it does make sense to move it to CR first without this.

<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.

<tabatkins> anne: The concern is that nobody's tried to ipmlement it yet.

<tabatkins> anne: I think that Transforms should redefine the boxes that already exist when transformed; the border box should get bigger, etc.

<tabatkins> anne: So I don't have to constantly reference Transforms when talking about boxes.

<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.

<tabatkins> anne: I think browsers act like the transform didn't happen for now.

<tabatkins> anne: Which works for me - if the border box doesn't change, and only alters for painting, that's easy.

<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.

<tabatkins> sylvaing: We have 4 impls, is what we have enough for authors? Are we missing use-cases?

<tabatkins> dbaron: I think we're definitely missing use-cases, but I think we're still okay to move forward.

<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?

<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.

<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?

<tabatkins> glazou: For example, if you have a rotation and want to rotate it a bit further, it's a huge pain.

<tabatkins> sylvaing: You can do that now through the matrix api, but it uses CSSValue, which we're not going to implement.

<tabatkins> jdaggett: Like, if you do a rotate, transform, rotate, you lose something. What do you want to show to authors?

<tabatkins> glazou: The three operations, hopefully - a stack.

<tabatkins> dbaron: We have to store that information and pass it through anyway to do the transitions.

<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.

<tabatkins> dbaron: Do you really need it at the computed level? Is specified enough? You already have it on the specified level.

<tabatkins> glazou: Yes, but it's a string that you have to parse, which is unacceptable.

<tabatkins> tabatkins: So make Anne work on the Values API faster. ^_^

<tabatkins> szilles: What does SVG do? Also, is the matrix decomposition unique?

<tabatkins> dbaron: There's a reference to an algorithm for a unique decomposition, but it's buggy (I raised this earlier).

<tabatkins> dbaron: I think that authors want back the order they originally specified, though, rather than some canonical transform.

<anne> tabatkins, the last on that is that people should start experimenting

<tabatkins> sylvaing: Also, SVG can do each transform from a different origin, while CSS does the whole thing from a single origin.

<tabatkins> Anthony (SVG): Doesn't look like SVG has a neat way of getting back the original transforms either.

<tabatkins> glazou: Sounds like something we can discuss in the FXTF meeting.

<tabatkins> RESOLVED: Discuss an API to parse the specified value into an author-convenient form, before pushing the spec forward.

<tabatkins> glazou: Next, tests. What kind of tests do we need for Transforms, who will write them, what schedule?

<tabatkins> glazou: Corollary - do we have enough interop that we can remove prefixes?

<tabatkins> dsinger: If Transitions is going to move slower than Transforms, we should move the section on Transitioning Transforms to the Transitions spec.

<tabatkins> anne: Can we require that this testsuite only has reftests?

<tabatkins> johnjan: No, we can't require it.

<tabatkins> anne: Why not?

<tabatkins> tabatkins: Can we resolve that everything that *can* be reftests, *must* be reftests?

<tabatkins> johnjan: Yeah, that's acceptable.

<tabatkins> dbaron: We have 107 reftests for Transforms. I'd need to ensure they're all test-suite worthy.

<tabatkins> glazou: We'd probably need a lead on the 2d testsuite.

<tabatkins> johnjan: I can do that.

<dbaron> (also a bunch of parsing tests)

<tabatkins> glazou: dbaron, can you estimate how many tests we might need for the Transforms spec?

<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.

<anthony> SVG test suite is here: http://dev.w3.org/cvsweb/SVG/profiles/1.1F2/test/svg/?sortby=file#dirlist

RESOLUTION: Any Transforms tests that can be reftests must be reftests.

<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.

<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

<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.

<tabatkins> glazou: So, maybe a CR/PR by June would be awesome.

<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?

<tabatkins> RESOLVED: Remove the value API from 2d Transforms.

<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.

<tabatkins> shepazu: So people are going to get a point, expect it to be in one place, and it's not there.

<tabatkins> shepazu: It's a tricky solution but that can be exposed simply for authors.

<tabatkins> shepazu: smfr already has a very good idea of what's evolved there, and he'll add it to the 2d transforms spec.

<tabatkins> glazou: More agenda!

<tabatkins> glazou: howcome, we have some things for you.

<tabatkins> howcome: 15 minutes each, they're all easy. ^_^

<tabatkins> glazou: today, beginning of afternoon?

<tabatkins> howcome: Yeah.

<tabatkins> Gylling: I'm the AC rep of the DAISY consortium, but here today for EPUB and the IPDF.

<tabatkins> gylling: This isn't really intended to be a primer for epub, so let's move quickly through that.

<tabatkins> gylling: In the current revision of epub, we have adobe, apple, google, and other organizations working with us.

<tabatkins> gylling: What makes epub stand out in the ebook wars is that epub uses w3c standards as the highest priority.

<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.

<tabatkins> jdaggett: What does that mean? Final spec, or impls?

<tabatkins> gylling: Final spec. The ipdf bylaws do not echo the w3c in requiring 2 independent impls.

<tabatkins> gylling: Of course, as we use existing web techs, generally there were already sufficient impls by the time we used something.

<tabatkins> gylling: But the situation is becoming somewhat more tricky now.

<tabatkins> gylling: bert, you sent a few questions earlier?

<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?

<mgylling> http://code.google.com/p/epub-revision/wiki/ImplementationPipeline

<tabatkins> gylling: This is the current schedule.

<tantek> greetings from SF.

<tantek> sorry I couldn't be there in person!

<tabatkins> gylling: So we started out this summer collecting requirements. it was an open-ended process initially.

<tabatkins> gylling: In our SF meeting two weeks ago, we deferred/postponed a large number of our requirements.

<tabatkins> gylling: So we now have a smaller set of requirements that can be reviewed.

<tabatkins> gylling: This is what the epub wg has set out to have done by May next year.

<tabatkins> gylling: There are a few outstanding items, that we'll talk about tomorrow.

<tabatkins> gylling: But one of th emajor things we intend to do in this revision is to increase ou support for i18n.

<tabatkins> gylling: Writing Modes is one of th emost critical features for us right now in epub.

<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.

<tabatkins> gylling: Inverting the question, though, would an implementation in an ebook device suffice to satisfy the w3c requirements?

<tabatkins> Bert: That's what I was trying to get at. Are your results public?

<tabatkins> gylling: If we can submit test results based on ebook devices, there's not a bunch of problem.

<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.

<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

<tabatkins> fantasai: I'm trying to stabilize the specs as fast as possible.

<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.

<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.

<tabatkins> howcome: There seems to be some kind of consensus that epub has accepted the alternate stylesheet approach.

<tabatkins> fantasai: Right. I think epub is clear that Writing Modes is unclear until after TPAC.

<tabatkins> szilles: We shouldn't be having a discussion about what we'll do after a discussion until after the discussion.

<tabatkins> howcome: If I'm right, you're aiming for a per-document writing-mode switch, right?

<tabatkins> fantasai: Right, though you'll have some form of mixed content.

<tabatkins> fantasai: In terms of being able to switch the entire stylesheet, epub has accepted the alternate stylesheet mechanism.

<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.

<tabatkins> howcome: CSS now has a way to do running headers and footers. Will epub adopt that as well?

<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.

<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.

<tabatkins> Bert: How does your collab/discussion process work?

<tabatkins> Bert: If we have a question, how do we send it?

<tabatkins> gylling: I think the easiest is to set up a liaison.

<tabatkins> gylling: They would participate in our weekly telcons and our mailing list, which is public.

<tabatkins> jdaggett: The way epub is set up, different "working groups" handle different areas. One handles i18n, another handles styling, etc.

<tabatkins> jdaggett: I think there's a minor dependency on CSS3 Speech?

<tabatkins> gylling: Right - i18n and css aren't the only thing. We also need, frex, pagination.

<tabatkins> howcome: What do you mean by pagination?

<tabatkins> gylling: Dynamic reflow and pagination. Also page templates.

<tabatkins> gylling: The feature that overshadows everything else is Writing Modes, though.

<tabatkins> Bert: I'd like to have some names to follow who know what's going on.

<tabatkins> kojiishi: I'm fine with being the liaison for egls (?), but would like someone else that can handle the other groups.

<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.

<tabatkins> MikeSmith: kennyluck has some insights into the vertical text issues as well.

<tabatkins> fantasai: I can attend the epub telcon - it's at a sane time in pacific timezone.

<tabatkins> gylling: So if I understand correctly, we have a liaison, we'll find out if ebook impls can serve as impls for tests.

<tabatkins> fantasai: ebook readers will certainly serve.

<tabatkins> Bert: Also a question is the test format.

<tabatkins> gylling: I think epub with write access could do the tests in css format and contribute the results directly.

<tabatkins> Bert: Are there resources set aside for testing purposes?

<tabatkins> gylling: I can't give you firm numbers, but yes, there will be resources for testing.

<tabatkins> Bert: Any idea how many impls you expect to exist?

<tabatkins> gylling: Can't say. But in terms of rendering, there are 4 separate entities, only one of which is based on webkit.

<tabatkins> gylling: CSS3 Speech now.

<tabatkins> gylling: One of the things we're doing in epub is to enhance, for a11y reasons, speech synthesizers.

<tabatkins> gylling: We'd like to bring new life into the css3 speech module.

<tabatkins> gylling: The daisy consortium has a person we'd like to submit as a new editor.

<tabatkins> glazou: No problem.

<tabatkins> jdaggett: As long as they're a W3C member.

<tabatkins> fantasai: I looked over the spec, and I think claudio (?) did a good job of cleaning it up.

<tabatkins> fantasai: I think there's a section we should keep, another we shoudl drop, but otherwise sounds good.

<tabatkins> glazou: Is there already interest in implementing it?

<tabatkins> gylling: Yes, especially from the a11y who wants to interact with epub.

<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.

<tabatkins> gylling: The people you mentioned are currently meeting as the Speech Incubator group. I'll be meeting with them.

<tabatkins> glazou: Could you report to the WG after you meet with them?

<tabatkins> gylling: I'll try.

<plinss_> <br type='coffee' />

<myakura> re css3-speech, WebKit implemented 'speech' property about a month ago. http://webkit.org/b/46827

CSS2.1 Testing

round of intros

<ilkka> my name is Ilkka Oksanen

<tabatkins> glazou: Test suite current status?

<tabatkins> fantasai: Published a snapshot last week.

<tabatkins> fantasai: I haven't done any work on it since then.

<tabatkins> dsinger: Because it's perfect?

<tabatkins> fantasai: No, I've just been working on other stuff.

<tabatkins> fantasai: There's still a lot of error reports that ahven't been addressed. I'm guessing a couple weeks.

<tabatkins> glazou: What are the IR results? How many tests that don't pass 2 impls?

<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.

<tabatkins> tabatkins: To be clear, a lot of those tests are rc3 and haven't been tested by several browsers yet.

<tabatkins> jdaggett: Question on what versions are allowed?

<tabatkins> plinss: Public availability, and results must be a month old.

<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.

<tabatkins> jdaggett: I think we should require a public *binary*, not just source.

<tabatkins> tabatkins: So, we only release binaries for our public channel, every 6 weeks or so.

<tabatkins> johnjan: So, IE9 developer previews count?

<tabatkins> jdaggett: Sure, as long as we can get historical versions that the suite was run for.

<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.

<tabatkins> dsinger: Are there tests that are failing because the spec is wrong?

<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.

<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.

<tabatkins> glazou: I'd like to see all info about that in front of the group as soon as possible.

<tabatkins> dsinger: I'd just like a good wiki page somewhere that lists all the tests in each of those categories.

<tabatkins> dsinger: And then slowly see that page empty out until we're done.

<tabatkins> dbaron: 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.

<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.

<tabatkins> fantasai: CSS3 Lists defines list numbering, but CSS2.1 doesn't.

http://wiki.csswg.org/test/css2.1/issues

<tabatkins> glazou: My problem is that I don't have any stable visibility on the status of the testsuite.

<tabatkins> jdaggett: So what are you proposing, daniel? A specific date?

<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.

<tabatkins> johnjan: Is Nov 15th still the date for not changing the testsuite, or at least just triaging at that point?

<tabatkins> fantasai: That's a little early. I'll need two weeks after this for my changes.

<tabatkins> johnjan: Yeah, and we'll also need to do reviews of the changes.

<tabatkins> johnjan: So is 2 weeks enough time?

<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.

<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.

<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.

<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.

<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.

<tabatkins> glazou: So we'll have IRs based on the locked version by the end of year?

<tabatkins> johnjan: Early december, I think.

<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]

<tabatkins> jdaggett: Also, could you record the useragent language? Some of the font tests are locale-specific.

<tabatkins> plinss: Yes, I have the useragent data, so I'll pull that data out.

<tabatkins> RESOLVED: Target Nov 22nd for test suite RC4 freeze.

<tabatkins> dbaron: Did you publish change lists from rc1-2, and rc2-3?

<tabatkins> fantasai: I think I did rc2-3.

<tabatkins> plinss: I have changed test data, so I can generate a list like that.

http://lists.w3.org/Archives/Public/public-css-testsuite/2010Oct/0369.html

http://lists.w3.org/Archives/Public/public-css-testsuite/2010Oct/0005.html

<tabatkins> johnjan: I'd like to bring up a question about a consistent place to store the impl reports - the .data files.

<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.

<scribe> ACTION: fantasai to update links from W3C to implementation reports and test suite releases [recorded in http://www.w3.org/2010/11/01-CSS-minutes.html#action01]

<trackbot> Created ACTION-272 - Update links from W3C to implementation reports and test suite releases [on Elika Etemad - due 2010-11-08].

<tabatkins> plinss: I've put them in the rc1 and rc2 folders as appropriate.

<tabatkins> dbaron: We have a larg enumber of IR bugs because of one issue with Ahem fonts where the tests are questionably valid.

<tabatkins> dbaron: The Ahem font has a lot of glyphs that are boxes - they are exactly 1em tall and wide.

<tabatkins> dbaron: The baseline of the font is 4/5ths from the top to the bottom of the font.

<tabatkins> dbaron: So all the ascent metrics are 80% of the em square, the descents are 20%.

<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.

<tabatkins> dbaron: On Windows, our font metrics backend makes it okay.

<tabatkins> dbaron: We don't get good enough information anyway, so we just throw one out and subtract from the height.

<tabatkins> dbaron: But on Linux we get good info, so we use both the ascent and descent data, and both are rounded up.

<tabatkins> dbaron: So a pretty large amount of our test failures are because the Ahem font isn't a multiple of 5px.

<tabatkins> dbaron: I marked them as Moz bugs, but I could equally mark them as invalid, which could flip 50-80 tests.

<tabatkins> jdaggett: I think that in general we shouldn't be relying on rounding behavior.

<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.

<tabatkins> alexmog: The spec doesn't say that fonts have to be round numbers of pixels.

<tabatkins> jdaggett: Yes, but the spec also doesn't specify how to round, so we can't rely on rounding.

<tabatkins> chrisl: Can we just ignore the fact that windows GDI does weird things? We have two impls that use correct platform behavior.

<jdaggett> waterfall test for non-integer font sizes:

<jdaggett> http://people.mozilla.org/~jdaggett/tests/decimalfontwaterfalls.html

<jdaggett> alexmog: ^

<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.

<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.

<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.

<tabatkins> dbaron: Some were font ones, which I handed to jdaggett.

<tabatkins> jdaggett: I fixed the tests.

<dbaron> http://lists.w3.org/Archives/Public/public-css-testsuite/2010Oct/0178.html

<dbaron> http://lists.w3.org/Archives/Public/public-css-testsuite/2010Oct/0175.html

<tabatkins> jdaggett: But the metric ones we still need to look at.

<dbaron> And the other Moz failures I didn't analyze were margin-collapse-157, margin-collapse-clear-005 and margin-collapse-clear-011

<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.

<tabatkins> chrisl: Perhaps that's a spec problem, if an implementor finds it too difficult to figure out from the spec what should happen.

<tabatkins> fantasai: We just rewrote that section of the spec.

i18n

<tabatkins> richard ishida and aharon lanin introduce themselves

<tabatkins> also david clarke (sp?)

<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.

<tabatkins> also kennyluck

<tabatkins> fantasai: The point of i18n is to make everyone in the world happy with our technologies.

<tabatkins> fantasai: 2 major topics: bidi, and vertical text.

<tabatkins> fantasai: We're doing vertical text tomorrow.

<tabatkins> fantasai: aharon wanted to discuss bidi-related proposals for css3.

<tabatkins> Aharon: First thing i wanted to discuss was a couple of new proposals that I emailed to the list last night.

<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.

<tabatkins> Aharon: New stuff. (1) A small addition to Images.

http://lists.w3.org/Archives/Public/www-style/2010Nov/0000.html

<tabatkins> Aharon: I'd like an ability to flip an image based on directionality.

<myakura> http://www.w3.org/International/docs/html-bidi-requirements/#image-flip

<tabatkins> Aharon: One option is an 'rtlflip' keyword, so the image would be flipped horizontally when the direction is rtl.

<tabatkins> jdaggett: This isn't just bidi - vertical text may want to do rotations too. So, this is a writing-mode thing.

<tabatkins> Aharon: The other way was to declare the directionality of the image, and then auto-flip as appropriate.

<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.

<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 when or not to flip it.

<tabatkins> szilles: Because an image might be neutral in horizontal, but not in vertical.

<tabatkins> szilles: Would this apply to any replaced element?

<tabatkins> fantasai: If this should apply to all replaced element without overflowings, this should be handed to the HTMLWG as this would be a content property.

<tabatkins> johnjan: One problem is backwards compat.

<tabatkins> fantasai: Not a problem in CSS, as you can count on the property being ignored in legacy and just add a fallback.

<tabatkins> szilles: So I'm hearing that we aren't intended to cover <img>?

<tabatkins> fantasai: For content images, in most cases I don't believe you'd generally want to flip those images.

<tabatkins> fantasai: The types of images you get in CSS are very often something you want to flip.

<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.

<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.

<tabatkins> szilles: Good, I just wanted to be clear on the scope.

dbaron: should look into how this interacts with Exif orientation

http://dev.w3.org/csswg/css3-images/#image-orientation

<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.

dbaron: Didn't we have a boolean to honor the exif orientationKai

<tabatkins> tabatkins: If honored, it should happen at a level below the rtl flipping.

<tabatkins> ?: 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.

<tabatkins> dsinger: Any image editor that doesn't set EXIF correctly is buggy. It's not our responsibility to fix their bugs.

<tabatkins> tabatkins: We can't break webpages either.

<tabatkins> howcome: We should mandate a default behavior of not honoring, and have a property allowing honoring it.

http://lists.w3.org/Archives/Public/www-style/2010Nov/0004.html

<tabatkins> dbaron: Also, theoretically attr() and Generated Content could let us handle <img>s in HTML.

<tabatkins> Aharon: Next topic. You have list-style-position, which lets you put the marker inside or outside.

<tabatkins> Aharon: I'm only talking about the outside case.

<tabatkins> Aharon: Currently the bullet goes on the "start" side, based on the item's directionality.

<tabatkins> Aharon: Which sounds reasonable, until one realizes that one often has a list where the items are mixed directionality.

<tabatkins> Aharon: For example, a bibliography where some are english and some are hebrew.

<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.

I would suggest the syntax list-style-direction: left | right | start | match-parent, to be parallel with text-align

<tabatkins> Aharon: Further, the list itself creates a gutter for the bullet based on the list's direction.

<tabatkins> Aharon: If the bullets are mixed, then the bullets for items in the other direction are often invisible because they're off-page.

<tabatkins> Aharon: So my proposal is list-style-direction, which indicates the direction of the marker.

<tabatkins> Aharon: Four values: ltr, rtl, match-list, match-item.

<tabatkins> dbaron: I'm inclined to think we should instead find the right answer, and not expose this directly at all.

<tabatkins> Aharon: The use-case for having it match item is that in arabic, they sometimes like having markers on different sides.

<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.

<tabatkins> dbaron: Wait, maybe I've got that wrong. The gutter is always generated by the list.

<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.

<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.

<tabatkins> szilles: I'm curious why dbaron doesn't want a property there.

<tabatkins> dbaron: I don't think a full property is warranted to just change the behavior of a single value of anothe rproperty.

<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?

<tabatkins> aharon: When you text-align anything but start, in IE the outside marker follows the text, so they don't line up.

<tabatkins> aharon: Webkit doesn't make the marker move, so they still all line up.

<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.

<tabatkins> dbaron: We received a ton of feedback from authors that they don't like the bullet being separated from the text.

<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.

<tabatkins> dbaron: Right now we tie the bullet to the first line box.

<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.

dbaron: We still need to displace bullets from floats by match-parent

<tabatkins> aharon:

<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.

<tabatkins> glazou: Tab, could you keep up a wiki or something for an issues list for Lists?

<tabatkins> tabatkins: Yeah.

tabatkins, you missed something Aharon said, can you put it in the minutes?

<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.

No, you missed it. He was describing the behavior of match-parent on both list markers and text alignment and how they interact

You did not catch any of that.

The entire discussion of text-align and its interaction with the list marker was not minuted.

s/marker/marker position/

<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

Yes, an Aharon was discussing how that behavior handles certain use cases that are needed

Because, e.g. some lists are rendered with bullets all on one side

but an item of opposite directionality might be aligned to the opposite side

while leaving the bullet aligned with the others in the list

<dbaron> (and with list-style-position:outside the side for the bullet matches the item, as now)

<scribe> ScribeNick: fantasai

Accessibility

Multi-Col

howcome: I would like to confirm agreement on a few things
... Implementations seem to be coming along nicely
... Hopefully all of the functionality in the spec
... We need some clarifications in the spec
... It's all about spanning elements
... Remember we have a multicol element here, and we lay out incolums

howcome draws on the board

howcome: The issue is overflow
... There are two reasons for overflow: you could have a constrained height
... or you could have forced column breaks, more breaks than you have columns
... The issue is what to do if you have an element with column-span: all in one of the overflow columns
... Alex proposed to do nothing, i.e. pretend column-span was not set
... 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

dbaron: What if you have both a constrained height and forced breaks?

<dbaron> that wasn't me

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
... One special case: when you try to place a colspan and it itself doesn't fit, and creates overflow. That creates a circular dependency
... I think we resolved that if it doesn't fit as a span, you ignore the span

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

dbaron: You could also ignore in all cases whether there's a constrained height

stevez: I think it should be if it fits or not

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

stevez: This might interact with the EPUB case, where they paginate in addition to doing multicol

Alex: If the forced-break case is height-constrained, where does the overflow columns go?
... Do the columns overflowing from the second row have full height, or shortened height, i.e. height after the rowspan?

dbaron: So you're saying whether colspan works at all...

howcome: is dependent on whether there is room inside the multicol element

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
... As the available space after the colspan approaches zero, the number of columns for content after it approaches infinity

fantasai: From an implementation perspective, I would prefer this method.
... 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
... if overflow columns were full-height columns, then we lose that simplification

<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

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)

[note to minutes: insert pictures]

dbaron draws some content on the board

I have a some text, then a forced break, then more content.

Then a spanning element.

tab, fantasai: Then you balance the content, which may introduce breaks in the column before the forced break or after it or both

RESOLUTION: If a columnspanning element doesn't fit within the multicol element, then it doesn't span anymore

<scribe> New questions:

1. do columnspanning elements create a new block formatting context

2. does columnspanning turn inline elements into blocks?

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)?

2... or does it not apply to inline elements

fantasai: I think column-span should only apply to block-level elements

Bert reads the applies-to line from the spec

RESOLUTION: column-span applies to "in-flow block-level elements"

dbaron: Note in the prose that it has no effect on elements outside a multicol element

<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.

<dbaron> fantasai: If a column-spanning element is a BFC root, then margins don't collapse through its boundaries.

<tabatkin1> fantasai: I don't think that margin behavior should change based on whether a colspan is honored or not.

<sylvaing> CSS3 Multicolumn http://www.w3.org/TR/css3-multicol/

<tabatkin1> fantasai: So if it's a spanning element, it should automatically become a BFC and no longer collapse margins through its boundary.

whether or not it's triggered the overflow nonspanning case

fantasai: I think we might need to distinguish whether an element is spanning one column or not spanning

dbaron: I really don't want whether something is a block formatting context root depend on layout
... I really want to know what floats are relative to not depend on layout

tabatkin1: So they should become BFCs regardless of whether they actually span something or not

dbaron: We shouldn't have tricky behavior for an error case

Steve: So column-span: all; would mean span the current column in the overflow case
... i.e. the all in that case means the one column

RESOLUTION: column-spanning elements are BFC roots always

RESOLUTION: Initial value of column-span is 'none'

Bert: Last issue is, do margins between spanning elements collapse?
... e.g. if I have H2 followed by H3, can their margins collapse

fantasai: What about between the spanning element and the content of the columns above and below it?

Roughly, answers seem to be Yes, and No, but discussing...

Back to fantasai's issue

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.
... This way we avoid an overflow case.

Alex: I'm concerned people would use this for some weird design cases that don't work well

<sylvaing> (that was szilles)

steve zilles echoes the concern

<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'...)

dbaron: I'm concerned that we're getting too far from what we're implementing

howcome: We have implementations of multicol, we have to resolve these issues

dbaron: We're not getting much author feedback on columns

tabatkin1: They're not useful in continuous media

<johnjan> s /aaron /arron

more discussion of this case

steve zilles thinks this solution causes bad layout

fantasai thinks avoiding overflow is important

steve: People will insert forced breaks randomly in order to get the layout they want

<tabatkin1> fantasai: [draws a multicol element overflowing, showing how block-column overflow would result in a bad overflow situation in the constrained height case]

<tabatkin1> fantasai: [draws another one where the multicol has an auto height and stretches to fill the content]

<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".

<tabatkin1> fantasai: Right, so far. Ideally we'll have in the future a "column-length" that can cause new column rows.

<arron> referring to the first drawing by fantasai, are the columns overflowing to the right or below?

<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.

<tabatkin1> szilles: I could live with multiple breaks overflowing to the right today.

fantasai: I'm not happy with creating overflow cases when they are not necessary
... And if we do this today, then you would have to use column-length in order to get explicit-break columns to wrap

tabatkin1: column-length is not the right trigger for wrapping overflowing explicit break columns
... if they're explicit breaks, they're explicit breaks
... If you set column-length: 40em; and your explicit breaks are at 20em, what's your column row height?

steve: Ok, I see what you're saying
... Ok, I'm willing to withdraw my objection provided you add a note about this column-length property
... My concern is that people will start putting in explicit breaks just to get the behavior that column-length would have given
... But if you at least put in the spec that this is not intended for this purpose, and how we want to proceed

Peter: Authors don't read the spec. They'll do whatever it takes to make content work the way they want it right now.
... Let's just put this property in right now.

dbaron: I'm not sure this is useful

tabatkin1: This would make multicol usable for me

Peter: Fundamentally, multicol doesn't make much sense on continuous media
... But let's not force people into making unusable layouts.

dbaron: I'm not sure we're addressing use cases with multicol
... And I don't think we would implement all this.

fantasai: column-length is a piece of cake

dbaron: But we don't implement column-spanning. And we can't balance columns with forced column breaks in our current design.

?: We have a lot of demand for this, actually.

?: We haven't switched from table layouts to CSS due to lack of multicol

howcome: So how would you decide the gap between the column rows?

fantasai: use column-gap
... can give it two values, just like border-spacing, if needed

Alex: I want separate properties

fantasai: Do you need them to cascade independently?

Alex: I just like having separate properties

fantasai: If we need separate properties, we can split them out later and make column-gap a shorthand.

Steve: In XSLFO, we replicated the multicol box

various concerns raised to porting this idea to CSS

<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...)

Steve: I'm going back to my position of putting a note that this doesn't solve the following problems.

howcome: We go back to the issue of where the overflowing forced-break column goes: off to the right, or wrap under?
... I'm in favor of wrapping under, quite stronger.

Alex: You need gap and rules, though.

fantasai thinks we should just use the column-gap and deal with customized gaps and rules later

steve: But I don't think column-gap is good enough.

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
... The only other reasonable default is a zero gap. I don't see how that's better
...

tabatkin1 doesn't want to half-ass this

scribe:

Kai: Web page layout is very precise right now.
... Automatically wrapping columns loses precision
... It's easier to control if it always overflows to the right

<Kai> it would be good to have this as default and have the ability to have it wrap

howcome takes a straw poll on behavior

A - overflow to the right

B - wrap under

Bert: A

Kai: A

Steve: A

Peter: B

Markus: A

Tab: A

beth: A

?: A

??: B

Chris: A

Daniel: A

John: A

Sylvain: A

Koji: A

<arron> Arron: A assuming right is actually end

fantasai: B

arron, :)

Alex: A

dbaron: A

jdaggett: A

no comment from the peanut gallery

<dbaron> howcome: B

<glazou> s/peanut gallery/other observers

Peter: I think it's unfortunate that we're choosing a behavior for multicol that doesn't work well for print

RESOLUTION: overflow to the right

- DRAFT -

SV_MEETING_TITLE

01 Nov 2010

Attendees

Contents

CSS2.1 Testing

i18n

Accessibility

Multi-Col

Summary of Action Items

Scribe.perl diagnostic output