<scribe> ScribeNick: tabatkin1

glazou: Main topic is 2.1 and tests
... Did we make any progress since TPAC?

johnjan: I think arron got all his tests submitted, so the remaining feedback is fantasai's.

<howcome> howcome has +47.21.65.aacc

<glazou> http://wiki.csswg.org/test/css2.1/issues

glazou: Do you think the tpac deadlines we set are still doable?

arronei: Yeah.

szilles: Elika's flying this morning and won't be on the call.

johnjan: Next thing is spec issues that came up due to the testing; not specifically spec issues, but may require us to modify the spec.

glazou: Do we have a list of these issues?

arronei: No.
... Were we going to discuss issue 101?

glazou: Let's talk about 101.

<dbaron> http://wiki.csswg.org/spec/css2.1#issue-101

johnjan: IE9 has implemented rules 3 and 7 per spec now.
... We feared that, since everyone broke those rules it would have a compat impact, but it turns out that's not true.

dbaron: It would be relatively straightforward to fix, but I'm not particularly comfortable doing so before the FF4 branch.
... Does the IE mode switching mean you're only testing some subset of pages?

johnjan: This should be all modes. We force standards mode on pages when we test things like this.

dbaron: But you haven't tested quirks?

johnjan: Not sure.

dbaron: Do quirksmode pages still render with a different engine in IE9 beta?

arronei: We currently force the mode into standards mode and then test the page. So a quirksmode page will still get tested in standards.

tabatkin1: If there's no significant compat impact, then I'm comfortable with dropping my proposal and keeping the spec as written.

glazou: So what's the preference of implementors?

johnjan: I'd like to keep the spec as-is.

dbaron: It's sorta hard to tell my final answer until I implement it, but I'm okay with keeping things as-is for now.

smfr: Agree with David.

glazou: So I'm hearing consensus to keep the text as-is and revisit the issue as needed.

RESOLUTION: Keep the current spec text for Issue 101, revisit this in the future after other browsers have implemented per spec.

<glazou> http://lists.w3.org/Archives/Public/www-style/2010Nov/0077.html

Intrinsic widths and heights.

dbaron: There's spec text about intrinsic widths and heights, based I think on a misunderstanding of some language in SVG.
... I think this led to some bugs in implementations.

<ChrisL> I agree, it has been misinterpreted and gives rise to undesirable behaviour

dbaron: In our case we implemented the weird behavior because we thought it's what we needed to do, even though we didn't particularly like the result.
... I think there are test-cases in the 2.1 suite that rely on this behavior, though I'd have to doublecheck to be sure.

<smfr> dbaron: maybe replaced-intrinsic-ratio-001.* ?

ChrisL: I talked with elika at tpac and agreed that it's easy to misinterpret.

<dbaron> smfr, yep

tabatkin1: I think I misinterpreted it in the same way as everyone else when talking with Chrome's implementors.

<dbaron> http://www.w3.org/TR/SVGMobile12/coords.html#IntrinsicSizing

smfr: It seems that Chris is saying the spec is poorly worded, but dbaron is saying we should remove %age width and height.

dbaron: The underlying issue is that the SVG wording at the above url defines intrinsic sizes of SVG in a way that there is never a % intrinsic width or height.
... So basically we have no use-case whatsoever for %age intrinsic width and height, but we refer to it from the CSS spec, which confused people into thinking there is such a thing.
... So we should remove it as a concept.

ChrisL: I'm trying to clarify what parts remain and what parts will be cut.

smfr: Seems like we just need some proposed changes to the spec.

dbaron: I sent the initial email in the middle of our discussion with SVG, so I'm not sure how explicit I was.

smfr: I'd have to go back and study that part of the spec and see what Webkit is doing there, but this sounds reasonable.

glazou: Then I suggest we accept dbaron's proposal, pending an email from webkit saying you agree.

action on simon to see if the intrinsic width change is acceptable for Webkit.

<trackbot> Sorry, couldn't find user - on

action simon to see if the intrinsic width change is acceptable for Webkit.

<trackbot> Created ACTION-274 - See if the intrinsic width change is acceptable for Webkit. [on Simon Fraser - due 2010-11-17].

Charter update

ChrisL: I sent a link to the charter to glazou, plinss_, and bert.
... PLH thought we were preparing the charter for March.
... PLH says we can't *say* 2.1 is done until it's actually done. Since we said it would be done in march, he thought we shoudl pursue an extension for March.
... And then get a proper charter renew there in march when 2.1 is done.

glazou: And a charter extension is easier, right?

ChrisL: Yes. There's still discussion required, but it's simpler.

glazou: So, who disagrees with a charter extension to finish 2.1?

dbaron: I'd heard that Tantek wanted to get UI published, which would require rechartering since it wasn't in our current charter.

ChrisL: Can that be described as part of another spec?

Bert: It's in the scope section, talking about styling of UI widgets.

ChrisL: If it's in scope, then there's no need to worry about publishing it.

<Bert> " It also includes the presentation and behavior of UI widgets."

dbaron: If publishing UI is fine under the current charter, then I'm okay with doing an extension.

RESOLUTION: Request an extension of the CSS charter until March.

<glazou> http://www.w3.org/mid/alpine.DEB.1.10.1011041142350.18200@wnl.j3.bet

Background shorthand

<dbaron> I think we should have fantasai around for this discussion.

glazou: Reported by Yves Lafon, about having a double slash in the border-image shorthand.

