W3C home > Mailing lists > Public > www-style@w3.org > March 2017

[CSSWG] Minutes Telecon 2017-03-22 [css-cascade-3] [css-conditional] [css-value] [css-backgrounds] [css-transforms] [flexbox] [css-ui-3]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 22 Mar 2017 21:11:19 -0400
Message-ID: <CADhPm3srtnMi3TmYOMmPnJrnXk=6AGkzt6WjZNwXup99=DMj_w@mail.gmail.com>
To: www-style@w3.org
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

REC spec steps tête-à-tête

  - Cascade 3
      - fantasai reported that there are edits that need to be made.
      - gregwhitwoth with port the Microsoft tests into the test
  - Conditional Rules
      - dbaron & zcorpan need to incorporate edits.
  - Values & Units
      - Approval for the <position> edits will be added to next
          week's agenda.
  - Background and Borders
      - There are working group approved edits that need to be made
          to the spec and then have a republish.
      - tmichel will put together an implementation report.
  - Transforms
      - About half the open issues need feedback from people who
          have worked on SVG. smfr will reach out members of the old
          SVG working group to set up a call, perhaps during the old
          SVG telecon time.
      - smfr will need assistance in evaluating the test suite.
  - Flexbox
      - Open items are actively being discussed on telecons
          (including today) and after that there will be a
          republication ask.
      - gregwhitworth and/or gsnedders will evaluate the test suite
  - CSS UI
      - astearns and fantasai will split the work of reviewing the
          tests Florian submitted.

