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

[CSSWG] Minutes Telecon 2017-07-12 [css2.2] [css-align]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 12 Jul 2017 20:34:36 -0400
Message-ID: <CADhPm3voJYrtfDzqQEhGZXmPHv2P+gD4TTCaEPDxt+sn=B62SA@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.
=========================================


TTML request for review
-----------------------

  - Anyone with interest was asked to respond to the request for
      review: https://lists.w3.org/Archives/Public/www-style/2017Jul/0005.html

Spec Rec next steps
-------------------

  - fantasai will reply to Chris shortly in order to resolve if
      Writing Modes needs one more CR cycle.
  - gregwhitworth began reviewing all the Flexbox tests to establish
      coverage.

CSS2 publication issues
-----------------------

  - Though the group recorded several resolutions in February to
      change the CSS2 publication process (recorded here:
      https://lists.w3.org/Archives/Public/www-style/2017Feb/0058.html)
      the new process still hadn't been fully implemented.
      - This has lead to there being greater confusion as to what is
          the most up to date and possibly new work occurring in
          more than one place.
  - There was some concern that this new process was either not the
      best way forward or not well understood, so there will be a
      conversation at the Paris F2F to revisit the original decision.
  - In order to reduce confusion as to what is currently out there,
      Bert will look through css-testing and make sure that any
      changes there are merged into css22 before deleting
      css-testing as well as css-source (which is currently empty).

Compatible alignments aren't always compatible
----------------------------------------------

  - There were three items listed in github for the group to choose
      from:
      1) Exclude items with align-self: stretch and a specified
         height constraint (min-height/height/max-height) from
         align-content: last baseline alignment.
      2) Exclude items with align-self: stretch whose specified
         height constraint gets triggered such that it no longer
         sizes as stretch.
      3) Treat items with align-self: stretch and align-content:
         last baseline as having an end fallback alignment instead
         of a start fallback alignment.
  - RESOLVED: Option 3 from issue.

===== FULL MINUTES BELOW ======

Agenda: https://lists.w3.org/Archives/Public/www-style/2017Jul/0004.html

Present:
  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Tantek Çelik
  Alex Critchfield
  Elika Etemad
  Tony Graham
  Dael Jackson
  Brian Kardell
  Ian Kilpatrick
  Tomoya Kimura
  Peter Linss
  Myles Maxfield
  Anton Prowse
  Melanie Richards
  Florian Rivoal
  Geoffrey Sneddon
  Alan Stearns
  Greg Whitworth

Regrets:
  Rachel Andrew
  Dave Cramer
  Daniel Glazman
  Chris Lilley
  Rachel Nabors
  Jin Simmons
  Lea Verou

Scribe: dael

TTML request for review
-----------------------

  Rossen: Let's get going. Are there any extra items people want to
          bring forward?
  Rossen: Or change anything in the current agenda?
  Rossen: Only extra I want to add is a heads up that ttml WG is
          requesting wide review for their WD.
  <Rossen> https://lists.w3.org/Archives/Public/www-style/2017Jul/0005.html
  Rossen: If anyone has a chance they're depending on you.
  Rossen: I skimmed the list, there looks to be ruby, inline block,
          etc.

  Florian: I seem to recall dbaron giving feedback on something like
           this. Was it a previous call for comment?
  Rossen: Might have been. This call was just today. To be honest, I
          don't know. Maybe it was a previous.
  Rossen: Since he gave feedback before I'm hoping he'll take a look
          and either reaffirm what's supposed to happen happened or
          commenting from his PoV

