W3C home > Mailing lists > Public > www-style@w3.org > May 2019

[CSSWG] Minutes San Francisco F2F 2019-02-27 Part IV: Overflow, Multicol, Fonts, Lists, Grid, Text and Sizing [css-overflow] [css-multicol] [css-fonts] [css-lists] [css-grid] [css-text] [css-sizing]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 16 May 2019 18:56:22 -0400
Message-ID: <CADhPm3sjDTP0MoJuFWVBL0XpzoBkFHijz+838mZycGEVGsNM8A@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.
=========================================


CSS Overflow
------------

  - heycam gave an update about the work to specify
      -webkit-line-clamp. There are a few differences being introduced
      intentionally such as skipping newer formatting contexts (such
      as flexbox) and having any independent formatting context child
      get skipped over.
  - iank will try fixing Blink to use the block-end edge of the line
      box (per spec, consistent with normal sizing rules) rather than
      the block-end edge of the lowest item (current -webkit-
      behavior).

CSS Multicol
------------

  - RESOLVED: Clarify the spec using the notion that this is an out of
              flow that leaves a forced break behind (Issue #1072: How
              do elements between column-span and its multicol
              ancestor appear around the span)
  - RESOLVED: Update the spec to return to the behavior as implemented
              in Blink/WebKit/Edge that `column-fill: auto` balances
              an unconstrained container, and does not balance a
              constrained container (Issue #3224: Improve column-fill
              and make it backward-compatible)
  - RESOLVED: Include min and max as constraints [in the above
              resolution] (Issue #3224: Improve column-fill and make
              it backward-compatible)

CSS Fonts
---------

  - RESOLVED: Use ascii-case folding (Issue #3675: Font-family name
              matching requires full Unicode case comparison)

CSS Lists
---------

  - There were three proposals to solve Issue #3686 (Initial value of
      counter-increment needs to be something different from none)
      which will be discussed in the issue:
      (A) fantasai's proposal: if an element has display: list-item,
          then the list-item counter is incremented unless the
          counter-increment property contains a reference to the
          list-item counter. (Authors can override this effect with
          counter-increment: list-item 0.)
      (B) dbaron's proposal: if an element has display: list-item,
          then the list-item counter is incremented. (Authors can
          override this effect with counter-increment: list-item -1,
          unless the list is reversed, in which case it would be by 1.)
      (C) Fremy's proposal: if an element has display: list-item, then
          the list-item counter is incremented unless the
          counter-reset, counter-set, or counter-increment property
          contains a reference to the list-item counter.

CSS Grid
--------

  - RESOLVED: When calculating content based base sizes of spanning
              items, if extra space needs to be distributed past the
              growth limit, and there is a range available in another
              column, put it in there (Issue #3648: Distribute extra
              space into non-intrinsic tracks instead of going beyond
              growth limits)

CSS Text & Sizing
-----------------

  - RESOLVED: Preserved spaces from pre-wrap hang when they occur
              before a soft wrap, but would not hang when at the end
              of block or forced break (Issue #3440: When to/not to
              include preserved trailing spaces)

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

Agenda: https://wiki.csswg.org/planning/sf-2019

Scribe: iank

CSS Overflow
============