Publication of Paint as FPWD

  - RESOLVED: Publish FPWD for CSS Paint
  - RESOLVED: Short name is fill-stroke with a title of Fill and


  - Though there was agreement that the use case in issue 401
      (https://github.com/w3c/csswg-drafts/issues/401) was broken by
      the change, the group felt that the change was throughly
      considered and still the right choice.
  - RESOLVED: No change on issue 401
  - fremy will open bugs on those browsers that do not conform to
      spec when sizing images with intrinsic aspect ratio. These
      bugs will reference issue 1112
      in case a behavior change is needed.
  - fantasai requested more review of the flex basis and box-sizing
      issue (https://github.com/w3c/csswg-drafts/issues/316) to see
      if there's actually a compat risk to fixing the behavior to be
      as intended.
  - The remaining issues that need discussion will be added to next
      week's agenda so that Flexbox can be republished.


Agenda: https://lists.w3.org/Archives/Public/www-style/2017Mar/0067.html

  Rachel Andrew
  Rossen Atanassov
  David Baron
  Bert Bos
  Tantek Çelik
  Alex Critchfield
  Benjamin De Cock
  Emil Eklund
  Elika Etemad
  Simon Fraser
  Tony Graham
  Dael Jackson
  Brad Kemper
  Vladamir Levantovsky
  Chris Lilley (IRC Only)
  Peter Linss
  Myles Maxfield
  Thierry Michel
  Michael Miller
  Theresa O'Connor
  Anton Prowse
  Matt Rakow
  Melanie Richards
  Hiroshi Sakakibara
  Jen Simmons
  Geoffrey Sneddon
  Alan Stearns
  Greg Whitworth

  Dave Cramer
  Daniel Glazman
  Florian Rivoal

Scribe: dael

  astearns: Let's get going
  astearns: Is there anything anyone would like to add to the agenda?
  <fantasai> astearns: Publication of Paint as FPWD?
  astearns: I'll add the publication as the item after rec steps.
            Thanks fantasai.

REC spec steps tête-à-tête

  astearns: We had a bunch of chatter on public & private lists for
            some including fonts and variables.
  astearns: There are a few blanks we need to add in.

Cascade 3

  astearns: So does anyone know next steps for cascade 3?
  <gregwhitworth> testsuite was what we discussed last right?
  <fantasai> astearns, cascade 3 needs an edit to drop scoped styles
             and it needs a testsuite
  astearns: [reads gregwhitworth & fantasai]
  astearns: I'll put that as next steps that we'll have those edits
            to reduce scope. Who is going to work on test suite?
  <fantasai> astearns, tests exist, but perhaps not in the right
             format, e.g. IIRC dbaron said Mozilla's tests are in
             mochitest format
  <dbaron> reducing the scope, eh?
  gregwhitworth: We reviewed last time. We have extensive tests we
                 can provide, but need to port. There is one thing
                 in cascade we don't support.
  astearns: Is that on you?
  gregwhitworth: Yeah. Sure.

  <fantasai> what's unsupported?
  astearns: [reads fantasai ]
  astearns: Can we get a volunteer to convert those?
  astearns: Lacking a volunteer we'll find someone. We have three
            next steps.

Conditional Rules

  astearns: Conditional rules. What's the next step?
  <fantasai> astearns, Conditional Rules needs republication
  <fantasai> astearns, it's taken some edits. Has outstanding
             resolution to publish
  dbaron: I suspect needing tests is at least a big piece.
  dbaron: I haven't looked at the state of the suite.
  astearns: [reads fantasai]
  astearns: fantasai, what needs to be changed?
  <fantasai> astearns, yeah, on the call, can't speak atm, dbaron
             should have updates
  dbaron: I have another thing. The OM stuff needs work. They have
          competing models and we really need some pieces of one and
          some of the other.
  astearns: So outstanding edits, can I add you, dbaron, as the
            person to review and edit?
  dbaron: Me and zcorpan probably.
  dbaron: It might come down to deleting stuff from conditional
          rules because OM is in a better state. We also need to
          figure out which spec should have it.

  astearns: What about test suite? Do we have tests in various
  dbaron: I'm sure Gecko has some, I don't know what format or
          amount of conversion.
  astearns: Can you find someone to make that assessment?
  <gregwhitworth> I'm sure we all have tests, converting them all to
                  work in the wg is hard to promise
  dbaron: I could eventually. I'm at a state where I can't promise
          anything before next F2F
  <gregwhitworth> this is me too
  astearns: That's fair. It's good to have that there are test to
            convert, even without a person.
  astearns: [reads gregwhitworth]

Values & Units

  astearns: On to Values & Units. What needs to be done there?
  astearns: Who should know?
  <fantasai> astearns, needs republication after <position> edits
  <fantasai> astearns, also needs a test suite compiled
  astearns: [reads fantasai]
  <fantasai> <position> edits are done; needs review
  Rossen: Which <position> edits?
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2017Mar/0054.html
  astearns: [reads fantasai]
  astearns: Looks like we need the edits on the agenda and then
            republish. I'll put that on me to add to the agenda next
  <fantasai> astearns, see link above for edits & commentary on said

Backgrounds & Borders

  astearns: Backgrounds & borders has had test suite work. It would
            be great to have someone review the state of the test
            suite and see if recent edits have been good.
  astearns: Who can take a look at the B&B tests?
  <fantasai> spec needs republication as well; a handful of edits
  <fantasai> but nothing significant
  Rossen: Have there been changes recently? It seems the spec has
          been stable for quite some time.
  Rossen: It seems to have fallen off the radar. There's quite a bit
          of interop and we need to button up the test suite.
  <fantasai> https://drafts.csswg.org/css-backgrounds-3/#changes
  Rossen: I see fantasai points out there's a handful of edits.
  Rossen: I'm assuming they're mostly editorial and I'm curious to
          know if we need any kind of resolution or if they're the
          result of resolutions.
  <fantasai> They're not editorial, but they're WG-resolved.
  <fantasai> but again, see message wrt <position>
  <dbaron> Mozilla has a lot of B&B tests, some of which may have
           been contributed to the WG before the WG accepted
           reftests... and thus might need to be re-contributed...
  astearns: [reads fantasai]
  Rossen: Okay.
  Rossen: In that case is those are shovel ready we just need to
          make it happen and republish.

  astearns: That and get someone to review test suite.
  Rossen: Right.
  Rossen: I think the test suite is on everyone. I would be
          surprised if there's an impl on call that doesn't use
          testing as part of their practice. Those are the tests we
  astearns: But assigning evaluation to everyone doesn't get us
            anywhere. Getting one person to evaluate and put a
            report together if we're ready is good.
  Rossen: Right. I mis-understood.
  astearns: From IRC there's additional tests for Mozilla. We need
            more test review in this process because each spec needs
            review of if the test suite is in a good state.
  Rossen: I see bradk, Bert, and fantasai as editors.
  Rossen: bradk or Bert is this something you can take as an action?
  tmichel: A few months ago I worked on the test suite and tried to
           evaluate coverage.
  tmichel: My opinion is that most of the features are covered but
           today we have about 80% of the tests passing 2 impl.
  tmichel: The impl work is pending. It's improved a lot in a year.
  astearns: tmichel can you put together an impl report to show
            what's not passing?
  tmichel: Yeah, I can do that.
  astearns: Thank you.
  tmichel: Are you interested in only the ones that are not two, or
           are you interested in only one?
  astearns: All tests with NOT 2.
  tmichel: Thank you
  <bradk> thanks tmichel


  astearns: Transforms. What is the next step? There were a bunch of
            issues resolved in seattle.
  smfr: There's 27 open issues. A fair portion need SVG work. We'll
        have to go through those with SVG representation. I don't
        know what that will be.
  Rossen: We have a large bit of SVG representation.
  fantasai: I think we should make an explicit effort to pull in the
            former SVG WG people that aren't here and get them
            involved. We need to coordinate a specific SVG meeting
            or telecon. Maybe we can slot it into the old SVG time
            slot. We won't be able to get them all to the F2F. We
            could probably do a telecon.
  Rossen: I like that idea.
  Rossen: I think sending an e-mail to the SVG ML to get things
          going would be great. We'll see if we can re-use the SVG
  Rossen: smfr out of the 25 how many need SVG? All?
  smfr: Maybe 12 or 15-ish?
  Rossen: About half.
  fantasai: Paint has a bunch of issues that need SVG too.
  Rossen: That's fine. Sounds great. Let's reach out and go from

  Rossen: We didn't cover...do we have any test suite for transforms
          L1? If not can we get that moving?
  smfr: I think we have some contributed, but I don't believe
        they've been brought together for review. I don't have
        bandwidth for that.
  Rossen: So you'll need help evaluating what's there and do another
          round of calls for tests.
  gsnedders: From memory there were problems with references not
  Rossen: Okay.
  Rossen: gsnedders is this something you can run through and see if
          there are any good tests and next week we can discuss?
  astearns: gsnedders needs to finish the web-platform-tests
            transaction first.
  Rossen: Fair enough.

  <gregwhitworth> when does that happen?
  gsnedders: Plan is to do it on Tuesday.
  gregwhitworth: Will we be working out of wpt at that point?
  gsnedders: Yes.
  gregwhitworth: Okay, cool.
  <gsnedders> gregwhitworth I'll send out a further email on Friday
  <gregwhitworth> gsnedders thank you so much!!
  <gsnedders> gregwhitworth confirming that yes, it's going ahead
              roughly when I said so (okay okay a day late)


  astearns: Next is flexbox. It looks like someone recently
            reviewed, but no one can remember where that evaluation
            went. Did that happen?
  astearns: And is that the next step?
  fantasai: It needs republication. There's a couple of open issues.
            We do need the test suite compiled and evaluated. All
            these need to happen.
  astearns: A couple of the flex issues are on agenda. Is there
            anyone that can volunteer for test suite?

  <skk> Regarding test (not specific to any specs), I read minutes
        that there lacks QA people in WG. If it's OK, I want to
        announce broadly as much as possible that in Japan. If there
        is a website regarding this, it's easier for me to tell
        people in JP.
  skk: Regarding what I put in IRC...There's no website. If there's
       a website it's easier for me to announce that we need QA in
  <dbaron> https://wiki.csswg.org/test ?
  <gsnedders> dbaron: and http://web-platform-test.org/
  astearns: Let me talk to you off the call for what would help with
            recruiting QA people in Japan.
  <skk> It's happy to communicate in email. Thanks.
  <fantasai> skk, astearns, feel free to loop me in; gsnedders might
             be helpful, too, he knows where existing docs are :)

  astearns: We still need a volunteer.
  gregwhitworth: I can do both the list dive and the review. I can
                 see what we have and what we have internally.
  gsnedders: I've also spoken with people at looking in the next
  astearns: Depending on gregwhitworth timing perhaps you two can


  astearns: Next is UI. I believe next step is review test suite
            from florian
  <tantek> someone other than the editors preferably :)
  astearns: This is smaller, this is just getting florian's
            submissions into the suite. And as tantek mentioned it
            should be a non-editor.
  astearns: fantasai, are you and editor?
  fantasai: Nope.
  astearns: Can I assign the review to you?
  fantasai: Um...I guess.
  fantasai: My current priority is to get grid, flexbox, and
            display:all published.
  astearns: I'm hoping this is a small task. It's reviewing
            florian's work.
  <tantek> I'm sensing that fantasai is already quite overloaded,
           would help to get another volunteer!
  <tantek> also this feels like something that a new-ish person
           could review
  <tantek> so if there's a new WG member that wants to try an "easy"
           review task, this would be a great one to do!
  <tantek> we have a few new WG members right?
  gsnedders: In a general sense I'd like us to land as many open
             pull requests as possible in the next week as pulling
             them over in manual work.
  astearns: That is true. And I doubt fantasai will get to it in
            that time. It would be great to have another volunteer.
  fantasai: I'll give it a try tomorrow.
  astearns: Once you do look fantasai see if there's anything you
            and I can split up. I'll volunteer.

  gsnedders: I was planning on looking at the 2.2 test in the next
             few days because they have silly amounts of comments
             and I don't want to move them over.
  <gsnedders> https://github.com/w3c/csswg-test/pull/1139
  astearns: So as you look at 2.1 tests if there's anything you can
            throw to me I'll try and help.
  <bdc> (I'm also happy to have a look, although I'm not entirely
         sure yet how all of this works)
  <gsnedders> bdc: http://web-platform-tests.org/reviewing-tests/index.html

  astearns: So that's everything. We have next steps for all specs
            on the list. I'll send a summary to the private list.
            We'll try to make this quicker and easier as we go.

Publication of Paint as FPWD

  <fantasai> https://lists.w3.org/Archives/Public/www-style/2017Mar/0059.html
  fantasai: TabAtkins and I think we're ready. We merged in heycam's
            paint spec. We finished last week. There's a ton of
            issues, but I think it's ready for FPWD.
  astearns: Anyone have anything to add?
  Rossen: Did anyone besides the editors review?
  <ChrisL> I can take a look at Paint.
  fantasai: Amelia sent a bunch. Someone else sent some changes. We
            should look at that set as an issue, but it shouldn't
            hold up FPWD. It was mostly syntax adjustment.
  <ChrisL> +1 to fpwd
  fantasai: We did go over it in detail in, I believe it was the
            Sydney F2F so the design of features has been discussed
            with WG.
  Rossen: Thanks.

  astearns: Objections to FPWD for Paint?
  <tantek> ship it!

  RESOLVED: Publish FPWD for CSS Paint

  fantasai: Can we get short name approval?
  astearns: Are we going with paint?
  fantasai: Yeah. Someone, used to be plh, has to officially notify
            the webmaster it's okay.
  <tmichel> yes Plh is still the right person
  <ChrisL> shortname approval is part of the fpwd transition request
  astearns: plh is still right according to tmichel and ChrisL said
            we put the short name as part of the request. Objections
            to paint as the short name?

  RESOLVED: Short name is paint.

  <ChrisL> ok I will do the transition request

  Rossen: And the name will be ... ?
  dbaron: Sorry, I had a hard time getting off mute. Is short name
          css-paint or paint?
  fantasai: Just paint. That's the naming convention of fxtf.
  dbaron: It's a broad short name.
  fantasai: It's fill and stroke properties from svg.
  dbaron: Okay...I guess.
  <tantek> I thought Houdini had a Paint also
  <ChrisL> paint api
  <tantek> this will be confusing

  fantasai: I'll take alternatives. I just don't have one.
  Rossen: fxtf-paint?
  dbaron: Let's not put fxtf in the name of a spec when it may be
          about to disappear.
  <gsnedders> +1 on what dbaron said
  Rossen: Yes, but I strongly agree paint is broad.
  dbaron: Paint is fine. Let's stick with it.
  fantasai: If there are better ideas let us know and we'll prepare
            the publication next week. Post the better idea to the
  Rossen: Module is fill and stroke?
  fantasai: Yes. That's clearer and easier for people. But as a
            short name 'fill and stroke' is a bit long.
  <tantek> why not "fill-stroke" then :P
  tantek: I'm a little concerned about confusion with Houdini's
          paint. If this does not have something to do with
          Houdini's we shouldn't have short names that make it seem
          that way.
  <Bert> (good point, tantek)
  Rossen: fill-stroke seems pretty good.
  astearns: Yep. Any concerns on fill-stroke?
  fantasai: My only concern is if that ends up too specific. I'm not
            100% sure.
  astearns: More specific is probably better than too general.
  fantasai: True.
  astearns: Objections to short name of fill-stroke?
  <bdc> +1

  RESOLVED: Short name is fill-stroke with a title of Fill and Stroke


