- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 16 Nov 2010 22:06:10 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- RESOLVED: Keep the current spec text for CSS2.1 Issue 101, revisit
if necessary in the future after other browsers have
implemented per spec.
http://wiki.csswg.org/spec/css2.1#issue-101
- Discussed dropping all mention of percentage intrinsic widths from
the spec, since SVG doesn't in fact have them. Pending proposed text
and resolution.
- RESOLVED: Request an extension of the CSS charter until March.
- RESOLVED: Publish Writing Modes, minus chapter 7 over logical properties,
subject to potential objections from jdaggett.
- Discussed having transforms not apply to non-replaced inlines.
- Discussed transforms coordination with FXTF
====== Full minutes below ======
Present:
Tab Atkins
David Baron
Bert Bos
Arron Eicholz
Simon Fraser
Daniel Glazman
John Jansen
Håkon Wium Lie
Chris Lilley
Peter Linss
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2010/11/10-CSS-irc
Scribe: Tab Atkins
CSS2.1
------
glazou: Main topic is 2.1 and tests
glazou: Did we make any progress since TPAC?
johnjan: I think arron got all his tests submitted, so the remaining
feedback is fantasai's.
<glazou> http://wiki.csswg.org/test/css2.1/issues
glazou: Do you think the tpac deadlines we set are still doable?
arronei: Yeah.
szilles: fantasai'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.
arronei: 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.
johnjan: 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.
dbaron: 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.
tabatkins: 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.
RESOLVED: Keep the current spec text for Issue 101, revisit this in
the future after other browsers have implemented per spec.
Topic: Intrinsic widths and heights.
<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.
dbaron: 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.
dbaron: 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.* ?
<dbaron> smfr, yep
ChrisL: I talked with elika at tpac and agreed that it's easy to misinterpret.
tabatkins: 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.
dbaron: 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.
dbaron: 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.
ACTION simon to see if the intrinsic width change is acceptable for Webkit.
<trackbot> Created ACTION-274
Charter
-------
ChrisL: I sent a link to the charter to glazou, plinss_, and bert.
ChrisL: PLH thought we were preparing the charter for March.
ChrisL: 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 should
pursue an extension for March.
ChrisL: 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.
RESOLVED: Request an extension of the CSS charter until March.
border-image shorthand
----------------------
<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.
CSS3 Writing Modes
------------------
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.
dbaron: 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?
* dbaron notices a few occurrences of "-->" in the spec and wonders why
they're there
RESOLVED: 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
glazou: I think dbaron requested that we push the border-image issue
until Elika is here.
CSS 2D Transforms
-----------------
smfr: About 2d transforms
smfr: First is transforms on inline elements. We don't currently have
compat. Gecko has certain confusing behavior about rotating each
individual box.
smfr: Conceptually I don't think there's a behavior that's reasonable
for users.
smfr: 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
tabatkins: 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.
tabatkins: I brought this up at TPAC, and we discussed seeing if we could
properly 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.
smfr: 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
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.
smfr: 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.
smfr: 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.
ChrisL: Technically, I believe that the spec would have two
conformance classes, one for CSS and one for SVG.
ChrisL: 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.
ChrisL: 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.
tabatkins: It isn't.
ChrisL: What exactly was resolved?
tabatkins: I'd have to look in the minutes to be certain.
tabatkins: 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.
tabatkins: 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.
Splitting 'display'
-------------------
tabatkins: 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?
tabatkins: Yeah, I'll send something to the list.
glazou: Tab, could you send the minutes quickly?
<RRSAgent> http://www.w3.org/2010/11/10-CSS-minutes.html
Received on Wednesday, 17 November 2010 06:06:49 UTC