[CSSWG] Minutes Telecon 2017-03-29 [fill-stroke] [css-align-3] [css-images-4] [css-multicol] [css-cascade-3] [css-conditional] [css-value] [css-backgrounds] [css-transforms] [flexbox] [css-ui-3] [css-fonts-3]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.


  - RESOLVED: FPWD of fill-stroke as level 3

Spec REC-ing

  - Fonts 3
      - ChrisL requested some help getting the test font to work in
          Edge and Firefox.
      - The decisions on what to move into Level 4 are blocked on
          the test font issue.
  - Cascade 3
      - Some tests have been added, Microsoft is working on adding
  - Conditional Rules
      - RESOLVED: Republish CSS Conditional Rules CR update
      - The edits around CSSOM will wait until during or after the
  - Values & Units
      - Publication is waiting on review of the <position> changes.
          Review was requested over the next week.
  - Backgrounds & Borders
      - The implementation report from tmichel had 82% passage. 20
          of the tests had problems so he'll fix them and re-run the
  - Transforms
      - fantasai is preparing an agenda before scheduling a
          conference call with SVG folks.
  - Flexbox
      - Open items will be added to the agenda.
      - gregwhitworth is working to understand what tests are
          currently in the test suite.
  - CSS UI
      - The open pull requests have been reviewed and those that
          needed changes are ready for re-review.

Publish request to updated WD of css-align-3

  - RESOLVED: Republish updated WD of css-align-3