szilles: Let's talk about Writing Modes first. I didn't see an updated draft from Elika, but I think there was an agreement from the WG that everything minus logical properties was acceptable for a fpwd, so we'd like to get that going if there's no objection.

dbaron: You mean all of section 7 in the spec?

szilles: Yes.

dbaron: That seems reasonable to me, but I'd like to give jdaggett a chance to raise something.
... I'd be fine with a resolution if we give jdaggett a chance to reject.

plinss_: I think jdaggett was there when we resolved, we just deferred the actual resolution so we could see the edits that were being done.

dbaron: Sounds fine.

glazou: So do we wait for the edits or resolve now?

RESOLUTION: Publish Writing Modes, minus chapter 7 over logical properties, subject to potential objections from jdaggett.

ACTION dbaron to ping jdaggett about Writing Modes to make sure it all looks okay.

<trackbot> Created ACTION-275 - Ping jdaggett about Writing Modes to make sure it all looks okay. [on David Baron - due 2010-11-17].

glazou: I think dbaron requested that we push the border-image issue until Elika is here.

css3-2d-transforms

smfr: About 2d transforms
... First is transforms on inline elements. We don't currently have compat. Gecko has certain confusing behavior about rotating each individual box.
... Conceptually I don't think there's a behavior that's reasonable for users.
... I propose we restrict transforms to only act on things that aren't inlines.

glazou: I have a problem. That wouldn't allow an image to be rotated in a paragraph.

<dbaron> things that aren't non-replaced inlines

tabatkin1: No, the term we'd use to restrict them would still allow transformation of things like inline-blocks and images.

smfr: One use-case is to scale a link on hover, which works fine until the link gets broken across lines. You could just make them inline-block.

tabatkin1: I brought this up at TPAC, and we discussed seeing if we could propertly define a notion of bounding box and transform that.

dbaron: We tried that, but the overflow behavior is hard.

smfr: And I don't think it results in good behavior still - in the link-broken-across-lines case, a scale or skew causes it to grow outside of the element, which is weird.
... I should come up with correct wording so we don't prevent inline-blocks and such.

ACTION simon to send an email to the list with suggested wording for transform change.

<trackbot> Created ACTION-276 - Send an email to the list with suggested wording for transform change. [on Simon Fraser - due 2010-11-17].

smfr: Next, CSS agreed to move forward on css transforms for CSS, but FXTF wants to work on it as well and have it apply jointly to CSS and SVG.
... These seem to be in conflict - I don't see how the CSSWG can move forward on a 2d transforms spec at the same time as the FXTF creates one that also works in SVG.
... So I'm a little confused about how to proceed.

ChrisL: I'm confused too, becuase I thought we'd already agreed. The FXTF had already evolved into harmony, but then the CSSWG spec seems to be changing independently.
... Technically, I believe that the spec would have two conformance classes, one for CSS and one for SVG.
... I believe that MS in the meeting was saying they look forward to the joint spec so they can work on both things.

smfr: Webkit doesn't currently necessarily have correct behavior when it comes to CSS transforms applied to SVG.

ChrisL: Right, but I think it's easier to just go ahead and find the joint issues now, rather than try and develop on just one side and then later find incompatibilities.
... In other words, I don't think pursuing it jointly will necessarily be slower.

smfr: Right; I just want to make sure that the resolution to move Transforms 2d forward wasn't in conflict with the combined effort.

tabatkin1: It isn't.

ChrisL: What exactly was resolved?

tabatkin1: I'd have to look in the minutes to be certain.
... I don't believe that anyone is ever consciously trying to do something against the FXTF integration.

glazou: Right, definitely to the contrary.

smfr: It's probably up to the FXTF to look at the resolutions the CSSWG made during TPAC and ensure they're integrated properly.

ChrisL: I'm not saying there's any conscious objection, I'm just concerned about accidental incompatibilities.

tabatkin1: Do we want to split Transforms, so we can push forward with the simple stuff and get it unprefixed, while putting the new element-point api in level 4?

ChrisL: Maybe. This sounds like we should talk about it in the FXTF.

tabatkin1: New topic - splitting the display property. Do we want to pursue this? I think we need to, given that we're pushing the new layout modes.

dbaron: I think we need to look at this.

<dbaron> (details need to be worked out)

szilles: Can we get a pointer to the latest proposal?

tabatkin1: Yeah, I'll send something to the list.

glazou: Tab, could you send the minutes quickly?

<glazou> Chris, yt ?

<ChrisL> yes

This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/XXX/Writing Modes/
Found ScribeNick: tabatkin1
Inferring Scribes: tabatkin1
Default Present: +33.9.50.89.aaaa, glazou, Bert, johnjan, +1.650.253.aabb, arronei, tabatkins, dbaron, SteveZ, +47.21.65.aacc, +39.524.9.aadd, +1.408.636.aaee, smfr, ChrisL, +47.21.65.aaff, howcome, +1.858.216.aagg, plinss_
Present: +33.9.50.89.aaaa glazou Bert johnjan +1.650.253.aabb arronei tabatkins dbaron SteveZ +47.21.65.aacc +39.524.9.aadd +1.408.636.aaee smfr ChrisL +47.21.65.aaff howcome +1.858.216.aagg plinss_
Regrets: Elika

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting

Got date from IRC log name: 10 Nov 2010
Guessing minutes URL: http://www.w3.org/2010/11/10-CSS-minutes.html
People with action items: