W3C home > Mailing lists > Public > www-style@w3.org > December 2015

[CSSWG] Minutes Telecon 2015-12-02 [css-round-display] [css-snappoints] [css-will-change]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 3 Dec 2015 05:31:43 -0500
Message-ID: <CADhPm3t9_fcrr8mZ9eYzkghmkJ0pnmOK5_c10w6RAv51T-28AQ@mail.gmail.com>
To: www-style@w3.org
Organizing the Developer Meet Up at Sydney

  - There were some offers to speak at the developer meet up.
      - Rossen will take over the Houdini talk since TabAtkins won't
          be able to attend.
      - astearns is willing to give the talk he's giving at this
          week's dotCSS conference.
      - fantasai will do a talk on best practices.
      - gregwhitworth offered to do a talk on a TBD topic.
      - Bert was willing to speak if needed.
  - Bert said that the local organization was handled.

Animating 2d Rotation Transform Function for Polar Coordinates

  - Jihye introduced her proposed solution for handling the
      relationship between polar-angle and animations.
  - The best path forward depended on if the computed value of
      polar-angle is an angle or stays as a keyword.
  - Jihye will look for use cases of the property to determine which
      solution is the right one and present her use cases and
      conclusion on the mailing list.

Using Polar Positioning as Part of Absolute Positioning

  - Most members of the group thought it would be possible to use
      polar positioning as a part of absolute positioning, but were
      unconvinced it was a good idea.
  - bradk, who proposed the idea, was having technical troubles so
      the conversation will continue on the mailing list.

Dealing with Pull Request Pile Ups in our Test Repo

  - There is a backlog in the test repo which needs to be worked
      through. The issue was raised on the telecon in hopes of
      having these specific pull requests addressed and to begin
      working on preventing this in the future.
  - The idea of assigning who is responsible for testing was raised
      and, though it had been tried before, was still believed to be
      a good idea worth investigating further.
  - A lack of QA people in the working group or any person in charge
      of testing overall were both noted as additional problems that
      should be a part of the conversation.
  - For now the conversation will continue on the mailing list and
      in a week or two we will check back to see if the backlog is
      starting to clear.
  - The standard for accepting a test was briefly touched upon with
      several people expressing that it should be a lower standard
      than code.

Progress Report on Snap Points

  - RESOLVED: Replace scroll-snap-destination with
  - RESOLVED: Replace scroll-snap-coordinate with scroll-snap-align
              and scroll-snap-area
  - RESOLVED: Add axis keywords to a property applied to the scroll
              container with added issues

Will Change

  - Both topics were editorial and can stay on the mailing list.


Agenda: https://lists.w3.org/Archives/Public/www-style/2015Dec/0022.html

  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Dave Cramer
  Alex Critchfield
  Greg Davis
  Elika Etemad
  Simon Fraser
  Daniel Glazman
  Tony Graham
  Jihye Hong
  Dael Jackson
  Brian Kardell
  Brad Kemper
  Peter Linss
  Myles Maxfield
  Thierry Michel
  Edward O'Connor
  Anton Prowse
  Matt Rakow
  Florian Rivoal
  Alan Stearns
  Ian Vollick
  Greg Whitworth

  Adenilson Cavalcanti
  Tantek Çelik
  Lea Verou

  Scribe: dael