Convert -webkit-line-clamp alias requirement into a spec issue
--------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2847

  heycam: Talked about -webkit-line-clamp, wanted to give an update,
          last couple weeks looking at implementing, and looking at
          what the actual behavior inside blink/webkit
  heycam: At high level, in the spec we talk about it as a
          fragmentation, once you reach Nth line, subsequent lines
          fragment, and lines disappear.
  heycam: In blink/WK the effect is only influencing its size. Like a
          max-block-size constraint, element is reflowed, where is
          position of last line? This affects intrinsic block-size
  heycam: As in blink/WK you'll end up with an element w/ this size,
          however the remaining lines will appear as overflow.
  heycam: These differences aren't insignificant, I've written patch
          for what blink/WK have done. Wanted to do this in a
          reasonable time.
  TabAtkins: The existing -webkit-line-clamp impls are bad and
             horrible.
  heycam: Apart from the difference with fragmenting or not, elements
          on subsequent lines will actually show, however this
          probably isn't a webcompat constraint.
  heycam: -webkit-line-clamp only works on -webkit-box, orientation:
          vertical. Some risk that if we don't respect that it may
          appear on elements that wasn't expected to have that treated.
  <fantasai> The differences are largely intentional
             https://medium.com/mofed/css-line-clamp-the-good-the-bad-and-the-straight-up-broken-865413f16e5
  <fantasai> Main concern is really interaction with -webkit-box

  TabAtkins: iank did some looking.
  iank: I did some analysis by adding a bunch of usecounters in our
        -webkit-box implementation to answer questions like how many
        w/ single block-flow child, vs. multiple.
  iank: This allowed us to kill percentage -webkit-line-clamp
  heycam: yaya
  <dholbert> https://www.chromestatus.com/features/5393405823680512
             seems to be the query for percentage values of
             webkit-line-clamp
  <astearns> https://www.chromestatus.com/metrics/feature/timeline/popularity/2139

  heycam: One other difference between spec and impl, any independent
          formatting context child gets skipped over, that means a
          BFC, overflow: scroll, display: flex etc, I think that makes
          sense, is nice simple model, however it is a difference.
  heycam: Where this difference has more of an effect, as it only
          works on a "box-item" that establishes a independent
          formatting context.
  heycam: If respected that rule, we'd never be able to apply that
          line-clamp. Needs to be an exception around this.
  fantasai: A couple of options: an exception for -webkit-line-clamp
            stuff, e.g. inherit the line clamp behavior into the
            flex-item, or automatically apply.
  heycam: I think that's a sensible thing to do.

  florian: Most differences are intentional
  florian: We probably need to do at the syntax level, where you
           specifically that you need -webkit-box, etc, to apply the
           prefixed version.

  florian: We should do these tweaks, need to confess to ulterior
           motive, I think feature is good on its own, the way that we
           spec'd it is good. But it's also the first step helps us
           solves a bigger problem.
  florian: This solution is a subset which we need to get to overflow:
           fragments.
  florian: I think this is a good things.
  florian: Wouldn't want to clean the hacks so much that we lose the
           nice version.
  heycam: What is in the spec at the moment is good, I'll probably
          only implement the -webkit-line-clamp for compat reasons,
          but want to try and get to the standards based version.
  heycam: The aim for the fragmentation based solution is good.
  heycam: I don't think making the prefixed -webkit-line-clamp
          property an alias of the standards-based thing is possible.
  florian: I think there is an issue in the spec, about this.

  heycam: Can I ask people if skipping over new formatting contexts is
          a good thing?
  fantasai: I think that its not clear for many new formatting contexts
            (like flex) where it applies.
  fantasai: e.g. horizontal flexbox or table, what do you clamp? each
            item in the row, first item only...
  heycam: I agree.
  florian: I would to keep a vertical -webkit-box w/ single item is
           simpler, if isn't sufficient for web compat, and need to
           handle multiple items, then if we need to handle that, yup
           can add to spec.

  heycam: Can I also ask if people are against the size calculation
          the current implementations have.
  florian: Would rather not spec, until we need them.
  iank: We might need them.
  heycam: I've written a bunch of tests to determine what is happening.

  scribe: emilio

  heycam: One final difference, is the exact position, in standards
          version it is the block-end edge of the line-box, in
          implementations its actually block-end edge of the items
          within that linebox.
  fantasai: The line-box can be taller.
  florian: It makes the line shorter, because the line can be taller
           due to line-height
  TabAtkins: Is that what auto-sizing does?
  (somebody): no
  TabAtkins: Then that's bad
  heycam: I agree that line-box block-end edge makes more sense
  iank: I actually got a request a couple days ago about our behavior
        being bad, and it's a one-liner, so I may just try to change it
  iank: To do the same as auto-height
  TabAtkins: Cool
  iank: WebKit's behavior is also bad, and it's probably the same
        one-liner

  heycam: Another difference is that the flex item is inflexible if
          you have line-clamp on the flex container
  heycam: I suspect this is not a problem in practice since authors
          are not using this feature for flexbox sizing anyway
  heycam: I think this is all we wanted to get out of this
  heycam: I'll change the patch to use the line-box block-end edge as
          iank is going to do in Blink and land the weirdo behavior
  <iank> Use counters, see
https://www.chromestatus.com/metrics/feature/popularity
         and WebkitBox* counters.

  <TabAtkins> I propose "boxflex item" and "boxflex container" as
              words to refer to the old stuff.

  fantasai: For the flex special-case, the simpler thing is that if
            you have an anonymous flex item, you inherit line-clamp
            from the parent
  heycam: Current patch makes it apply to both anon and non-anon flex
          containers
  heycam: May be more complicated
  emilio: No, just inherit from ::-moz-anonymous-* thing
  heycam: Ah, ok, maybe not

  florian: If we specify that -webkit-line-clamp only applies to
           display: -webkit-box, we need to define what that is
  iank: Some of it is in the compat spec
  florian: Should we pull that in?
  florian: Can we rely on the compat spec to do that?
  dholbert: Yeah, it's not exactly the WebKit implementation but has
            been good enough
  <xfq> https://compat.spec.whatwg.org/#css-keyword-mappings
  florian: ok, there's no w3c spec that depends on the compat spec, so
           may be an issue
  fantasai: Isn't it a whatwg spec? we can refer to that
  florian: We can pull from compat spec as well
  (everyone): Let's not discuss that now

  heycam: Is the idea to do that when we have the non-webkit version
          as well?
  heycam: Or does it makes sense to do it already?
  florian: I think we should spec everything we're moderately sure we
           won't be able to rip off
  dholbert: We can move -webkit-line-clamp to the compat spec too
  florian: The way I see it is that things that we need to define
           precisely how they work should get on the proper spec
  florian: You could see the compat spec as an incubation thing for
           these things
  TabAtkins: The ideal is that things in compat should effectively
             migrate out into real spec

  <florian> this is also why it is hard to have normative refs to the
            compat spec. Not because it's in whatwg (that's fine), but
            because it a fast and loose spec that's not terribly
            precise or stable

CSS Multicol
============

multicol descendant ancestors of a column-span
----------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1072#issuecomment-465362932

  rachelandrew: It's a reopened issue that was resolved on but dbaron
                reopened requesting some clarification
  rachelandrew: The example is figure 21 in the spec
  rachelandrew: The initial thing was mentioned was essentially a
                clarification. The situation is when margins paddings
                and borders are split by the spanner, but an empty
                fragment ends up before the spanner
  <fantasai> I think this just needs to adopt the same wording as
             CSS2.1 block-in-inline splits
  dbaron: A bunch of the clarifications was just to say what happens
          for elements that are both descendants of the multicol and
          ancestors of the spanner when they're split by the spanner

  dbaron: A more interesting question is what happens when there's an
          explicit height and how's it distributed
  fantasai: Simplest is to treat the split as creating a fragmentation
            break, but computes padding borders as if the spanner
            didn't exist
  dbaron: I think everyone pretty much agreed with the outcomes even
          if there's disagreement on how to describe them

  florian: There are a couple related aspects
  florian: <section><div><aside column-span: all> split element
  florian: We thought it could be described like the spanner being
           out-of-flow
  florian: but forces a fragmentation break
  florian: so that it doesn't influence min-content and such
  florian: The div is not affected by the span itself
  florian: I think it's easier to define the span this way
  rachelandrew: I think it's one of the cleanest way to describe it
  rachelandrew: and easier to understand
  fantasai: I think out of flow stuff in CSS is taken out of the flow,
            the rest of the stuff is supposed to ignore it. An
            out-of-flow span in a paragraph doesn't cause a break on
            the parent
  emilio: Actually, it leaves behind a break opportunity
  florian: It's not quite true that out-of-flow don't affect the float
           -> floats
  florian: We need to define the specifics, but other than that is out
           of flow
  emilio: At least in Gecko, Webkit and Blink, out-of-flows do create
          break opportunities. I believe it's a bug. Edge does it
          right.
  florian: In this case it would be a forced break rather than a break
           opportunity
  Rossen: This is the model we use in Edge. We treat it as out-of-flow
          and force a break
  Rossen: This is the exact model we use for spanners in edge
  AmeliaBR: It is probably worth referencing it as being similar to a
            flow wrt. Background painting order and co?
  rachelandrew: Yeah I think I should write some spec text

  RESOLVED: Clarify the spec using the notion that this is an out of
            flow that leaves a forced break behind

Improve column-fill and make it backward-compatible
---------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3224

  rachelandrew: Turns out that a commented out sentence in the spec
                which Blink / WebKit and Edge implement
  rachelandrew: <reads from issue>
  rachelandrew: Firefox does not balance, given that text was
                commented out in 2012
  rachelandrew: I put together a couple examples
  rachelandrew: Proposal is to update the spec to the behavior WebKit
                / Blink / Edge

  rachelandrew: Another issue is to include min and max constrains
  rachelandrew: And whether we should introduce a "never-balance" mode
  florian: I think we almost concluded last time
  florian: We should generally follow the behavior of everybody but
           Firefox, except with the nuance that if it's not min- and
           max- we never go into the fill mode
  florian: As for adding a new fill behavior, not opposed but probably
           level 2
  florian: If we didn't include the min- thing I'd be more reluctant
           to follow Chrome / Edge / webKit
  rachelandrew: Have looked at Prince and they match FF
  florian: I think web compat is the dominant thing here
  florian: 1 and 2 solve the problem sufficiently well that you can do
           what you want in more cases
  rachelandrew: Unless people have objections I think that'd be a good
                resolution

  emilio: Has FF had compat issues because of that?
  florian: No, but others have shipped that behavior for a long time
  florian: and if we put 2 together it's not a bad behavior
  rachelandrew: Without being able to do the min-size thing it does
                get annoying, we use server-side stuff to measure
                content and not get the weird columns
  florian: Right, without the 2 part I'd prefer FF, but not otherwise

  RESOLVED: Update the spec to return to the behavior as implemented
            in Blink/WebKit/Edge that `column-fill: auto` balances an
            unconstrained container, and does not balance a
            constrained container
  RESOLVED: Include min and max as constraints

CSS Fonts
=========

Font-family name matching requires full Unicode case comparison
---------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3675

  myles: Spec says that in order to match font-family names full
         unicode case folding needs to be performed
  myles: so you need to run the names to complicated ICU routines
  myles: We just fold ascii chars in WebKit, for performance reasons
  myles: We never perform unicode case folding in WebKit
  fantasai: When you search on a page?
  myles: That particular API is a different one, but we do use unicode
  fantasai: It should use compatibility decomposition and caseless
            matching
  myles: ascii case folding is fast
  myles: I haven't done any measurement but if we used the unicode
         case comparison it'd likely be a perf regression because font
         lookups are not
  myles: Wanted to relax this restriction

  heycam: Why not require the ascii-case folding?
  myles: That's fine too
  heycam: I don't think there's many situations when you have
          non-ascii names?
  myles: Fonts have many names in many languages, in addition to an
         ascii name, generally

  florian: Isn't common to have a case-mismatched cyrillic name? Is it
           not a compat issue?
  myles: It's not

  myles: Proposed resolution is that font-family lookups should use
         ascii-case-insensitive matching
  dbaron: What do other implementations do?
  myles: Probably matches chrome
  eae: It does
  fantasai: I'd like to check with jfkthame
  emilio: I can check what Firefox does, hang on
  emilio: We do whatever nsCaseInsensitiveStringComparator does
  dbaron: That's ascii

  RESOLVED: Use ascii-case folding

CSS Lists
=========
  Scribe: heycam