Spec Rec next steps
-------------------

  Rossen: Writing modes.
  <Rossen> https://lists.w3.org/Archives/Public/www-style/2017Jul/0003.html
  Rossen: fantasai I don't know if you saw Chris's request.
  fantasai: I was going to do that yesterday and forgot.
  Rossen: His question was legit. He thinks everything was editorial.
  fantasai: There was a minor change - viewport change to scrollport
            - and I think I forgot to add that to changes.
  Rossen: And you think this merits another CR recycle?
  fantasai: It might require it. It's a substantive change, but it's
            to the way the implementors implemented.
  Rossen: Once you look can you respond to him? If we have to
          restart let's do it as soon as we can.
  fantasai: Yep.

  Rossen: Flexbox.
  Rossen: I know gregwhitworth was going over test coverage and we
          were ready with...where are we with flexbox?
  <fantasai> https://drafts.csswg.org/css-flexbox/issues-cr-20160526
  gregwhitworth: I opened a few PRs for the changes I found. I need
                 to check is Christian investigated something that
                 wasn't interop on Linux. Based on fantasai rec I've
                 gone through every text to look for gaps.

  gregwhitworth: I believe dbaron was going to provide some tests. I
                 believe.
  Rossen: I think there are a few specs waiting for Mozilla tests.
          Flexbox, B&B, Conditional, I think.
  fantasai: It might be useful if someone from Mozilla can drop
            links and then someone else can do the rest.
  Rossen: Definitely. I'm not expecting dbaron to port the tests, I
          was relying on him as the Mozilla liason to delegate. He's
          just our main contact.
  gregwhitworth: Is there a reason we're preferring Mozilla tests
                 over others?
  Rossen: We're preferring them over having nothing.
  fantasai: What I've noticed is when different vendors do tests
            they cover different things. If we want a good test
            suite we should bring as many tests together. Mozilla
            tests are in ref test format so we need to just tag
            them. But I don't know what the process is to submit it
            through. It should be fairly easily.
  Rossen: Moving along, thank you gregwhitworth for moving those
          forward.
  <fantasai> dbaron or dholbert, can you drop us some DXR links to
             the Flexbox tests that haven't been submitted yet?
  <dholbert> fantasai: Mozilla's flexbox tests almost all live in
             https://dxr.mozilla.org/mozilla-central/source/layout/reftests/w3c-css/submitted/flexbox/
             (with the exception of a few that test mozilla-specific
             quirks/interactions), but I think those are all
             submitted... not sure which ones "that haven't been
             submitted yet" you're referring to
  <fantasai> dholbert: Wasn't sure if there were any, if they're all
             submitted then that's great!
  <dholbert> fantasai: (looking in more detail) we have other tests
             that rely on Mozilla-specific reftest extensions, like
             MozReftestInvalidate, and perhaps depend on exact font
             metrics (IIRC) and hence aren't suitable for
             submission. Those ones live at
https://dxr.mozilla.org/mozilla-central/source/layout/reftests/flexbox/

  Rossen: fantasai did you get to catch up on any of the other
          specs? V&U UI?
  fantasai: I only did display and align lately.
  * fantasai has a DoC for Display now
  Rossen: As part of this I wanted to go over CSS 2
  Florian: Before that one, where are we with CSS Contain? There was
           an issue on something linked from CSS contain and we were
           waiting on Chris to get feedback from Ralph.
  Rossen: Chris is on an airplane over a bunch of water. I haven't
          seen anything on private or public list. Feel free to
          refresh the mail thread if there is one.

