W3C home > Mailing lists > Public > www-style@w3.org > August 2012

[CSSWG] Minutes and Resolutions 2012-08-01

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 02 Aug 2012 15:46:56 -0700
Message-ID: <501B0360.1000307@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Summary:
   - RESOLVED: Publish FPWD of the Compositing draft.
   - RESOLVED: order affects abspos, Flexbox goes to CR
   - Discussed interpolation of transforms
   - RESOLVED: Accepted the following clarifying edits to CSS2.1:
                 https://www.w3.org/Bugs/Public/show_bug.cgi?id=17121#c2
                 https://www.w3.org/Bugs/Public/show_bug.cgi?id=17121#c5
                 https://www.w3.org/Bugs/Public/show_bug.cgi?id=17122#c1
                 https://www.w3.org/Bugs/Public/show_bug.cgi?id=15686#c2
   - Discussed whether/how 'overflow' applies to table elements
   - Action: review css3-text ED for publication request next week

====== Full minutes below ======

Present:

   Glenn Adams
   Rossen Atanassov
   Tab Atkins
   David Baron
   Bert Bos
   Rik Cabanier
   Arron Eicholz
   Katie Ellison
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   John Jansen
   Anton Prowse
   Florian Rivoal
   Dirk Schulze
   Alan Stearns
   David Storey (via IRC)
   Leif Arne Storset (Opera Software)
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2012/08/01-css-irc
Scribe: fantasai

Administrative
--------------

   glazou: any additions to agenda?
   glazou: If you plan to attend or not attend, please add your name to
           the wiki so we know who is coming / when / where
   <glazou> http://wiki.csswg.org/planning/sandiego-2012#participants
   Florian: For TPAC meeting, Opera is joining Adobe as a sponsor
   glazou: Thank you very much
   glazou: Any other organization?
   Glenn: Sunday before or Sunday after?
   glazou: before

Compositing FPWD
----------------

   <cabanier> https://dvcs.w3.org/hg/FXTF/rawfile/4b53107dd95d/compositing/index.html
   <glazou> https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html
   Rik: SVGWG already approved to move to FPWD
   Rik: Think the spec is in reasonable shape.
   Rik: need to get more consensus on CSS keywords
   Rik: There are many; some people requested fewer
   Rik: As WD will get more exposure
   Rik: e.g. dbaron gave me very good feedback
   Rik: Think it's in readable shape, would like to move to WD
   glazou: Opinions?
   Florian: I haven't read everything, but I like it so, yeah
   Tab: I approve
   dbaron: The biggest thing I was worried about was z-ordering stuff,
           possible I confused people
   dbaron: If it's either fixed, or there's a note that it needs to be fixed,
           I'm ok with it
   Rik: I rewrote it with stacking context, like you said, and linked to
        Appendix E
   Rik: ... add an example that shows what is happening, ppl will not get
        confused.
   glazou: So, no objections against FPWD of compositing?
   glazou: Okay, so let's do that.
   RESOLVED: Publish FPWD of the Compositing draft.

   glazou: Anything else wrt compositing?
   Bert: It's part of CSS and SVG, who does the publishing, is that me?
   Rik: I think it's part of CSS, so we opened a Bugzilla as part of CSS
   Rik: FX will not get as much exposure, and it's not specific to SVG,
        just adding CSS properties
   Rik: Let me know if I need to change anything
   ACTION Bert: Publish Compositing FPWD
   <trackbot> Created ACTION-487