counter-increment initial value
-------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3686

  fantasai: So there's a plan to use css counters for lists
  fantasai: Looks like Gecko is on the process of implementing it
  <TabAtkins> Today: <ol><li>one<li style="display:block">two<li>
              three</ol> results in "1. one\ntwo\n2. three"
  fantasai: They're blocked on an issue about the initial value of
            counter-increment
  fantasai: Basically by default we need to increment list-item
  emilio: The issue is not that we need it to implement this behavior,
          but we need it to allow the author to say
          counter-increment:none on a list
  dbaron: And does that style go on the list item or the marker pseudo?
  emilio: The list item
  florian: This is not just for markup lists, because if it was we can
           do it in the UA sheet, but it's also when you create list
           items through the display property

  emilio: The computed value of counter-increment needs to depend on
          display
  emilio: It's not a huge issue
  emilio: We have this kind of relationship for fonts and other
          properties
  emilio: The issue is that the author specified value gets lost
  TabAtkins: Sure
  dbaron: So auto would mean list item 1 if your display is list-item,
          and none for anything else?
  emilio: Yes
  emilio: and the computed value wouldn't include "auto"
  emilio: Otherwise you get into trouble with gCS, checking it against
          none or something

  fremy: What if on a list item currently you do counter-set:
         my-list-item 5
  TabAtkins: counter-set or counter-increment?
  emilio: If you set counter-increment to something else you will lose
          the auto increment
  emilio: Edge does something like this
  AmeliaBR: You have a todo list, and you're keeping your own track of
            how many items in the list are completed or not, don't
            want to muck up the existing list counters

  fantasai: We discussed something similar to this ~12 years ago
  fantasai: From what I recall, the conclusion we ended up with was
            that the magic counter would be implied no matter what the
            value of the counter property was
  fantasai: if you want to override that implied behavior, you could
            call it out explicitly
  fantasai: 'none' would not turn off increments for list-item
  fantasai: Neither would 'foo 0'
  fantasai: but 'list-item 0' would
  <fremy> +1
  emilio: ok
  emilio: Then we don't need this, but we should change the spec to
          say that the only way you can reset list-item is this way
  TabAtkins: Happy with that, then the spec doesn't have to disagree
             with implementations as much

  Rossen: The issue about the initial value of counter-increment
  Rossen: being something different from none
  emilio: One annoying thing is that counter-increment is the only
          weirdo property that depends on display
  emilio: you can explain counter-set for <li value=foo> using
          attribute mapping
  emilio: If you define that to be magical and non-overridable, then
          it becomes more complicated to implement
  fantasai: You run into the same issue if people are using counters
            already and are clobbered
  emilio: For li items inside an ol with the value attribute
  emilio: I'm fine restricting this solution to counter-increment
  emilio: or maybe counter-reset too?
  TabAtkins: We already need magic for these things because of reversed
  AmeliaBR: It sounds like in addition to having the list-item is
            always auto incremented unless explicitly told, we also
            need a way to say increment if displayed versus always
            increment
  emilio: That is the magic that counter-increment needs for list-item
  emilio: We don't need that magic for counter-set or counter-reset
          for lists

  dbaron: There's one other thing that makes me uncomfortable, but
          leads to an alternative
  dbaron: Right now if you say counter-increment: foo 1, foo 1; you
          increment the counter by 2
  fantasai: There's no comma
  dbaron: Saying that if you say list-item at all anywhere then it
          overrides the implicit "list-item 1" feels weird to me
  dbaron: Another way to do it is that display:list-item implicitly
          have a "list-item 1" in there. But you can add
          "list-item -1" in there to undo that effect
  [general groans]
  emilio: So you say display: list-item has a magic list-item 1
          increment
  emilio: and you can specify another one to cancel it
  dbaron: You say list-item -1

  fantasai: One of authors' goals is to expose counters to do
            interesting things with them
  fantasai: I think this makes it very confusing
  AmeliaBR: If you hide a list item then the next one would jump down
            a number
  fantasai: I would rather it be an override
  dbaron: I don't understand the hiding thing
  dbaron: It feels inconsistent that counter:foo 1 doesn't change it,
          but if you put list-item into that list that the other one
          disappears

  fremy: If you do a set and don't do the increment, it's wrong?
  fremy: If you have <li value=4> you don't increment
  fremy: it sets to that value
  dbaron: How you implement <li value> is another question
  <AmeliaBR> if you have `counter-increment: list-item -1`, that
             wouldn't have the magical dependence on display. So now
             hidden elements would reduce your overall counter,
             wouldn't they?
  emilio: The way the spec defines it is mapping the attribute to
          counter-set property
  emilio: and then to counter-increment: none too
  dbaron: If we change it this way, we have to change the mapping of
          the value attribute to counter-increment: list-item 0
  dbaron: to explicitly suppress the incrementing
  dbaron: and then if the author sets some other counter, it would
          break their value attribute
  dbaron: If the UA sheet for <li value=5> counter-set: list-item 5;
          counter-increment: list-item 0; then the author sets
          counter-increment explicitly
  dbaron: It would lose the 'list-item 0' counteraction
  * TabAtkins did not realize that "counter-increment: foo 1 foo 1;"
              was equivalent to "counter-increment: foo 2;"...

  fremy: Does anybody use the value attribute?
  AmeliaBR: Yes, commonly with pages of lists

  AmeliaBR: Has anyone thought for the issue of having the list-item
            counter depend on display, is that something we're ok with
            exposing to user counters as well?
  emilio: No
  AmeliaBR: Definitely a no?
  AmeliaBR: That only list-item has that?
  TabAtkins: We do have the case that counters only increment on
             things that generate boxes
  TabAtkins: but that's different from what list-item wants to do,
             which is depend on display:list-item explicitly
  AmeliaBR: So regular counters turn off with display:none, but the
            list-item counter turns off for anything other than
            display:list-item
  TabAtkins: Yes

  emilio: So there are 2 proposals
  emilio: One is that list-item is magically appended to
          counter-increment for list items
  fantasai: Unconditionally
  fantasai: that's dbaron's proposal
  fantasai: The alternative, the earlier discussed one, is that it's
            only added if the list-item counter is not mentioned in
            the explicit list
  fantasai: so the author doesn't have to think about what the UA is
            doing

  fremy: I was thinking about dbaron's issue -- there is a way of
         extending this
  fremy: You could stop the magical behavior if list-item appears
         explicitly in any of the counter properties
  fremy: Then you can map value="" into counter-set without worrying
         about counter-increment being clobbered by the author
  fantasai: I don't think you want to do that
  fantasai: Having property interactions like this makes it more
            difficult to implement
  fantasai: We want authors to be able to manipulate the list-item
            counter in a straightforward manner
  fantasai: Looking at other properties is more confusing
  fantasai: The author wants to set the counter to something, or
            change the increment, or both -- but if mentioning
            list-item in one changes how the other behaves, that's
            confusing
  fremy: <li value="5"> maps to counter-set: list-item 5; and the
         counter-increment won't use the implied list-item because it
         appears in counter-set
  fantasai: Why wouldn't you have this behavior for other counters?
  fantasai: If it's useful we can do it for other counters
  <dbaron> "Inheriting counters must be done before resetting
           counters, which must be done before setting counters, which
           must be done before incrementing counters, which must be
           done before using counters (for example, in the content
           property)."
  emilio: Resets are applied before increments
  dbaron: Reset, then sets, then increments
  emilio: So the increment will always be applied unless you suppress
          it
  fremy: Either you set the list-item value, and not do the automatic
         increment
  emilio: If you do what dbaron says, you could map the li value to
          counter-set, then counter-increment: list-item -1
  fantasai: If we're cringing at this proposal in here, there will be
            a lot more cringing out in the world
  <fremy> so counter-increment has "listitem 1" implied except if you
          "counter-set: listitem 5" or "counter-increment: listitem 0"

  TabAtkins: I suggest figuring out the technical issues in the GH
             issue itself
  dbaron: I think I'm OK with Elika's proposal
  dbaron: Mine has the disadvantage [...]
  AmeliaBR: I am voting for fremy's proposal
  Rossen: It sounds like the leading one for a resolution would be
          fantasai's
  dbaron: I will write the 3 alternatives in the issue
  emilio: We could look at the code to understand the weirdness and
          report back