Absolute Positioned Elements in Flex Containers Removes Common Layout

  <astearns> https://lists.w3.org/Archives/Public/www-style/2017Mar/0067.html
  <fantasai> https://github.com/w3c/csswg-drafts/issues/401
  fantasai: We got an issue where somebody is complaining about a
            change we made. In an earlier draft we have a behavior
            that static position is where it would have been if it
            was in flow. The major problem with that is
            implementations were making it take space when you were
            using space around or other alignment properties.
  fantasai: That kind of violates the idea that abspos things
            shouldn't effect flow layout. There was lots of
            suggestions and discussion and we ended up with the
            current spec.
  fantasai: This broke some use cases. This was a library with
            vertical dividers and they did it with abspos and they
            couldn't do that anymore.
  <dbaron> what do implementations do today?
  <dbaron> I'm skeptical that we can just go change behavior for
           this stuff at this point
  fantasai: They filed an issue. They're unhappy with the change. I
            don't have a strong opinion, but implementor have an
            incentive not to change and authors are frustrated they
            can't get the static position they want.
  fantasai: This is for the WG to discuss.

  dbaron: What do implementations do today?
  Rossen: We all match the behavior we agreed on. We started by
          computing static position as was requested by this issue.
          Later we reverted to 0,0 when order came into play. That
          added impl complexity. At this point all impl compute
          static position as the origin of the flexbox. For what
          it's worth there's already some content dependency on this
          given the amount of flexbox content.
  <bdc> safari does the right thing imo
  Rossen: In short, we all do what the spec says. And there's
          content that will break if we change impl.
  Rossen: Also, the 0,0 static position was not random. There were
          long discussions. That was not a quick decision to wave it
  fantasai: I think it was largely because there were a lot of
            complications on meaning for 'where it would have been'.
            There was a justification problem where if you justify
            and there's an abspos in the middle where does it go. We
            punted all this complexity and defined static position
            as if the abspos were the only item in the flex
  Rossen: Correct. Also one thing worth pointing out is there's an
          easy work around to achieve the same by adding the 0 size
          flexbox with relative position and have whatever you want
          inside to achieve the same behavior. It sucks to add
          another element, but it's a totally achievable work around.
  <rachelandrew> It seems to be an issue with this particular
                 library - I'm not hearing the same issue a lot from
                 other authors

  astearns: I'm not hearing any impl interest in changing behavior
            to help this use case. Does anyone want to speak in
            favor of this change?
  eae: We'd rather not change.
  fantasai: If we're starting over we could dig in further, but at
            this point it will be quite difficult to make a change
            for something that's not super compelling. Another issue
            is I don't know how you interpret this in grid and we
            try and keep them consistent.
  astearns: In effect we're resolving the static position of abspos
            elements is different in flex and grid then in previous
            layout systems.
  Rossen: But that resolution has been recorded and made in the past.
  <tantek> resolving to keep prev resolution is usually a good thing
  astearns: Right. We're resolving no change and that out new layout
            system is different from those in the past.
  astearns: So objections to resolving no change?

  RESOLVED: No change on issue 401