Organizing the developer meet up at Sydney

  Rossen: Good morning. Let's get going.
  Rossen: Do we have any additional agenda items anyone wants to add?

  Rossen: I saw that there was some chat about this on the private
          list. TabAtkins was mentioned doing a talk on Houdini,
          Bert asked about who would speak on CSS. Do we have a plan?
  Bert: No plan. I think the situation got worse because TabAtkins
        isn't coming. So we need somebody for Houdini. Rossen you'd
        be good.
  Rossen: I can do that, yes.
  <glazou> Tab confirmed on w3c-css-wg
  Rossen: TabAtkins, are you not coming to Sydney?
  Rossen: We'll miss you.

  Bert: So Rossen would be good for Houdini. We can push some topics
        we want to push, select what we want to talk about with the
        devs. If people have ideas for speakers or topics let's hear
  Rossen: astearns is talking at a CSS conference I think...what was
          it next week?
  <astearns> dotCSS
  astearns: [breaking up] Getting some more participation in CSSWG
            and Houdini.
  Rossen: It was hard to hear, but you said testing and contributing
          to CSSWG?
  <astearns> yes
  Rossen: Okay, great.
  Rossen: So if we have nothing else, astearns can rehash that topic.
          Or we can do something different. Are there any members
          that express willingness to talk at that dev meetup?
  <astearns> happy to jump on stage and rehash.

  fantasai: In Sydney?
  Rossen: Yes.
  fantasai: I can do a best practices thing.
  Rossen: Great.

  Rossen: Who is hosting this?
  Bert: Organized mainly by Shane and will happen either at the
        Google place or at a nearby place. We're expecting 30-60
        people. Local organization is taken care of. My question is
        what do we want to talk about while we're there. That was
        the question for today. The rest is taken care of by Shane.
  gregwhitworth: Is there a way to determine what level of developer
                 we're getting?
  Bert: Professional web developers.
  hober: Since modularization developers level independently. We'll
         have a mix.
  Bert: Yes, but we can assume they know quite a bit about CSS. Not
        everything we do but CSS in general yes.
  Rossen: I'm still not hearing any takers besides fantasai doing a
          process talk. It would be good to have at least one or two.
  fantasai: I said best practices.
  Rossen: Yes, do that.

  Rossen: Do we have anyone that wants to take the opportunity to
          talk about the more recent stuff or the things coming in?
          It would be good to have something more inspiring than
          'come help us'.
  Rossen: I'll take that as a weak yes.
  gregwhitworth: Can we do this on the list? I'm open to talking,
                 but I'd like to figure out what would be beneficial.
                 There's lots of buzz about round-display. I think
                 we can find speakers, but it would be cool to
                 figure out the subjects and then see who is best to
                 speak to them. Is that alright?
  Rossen: That's true, but speakers come with their topics. But for
          example if you want to talk about grid and flexbox, that
          is pretty relevant and recent from a web developer point
          of view.
  gregwhitworth: I'm game, yeah.

  Rossen: Bert did you have anything in mind to talk about yourself?
  Bert: No, I haven't thought about that. Maybe I'll come up with
        something, but not at the moment.
  Rossen: Let's leave it here. It sounds like we will have topics
          that will fill time. Between Houdini and fantasai and
          gregwhitworth's topics we'll have things. I'm also curious
          as to if SVG will join. That would take more time. I'll
          touch base with Shane.

Round Display