CSS2 publications issues
------------------------

  <Rossen> https://lists.w3.org/Archives/Member/w3c-css-wg/2017JulSep/0013.html
           (member only list)
  Message text from fantasai:
  [
    I had a long conversation with plh about our proposed process
       for updating CSS2.1, and he's on board. However, we've got a
       bit of a mess on our hands.

    What we need:
       Two copies of CSS2 in the CSSWG repo:
         * one to represent CSS2-REC with PR-ready errata folded in
         * one to represent CSS2-updates with all errata folded in
       Two copies of CSS2 on /TR, one to represent each of these.

    What we have;
       Four copies of CSS2 in the CSSWG repo
       Two copies of CSS2 on /TR, unclear which represents what.

    Actions that need to happen:
       * Reduce the copies in the CSSWG repo as described above.
       * Set up css2-testing and redirects per
https://lists.w3.org/Archives/Public/www-style/2017Feb/0058.html
       * We also have an outstanding resolution to have a note at
           the top of each section and subsection of CSS2.1 that has
           been obsoleted by a later CSS module, pointing to the
           relevant section(s) in that module. There is just a
           generic notice atm, which is better than nothing, but
           this action needs to be handled 100% and CSS2-REC
           republished.
https://lists.w3.org/Archives/Public/www-style/2015Mar/0317.html
  ]

  Rossen: There was some back and forth between gsnedders and
          fantasai added it as an agenda item.
  fantasai: I wanted to look at the status of css2 to make some
            progress. We had a plan in Seattle with plh and that's a
            summary of the plan. There was blockage to get things
            published and I explained what we wanted to try to plh
            in person. We're going to experiment with this process
            as we discussed.
  fantasai: What we don't have is the impl of the plan. The question
            is who will do the things that need to be done. We need
            to have 2 copies of CSS 2, one reflecting short term
            what will be published and one where we will put all of
            the changes we've agreed to and resolved on
  fantasai: There seems to be 4 copies and that needs to go down to
            2. I don't know which is which or what the state is.
            Also, both of these need to be on TR. We need /tr/
            css2-testing set up
  <gsnedders> there's only three
  fantasai: We also have a resolution of a note on each section that
            has been obsoleted that points to the newer spec and
            that's on both copies.
  fantasai: None of this has been done so they need to be assigned
            to somebody.
  gsnedders: I sent a long email end of May having spoken to plh at
             start of May and much of that was for Bert who had just
             gone on vacation. We seem to have a complete mess where
             some of the copies...the one meant to be ready to go to
             PR has changes not in the experimental. I don't know
             where we need to start.
  <gsnedders> https://lists.w3.org/Archives/Public/www-style/2017May/0042.html
              is the email I sent

  Rossen: Bert can you shed some light?
  Bert: The mess started in Seattle. There were 3 before that, one
        which was empty- css2-source. We can delete that. Before Jan
        we had 2 directories, one with 2.1 and one css2 which is the
        next version. The later is the most up to date, it has all
        the errata.
  Bert: css2-testing was created after Seattle, but I'm not sure
        what to do with it because who will decide what's in it and
        when to publish? So I've been concentrating on css2 up to
        date. It has all the errata.
  Bert: Do we want to publish this note? I'm not sure what the
        process is and how to keep people from getting confused. I'd
        rather undo the note thing and publish css2.2. I think we
        still have all the tests.
  fantasai: My concern for CR of 2.2 is that in order to update the
            rec we need changes batched so all things have a test
            and implementation. Going through the updating rec
            process seems what we should do instead of making more
            and more css2 steps. It should be possible to maintain a
            rec.
  fantasai: At the least we should be able to update the rec with
            changes that satisfy PR exit. But we have many changes
            that won't pass and if we include them we'll never get
            to publish another rec of css2.
  fantasai: Seattle decision had us maintain css2 so css2.1 cycles
            through editing process and gets updated. So people can
            review and work on impl and understand errata that have
            not gotten PR we want to have a public copy with all
            errata, tested and not.
  fantasai: While the ED repo is public it's better to have an
            official draft on TR which is why we would have the
            note. That should auto-sync from the ED when there's a
            change.
  fantasai: If we resolve on a change it should go to TR. That way
            we'll have a copy with all the changes and a copy
            working through rec maintenance.

  Florian: To clarify, the thing that was css2.2 up till now keeps
           the same content and becomes a note so there's a ED
           version and a TR note version and then we cherry pick
           items to update the css2.1.
  fantasai: Yeah.
  Florian: So there's no third testing thing in addition to 2.2 and
           2.1?
  fantasai: Yeah. We bikeshedded 2.2 to 2-testing, but it's more or
            less the same thing. Updating process is different. It's
            things we agreed on that don't have tests.
  <gsnedders> Where did we resolve on the name?
  <gsnedders> (of CSS2-testing)

  Rossen: Going forward, we have 2 weeks before Paris. What can we
          have actionable before then? What I see is we have
          css2-source, let's leave that. css21 is no need to touch.
          css2-testing for the note needs to happen so that's
          actionable and there is the current version, css22, where
          Bert has made changes.
  Rossen: What of this can be actionable before Paris? We had a long
          discussion in Seattle and we'll have a long discussion on
          this in Paris and I want to avoid taking the all call, so
          what of this is actionable?
  <Florian> 1) delete -source
  <Florian> 2) delete -testing
  <Florian> 3) rename 2.2 into -testing
  <Florian> 4) update TR accordingly
  fantasai: We have resolutions on all of this. I linked to those.
            We need to have some sense of what's going on in the
            repo. If there's anything out of date we should delete.
            The current css2 has all changes which means that is the
            source for css2-testing as it has all changes. Then we
            need a copy of the spec with only changes ready for rec.
  fantasai: Those two copies need to be in the ED repo. Once we have
            that we need to take the action on linking from each
            section and subsection to the relevant spec if it
            exists. We agreed that the next thing after clicking on
            a link is a note if it was deprecated.
  fantasai: And then publishing to TR. That's all actionable.
  gsnedders: We don't have one copy of css2-testing because there
             are changes only in css2 draft and some in css2-testing.
  fantasai: So we need someone to sync everything.
  fantasai: There will be 2 drafts, one with a subset of the changes.

  Rossen: Let's start with this. Can we action someone to pull back
          together everything in 2 versions? gsnedders or bert?
  Bert: If I understand fantasai wants css2-testing to be the most
        complete and css2...I don't know what that would contain
  Florian: CSS2 and 2-testing should be the same.
  Bert: How will we publish the next revision?
  Florian: The 2.1 draft.
  Bert: That's the first revision. We're going to publish the 2nd?
  Bert: I propose we just delete 2.1.
  Florian: We'll need something identical to 2.1+cherry picked
           changes. I think that's easier to start with 2.1 and add
           instead of start with everything and remove.
  Florian: There should be css2 which becomes css2-testing which is
           everything. Then we cherry pick things into 2.1 which we
           republish.
  Bert: How?
  Florian: We resolve on here's a thing with tests and impl.
  Bert: We have tests for 2.2, not for css2-testing. That's only a
        note so we don't have tests.
  Florian: I think separating that you don't like the process, the
           actionable thing is to not delete 2.1 and to make sure
           that between css2 and css2-testing, regardless of names,
           there's only one draft left. Once we have that we have
           the basis for either what we did before or the new
           process.
  Rossen: New process being one spec and one for changeS?
  Florian: Yes.
  <tantek> Rossen: do you understand what Bert is saying / proposing
           vs. what Florian is saying / proposing vs what fantasai
           is saying / proposing?
  * tantek is now having serious flashbacks from Seattle
  <Rossen> tantek, torlling is not the same as fixing the process
  <tantek> Rossen: as long as no one is writing down their proposal,
           we'll keep repeating history
  <fantasai> tantek, we already resolved on everything.
  <fantasai> it's not being implemented.
  <tantek> fantasai: that's what I thought in Seattle
  <fantasai> We changed the process in Seattle, and resolved on it
             in February
  <tantek> fantasai: that's what I remember too, hence why I'm
           confused about the confusion
  <fantasai> tantek, resolutions are in