Sizing images with intrinsic aspect-ratio: ¿harmonize with grids?

  <astearns> https://github.com/w3c/csswg-drafts/issues/1112
  fremy: Basically this issue came up when I was pursuing Manuel
         Rego's question on the images change in grid. He asked if
         this applied to flex. I was wondering what we do and I
         found we aren't interop.
  fremy: When we have images the decision to flex is different
         across browsers. I wanted to point it out. It seems like
         Edge is per spec. I wanted to make sure people are okay
         with spec and, if so, we can file a bug.
  astearns: Opinions on FF and Chrome behavior?
  fremy: I think if no one reviewed the test case it's unlike
         there's a conclusion. It's a good time to ping people and
         make sure there's review.
  astearns: I think next step is for you to write bugs.
  fremy: That's fine. I can do that.
  dbaron: If you write bug, please link to this issue in both
  fremy: Okay
  fantasai: I think there's two things where there are bugs, but if
            anyone wants to think about what we should be doing
            here...there is a distinction in flexbox where if you're
            larger then intrinsic you get one behavior and smaller
            is a different behavior. Anyone with an interest can
            look at the behavior as spec and do we need to tweak
            flex, or grid, or leave as-is. That's the question at

  ACTION fremy to write bugs on other browsers to get a response on
         if they can change to match spec (for issue #1112)
  <trackbot> Created ACTION-837

Flex basis and box-sizing

  <fantasai> https://github.com/w3c/csswg-drafts/issues/316
  fantasai: There's another flex issue that needs input ^
  fantasai: Not to resolve now.
  fantasai: We have a problem with how flexbox works. The goal was
            if you say flex and then an int the goal is the flexbox
            would take that int's space. So if you want it even you
            can do all 1, or you could do 2 and 1 to get thirds. But
            that doesn't work right now because the effective flex
            basis is not 0, but the sum of the margins and borders
            and padding.
  fantasai: It would be nice to fix the spec to get expected
            behavior of exact proportions. I don't know if that's
            web compat or how to evaluate this.
  astearns: So you would get the precise behavior only if box-sizing
            is set to border-box?
  fantasai: For sure that would work. Flex basis is set to follow
            content box-sizing. If you're using border box sizing it
            should account for the entire border box.
  dbaron: I guess some of the question is what stage can things go
          negative. Normally with box-sizing we have that the
          content box can't be negative.
  fantasai: I'm not sure what case would be negative.
  dbaron: Flex basis of 0 and border box then your content box would
          be negative.
  astearns: If you have borders.
  fantasai: Yeah.
  <dbaron> It's also not clear to me if we could take a compat hit
           here at this point
  <tantek> yeah
  fantasai: End result to maintain the variant where content box is
            never negative the flex would have to impose the sum of
            borders and padding as a minimum. So content box won't
            be negative but flex basis used value could be negative.
            We use the outer size of the flex item in calculations.

  astearns: Both dbaron and TabAtkins mentioned that for compat we
            probably can't change. I'm thinking this might be next
            level of flexbox to have an additional switch to get the
            desired behavior.
  fantasai: I'm worried, but I'm not sure we're in that situation. I
            think more flexbox use an equal number instead of aiming
            for a ratio and that's the only cases where you would
            have a change. If the padding is small comparatively you
            wouldn't really notice the change. It might be an issue,
            it might not. I do think we really screwed up in
            relation to the intention for it.
  fantasai: I'm interested in what people think about compat and
            what's a good way to evaluate.
  astearns: Alright. Thanks for bringing this up. It's good to get
            people thinking.


  asteanrs: Next topic is percentage [max-]width|height and
            intrinsic sizes.
  astearns: We have 3 minutes
  fantasai: That's scary. Let's just resolve to republish flexbox as
            it's out of date?
  <tantek> yes please resolve to republish
  astearns: That's possible. It's CR?
  fantasai: Yes.
  fantasai: Let me pull the issue list.
  <fantasai> https://drafts.csswg.org/css-flexbox/issues-cr-20160526
  fantasai: I do have a DoC, but we have a couple more issues.
  astearns: We're close but not quite for republish.
  <tantek> ok
  astearns: Let's get those issue on next week's agenda.

  astearns: I think we should call it for the week, looking at the
            remaining issues.
  astearns: Thanks everyone for calling in. I'll follow-up on a few
            of the rec steps that need some people assigned.
  astearns: I'll also send a summary.
  astearns: Thanks everyone.
Received on Thursday, 23 March 2017 01:12:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:07 UTC