Animating 2d Rotation Transform Function for Polar Coordinates

  <Rossen> https://lists.w3.org/Archives/Public/www-style/2015Nov/0277.html
  <jihye> https://drafts.csswg.org/css-round-display/#2d-rotation-transform-function

  jihye: We sent the extension of the 2d rotation as added to round
  jihye: Keyword values polar-angle and polar-angle-reverse can be
         the value for the rotate function. There was discussion
         about animating this function. When polar-angle property is
         inside an animation and 2d rotation transform function is
         given polar-angle the transform changes because the
  jihye: Because polar-angle and polar-angle-reverse are computed
         value of polar-angle property the element revolves around
         the origin and the anchor point of the element.
  jihye: It is difficult to design the element's behavior where
         there is animation for the extended 2d transform. There can
         be a situation where polar-angle property and the function
         are animated.
  jihye: When the animation of the function is defined with
         polar-angle or polar-angle-reverse it means animating
         polar-angle property is used for an animation.
  jihye: It is possible, but I think it's weird.
  jihye: I think if you want to use the function with the keyword
         value for an animation there should be a condition of not
         animating the polar-angle property. With that condition
         it's animated with computed value. Does this make sense?

  smfr: I have a question, imagine you have a transform that looks
  <smfr> transform: translateX(100px) rotate(polar-angle);
  smfr: It has a translate and then polar-angle. Is the expectation
        that the angle is computed after the translation? Does
        polar-angle get computed after other transforms?
  fantasai: It's just a value of the polar-angle, it's not dependent
            on position.
  smfr: I thought there was a value that computed relative to the
        origin of the containing box.
  fantasai: No. It ends up working like that if you're doing a
            clock-face type layout, but if you position it using
            another property than polar-positioning, we would still
            take the value of the polar-angle.
  smfr: So if there's a transform does it effect the value?
  fantasai: No, just like margins or it being a flex box don't. It's
            just the value of the polar-angle property. It's a good
            point and we should make sure it's clear in the spec.

  <dbaron> So when determining the computed value of 'transform',
           does polar-angle turn into an angle, or remain as a

  myles: Am I right that the proposal is to make polar-angle not
  fantasai: It should be.
  myles: Then I'm confused.
  jihye: I think polar-angle is animatable and when 2D rotation
         transform with polar-angle or polar-angle-reverse we have
         to have a condition that not using polar-angle as animation.
         Is it possible to have this kind of limitation?

  dbaron: One thing I don't understand is if when you figure out the
          computed value of transform, does polar-angle turn into an
          angle or stay a keyword?
  fantasai: That's the fundamental question
  jihye: I think computed value.
  Rossen: What do you mean computed value? Is it an angle or a
          keyword? Both could be computed
  jihye: An angle, not a keyword.
  myles: So if that's true it's well defined to have animations on
         both properties. The element will just look like it's
         swimming when you animate.
  myles: When I brought this up a couple weeks ago, I wasn't sure if
         we've had anything where one animation depends on the
         result of another one.
  fantasai: Same situation as border color.
  myles: If there's precedent, it sounds fine.
  Rossen: Okay. So does that sound like a good outcome?
  Rossen: For you, jihye?

  jihye: Is it okay that polar-angle property is animatable and the
         function is used in animation? Both are okay?
  <bradk> Yes
  dbaron: I think it is. I think one other thing is that the
          animation behavior basically can be derived from what the
          computed value is, essentially. It maybe is worth thinking
          more about which computed value and animation behavior you
          want. That's not clear to me.
  dbaron: In other words, the decision about if polar-angle turns
          into an angle or is a keyword in the computed value it
          determines what the animation is.
  fantasai: If it stays as a keyword you can't animate between
            polar-angle, but as polar-angle animates, the rotation
            will also animate. If it turns into a value at computed
            value time then you can animate between polar-angle and
            a different angle. But if you animate polar-angle and
            the rotation, the rotation animation will not track the
            changes in polar-angle.

  Florian: I think we need to look at a number of examples that
           would try to do this and pick what makes sense. In theory
           it could be both, but it depends in practice what people
  Rossen: jihye do you have examples or preference for one or the
          other? Or are you looking for feedback?
  jihye: Maybe I can...I will write down the examples/use case in
         the mailing list and discussion can continue later.
  Rossen: That sounds fair. It would be good to see examples for
          that. I'm also having a hard time wrapping my head around
          which makes more sense.
  Rossen: Did you want to move on?
  jihye: Let's move on.