CSS Grid
========

Extra space into non-intrinsic tracks instead exceeding growth limits
---------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3648

  fantasai: Let's say there are two columns
  fantasai: one is minmax(0, 100px), the other is minmax(auto, 100px)
  fantasai: Normally we do a first pass to figure out the base size
  fantasai: min size of each column
  fantasai: first is fixed and gets 0
  fantasai: The second is roughly the min-content contribution of any
            items in that column
  fantasai: Let's suppose that item is 150px
  fantasai: The max specified here is 100px
  fantasai: since the first column says I'm 0px, we put all 100 or
            150px into the second column
  fantasai: and blow out the maximum
  fantasai: in order to fit the content
  fantasai: But the author did give us some space, first column has a
            range
  fantasai: Instead of blowing out the max on the second column, we
            could take those 50px and put them into the first column
  fantasai: and it wouldn't violate any of the max constraints on the
            columns
  fantasai: We ran this idea by jensimmons and rachelandrew and they
            both said yeah we'd expect that to happen
  fantasai: so I'm suggesting adjusting the grid algorithm so that
            when computing the min size of a spanning item, if you hit
            the growth limit, and have another that is still below
            its max, you increase that one

  TabAtkins: Sounds reasonable
  rachelandrew: I like this because it is more similar to the flex
                behavior, which people will expect
  rachelandrew: Why overflow the column when there is still space there
  rachelandrew: This could happen when you have a single row grid, and
                they're using grid for whatever reason, and they'll
                expect that space to be used
  iank: What happens if the item is 150px in width? are the columns
        50px and 100px?
  fantasai: Yes
  jensimmons: Right now they're 0 and 150 but we're proposing they be
              50 and 100
  Rossen: Any objections?

  RESOLVED: When calculating content based base sizes of spanning
            items, if extra space needs to be distributed past the
            growth limit, and there is a range available in another
            column, put it in there

  iank: You'll need to specify which columns take the slack
  iank: 2 on the left and 2 on the right
  fantasai: All of them