https://lists.w3.org/Archives/Member/w3c-css-wg/2017JulSep/0013.html
  <tantek> however I can't find a link to an explicit step by step
           process for CSS2.2 that we agreed on
  <tantek> fantasai: that helps, however we still don't have a list
           of steps for continued iteration

  <gsnedders> Rossen: do you want me to write down a list of actions
              from
https://lists.w3.org/Archives/Public/www-style/2017May/0042.html?
  <dbaron> Somebody should gather the list of resolutions into a
           document.
  <gsnedders> dbaron: yes

  <fantasai> tantek, diagram :
https://lists.w3.org/Archives/Public/www-archive/2017Jul/att-0000/css21-update-process.jpg
  <tantek> fantasai++ that's a good start

  Rossen: I think we resolved on this in the past. What I want to do
          is see if we can action Bert or gsnedders to have some
          things actionable going forward before Paris. This seems
          to be repeating conversations we've already had. Let's not
          repeat again and again. If we believe we resolved in the
          past something that we should change let's talk about that.
  Rossen: It seems the actionable part is for the resolutions in the
          past we need to consolidate down to 2 working versions of
          the spec, one that stable & public and the other that is
          the editorial version.
  gsnedders: I haven't done anything on this because I don't feel I
             know the current state of the directories.
  fantasai: Let's do this. Out of all of the copies of css2.1,
            somebody, preferably Bert, gets one copy of css2.1
            called whatever and all of the agreed changes are into
            that, whither we have tests or not. We need to
            defragment this.
  fantasai: And then pull down a copy of css2.1 source as of the
            date it was published on TR as a REC and put that in the
            repo. Then we can take the changes tested and impl and
            copy them into the REC source.
  <Florian> +1 to fantasai
  <dbaron> I think one issue with that plan fantasai stated is that
           the cherry-picking requires a decent list of the changes
           and their associated tests.
  <fantasai> dbaron, Bert maintains an errata document
  <fantasai> dbaron, the process for making a change to CSS2.1 so
             far has been to edit it into the ED, write it up in the
             errata document, and write it up in the Changes list
  <fantasai> dbaron, so all we need to do is add annotations to the
             errata document linking to the relevant tests
  Rossen: It seems like we have currently the css22 which has all of
          Bert's work. There's css2-testing that doesn't have
          anything in it.
  Florian: gsnedders said there was stuff different.
  gsnedders: There are.
  Rossen: Those things can be put into css22 which is the current
          version. We retire css-testing for now. css2-source is
          empty. After this we have css21 which is current TR and
          css22 which has everything bert has worked on plus the
          note. Does that sound like the action we want to give Bert
          if he's willing to take it?
  Bert: Let me see. Delete empty directory, deleting css2-testing
        okay. css2 will become the note, that's easy, I need to just
        change the title. css21 has old sources.
  Florian: css2-testing can only be deleted if everything in it is
           in css22. We need to verify that.
  Rossen: Let's sort that out on the side. That will be part of
          deleting.
  Bert: I can do a comparison.
  <gsnedders> Bert: I think it's missing