Blink Intent to Implement conic-gradient()/Images 4

  - RESOLVED: Add leaverou as co-editor for CSS Images
  - RESOLVED: New WD publication for CSS Images 4
  - RESOLVED: Update shortname to css-images-4


  - RESOLVED: column-spans create a formatting context, not a
              specific one
  - Issue 1074 (definition of `column-span` should say what happens
      without an ancestor multicol /
      was discussed, but no resolution was reached.
      - Originally a few people believed that the logical behavior
          would be to retain the formatting context as the author
          laid out the context with the assumption that it
          establishes a new formatting context.
      - However, it was then brought up that this is inconsistent
           with how other layout modes like flexbox and grid work.
      - These two sides couldn't agree on the best solution during
           the course of the call, so conversation will continue on


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

  Rachel Andrew
  Rossen Atanassov
  David Baron
  Bert Bos
  Tantek Çelik
  Alex Critchfield
  Benjamin De Cock
  Emil Eklund
  Elika Etemad
  Daniel Glazman
  Dael Jackson
  Brad Kemper
  Vladamir Levantovsky
  Chris Lilley
  Peter Linss
  Thierry Michel
  Anton Prowse
  Matt Rakow
  Melanie Richards
  Jen Simmons
  Geoffrey Sneddon
  Alan Stearns
  Lea Verou
  Steve Zilles

  Tony Graham
  Michael Miller

Scribe: dael

  Rossen: Let's get going.
  Rossen: Any extra items that you want on the agenda?
  glazou: The CSS Grid issue I mentioned. Issue 1137.
  Rossen: Thanks. This issue hasn't had any take on GH so I'll leave
          it for the end. If we don't get it it'll take it's turn on

  Rossen: Quick reminder. Next F2F is coming up soon. We have a
          couple weeks. If you haven't made travel arrangements you
          better hurry up.
  Rossen: Also please add topics to the F2F agenda.


  fantasai: For the agenda, for fill-stroke to publish I need a
            level so we need to resolve on that.
  Rossen: Did you have one in mind?
  fantasai: I would suggest 3.
  ChrisL: makes sense to me
  Rossen: Any objections to FPWD of fill-stroke as level 3?
  <tantek> ship it!

  RESOLVED: FPWD of fill-stroke as level 3

Spec REC-ing

Writing Modes

  Rossen: First is writing modes. I didn't hear from koji. Is he on
          the call?
  Rossen: Okay, let's come back to that.

  Rossen: Updates on Fonts L3? I know Chris was adding tests and
          myles IDing features for L4.
  ChrisL: I sent an update with more tests and I started converting
          to ref tests. Still blocked that Edge and FF don't render
          the test font correctly. The font renders differently...I
          sent you a message Rossen
  Rossen: It's an interop issue between the browsers?
  ChrisL: Yes.
  fantasai: Sounds like it might be on the font.
  <dbaron> I think Chris said something about the advance in the
           test font
  ChrisL: Yes. I think Firefox is passing some tests but it's hard
          to tell because characters are on top of each other.
  Rossen: Did you try IE?
  ChrisL: I did not.
  fantasai: Maybe CC Sergey on the issue?
  Rossen: I have fonts people I can talk to. I'm looking for the
          email from you and I'm not seeing it yet. Once I find it
          I'll get someone to look.
  <dbaron> ChrisL, maybe cc: jfkthame about the font thing for
           Gecko... although my guess might be that the bug is the
           other way around... ?

  Rossen: In respect to the test, besides that blocker you said you
          added a number of tests. Do you need any help?
  ChrisL: I need a bit of help. Some things aren't testable using
          that method. In general it's going well.
  Rossen: In terms of IDing features to move to L4 have we made
  ChrisL: Not yet. It's hard to tell FF and Edge pass/fail.
  Rossen: So because of the blocker we can't make progress.
  ChrisL: Yes.
  Rossen: Thank you.

Cascade 3

  Rossen: Next is Cascade 3
  Rossen: We had scoped style edits for fantasai I think those are
  fantasai: I don't think so. I don't remember doing them.
  Rossen: Okay. So these are still pending.
  Rossen: From last time we had that you were going to drop scoped
  Rossen: gregwhitworth testing update?
  gregwhitworth: We weren't able to get any of our tests converted
                 except one, but we're looking at that internally.
                 We're hoping to get the others in this week. I
                 think another browser was doing testing too.
  Rossen: I think there was an ask for dbaron to find someone from
          Mozilla to convert those tests. Has that happened?
  dbaron: No.
  Rossen: Okay. Thanks

Conditional Rules

  Rossen: Conditional rules.
  Rossen: We had some edits to be done for CSSOM. Did we make those
          dbaron or zcorpan?
  dbaron: I didn't.
  Rossen: Okay.
  Rossen: I don't see zcorpan on. I'll reach out. If he can't help,
          would you need someone else to help?
  dbaron: I don't know. Depends on speed. I'm pretty unavailable
          before the F2F.
  Rossen: I'm just trying to draw a timeline for expectations. If
          you can't work and zcorpan isn't available maybe we can
          get someone else.
  fantasai: I suggest deferring to the F2F. dbaron and zcorpan can
            work it out there. They seemed like simple edits.

  fantasai: There have been some edits that should probably be
            published. If ChrisL or Bert can prepare a CR that would
            be good.
  Rossen: I recall last week we wanted the CSSOM edits before we
          republish. If we want another publish before the F2F I'm
          in favor of that. But I wouldn't want too much paperwork
          for Chris & Co in this month if there aren't that many
          edits. I'll give it to the editors for a preference.
  * fantasai can take care of publication requirements, if ChrisL
             can handle the webmaster side
  dbaron: I don't know what's in it.
  Rossen: fantasai do you know?
  fantasai: We made changes to how parenthesis are handled in
            @supports rules. They were resolved on a few years ago.
            If ChrisL will do publication I can do the paperwork on
            dbaron's behalf.
  ChrisL: Updated CR with technical edits. Is there a DoC?
  fantasai: I can draft one.
  Rossen: Objections to republishing CSS Conditional Rules CR update?

  RESOLVED: Republish CSS Conditional Rules CR update

  Rossen: There was a request for tests from Mozilla and Microsoft.
  gregwhitworth: We haven't gotten to that one yet.
  Rossen: Okay.
  Rossen: Did we get Mozilla tests?
  dbaron: I haven't looked yet. I don't know if someone else has a
  Rossen: tantek can you help?
  <tantek> Not for now, but I can look into it?
  Rossen: We'll continue to wait for more tests.

Values & Units

  Rossen: Values & Units.
  Rossen: Any updates on...there was a republication call. Are the
          edits ready?
  fantasai: They are. Waiting for people to look over <position>
            edits. If they're approved we're good to go.
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2017Mar/0054.html
  Rossen: Has anyone been able to look at the edits?
  Rossen: Let's give people one more week on this.
  Rossen: It would be good to hear from implementors and anyone else
          with interest since it's a core spec. Please look we'd
          like to republish.

Backgrounds & Borders

  Rossen: Backgrounds & Borders
  Rossen: We were going to get an implementation report, maybe some
          Mozilla tests. dbaron I'll take it you couldn't look into
          those tests.
  dbaron: Right. I haven't had a chance to look into any testing in
          the last week.
  * fantasai will need a resolution to republish css-backgrounds
             along with css-values

  astearns: tmichel sent the implementation report to the list. I
            haven't had a chance to look.
  tmichel: I don't have more than the email I sent.
  tmichel: I did a list of the tests that have 1 or 0
           implementations and also some links to what we call an
           implementation report that lists all the tests and
  tmichel: As I said we have about 80% fulfilling the requirements
  <tmichel> 82 % passing.
  Rossen: So 82.5% of the tests pass. We have about 17.5% with 0 or
          1 impl meaning we're not that ready. Thank you tmichel for
          preparing the reports.
  <Bert> (There were several dubious tests for backgrounds. What to
         do with those?)
  <fantasai> Bert, correct them :)

  Rossen: Next call to action would be a look from implementors to
          see what is not passing and start to evaluate the tests
          and impl so we can get closer to CR.
  <fantasai> Next action is file bugs and link them from the report
  Rossen: So again, thank you tmichel

  tmichel: I'd like to add...I have some email with Gerard and he
           pointed out about 20 tests that were wrong so I should be
           able to edit those today. They have improper images or
  tmichel: 20 broken tests. I should be fixing those and then I will
           run the implementations again on those. So there's 20
           more tests that may be passing.
  Rossen: That would be great news.
  tmichel: Sure.
  tmichel: I'll let you know when it's done.

  <fantasai> gsnedders, dbaron: do we have export set up from
             mozilla's repo to WPT's CSS repo?
  <dbaron> fantasai: for the stuff that we were previously exporting
           to csswg-test?
  <fantasai> dbaron, yeah
  <fantasai> dbaron, also in general...
  <dbaron> fantasai, I figure I'll continue doing it
  <gsnedders> dbaron, fantasai:
  <gsnedders> dbaron: probably should've :needsinfo'd you
  <fantasai> dbaron, wanted to know what's the best way to shift
             things from mozilla's internal to csswg
  <fantasai> dbaron, since understanding that process would make it
             possible to shift more Mozilla tests into WPT :)
  <gsnedders> fantasai: in a few weeks, cp from anywhere in the repo
              to testing/web-platform/tests will get them there
  <gsnedders> fantasai: I think there are some rules about making
              sure they're not MPL licensed before moving them there
  <dbaron> fantasai, did we drop the various metadata requirements?
           Otherwise the issue is still needing to add all the spec
           metadata that the tests don't currently have.
  <fantasai> dbaron, not all of them, no
  <fantasai> dbaron, they still need to be tied into a spec section