CSS Text & Sizing
=================

When to/not to include preserved trailing spaces
------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3440

  fantasai: Some discussion back and forth about how to handle
            preserved whitespace at the end of a line
  fantasai: Most recent resolution is that it hangs if it doesn't fit
            in the line box
  fantasai: koji came back to say that doesn't make sense if you have
            a paragraph that is white-space:pre-wrap
  fantasai: since then you will end up not justifying fully with the
            last visible letter to the edge of the container
  fantasai: because if that white space happened to fit, it would be
            within the container, otherwise you wouldn't get a flush
            edge
  fantasai: The discussion is now: should we say it's force hang
            instead?
  fantasai: Or do something else?
  florian: koji raised this only in the case of justification?
  florian: On other alignments browsers were aligned, and you're not
           trying to change that?
  koji: For justification including trailing spaces it's clearly wrong
  koji: For right and center, I'm neutral
  koji: In those cases I can see both sides of the argument
  <fantasai> I think this is why actually I made the comment in
             https://github.com/w3c/csswg-drafts/issues/3440#issuecomment-458783789

  florian: I'm trying to understand the use cases better
  florian: because I'm a little bit confused about whether it's in
           general OK, or already broken, to try to use pre-wrap on
           body text, paragraphs
  florian: If you have source code that is pre, and you want to switch
           to pre-wrap to avoid overflow, that's fine
  florian: If you apply pre-wrap to body text, there are some odd
           things that happens
  florian: Links in the text are underlined, if your linked phrase
           have spaces, you'll have a hanging underlined space at the
           end
  florian: so it's a bit strange, but I'm not sure
  florian: Don't know if we should try to support that more, in which
           case what you say about justification is right
  florian: or decide we don't really care about this, and not optimize
           for it
  florian: Maybe people want to use double space after a period? that
           also feels into the category of not needing to try to
           support it
  florian: So these are kind of at the edge
  florian: of reasonable use of the properties
  fantasai: format=flowed plain text email is essentially pre-wrap text
  florian: but you don't re-justify it
  florian: If you try to preserve the format of the email, you don't
           go to justify it, since your alignments made with spaces
           will be broken by the justification
  fantasai: As far as trailing spaces underlined go, you can use
            text-decoration-skip

  fantasai: I think it's a bit weird for something to hang for some
            operations but not others
  fantasai: It might make more sense to say that if there is a soft
            break after a space, then that space force hangs
  fantasai: for alignment, justification, everything
  fantasai: but if there's a hard break, then that space does not hang
  fantasai: For the use case of pre-wrap on an entire paragraph,
            you're not going to be end it with a period, a space, then
            a line break
  fantasai: but for a line of text that happens to end with a space,
            then that would work
  florian: If we do force hang in that situation, what does it do for
           the max content size? include the size of not?
  fantasai: Max size is always unwrapped, so you include the spaces
  florian: What about space at the end of the paragraph?
  fantasai: Then there's a force break right after it
  florian: ok

  fantasai: Let's say you have a word, a space, a word, another space,
            end of the block
  fantasai: then you wrap in the middle of that
  fantasai: so you have word, space, soft-break, word, space, end of
            block
  fantasai: If you were to right align that text, the space that is at
            the end of the block would not hang
  fantasai: It's at the end of the block
  fantasai: The space that is wrapped does hang
  fantasai: When you left align you won't notice
  fantasai: when you right align or justify you will see the first
            line's space hang
  fantasai: Generally you want spaces to disappear when you break the
            line on them: we can distinguish between these cases from
            other trailing spaces by whether there's a soft wrap there
            or not
  koji: I think that makes sense
  koji: If other browsers are willing to match, I think we can try to
        match
  koji: Is Gecko happy with it? I think xidorn wanted to include
        trailing spaces
  koji: for right and center
  heycam: We can resolve and ping xidorn to get his opinion

  RESOLVED: Preserved spaces from pre-wrap hang when they occur before
            a soft wrap, but would not hang when at the end of block
            or forced break

  florian: Currently we say that spaces hang when they go beyond the
           edge of the block, browsers are allowed to discard them
  florian: We key that off the fact they hang
  florian: Are we still allowed to drop the last spaces before the
           forced break, or also not allowed to do that
  fantasai: Let's discuss that another day

  -- adjourned --
Received on Thursday, 16 May 2019 22:57:46 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:11 UTC