3ab2236828f6dc90a7a949aefad2e2ad24bbd1e4 and
a2181b24fd27c22b456fad91261405905d1ab0a3
  <fantasai> gsnedders, git or hg? :)
  <gsnedders> Bert: css2 is missing those commits from css2-testing
  <gsnedders> fantasai: git
  <gsnedders> maybe a3be294641351a82c20c27888eca6f46f40adfac too

  Rossen: How about this, the action is delete any empty directories
          as well as css2-testing after verifying that it would
          merge cleanly with css22.
  Bert: I'm afraid of a large bit of work as css21 directory has old
        sources.
  Rossen: We're not doing anything with 21. Just consolidate
          everything into css22. Then we'll figure out next steps.
  Rossen: Action is only for css22.
  Rossen: css21 doesn't need to change right now.
  Bert: Okay. I see problems in the future, but we'll deal with that
        later.

  Rossen: Is there anything else on this topic or should we move on?
  gsnedders: There's other things. We need...let's not do this now.
             I'll send a list of actions based off of my May email
             and we can discuss on the list.
  Florian: Shouldn't those happen after what we discussed doing?
  Rossen: I was asking if there's anything that needs to happen
          before Paris. I don't want to continue this discussion on
          the call. Before we consolidate we won't have traction.
  gsnedders: Css-testing isn't on drafts.csswg.org as it's not known
             by the system.
  Florian: We'll delete it so that's fine.