Flexbox
-------

   <glazou> http://dev.w3.org/csswg/css3-flexbox/
   Tab: We concluded last week with some resolutions that should cover
        what we need to do, and left actual details to me and fantasai
   Tab: We tried to go with Option D, and to match it thematically with
        how abspos works in block layout
   Tab: You look for your next/previous item and attach it there
   Tab: fantasai worked out how to treat it as a placeholder and just
        do some packing-space suppression
   Florian: As long as Morten is happy, it's good with me
   <fantasai> Morten's response -
              http://lists.w3.org/Archives/Public/www-style/2012Aug/0023.html
   szilles: If there's a sequence of abspos, they are processed and
            attached to the same edge
   fantasai: yes
   szilles: And order means that I don't choose the adjacent edge until
            after I've finished reordering.
   szilles: If you could make the wording a little more obvious in that
            direction, would be helpful
   Tab: wrt first one, we do talk about in-flow items--abspos is out of flow
   Tab: Second one, we're explicit that you run reordering first.
   Florian: Maybe clarify in a note or something
   szilles: great job

   Tab: One bit that's important, last week WG officially resolved that
        'order' doesn't apply to abspos
   Tab: Wanted to ask WG if ok with reverting that.
   Tab: As written right now, order affects the abspos.
   Florian: Sounds fine to me. Was only concerned about applying to
            placeholders.
   Tab: Morten's ok with it, and chrome is ok today
   * fantasai notes bzbarsky said it would be easy for Gecko

   Anton: I'm wondering, do we expect abspos static positioning to work
          with layout models in this way?
   Anton: It's ok, but I think we need to think about the consequences
          with other layout models
   Anton: Note also that float or clear doesn't affect abspos
   Anton: Might decide that's an anomaly
   fantasai: or maybe it was added for compat
   Tab: Could have principle that do layout, then position abspos
   dbaron: Concerned about that. Don't really want to do layout
   ...
   Florian: I think it's in line with what we called the Rossen Principle.
            In block layout, if you abspos and don't give coordinates it
            goes where it would have been
   Florian: Flexbox does roughly the same thing
   Florian: Don't think anything very different here wrt high-level view
   Tab: I think dbaron just wants a clarification of whether for future
        models you do any work
   Florian: Hard to discuss without a specific case in mind
   Rossen: Wrt Grid, we always position in the origin of a grid cell in Grid
   Rossen: You honor grid-row/grid-column positioning, but otherwise put
           in origin
   Rossen: I do agree there's a higher-order question of should it follow
           block/flow layout model in other layout models, where that
           doesn't make any sense?
   Rossen: Or go with something simpler, like Tab was suggesting (origin
           of flex container) last week
   Rossen: I'm still in favor of going for something simpler in layout
           models that have no concept of flow.
   ...
   szilles: Positioning of flexboxes is ...
   * fantasai reminds everyone that we should close the topic
   <dbaron> For reference, my position in last week's straw poll would
            have been A.
   Tab: Want to request resolution of reversing order, and of going to CR
   RESOLVED: order affects abspos, Flexbox goes to CR
   ACTION Bert: send Flexbox CR transition request
   <trackbot> Created ACTION-488

   dbaron: The idea of this model is that you apply order to the abspos to
           figure out where it goes in the order, and then use that as the
           static position?
   Tab: yes
   Anton: You're not really treating it as a flex item, you're using order
          to figure out which item is the next/previous item to attach its
          position to that.
   dbaron: So I'm not really happy with adding 100 lines of code for
           something I haven't heard a use case for
   Tab: Brad produced some things in the mail thread
   fantasai: ...
   glazou: But you are not objecting to the change?
   dbaron: No. Close to it, but no.
   glazou: Ok, let's move on
   * sylvaing #dbaron { objection: 0.99; /* that was close */ }