Transforms L1

  Rossen: Transforms L1
  Rossen: We were going to set up a conference call with SVG folks.
          Did we get around to this fantasai?
  fantasai: I'm going to do that. I'll have to check with Simon. But
            I wanted to prep the agenda first.


  Rossen: Flexbox
  Rossen: We had a few more edits holding us from republication. Did
          those edits make it over the week?
  Rossen: fantasai?
  fantasai: It was a couple of open issues, not just edits. We need
            to get those on the agenda.
  Rossen: Alright.

  Rossen: Did we make progress on tests?
  gregwhitworth: I did a brief review of the tests. There's quite a
                 few in there. I'll run those against the browsers,
                 figure out where they fail as a start to figure out
                 what needs to be looked into. Once I get a handle
                 on that I'll figure out where we need more
                 coverage. I couldn't find any report from previous.
  gregwhitworth: I don't know the earliest I could get it to you,
                 I'm busy for a few weeks.


  Rossen: Progress on variables?
  gregwhitworth: I submitted our test suite. It is against the css
                 wg repo currently.
  Rossen: Awesome. Thanks gregwhitworth.


  Rossen: Finally, CSS UI there was a call for astearns or fantasai
          to review tests
  Florian: There were 4 pull requests. fantasai reviewed 3,
           gsnedders did the 4th. gsnedders' and one of fantasai's
           are done. The edits requested for fantasai's other two
           are done and awaiting review.
  fantasai: Should be able to work on that today.
  Rossen: So the tests you have...the pull requests were approved?
  Florian: The 4 PRs were by me so I needed review.
  Rossen: Okay. Good, good.
  Rossen: I thought it was spec edits.
  Florian: Hopefully not. I'll report soon.

  Rossen: Circling back to writing modes, I know koji sent a report.
          koji are you on?
  Rossen: Implementation reports are 98% passing which meets the TR
          exit criteria. We'll transition soon. We'll loop back next
  Rossen: Thanks for the updates and awesome progress.