Using Polar Positioning as Part of Absolute Positioning

  <Rossen> https://lists.w3.org/Archives/Public/www-style/2015Nov/0253.html
  jihye: When the element is positioned with polar-coordinates, the
         position property has to be polar. But there had been an
         opinion for using polar positioning as part of abspos.
  jihye: bradk suggested instead of having positioning position,
         polar distance activates polar positioning. When the
         element is abspos it can have 'top' 'right' 'bottom' 'left'.
         Combining with polar positioning...I think it's
         unreasonable because 'top' 'right' 'bottom' 'left'
         indicates how far the padding edge is from the containing
         block's edge in abspos.
  jihye: With 'top' 'right' 'bottom' 'left' it is positioned based
         on containing block edge. Polar-distance and polar-angle
         are relative to polar coordinates. So they cannot combine,
         I think.

  <bradk> I don't think my microphone is working

  Florian: They could if we gave a different meaning to 'top'
           'right' 'bottom' 'left' when polar positioning is
  ChrisL: You could combine, but it's awkward. You'd have to treat
          polar-positioning as a transform and change your
          coordinate system and push around matrices. I'm not saying
          it's a good idea, but it's possible.
  fantasai: Or have the offsets represent changes to the containing
            block area so it would change the meaning of 100%.
  ChrisL: That's true.
  fantasai: We might need an initial value for polar-distance. You
            could have abspos change what the offset is and if you
            polar position it's in that new box. Similar to grid
  Florian: Wouldn't that be super counter-intuitive? If you put 10px
           left it would move it by 5px.

  fantasai: It looks like bradk's mic is broken. We may want to
            revisit when he can participate.
  <bradk> Yes. I don't understand the arguments against, which were
          not on the mailing list.

  Florian: To add a point, one aspect I found interesting in that
           proposal is that it could also work with relative
           positioning. Because as currently proposed position polar
           is a kind of abspos. If we do something along bradk
           proposal it would work in other positioning modes.

  jihye: I have a question for bradk. He suggested center property,
         but I don't think that is different from polar-origin
         property and the center property he suggested. Can I get an
         answer to that?
  Rossen: Since bradk can't talk without a microphone, we can wait
          to see if he can type a reply.
  Rossen: Or we can move the topic to the mailing list.
  <bradk> Center prop would be usable in other situations
  <bradk> Could take other percentage values
  <bradk> Could be center-x and center-y also

  jihye: Yeah. The discussion should be in the mailing list. It's
         better there, I think.
  Rossen: Let's pause on this for now and move it to the mailing list.
  <bradk> Please present all arguments against in the mailing list.