Transforms
----------

   <glazou> http://wiki.csswg.org/topics/transform-interpolation
   Krit: Issue was ...
   Krit: Request from implementers that we don't do that, that we interpolate
         on each function pair
   Krit: So changed the spec to do interpolate on function pairs
   Krit: For perspective we do matrix decompse then interpolate [??]
   Krit: Thought it'd be a perf issue, but browsers didn't think so
   Krit: Have request from smfr that functions along same axis are interpolated,
         not matrix
   glazou: In wiki WebKit says they can't change to the preferred way anyway
   smfr: Could, but would prefer not to
   dbaron: I was originally asking the spec to change back to what it used
           to say
   dbaron: Also worried in general that this spec changes too much in ways
           that are incompatible with Web content
   dbaron: Afraid might have to come back 3 months and have to request revert
           of changes
   dbaron: But can't say sooner than 3 months
   Krit: Can you be more specific?
   dbaron: There's a lot of content using this
   dbaron: They stuff the result of any prefixed/unprefixed values into the
           same variable and use it the same way
   dbaron: prefixes isn't getting us anything here
   smfr: Risk of interpolating transforms is in cases where we used to not
         do convert then decompose, cases where we would now if we change
         the spec
   smfr: The spec is going away from using matrix interpolation, which is
         a good thing
   dbaron: Yes, worried about changing things *to* matrix interpolation
   Krit: If I got feedback on specific parts that needed to change, I
         changed it, that's all.
   dbaron: It was specified when I implemented it. If it's not anynmore,
           someone deleted it
   smfr: notion of primitives and derived [...]
   <sylvaing> I am also worried about making incompatible changes at this point
   smfr: e.g. translateX() will interpolate with translate()
   smfr: WebKit didn't implement that
   Krit: [...]
   Florian: I'm not very up to speed on how this behaves, but do completely
            agree with dbaron
   <dbaron> Gecko implemented that a few weeks ago, but we haven't shipped
            it yet.
   <sylvaing> at a minimum testcases showing some level of interop are
              warranted
   <sylvaing> (or lack thereof)
   Florian: Used too much to be changed without trouble
   Florian: Need to document things, but not change suboptimal behavior
   smfr: But whose implementation do we pick? Webkit, Gecko, Opera, IE?
   sylvaing: Need to write some test cases to figure that out
   Krit: These changes were made several months ago,
   Krit: even translateX() and translate(), was something not specified
         before, just said "transform function of he same type".
         Had to address, what does "same type" even mean
   Krit: So we say "transform function with the same name"
   Krit: This is different from editors' decision.
   Krit: I'm fine with changing everything to match transform names
   Krit: Still think it's useful for translate functions to interpolate
   Krit: e.g. you have translate() and translateX()
   Krit: with your interpretation we need to decompose to a matrix
   Krit: whereas I would prefer a numeric interpolation
   smfr: I agree, that's better
   smfr: I think that's safe, because in the direction of less matrix
         interpolation
   Krit: Same issue with scaleX()
   <krit> http://dev.w3.org/csswg/css3-transforms/#transform-primitives
   Krit: Things that are affected are scale(), translate(), translate3d()
         and scale3d()
   Krit: Not sure that's implemented by browsers, I don't think so
   Krit: But from our pov seems useful

   smfr: Seems unlikely that these changes break content
   smfr: one thing that happens when you fall into matrix interpolation
         is that you lose rotations greater than 360 deg
   smfr: So if someone has a high deg rotation (e.g. 760deg) and has one
         of these functions, you fall into matrix interpolation
   smfr: might be ppl doing that now

   Krit: second request, you said you'd like to interpolate between
         rotate3d along same axis?
   Krit: So rotations around same axis, would like to interpolate.
   smfr: WebKit will interpolate between rotateZ() and rotate()
   smfr: And for rotate3d() will check if axes match, otherwise
         go to matrix path
   smfr: That's just for that one function.
   smfr: I believe it will fill due to transform individually in the list
         if there are rotate3D()s in corresponding places even if axes are
         different
   dbaron is fine with that

   Krit: Everything else, implementers requested it. So should be ok.
   Florian: In general I would like to see test cases for these, to check
            if we are picking the interoperable solution
   Florian: If there is a difference, we need to figure out whether we
            want good or compatible
   Krit: We don't have a format for animation tests
   Florian: These are used a lot out there, so we can't break compatibility
   fantasai: Can always write a manual test
   fantasai: That's good enough to see what browsers are doing for purpose
             of speccing it
   <dbaron> It's really easy to write script tests for interpolation by
            using a negative transition-delay.
   some question of how to write testcases

