See also: IRC log
<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
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].
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
<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.
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:[End of scribe.perl diagnostic output]