Publish request to updated WD of css-align-3

  Rossen: Did people get to look through the edits?
  fantasai: It's a bunch of bug fixes. There's no real change. it
            was clarified to say what was intended.
  Rossen: Objections to republishing?

  RESOLVED: Republish updated WD of css-align-3

  <fantasai> https://lists.w3.org/Archives/Member/w3c-css-wg/2017JanMar/0198.html
  fantasai: There's two open issues. One is the one discussed
            earlier about scrollable inline blocks. We should add
            that to next week's agenda. Other is syntax on fallback
            alignment. TabAtkins and I were thinking we should just
            drop fallback from this level so we can go to CR.
  Rossen: Thank you. Issues are highlighted in the private list as
          well. Please provide feedback

Blink Intent to Implement conic-gradient()/Images 4

  leaverou: We have not published a draft of CSS Images 4 for 5
            years. Now that Blink published an intent to implement
            conic gradients, we need to publish one as soon as
            possible, so that people are not referring to outdated
            syntax. On that subject, since I wrote the initial
            proposal for conic gradients 6 years ago, edited that
            part of the spec several times, wrote a polyfill, and
            promoted it to both authors and implementors, it makes
            sense to be added as a co-editor so I can continue
            pushing the specification forward.
  <tantek> leaverou++ yes please!!!
  <tantek> also +1 to adding leaverou as co-editor
  <dbaron> https://www.w3.org/TR/css4-images/
  fantasai: I'm in favor of all that. We don't have a FPWD for
            images 4
  ChrisL: We do. It's 2012.
  <leaverou> https://www.w3.org/TR/2012/WD-css4-images-20120911/
  leaverou: Here it is ^
  fantasai: Yeah. We should update that.
  <ChrisL> minuted resolutions?

  gsnedders: I presume we want to resolve to change the short name.
  <ChrisL> yes it should be css-images-4
  <fantasai> the shortname change is against previous resolutions
  <fantasai> don't need to re-resolve :)
  Florian: That too. I'm in favor of the coeditor
  TabAtkins: Me too.
  Rossen: Let's go one at a time. First one, add leaverou as
          co-editor for css images. Objections?

  RESOLVED: add leaverou as co-editor for css images

  Rossen: Thanks leaverou and welcome as a coeditor.
  Rossen: Next is a new WD publication for css-images 4. Objections?

  RESOLVED: new WD publication for css-images 4

  Rossen: Final, short name for the spec.
  Rossen: I heard TabAtkins.
  fantasai: We have resolutions to update the short names. We're
            fine there.
  Rossen: What was the new shortname?
  fantasai: css-images-4
  Florian: Another resolution is easier to find. Rather than hunt.
  Rossen: Yes, please update.

  RESOLVED: Update shortname to css-images-4

  Rossen: Anything else to discuss in regards to conic-gradient()?
  leaverou: There are a lot of outstanding issues, but we can
            discuss after WD.


  Rossen: Who wants to take those?

