Re: [CSSWG] Minutes Berlin F2F Tue 2018-04-10 Part IV: CSS Grid and Box Alignment [css-grid-1][css-grid-2][css-align][css-sizing] / single-spaced

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


Grid L2
-------

   - Author expectations and use cases were toward having the per-axis subgrid
     (Issue #2280) however several people needed more time to review the spec
     text so the group will revisit this issue later in the F2F.
   - RESOLVED: Add an ar unit to the grid 2 spec for align-content and
               justify-content. (Issue #1116)

Grid L1
-------

   - The group believed that the Grid algorithm could still be adjusted to
       accomplish the use case in issue #2356; however the correct adjustments
       weren't immediately clear. TabAtkins and fantasai will look into a
       post-processing step that was suggested and Florian will reach out to
       Bert to see if he has any insights.
       https://github.com/w3c/csswg-drafts/issues/2356#issuecomment-379878492
   - RESOLVED: Edit in Rossen proposal in issue #2177 "Spanners that cross tracks
               that have content-based mins AND flexible maxes only contribute
               content sizes to those tracks; otherwise they participate normally."
               https://github.com/w3c/csswg-drafts/issues/2177
   - RESOLVED: Alignment and gaps in multicol behave exactly like grid and we
               will add a note explaining the concerns in the issue and how to
               solve them. (Issue #1420)
   - RESOLVED: Remove these terms (row-axis and column-axis) from the grid spec
               (Issue #1299)

Alignment
---------

   - RESOLVED: Zero out percentages on non-sizing use of calc. (Issue #2297)
   - RESOLVED: Fallback alignment for last-baseline is 'safe end' (Issue #1611)
   - RESOLVED: Publish a new WD of Alignment with the one edit from the baseline
               resolution.

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

Agenda: https://wiki.csswg.org/planning/berlin-2018#schedule

Scribe: dael

Grid Layout Level 2
===================

   Spec: https://www.w3.org/TR/css-grid-2/

Dual-axis vs. Per-axis Subgrids
-------------------------------
   github: https://github.com/w3c/csswg-drafts/issues/2280

   fantasai: Issue with grid L2: it has some proposals and no feedback.
             I can't do anything to go forward.
   fantasai: Open issue says, here's 2 proposals for subgrid, which do we want?
   fantasai: I wanted to bring this up because there's strong requests from the
             community to do this, but the spec for subgrid is, well, there's
             2 specs for subgrid. I don't know what to do next.
   florian: Is there author feedback?
   rachelandrew: I have feedback. Authors really want subgrid. The use cases
                 I've seen are tied to single-dimension subgrid...
                 the proposal that was pulled from L1 wouldn't solve them.
   rachelandrew: People want the columns to be subgridded. They don't want to
                 define the rows. Having it locked to both dimensions would be
                 more frustrating then useful. Things I've seen assumed one
                 dimension.

   fantasai: Proposal is then to resolve on per axis subgrids.
   Rossen: Didn't we decide in Tokyo?
   tantek: We added it as a possibility in Tokyo.
   Rossen: Sounds good to me. I thought we did that.
   Rossen: This is the 1.5 dimension model?
   fantasai: No, the way we set things up there's not many changes from one
             version to the other. Differences are in green.
             https://www.w3.org/TR/2018/WD-css-grid-2-20180206/#subgrids
   fantasai: Main change is for per axis you need to ensure that if you're
             interweaving the algorithm of the parent and child grids.
   fantasai: Algorithm is all defined. That's where spec is at. I think
             it's complete, mostly.

   astearns: Do we have impl?
   fantasai: I don't think anyone is working on subgrids.
   TabAtkins: Mats was interested and opposed the non-per axis. That's what
              Igalia partly implemented.
   rego: We didn't impl anything yet.
   <tantek> Mats is working on it, see the Firefox subgrid meta bug
            (with dependent implementation bugs)
            https://bugzilla.mozilla.org/show_bug.cgi?id=1240834

   fantasai: Syntactic difference is the per-axis version has a subgrid keyword
             on grid-template-rows and grid-template-columns.
             Dual-axis was a keyword on display.
   astearns: Would anyone object to single axis subgrid?
   TabAtkins: No one has described how to do it yet.
   fantasai: It's in the spec. Here's the algorithm (section 2.4:
             https://www.w3.org/TR/2018/WD-css-grid-2-20180206/#subgrid-sizing )
   astearns: It's specified as a diff to a doc with both.
   fantasai: It inlines everything in. It just has two colors of ink.

   astearns: Anyone besides TabAtkins have concerns on single axis subgrid?
   rego: Seems more complex to impl but it would be good to know use cases.
         If there are clear use cases where we need this it's fine.
   rachelandrew: I brought use cases to the last F2F but I rarely see something
                 from an author that works for double axis. An e-commerce site
                 that has a template where they want it to work no matter if
                 there's 2 rows or 6 rows of stuff.
   rachelandrew: Let me see if I can find the examples.
   <rachelandrew> https://codepen.io/rachelandrew/project/editor/68cc7a5da9cfbb56c6e8366d7d92e6ba
   <rachelandrew> this is a better view, some examples
                  https://codepen.io/rachelandrew/project/full/68cc7a5da9cfbb56c6e8366d7d92e6ba/XWYGMD/

   astearns: Would people object to dual-axis subgrid?
   florian: I think rachelandrew would.
   astearns: I'm hearing some people for and against single axis subgrid but
             I haven't heard opinions on per-axis besides everyone thought
             it was too hard to get to for the first level of grid.
   <tantek> IIRC, all variants of subgrid were too much for grid level 1
   Rossen: I still agree it was a good move to hold it back. To your second
           point as to if dual- or per-axis is what we want, now that we can
           reason about it and think holistically the dual-axis is an easy
           shortcut to cover some use cases but during Tokyo I heard enough
           compelling reasons to have the per-axis variant. I will admit I
           haven't reviewed the spec. But I prefer the per-axis one. I don't
           think there will be all that much work per-axis, at least in our impl.
   astearns: Perhaps we could leave it at people should review the spec and
             look at the use cases and then come back soon?
   rachelandrew: I could probably get more use cases now that people are
                 using grid.

   astearns: Is there an issue for choose which approach?
   fantasai: Yep. https://github.com/w3c/csswg-drafts/issues/2280
   astearns: I suggest we continue discussing in that issue.
   astearns: Anything else?
   fantasai: When do we want to return?
   Rossen: End of F2F.
   astearns: We can try and bring this up end of Thursday. Then perhaps we
             can make a decision then.
   astearns: Please take breaks or lunch time if as you read you have questions.

   dbaron: Would it help to get Mats on a call?
   fantasai: It would be good to have Mats look and reply on github.
   fantasai: I haven't heard from him.
   dbaron: If you want me to poke him can you send me what you want me to do?
   fantasai: Review the spec and comment.
   fantasai: And if there's nothing wrong with it say it's good.
   florian: Also express a preference? Or he always has.

"equal gutters" with justify-content on grid items
--------------------------------------------------
   github: https://github.com/w3c/csswg-drafts/issues/1116

   astearns: Other part of grid L2 as aspect ratio controls.
   fantasai: We resolved to add this to the first level of the WD.
             Just a request for people to let me know what they think.

   TabAtkins: Other than that I want a unit on these I think it looks great.
   fantasai: Unit proposed is ar unit for aspect ratio.
   astearns: Two options are a bare number or an ar unit.
   fantasai: I'm open to name suggestions.
   TabAtkins: I regret not putting a unit on flex.
   astearns: Could ar be used in other places?
   TabAtkins: A generic aspect ratio.
   florian: It's mathematically unitless.
   fantasai: It's a multiplier.
   TabAtkins: Whatever the other thing results in, multiply it.

   florian: Does the unit thing play into if we want to ever use calc on it.
   TabAtkins: Numbers tend to cause parsing issues. It causes issues on the
              flex things. I'd prefer not to continue that pattern. This
              has a specific meaning so it should be tagged in a specific way.
              Angles are just numbers.
   fantasai: They're not.
   TabAtkins: They're radians which are just an ID.
   <ChrisL> how are radians an ID?
   <TabAtkins> ChrisL, Radian is (length of arc) / (length of radius),
               which is unitless
   <ChrisL> an aspect ratio is (by definition) a ratio. It is a length
            divided by a length, and thus also unitless.
   <TabAtkins> Yes, that's my point. We already associate units with "unitless"
               things, to give it an easily-interpreted meaning and help with
               parsing. This is the same deal.
   <ChrisL> remember though that whenever we add units, it stops those things
            being used in custom properties, because we can't divide by unit-ed
            values

   fantasai: Somewhat related issue has been aspect ratio units for grid, #1173
   fantasai: There was a request for having an aspect ratio in the grid spec.
             A lot of the cases we want to have are covered by an aspect-ratio
             property that can apply to grid items (driving auto-sizing in the
             other dimension).
   fantasai: Question was if there isn't an element can you assign the aspect
             ratio property; then we need another approach.
   fantasai: You might decide you have a bunch of fr columns and you want the
             rows to be 1:1. Once we add aspect-ratio, if there's at least one
             element you can key off of you can auto-size the rest. If you
             don't put anything the auto row collapses to 0.
   astearns: The only things in having that row were spanning it would be weird.
   fantasai: One proposal was to have an ar unit in grid template columns that
             would represent the aspect ratio multiplied by track size in the
             opposite axis. Problem was, what if there are multiple tracks of
             different sizes?
   fantasai: Proposal I had is 1ar is always resolved value of 1fr in the
             opposite axis.
   florian: You can't map to a column 'cause you don't know which to match.
   fantasai: It's not clear what we need to do for this issue.
   astearns: And a side discussion.
   fantasai: A unit may be useful in this case.

   astearns: So do you want to resolve to add a ar unit?
   TabAtkins: If we accept the proposed syntax I feel we should have a unit.
   ChrisL: Remember when we add units you can't use them in custom properties.
           You can't divide by an ar.
   TabAtkins: You can, it works now.
   <TabAtkins> (I've been slow to add the functionality to calc(), but we
               resolved to do so a while back, and Typed OM allows it.)
   <ChrisL> fair enough; would be good to see that agreement in the spec,
            and implemented

   astearns: Objections to adding an ar unit to the grid 2 spec for align content
             and justify content?
   RESOLVED: Add an ar unit to the grid 2 spec for align-content and justify-content.

   astearns: Anything else on grid 2?
   fantasai: It's just those 2 things. Once we have agreement on subgrid and
             someone has read it [and there's no issues] I'd be happy to request
             CR.
   astearns: I'd like to get an impl started.

   astearns: I'd also like to see progress on grid area styling proposal.
   fantasai: That's grid 3. Grid 2 is just subgrid and this one other small
             thing. Styling of grid areas is more complex spec-wise for sure
             (uncertain about impl-wise). In terms of figuring out the spec
             that'll be harder.

Grid Layout Level 1
===================

Can the sizing algo be made to deal with this
---------------------------------------------
   github: https://github.com/w3c/csswg-drafts/issues/2356

   <florian> https://florian.rivoal.net/csswg/grid/grid-span-auto-001-ref.html
   florian: I was laying out a page of manga using grid so each cell is a grid.
            It should layout like ^
   florian: Defining a bunch of columns and rows and everything can fit,
            but it's manual.
   <florian> https://florian.rivoal.net/csswg/grid/grid-span-auto-001.html
   florian: Here's what you get ^
   florian: It has unneeded empty spaces.
   florian: I think this boils down to current sizing algorithm not considering
            enough things. It's described as a possibly improvable heuristic.
            If we agree this is a good thing to solve... it sounds desirable...
   florian: I think this is linear programming solvable by constraints. I'm not
            good enough at math to put the steps but I think this is solvable.

   <TabAtkins> Very simple example:
               https://github.com/w3c/csswg-drafts/issues/2356#issuecomment-379878492
   TabAtkins: Simple example ^
   TabAtkins: [explains example]
   TabAtkins: We take the largest of the planned increases so we're not loosely
              wrapping each item. Ideal would be the latter image. It's one
              possible version.

   florian: I believe an algorithm exists that could solve it... or are we too
            locked into compat?
   fantasai: I think we should be able to make the adjustments here. I don't
             think anyone depends on this slight amount of slack. As time goes
             on we might get more constrained but I think we're not at that
             state. If we could solve it it would be great, but I don't know
             how to do it.
   florian: I might be able to research the theoretical algorithm but I'm not
            right person to say if it's implementable.
   fremy: I've been working on some layouts and you can do a post-process to
          reduce the sizing.
   TabAtkins: This example (bottom of link) it shows one possible switch.
              But there's several ways to solve it like making the columns
              50,250,0, which is a big change from the current way they lay out.
   florian: Some examples have a range of solutions, mine has one solution.

   florian: I think it's worth looking into if there's a general option that
            we're not blocked in. I'd appreciate a mathematically-inclined
            person to help. Maybe do the current algorithm and squish would work.
   fremy: Browsers have already implemented grid and we don't want to change
          the whole algorithm, so a post-processing step is easier.
   TabAtkins: And your site may be doing it for you. In the manga example your
              images have known widths, it's just easier if CSS does it for you.

   fantasai: TabAtkins and I can take an action to look at adding a
             post-processing step to see if that works.
   fantasai: Maybe send a email to bert with a link to this issue to see if
             he has some insight?
   ChrisL: We were talking to people from Monash University with expertise.
   fantasai: We also had César who was working on an impl of Bert's grid spec.
   florian: I think the trickier part is that this is more complicated.
           If we have auto sizing it's simpler. If you have one min and one
           max you span. It's much harder to explain to people that don't
           know CSS but I'll try.

   astearns: Anything more?
   florian: Nope.

Grid track sizing items spanning a flexible track
-------------------------------------------------
   github: https://github.com/w3c/csswg-drafts/issues/2177

   rego: Quite related, you have an item that spans 2 columns.
         One of them is outside its flexible track, and we weren't sure
         what would be the best result. We're not sure what's the core
         approach. Rossen was trying to clarify in the last comment.
   astearns: There's a specific tweak to the algorithm you propose?
   rego: Original algorithm was aligned that you don't expand a track
         with a flexible track sizing. Maybe we can open the use cases.
   fantasai: We should try Rossen suggestion in the issue and see if it
             works. I haven't fully thought it through but that's what
             I'd want to try.

   Rossen: When we looked we played with magazine layouts. One recurring
           thing was when you have a splash page when an item that spans
           N columns and want to influence rest of layout. Those columns
           need to be flexible when you're on a browser. That was the
           original motivation.
   Rossen: Since then in the issue... we can go either way. I don't think
           there's enough concept to support one or the other. What I
           proposed should work.
   fantasai: Makes sense to me.
   astearns: Do we need a resolution to edit in Rossen proposal?
   fantasai: Resolution to add Rossen proposal and we'll revisit if
             there's a problem.

   RESOLVED: Edit in Rossen proposal in https://github.com/w3c/csswg-drafts/issues/2177

'justify-content' on multicol
-----------------------------
   github: https://github.com/w3c/csswg-drafts/issues/1420

   astearns: We've discussed in the past.
   TabAtkins: As florian says from third to last comment, right place to start
              reading is the one above.
   <fantasai> https://github.com/w3c/csswg-drafts/issues/1420#issuecomment-303958104

   TabAtkins: florian objections to current spec are 3.
   TabAtkins: 1) in current spec you can't robustly fix the ratio of the
                 default column gaps.
   florian: Fixed that.

   TabAtkins: 2) default behavior of space between ends up with not the correct
                 ratio because space-between space is added. Trivial fix, if
                 you set column-gap to 0 it works. Solving it precisely would
                 involve special cases multicol if the column gap and so we'd
                 be against that.
   florian: You should not set the column gap to 0, though, because depending
            on the space you end up with it might be 0 and it's unreadable.
   TabAtkins: Then you set padding.
   florian: I'm not completely opposed to your proposal. Setting gap to 0 it
            can be mushed so you get padding on the edges. Typically multicol
            has text, though, and if you don't have room you fallback to block
            which is good. But if you're forcing padding for space you keep the
            padding when you collapse.
   TabAtkins: I disagree. So you want space around. You leave column gap at
              1em and padding to 1/2em on either side. I don't see why when
              you go to 1 column that you don't want the 1/2em padding.
              You put it there for a reason and I don't see why it goes away.
              It goes away in multicol because it has no gaps, but you're
              explicitly putting the gaps.
   TabAtkins: If a single column you want the text flush you'd want that in
             many columns.
   fantasai: Like if you have 1 column and you split to 2 you don't want
             padding on common container but you want a gap between the 2.
   fantasai: Regardless, I'm opposed to different behavior between multicol
            and grid.
   rachelandrew: Authors wouldn't use space-around if they're not okay with
                 gaps on the outside. If you didn't want that you'd use
                 space-between.
   rachelandrew: I agree we want to be able to maintain the 1em so people
                 don't set column-gap to 0.
   florian: This issue traces back to before we merged the models. Now we have.
            I'm okay with what you proposed, we just never discussed it. It was
            just added to the spec. If everyone agrees.

   fantasai: Proposed that alignment & gaps in multicol behave exactly like grid.
   astearns: Close no remaining changes.
   TabAtkins: I could go with a note for how it works.
   fantasai: I think people know how to do padding. They figured it would for
             grid so you'd have to have a note in both.
   florian: There's many ways to space in grid that don't require figuring
            this out. I think a note wouldn't hurt. Doesn't have to be multicol
            specific, but I think it would help more there.
   astearns: I'd prefer the note because it shows we considered this, discussed,
             and have a solution. As people read they can agree or disagree.
             Without a note it's fairly opaque.

   astearns: Proposal: alignment and gaps in multi col behave exactly like grid
             and we will add a not explaining the issues in the issue and how
             to solve them
   astearns: Obj?

   RESOLVED: Alignment and gaps in multicol behave exactly like grid and we will
             add a note explaining the issues in the issue and how to solve them.

Axis Names
----------
   github: https://github.com/w3c/csswg-drafts/issues/1299

   fantasai: SelenIT commented that rachelandrew's articles had the opposite
             meaning of row-axis and column-axis as what's in the grid spec.
             We only use them in a handful of places, and since most people
             learn grid from rachelandrew it's probably better to match her
             terminology.
   rachelandrew: I've commented before that people struggle to learn this.
                 People are used to a main and a cross which you don't have
                 in grid. People are explaining it all sorts of ways. It's
                 gone around and around.
   fantasai: 3 options:
                1 is don't change the spec.
                2 flip to match rachelandrew.
                3 remove terminology.
   <fantasai> Reasoning for the spec's usage is in
              https://github.com/w3c/csswg-drafts/issues/1299#issuecomment-298106439
   <fantasai> terminology is in https://drafts.csswg.org/css-grid-1/#grid-concepts

   TabAtkins: I'm in favor or removing the terminology. Both schemes make sense.
              Flipping to the other doesn't have a compelling reason because
              other people will not understand. We should use block and inline.
   rachelandrew: I prefer block and inline.

   Rossen: rachelandrew can you fix and teach people the way we have intended
           this to be spec?
   rachelandrew: I'd prefer us to use block and inline.
   Rossen: I think it's fine but also spec what the row and columns are correctly.
   fantasai: Note that the axis names appear 3-5 times total.
   Rossen: I'm slightly opposed because the column-axis and row-axis are
           something which applies to internal layout of grid. Easy to
           rationalize which is which. Even thought inline and block axis
           apply externally the two aren't necessarily the same.
   fantasai: Actually they are exactly the same.
   fantasai: Question for you--don't look at the spec
   fantasai: Which is the row axis? Horizontal or vertical?
   Rossen: Vertical.
   fantasai: It's horizontal in the spec.
   fantasai: If we want to match your head we need to flip.

   Rossen: Row is if you add more rows so it's how it advance.
   plinss: Thing you put in a row progress horizontally.

   astearns: I hear these terms aren't used much in the spec. What damage does
             removal cause?
   TabAtkins: Every time we use the terms we also call it block or inline
              in parentheses.
   fantasai: There's no occurrence of these terms where both aren't used.
   astearns: Useless terms. Causes confusion. We should remove.

   RESOLVED: Remove these terms from the grid spec.

   <rego> the last comment in previous issue:
         https://github.com/w3c/csswg-drafts/issues/1299#issuecomment-377490475
   <rego> was suggesting about if it'd make sense to change the properties
         "grid-column-start" to "grid-inline-start" and "grid-row-start" to
         "grid-block-start" and so on
   <fantasai> rego: no
   <rego> fantasai: :)

Alignment: Closing out last few open issues and republishing
============================================================

   Issues list: https://github.com/w3c/csswg-drafts/issues?q=is%3Aopen+is%3Aissue+label%3Acss-align-3

calc() with percentages in margins/padding
------------------------------------------
   github: https://github.com/w3c/csswg-drafts/issues/2297#issuecomment-376263348

   <fantasai> Comment summarizing issue:
              https://github.com/w3c/csswg-drafts/issues/2297#issuecomment-376263348
   fantasai: It was to discuss zeroing out a percentage vs the entire expression.
             Example calc (10% + 10px).
   fantasai: Zeroing the entire expression is what's impl. Zeroing the percent
             is more meaningful. This is for purpose of calculating the intrinsic
             size of the element.
   dbaron: It's also continuous in terms of what happens when you have a calc
           that approaches 0 and you remove the calc.
   TabAtkins: Are we okay with some properties having a different indefinite
              percent with calcs?
   fantasai: I prefer 0 out the percent.
   florian: Justification to zero everything is just that it's what we have impl.

   fantasai: I didn't hear anything.
   Rossen: I agree with fantasai. Zeroing the percent makes more sense.
           Having a box model with some percent and non-percent values results
           in the same logic, where we would zero out the % values and add the
           rest of the defined sizes

   fantasai: For sizes like width/height, we ignore entire calc. We closed that
             in #1132. Sorry, we throw out the calc and treat as auto.
             Fallback to initial value.
   fantasai: That makes sense for sizing in a way it doesn't here is if you
             fallback to the original that has some kind of meaning. In this
             ase there's no meaningful value for margins and padding.

   astearns: In only zeroing out percents when not sizing is a discrepency.
   fantasai: Correct.
   asteanrs: Why do we throw out the expression for sizing properties?
   florian: We can do calc of 10%+10px is the same as 10px but we can't do
           auto+10px because that's not defined.

   astearns: Arguments against only zeroing out percent on non-sizing props?
   astearns: Objections?

   RESOLVED: Zero out percentages on non-sizing use of calc.

Should last-baseline's fallback alignment be safe or unsafe?
------------------------------------------------------------
   github: https://github.com/w3c/csswg-drafts/issues/1611

   fantasai: Say you have a row flexbox and inside you have items with
             last-baseline alignment, but the flexbox is larger than the items
             we have to decide how to align them. Just like for first-baseline
             you align and then start align the set at the top, we align the
             last-baseline set at the bottom.
   fantasai: But what if it's too small to contain all the items? In that case,
             what happens? Do we continue to align at the bottom and the large
             items overflow the top or do we take the things that are too big
             and start-align them so they no longer participate in baseline
             alignment?
   astearns: From I can access and read safe is better, but from design unsafe
             is better.
   myles: Implementation difference.
   fantasai: We were generally unsure before.
   myles: Have we asked authors?

   florian: Can we default to safe? Defaulting to safe sounds...safer? And let
            authors opt-in if needed.
   TabAtkins: We don't let you set it. It seemed like more switches then you
              needed access to.
   fantasai: We could make it possible to combine the keywords.
   florian: I'd prefer default safe and have the keyword.

   astearns: We last left this that someone would write a blog post.
   fantasai: That was not done.
   astearns: I don't think we should assume we will add a switch. We should
             decide based on probability that this is a weird edge case so
             it's not worth our time to have a switch.
   TabAtkins: That's why we haven't done it.

   Rossen: Can we resolve on choosing safe? If someone squeaks really hard
           we'll solve it.
   astearns: Objections to using the safe behavior in this case of last-baseline
             alignment?
   fantasai: All using the alignment properties.
   astearns: In this case with content that will not fit in it's container and
             we fail to be able to last-baseline align things, things will
             overflow in a safe direction.

   RESOLVED: In this case with content that will not fit in its container and
             we fail to be able to last-baseline align things things will
             overflow in a safe direction.

Publication
-----------

   fantasai: New WD once dbaron says they're okay?
   astearns: Objections to new WD once we get through some of the remaining
             open issues?
   ChrisL: I'd rather be told when it's approved, not we approve some time
           in the future.
   Rossen: Let's publish now and again later.
   astearns: We just resolved 2 things.
   fantasai: One was no changes.
   Rossen: The one for calc was in sizing?
   astearns: Objections to publishing a new WD of Alignment with the one edit
             from the baseline-alignment resolution.

   RESOLVED: Publish a new WD of Alignment with the one edit from the
             baseline-alignment resolution.

   <br type="short">

Received on Friday, 27 April 2018 21:29:23 UTC