Compatible alignments aren't always compatible
----------------------------------------------
  github topic: https://github.com/w3c/csswg-drafts/issues/1556

  fantasai: There's an issue where we preform baseline content
            alignment on two items if their align-self allows them
            to both baseline align.
  fantasai: However for last-baseline we'd need both aligned to the
            bottom.
  fantasai: Otherwise if the boxes aren't the same size they're in
            different positions. If they're start to stretch fine.
            Does that make sense?
  * dbaron didn't follow
  TabAtkins: The important bit is for last-baseline they need to be
             end or stretch aligned to be compat.
  fantasai: There's two types of baseline alignment. You shrink wrap
            the box around content and move the box, that's self. Or
            the box can fill the area and you align the content in
            the box.
  fantasai: There's two different properties so we can do both on a
            flex item. If you want content baseline alignment you
            need for that box to be stretch to fill the whole row.
            Or you can do it if they're both start aligned so they
            grow downwards.
  fantasai: That's fine for first-baseline alignment, the box
            doesn't have to fill the whole row. For last-baseline if
            it's shorter than the entire row we have a problem. We
            need to evaluate what to do. Our spec says if you're
            bottom or stretch aligned you can do last-baseline.
            That's fine but if you have a width or max-width you're
            not necessarily stretched and you're aligned to the top.
  fantasai: There's 3 ways to deal with this which are in the issue.
            1 is exclude items with stretch and a height
            constraining. Another is that if you have align-self:
            stretch and align last-baseline you get bottom aligned
            instead of top aligned.
  fantasai: 3rd is exclude items that are stretched only if the
            constraint is triggered.
  <fantasai> https://github.com/w3c/csswg-drafts/issues/1556#issuecomment-311463877
  fantasai: These are all in the issue^
  fantasai: We need to pick one.
  <dbaron> I don't see why the growing thing requires start
  <dbaron> I also don't see how last-baseline is different for the
           growing thing

  Rossen: Going through our grid updates and doing this for grid
          items I'm pretty sure we did similar to #1 where
          constriction takes precedence over stretching. That makes
          sense and is mostly consistent except able cells.
  Rossen: Third seems more hacky where we're trying to make the
          fallback work. Does that mean constraints are ignored and,
          if yes, that's weird.
  dbaron: I didn't understand a bunch of the premises.
  dbaron: I don't understand why you can't combine start alignment
          with last-baseline align content by aligning a different
          amount. Basically first or last with an alignment that
          says stick to one side says you have to move and align the
          content. I don't see why that's different between first
          and last
  TabAtkins: Let's say you have a whole bunch of vertical space. One
             is start and one is center. They're small and there's a
             ton of space so they don't overlap vertically. How do
             you content align that? You can't without breaking self
             align.
  dbaron: I agree center is more interesting. but doing baseline
          alignment generally requires you grow boxes. In the case
          where they don't overlap you grow them by a lot.
  TabAtkins: That would be so weird. I don't think there's an
             obviously correct way to choose which to grow. I doubt
             anyone would expect that to happen.
  dbaron: You can...okay.
  TabAtkins: Elements have to grow, but this would require to grow
             an unbounded amount and it's not clear which should
             grow. If they share an edge they have a fairly obvious
             where they grow and how much.

  Rossen: In any of that, why would you decide to override the min/
          max constraint?
  TabAtkins: We're not. If a max is there it can make stretch not
             compat with end alignment. That's why one suggestion
             was stretch falls back to end.
  dbaron: What does fallback align mean?
  TabAtkins: If you can't fully align based on self you fallback to
             something that can be adhered to. If you can't grow
             enough in the left over space, we fallback to start by
             default.
  Rossen: Your third option you said it's end or start?
  TabAtkins: Yeah. In this case if you're trying to last-baseline
             align a stretch item we would do an end fallback.
  Rossen: Why? Why not start?
  TabAtkins: It means you can't align because if your alignments
             aren't compat there's no obvious way to make it work.

  Rossen: You have an item that's too small and cannot grow and you
          have to decide it goes to top or bottom. You're deciding
          if it's last-baseline it goes toward the bottom. Why?
  TabAtkins: So it's compat and last is possible. If it goes to
             start you cannot do last-baseline alignment in a
             reasonable manner.
  <Bert> (Seems to me that, even if you align to the bottom, there
         is still a chance that is needs to grow more than
         max-height to align the last-baseline...)
  <dbaron> OK, I think I'm ok with your suggested option #3 now.
  Rossen: I need to look at test cases.
  TabAtkins: This one is simple. Last line of text in a box. One is
             last aligned, the other tries to stretch but can't get
             far enough. It's impossible for the box to grow so that
             the last line can get down and align b/c the height
             constraint. Only want to make so is that the end edges
             align. If they're not sharing same vertical space you
             can't reliably do a baseline alignment.

  Rossen: Proposal is option #3?
  TabAtkins: We prefer option 3 because it means more things can
             baseline align. It's changing a currently undefinable
             default. Other 2 would also work, but they break the
             baseline alignment and we feel in this case it's better
             to try and honor.
  Rossen: All three are acceptable solution.
  <fantasai> +1 to everything Tab said
  Rossen: Opinions?
  <dbaron> I guess #3 probably seems better than #1 and #2, although
           there is the random complexity...

  Bert: Is it actually a solution? It seems there are two cases
        where you get conflicts. Say you have two items you want to
        align to last-baseline, first is very small with small
        height, second is very tall.
  TabAtkins: That's a natural break of baseline and is handled.
             First small one overflows upwards. Since it can't,
             it'll break the alignment and sit still.
  Bert: So you say the three solutions aren't 100%, they just
        improve the solution.
  TabAtkins: Yes. The one you brought up is unsolvable, but what
             we're trying to do is solve one where an undefinable
             default is causing the break. We want to make the
             default a little smarter.
  Bert: I'm okay with option #3.

  Rossen: Other opinions?
  Rossen: dbaron preference?
  Rossen: Oh, I see in IRC #3
  Rossen: Let's call to resolve on option #3?
  Rossen: Objections?
  * tantek is also ok with #3
  gregwhitworth: Would anybody see authors expecting for the stretch
                 to still be adhered to where it goes upwards? Like
                 it does #3 but still stretches.
  TabAtkins: This is when max-height is in play and we honor that
             over other constraints.
  gregwhitworth: I was just curious if an author wants the inverse.
  Rossen: Authors want rainbows and unicorns but we can't deliver
          them so we need to honor the constraints and have an okay
          default.
  Rossen: I don't hear objections.

  RESOLVED: Option 3 from issue

  Rossen: Please add topics for Paris. I see we're done for today.
          Thank you and we'll talk next week.
Received on Thursday, 13 July 2017 00:35:38 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 13 July 2017 00:35:39 UTC