W3C home > Mailing lists > Public > www-style@w3.org > November 2010

[CSSWG] Minutes and Resolutions Telecon 2010-11-10

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 16 Nov 2010 22:06:10 -0800
Message-ID: <4CE370D2.4060801@inkedblade.net>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:34 GMT