'column-span' and tables

  <Rossen> https://github.com/w3c/csswg-drafts/issues/1071
  fantasai: I think column-span & tables is an error in the spec. It
            should just say the element creates a new formatting
  Florian: I agree.
  Rossen: I couldn't agree more.
  Rossen: Objections to correcting wrong verbiage in the spec?
  Rossen: column-spans create a formatting context, not a specific
  Florian: Clarification, what we want is if it creates a formating
           context, good, if it doesn't it's a BFC
  fantasai: Its formatting context is determined by the display. We
            could do something in the future like block where you're
            sharing formatting context.
  Florian: We have a definition of establishes one that determines
           what you should establish?
  fantasai: I think so. If it's not clear in display we'll clarify.
  <fantasai> https://drafts.csswg.org/css-display/#formatting-context
  <fantasai> It's defined
  Rossen: For multicol it should be establishes.
  dbaron: It does need to link to something.
  Florian: If it exists good, if it doesn't I'll file an issues.
  Rossen: Objections?

  RESOLVED: column-spans create a formatting context, not a specific

  dbaron: Other question in that issue was around interop and tables.
  TabAtkins: I thought everyone agreed.
  dbaron: Nevermind. I'm crossing two issues.

Definition of `column-span` should say what happens without an
    ancestor multicol

  Rossen: Next was issue 1074
  <Rossen> https://github.com/w3c/csswg-drafts/issues/1074
  Rossen: Florian added this.

  Florian: We initially postponed because we wanted to work on other
           things, but there's no dependency. If you set column-span
           on something that's not a child of the multi-col what do
           you do? Nothing? Establish a formatting context? We have
           implementors doing both. What do we want?
  fantasai: I recommend always a formatting context. The author laid
            out the context with the assumption that it establishes
            a new formatting context, meaning it contains floats and
            margins--its children's margins don't collapse with the
            spanner itself. If the author is tweaking the layout and
            turns off multi-col there unexpected behavior on how the
            kids collapse in the spanner.
  <bradk> +1 fantasai
  fantasai: In order to minimize the difference between being a
            multicol and then not we may as well make it a
            formatting context. I'm not dead set, though.
  Florian: I believe we have the logic that if it is in a one column
           multi-col it does a formatting context so extending makes
           sense to me.
  Florian: Anyone feels the other way?
  <bradk> What fantasai said is right for when you have media
          queries too.

  jensimmons: I'm thinking about how this will feel consistent or
              not with Grid.
  jensimmons: Will it be weird the children will behave as if the
              formatting context exists where if you remove
              display:grid the children don't act separate.
  Rossen: I recall this issue...we discussed with howcome 5 years
          ago. I believe he pushed for not a formatting context.
          Those are probably some of the last changes he made so
          they should be easy to trace. Doesn't mean we can't change.
  Florian: We had a similar discussion. We did not discuss if you're
           not in multicol, we discussed the narrow one column
  Florian: We resolved in that case you get a formatting context.
           It's not clear if it's meant to apply when there's no
  Rossen: With those options, what do people think?

  Florian: I agree with fantasai and no one is speaking against.
  <Bert> (Sounds strange to me that 'column-span' has any effect
         outside columns.)
  Rossen: There was jensimmons's question.
  Florian: Yeah. Absolutely.
  <Florian> sorry Jen, didn't mean to dismiss your comment
  <dbaron> fwiw, my intuition was that it should work the other way,
  Rossen: In that case...do we have...dbaron your intuition is for
          the other way. Can you expand?
  dbaron: It was that it seemed weird for column-span do something
          when you're not in a multicol. It is different then a one
          column multicol.
  jensimmons: I agree. It feels weird it would do something when not
              in a multicol. If there's a one column multicol you're
              still in a multicol.
  Rossen: Yeah. it would feel weird if I added a grid property to
          the table and it behaves different.
  jensimmons: Right.

  fantasai: I think what makes it different from grid as far as its
            contents are concerned it like a special kind of block
            container. So it's still a block container, just not a
            multicol block container.
  Florian: If you change your mind and stop using grid you have to
           change the design of the grid items. If you change your
           mind and stop using multicol you don't have to change the
           contents so you might forget you have something. I could
           be convinced either way.
  jensimmons: I think of this as a matter of how the browsers use
              this then I have no opinion. But if there's anything
              like margin collapsing that would change then it
              doesn't impact authors and we should do things the way
              that works for browsers.
  Florian: It does make a difference for margin collapsing and float
           intrusion. fantasai meant that multicol layout isn't very
           different than block layout except that there's a
           boundary. Almost everything is the same as normal block
           layout. You might not change everything and be left with
           just spanners. For grid or tables you'd have to rework
  * bradk thinks that Column-span will become a hack for getting
          bfc. Not necessarily a bad thing.
  <fantasai> bradk, we have 'display: flow-root' for that!
  <fantasai> bradk, you can request a BFC explicitly :)

  Rossen: Let me try to move this forward. If we have an element to
          which we apply column-span:all and there's a 2 column
          multicol. The element will be taken out of the flow, made
          BFC, and everything around it would behave like a BFC
          would such as margin collapsing. Then the container of the
          multicol is resized so it becomes a single column- nothing
          else has changed.
  Rossen: Because of the column definition it became a single
          column. This column-span:all is still spanning all
          columns. Questions is if this is a BFC. correct?
  Florian: No, that one is so far a BFC. If you now remove that this
           is a multicol at all, should we still have a BFC?
  Rossen: Right, right. This is how it works when the parent is a
          multicolumn. The last change is we remove the root. In
          which case what happens?
  Rossen: First my intuition as an implementor if this element that
          used to be multicol no longer has a reason to be a BFC
          there will be a layout change. The fact that there's
          something inside of it that changes its BFC-ness shouldn't
          be any different. Do we have a reason to believe it should
          be treated differently?
  <dbaron> The other content-editing risk is that if people start
           using 'column-span: all' to force a BFC, they might get
           unexpected results if they then take their content and
           put it inside a multicol...
  <gsnedders> don't we have a proposal to add a property that
              literally just creates a BFC?
  <Rossen> gsnedders, yes :)
  <gsnedders> IMO that's something we should try to get to REC ASAP
              given it'll stop authors doing weird hacks

  Rossen: I'm making a case for it to not be a BFC anymore.
  jensimmons: I lean that way too. If we don't do it that way...we
              would create column-span into a brand new property
              that works by itself. You remove the multi-col and you
              think you're done, but you're not because there's a
  Florian: I think that's the critical question. If you're writing
           from scratch it makes no sense. But if you're in the
           scenario should you have to go through all your
           stylesheets and remove everything? If you remove the
           multicol do you have to go back into all your style
           sheets. If you want to remove all column-ness you may
           want to remove them from everywhere if they still have
           effect without multicol. The scenario where you had
           multicol and edited it away.
  jensimmons: And that's the case fantasai is making that you had
              the layout working and you remove the multicol it
              would be good to have it still work. But I think it
              makes sense to work more like grid.
  <rachelandrew> agree with jensimmons, I'm not keen on it creating
                 a BFC if multi-col is gone
  fantasai: But this is the only part that behaves differently.
            Currently all your children and descendants don't care
            that they're in a multicol in terms of layout.
            column-span does change how a child or
            descendant...that's the only property with an effect.
            For grid or layout everything changes from block to grid
            container. You will notice if something is off. This is
            fairly subtle and it's rarely used feature. The other
            children have no special behavior
  <Bert> (Keeping the BFC only makes (a little) sense if you had
         *one* column before you removed the 'columns' property.
         With more columns, ignoring the column-span is probably
         exactly what you want...)
  Florian: I have a slightly different argument. If instead of
           thinking in terms of editing the multicol, we think of MQ
           putting it in and out.
  Rossen: That's the same thing.
  Florian: Technically, but authorwise the thinking is different.
  * fantasai thinks there will be more errors in pages if we don't
             create a BFC
  Rossen: I think we need to discuss this. As an implementor I'm
          leaning toward jensimmons.

  Rossen: We're at the top of the hour. I would encourage people to
          continue discussing in issue 1074.
  Rossen: Thanks for joining us and we'll talk to you next week.

  jensimmons: Congrats to everyone for getting grid out in the last
  <ChrisL> cheers
  <bdc> +1000 jen, huge win for the web!

Received on Thursday, 30 March 2017 01:44:03 UTC