Dealing with Pull Request Pile Ups in our Test Repo

  <Florian> https://github.com/w3c/csswg-test/pulls
  Rossen: Florian brought this up as a frustration and it's a good
          topic for us to bring up for discussion and visibility. As
          stands the test repo pull requests are piled up a bit.
          There's a few questions. How and who should deal with this?
  Rossen: The presence of volunteers to deal with this. And in the
          future how to move forward so there's more test coverage
          in the repo.
  Florian: I don't know if everyone has opened the link, but there's
           28 pull requests, most of which are months old. Only 6
           are mine.
  Florian: It's not necessarily all things get stuck, but depending
           on which spec and area, some topics have a hard time
           getting review and that's bad.

  Rossen: So that is the problem.
  Rossen: Do you have a proposed way forward?
  Florian: One would be, since now everything is piled up, but once
           that's done go through every spec affected by a pull
           request, ask who feels responsible, and if yes why it
           didn't happen and if no who is responsible for that.
  Rossen: Okay. So I'm not hearing anyone...
  Florian: Not hearing anyone rush to the rescue.
  Rossen: No, and historically editors are willing to jump on test
          coverage, but specs are different in their velocity of
          being worked on. If editors aren't paying attention to one
          area I can see how it piles up.

  Florian: I think the problem is worse than the queue. When I have
           something like a few test cases submitted and waiting, I
           don't submit more, and I don't think I'm alone in that.
           So there's tests in people's head or computer because
           something isn't moving.
  Rossen: That's a fair point. Especially with TTWF events where we
          try and get attention. If the response from our side is
          silence and sitting on reviews, it's going to discourage.
  Rossen: I'm not going to push for immediate action or having to
          have a process in place, but I wanted to bring this on
          everyone's radar for awareness. If people have ideas it
          would be great to discuss those on the list. We can
          revisit in week or two.
  Rossen: We'll have to make more decisions with no movement.

  fantasai: We in the WG...it's largely people in a PM role. We have
            developers on the list, but we don't have QA people
            across the WG.
  fantasai: QA people do their own thing. Maybe we create a
            community there and maybe have them talk about how to
            make their jobs easier in a community. But we don't have
            that now. Jeffery S. is the only QA person we have now
            and that's new. The people working on testing need to
            get involved.
  Florian: Producing the test suite is in the charter of this group.
           People in the group should care.
  fantasai: But this has been a problem for how many years? Whatever
            we have in terms of structure isn't working.
  Florian: I think what you're suggesting would help. but also name
           who is in charge of test suite.
  <dbaron> Didn't we do that before?
  ChrisL: I think that's a good idea.
  fantasai: I'd like that. We've tried and it varies on the person
            named. I think we should do that and have a strong
            ownership model of the tests. Then the question is who
            will work on tests and who cares.
  Florian: I'm willing to review tests submitted against specs, but
           can't review my own.
  Florian: Naming isn't just ownership, but visibility for when
           someone isn't doing it we know we need someone else.
  <fantasai> We don't have sufficient people to replace people who
             aren't doing their job.
  Rossen: Submitting tests shouldn't be different than code changes.
          You write code, submit it, and someone reviews your
          changes. Testing shouldn't be different, it isn't on our
  Rossen: Having people that are reviewers for an area, spec editor
          or not, has to be determined. In the end someone has to
          own the test side of something like, say, flexbox. When
          tests come that person should be expected to review.
  Rossen: There there is a thing where someone dumps hundreds of
          tests and that's a bottleneck.
  Florian: That's okay. If that happens it needs to clear eventually.
  Florian: I think we need two people for each area since the person
           in charge couldn't submit tests themselves.
  Rossen: Certainly.
  <dbaron> I tend to think tests shouldn't have as high a standard
           of review as code; there are many categories of tests
           where mistakes will be caught as a result of seeing
           failures and saying "but that behavior is correct"
  <astearns> +1 to dbaron's comment

  Florian: So do we name people today? Probably not. The other
           question is do we go through specs in the queue today and
           see if people will react.
  Rossen: I don't think we could get anywhere actionable today. We
          have 13 minutes and more topics. We brought awareness. It
          would be good for use to discuss this on the ML and move
          forward both with the current queue and get the process
          forward for the future.
  Rossen: Let's stop here and Florian if you want to ping people for
          your areas I would start with the spec editor and if you
          happen to be the spec editor ping someone else and see if
          they can help. Otherwise ping me.
  Florian: I've done that already.
  Rossen: I see. We have a problem and as fantasai pointed out it's
          not new.
  * fantasai notes that we don't seem to have anyone in charge of
             testing overall, either.

  <Florian> Just for the record, some of the specs in the test case
            PR queue: css-page, css-ui, selectors, css-cascade,
            css-flexbox, css-variables, css21, css-transforms,
            css-shapes, css-fonts, css-masking, clip-path

  <dbaron> Not sure the will-change ones need group discussion
           rather than just an editor response.