CSS2.1
------

   <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2012JulSep/0090.html
   https://lists.w3.org/Archives/Member/w3c-css-wg/2012JulSep/0101.html

   Anton: First one is follow-up on adding concept of formatting contexts
   Anton: Rossen wanted it clearer when a box establishes an inline
          formatting context
   https://www.w3.org/Bugs/Public/show_bug.cgi?id=17121#c2
   https://www.w3.org/Bugs/Public/show_bug.cgi?id=17121#c5
   https://www.w3.org/Bugs/Public/show_bug.cgi?id=17122#c1
   https://www.w3.org/Bugs/Public/show_bug.cgi?id=15686#c2
   fantasai: Those edits all look good to me
   Anton: proposal to satisfy Rossen is
          https://www.w3.org/Bugs/Public/show_bug.cgi?id=17121#c5
   Anton: This was what was implied in the text before, now just explicitly
          stating it
   Rossen: Change sounds good to me
   <stearns> looks good to me
   RESOLVED: Accept edits listed above

   Item B
   Anton: We raised issue that there was no interop on whether overflow
          affects the table wrapper box or the table box
   Anton: Agreed to implement whatever is most widely implemented
   https://www.w3.org/Bugs/Public/show_bug.cgi?id=17121#c5
   <antonp> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17505#c6
   Anton: Answer was some UAs are using the table box (Gecko and Trident)
          whereas WebKit and Opera 12 seem to apply to wrapper box but
          are doing something weird
   Anton: Which one resolve to?
   fantasai: height applies to table box, so makes sense for overflow to
             also apply to table box

   dbaron: What values of overflow apply to the table box?
   Anton: Didn't investigate that one. Personally tested overflow: hidden
   Florian: We'll align with whatever sensible behavior we agree on
   fantasai: Do we want to resolve that 'overflow' applies to the table box,
             and later figure out whether 'overflow: scroll' applies?
   dbaron: I'm reading the spec, and the spec says overflow doesn't apply
           to tables
   Anton: We have bugs on that, we know that is kind-of wrong.
   Anton: In reality it does apply to tables, it's a question of which box
          it applies to.
   Anton: The formatting context edits will fix the Applies to line.
   Anton: But first we have to resolve on is the table box or table wrapper box
   Florian: Test results sound good enough reason to say apply to table box
   Florian: Is anyone disagreeing?
   Bert: Don't see how it would affect table
   fantasai: could have a fixed-height div inside a cell, that has overflowing
             content
   Anton: Question is where do we truncate it, or where do we put the scroll bar
   Bert: Isn't it easiest to say it doesn't apply?
   glazou: I'm still not hearing any important change or removal on this issue...
   glazou: Do we need more time?
   dbaron: I'm trying to figure out why we do anything for overflow on tables
   dbaron: I haven't found the code yet
   dbaron: I'm concerned about saying that overflow applies to tables
   dbaron: Not sure anyone applies values other than 'hidden' to tables
   <sylvaing> +1
   Anton: The spec used to say it applied to tables, but during the terminology
          fixes, it accidentally got removed
   Anton: Separate question of whether we want that or not
   Florian: Not exactly excited for 'overflow: paged' applying to tables
   dbaron: Found list of where we support 'overflow: hidden' but not other
           overflow values --
   dbaron: table, table cell, svg:svg, svg:foreignObject
   Florian: Is anyone interested in other values on table?
   Florian: Or should we just spec that only 'hidden' applies
   glazou: suggest deferring to next week
   Arronei offers to help Anton work on testcases

   <stearns> antonp: I have a couple questions on your item [C] we didn't
             get to today
   <stearns> antonp: added my questions to
             https://www.w3.org/Bugs/Public/show_bug.cgi?id=18346

CSS3 Text
---------

   fantasai: Thinking about publishing WD soon
   fantasai: Would like people to review
   fantasai: Also thinking about splitting it, with text decoration parts
             in separate module
   fantasai: It's a very long module
   szilles: where would parts common to both go?
   fantasai: There aren't really any
   Florian: I'm in favor of shorter modules, if you don't mind the overhead.

glazou: Everyone, please add agenda items to F2F wiki
Meeting closed.
Received on Thursday, 2 August 2012 22:47:24 GMT

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