Progress Report on Snap Points

  Rossen: It's a status update we're looking for from MaRakow.
  MaRakow: I'm working on merging in the snap point changes; I'm
           adding area and align first and those are mostly merged
           in. Once those are in and I update the definitions I
           think it'll be a coherent set I can push up.
  MaRakow: Right now it has references to other items that need to
           be merged, but it should be a reasonable intermediate.

  fantasai: While you work on this we should have resolutions on the
            specific technical things that we're changing.
  <fantasai> 1. Replacing scroll-snap-destination with
  <fantasai> 2. Replacing scroll-snap-coordinate with
  <fantasai> and scroll-snap-area
  <fantasai> 3. Adding axis keywords to scroll-snap-type
  fantasai: These are the things you're working on. If there's no
            reason to disagree and you're doing the editing, it
            would be good to have a resolution from the WG on the
            books since we didn't get there at TPAC.
  MaRakow: For #1 and #2 that makes sense but there may be some
           small changes. #3 we discussed if axis was going to be
           its own property and that's still on the ML.
  fantasai: Yes and we can have an issue on that. I would take that
            ML discussion as a separate issue and have the
            resolutions as the changes we're making.
  MaRakow: Would it make sense to resolve the issue before the
  fantasai: I want to give implementors a clear direction where
            we're going.
  fantasai: So, we can make the resolution be have axis keywords on
            a scroll container, TBD which property. That's what's up
            in the air.
  fantasai: I want to make sure the things we agreed on are recorded
            as agreed on.
  fantasai: So for #3 we would resolve "Add axis keywords to a
            property applied to the scroll container."
  MaRakow: Yeah. I think that makes sense.

  fantasai: So we're in agreement. Does the rest of the WG want to
  Rossen: So you agree on points 1 and 2. Right now you also agree
          on the axis keyword pending some open issues.
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2015Nov/0328.html
  fantasai: Open issue^
  <fantasai> "Add axis keywords, pending shorthanding issue, per
             [message above]"
  Rossen: Okay, anyone object?

  RESOLVED: Replace scroll-snap-destination with scroll-snap-padding
  RESOLVED: Replace scroll-snap-coordinate with scroll-snap-align
            and scroll-snap-area
  RESOLVED: Add axis keywords to a property applied to the scroll
            container with added issues

  Rossen: Okay. We're looking forward to more edits and the spec
          coming out soon.
  fantasai: We are looking for comments on that issue.

Will Change

  Rossen: dbaron preference on will change topics?
  Rossen: First one is establishing containing block for fixed
  dbaron: It's okay to let the editor deal with these.
  <Rossen> http://lists.w3.org/Archives/Public/www-style/2015Nov/0334.html
  <Rossen> http://lists.w3.org/Archives/Public/www-style/2015Nov/0332.html
  dbaron: They're both wording details. I don't think there's big
          issues to discuss. As long as the editor agrees that what
          was meant by the spec is what I think, we don't need
  Rossen: Okay.
  Rossen: Sounds good.
  Rossen: If this is something that can be taken care of by
          TabAtkins let's leave it.
  Rossen: We have 3 minutes. Any topics or do we end early?

Dealing with Pull Request Pile Ups in our Test Repo

  dbaron: One comment on the testing issue. I tend to think the
          standard of review for tests shouldn't be as strict as
          code. If a test is testing something that a dev later
          concludes isn't what the spec calls for that gets caught
          later in the process.
  dbaron: Basically I think tests shouldn't need a huge amount of
          review. They should be reviewed...at least for
          contributers proven somewhat competent, they should jsut
          be reviewed for is this testing the thing it says it's
          testing. Rather that than set up a comprehensive process.
  <astearns> tests have long-term continuous review by getting in
             the test suite and getting run
  fantasai: I think that is the key issue. As long as a test is
            testing for what it says it should be accepted.
  <fantasai> Review requirements:
  <fantasai> 1. Does this pass when it should pass?
  <fantasai> 2. Does this fail when it should fail?
  <fantasai> 3. Does this test what it thinks its testing?
  <fantasai> I don't think anything else is necessary, though more
             detailed comments might be nice in some cases.
  Florian: There's a higher risk for tests that pass when it
           shouldn't, but given the lack of review we have that's a
           lesser evil.
  Rossen: These are all fair points. I wasn't suggesting a level of
          rigor. If they're going through a short list and later let
          them be rejected that's fine. Or we can do detailed
          reviews and only accept tests that we think will pass.
          It's a long topic, but something we should keep discussing
          and come up with solutions.
  Rossen: Especially while we have tests. We don't want to stop that.

  Rossen: We're at the top of the hour. That's everyone and see you
          next week.
Received on Thursday, 3 December 2015 10:32:42 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:55 UTC