W3C home > Mailing lists > Public > www-style@w3.org > April 2018

Re: [CSSWG] Minutes Berlin F2F Tue 2018-04-10 Part V: Sizing, Flexbox, Overflow [css-sizing][css-flexbox][css-overflow][css-tables] / single-spaced

From: fantasai <fantasai.lists@inkedblade.net>
Date: Fri, 27 Apr 2018 14:29:14 -0700
To: www-style@w3.org
Message-ID: <dceeba11-da4e-8ef6-4861-b1cdecd75168@inkedblade.net>
=========================================
   These are the official CSSWG minutes.
   Unless you're correcting the minutes,
  Please respond by starting a new thread
    with an appropriate subject line.
=========================================


Sizing
------

   - RESOLVED: Treat indefinite percentages in min-width and min-height as 0.
               (Issue #2384)
   - RESOLVED: Add a note to the spec explaining this problem (adding a 'size'
               shorthand for 'width'/'height') and move this issue to level 4.
               (Issue #820)
   - RESOLVED: Publish a new WD of Sizing with all current resolutions edited in.

Flexbox
-------

   - RESOLVED: Tables defines used min-size to fold in its min-content size
               where necessary (for 'table-layout: auto'); Flexbox ensures
               it is hooked up to this terminology when looking up an item’s
               minimum size.
   - RESOLVED: Have an initial ED of Flexbox L2, defining combination w/
               additional alignment values and gap properties.

Overflow
--------

   - RESOLVED: Allow 2 values on the overflow property in physical x/y order
               for any existing values.
   - RESOLVED: add block and inline longhands to overscroll-behavior
   - RESOLVED: text-overflow and resize apply to elements with
               'overflow: clip' just as they apply to elements with
               'overflow: hidden'
   - RESOLVED: when 'overflow: clip' is propagated to the viewport it
               changes to 'overflow: hidden' the same way 'visible' is
               changed to 'auto'

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

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

Sizing
======

Does indefinite min-height: N% fall back to zero or auto?
---------------------------------------------------------
   github: https://github.com/w3c/csswg-drafts/issues/2384

   TabAtkins: This is for min-width and height. Do they fallback to auto or 0?
              General rule is we fall back to initial value. Is that 0 or auto?
              Initial used to be 0, changed to auto.
   TabAtkins: 2.1 explicitly says they're treated as 0, but it was probably on
              the assumption that 0 was the initial value.
   TabAtkins: Only real case is you have a flex item and you can't resolve the
             min-height should it be auto or 0?
   TabAtkins: I'm of the opinion it should be auto.

   Rossen: Current?
   TabAtkins: 0 which was previous initial value.
   TabAtkins: Change to be consistent with the change to initial.
   fantasai: I'm trying to wrap my head around when this would be different.
   astearns: Last time we discussed 0% when we said it should be 0 it's different
             on width then min-width.
   fantasai: auto for width isn't the same as min-width.
   astearns: We could throw out the calc on min-width if it's doesn't resolve.
   TabAtkins: Either the percent zeroes out or we throw it out.
   fantasai: Makes more sense.

   tantek: Treat min-width and min-height the same as we just resolved to deal
           with percentages.
   astearns: So it's zero rather then auto.
   TabAtkins: Still a change from current. calc is replaced with 0.
              Current is calc(10%+10px)=0. Now it's =10px.
   fantasai: This makes the most sense. Consistent with margins and padding.
   fantasai: If you set min-width to a non-auto size you're not expecting it
             to look at content.
   astearns: Proposal: treat indefinite % in min-width and min-height as 0

   RESOLVED: Treat indefinite percentages in min-width and min-height as 0.

   Rossen: This is web compat?
   TabAtkins: If you have a complex calc it's a change. Percent-only is the same.

Adding a 'size' shorthand for 'width'/'height'
----------------------------------------------
   github: https://github.com/w3c/csswg-drafts/issues/820

   fantasai: Shorthands are nice. We have them for many things, but not combo
             of width and height.
   fantasai: We hadn't added that because there's a size property0like thing
             that the @page has that does not behave anything like this
             shorthand would. That sets the size of the writing box.
   fantasai: Options are do something weird where size works differently for
             @page. Other option is some other word than 'size'.
             "box-size" is the current issue in the suggestion.
   fantasai: It would be the shorthand for block-size and inline-size.
             min-box-size/max-box-size would be for the min/max props.

   florian: Naming conflict is that bad?
   fantasai: It's a descriptor technically, but operating on a box that accepts
             other properties that apply to boxes. It'll be weird forever.
   TabAtkins: Weird because page takes width and height and size should be a
              property there. Conflict itself is weird but especially in the
              exact case.

   TabAtkins: box-sizing is too close to box-size
   dbaron: box-size and block-size might be confused by some.
   <tantek> indeed

   Rossen: What is the motivation here?
   TabAtkins: People want to set width and height together.
   florian: When people want to say something different they repeat themselves.
   fantasai: It's likely you'll want both to a keyword like auto or 100% or
             contain.
   TabAtkins: Equal sizing is reasonable.
   Rossen: The short shorthand is always going to give you squares.
   florian: If you do percent it will not.
   TabAtkins: Unless box-size 50% is same for height and width.

   fantasai: If we didn't have a naming conflict this would be in the spec
             already.
   florian: I'd ignore the naming conflict and say you can't use it in
            @page rule
   astearns: I don't like that because if you don't know anything about
             @page it's surprising.
   astearns: Here I've found I have to use it and the styles I set up
             perfectly are no longer good.
   florian: It's the code you wrote to size the page, that would be weird.
   <fantasai> @page { size: 8.5in 11in; }
   <fantasai> @page { size: letter; }
   rune: Page doesn't match any elements?
   florian: No.

   astearns: I'm thinking copying from another container.
   emilio: I think having a special-case for @page rule for page rule isn't
           worth it.
   astearns: First comment TabAtkins said is people have been asking for this
             and it would be mildly useful. I'm not sure mildy is worth it.
   fantasai: I've had people bug me for this. Those people are not sitting here.
   astearns: I'm not hearing consensus on using size or another name. I'm not
             hearing huge enthusiasm for solving this.
   astearns: Might be worth a note in the spec saying we've considered a
             shorthand and have not found enough motivation for dealing with
             the problems and outline what the problems are.
   astearns: Objections?

   RESOLVED: Add a note to the spec explaining this problem and move this issue
             to level 4.

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

   florian: Do we need a new WD?
   fantasai: Sure.
   astearns: Objections to a new WD of Sizing with all current resolutions
             edited in?
   <tantek> +1

   RESOLVED: Publish a new WD of Sizing with all current resolutions edited in.

Flexbox
=======

Min-content of shrinkable flex items
------------------------------------
   github: https://github.com/w3c/csswg-drafts/issues/2353

   TabAtkins: We made some edits and we need to WG to approve.
   Rossen: Can you go over the edits?
   <fantasai> https://drafts.csswg.org/css-flexbox-1/#change-2017-flex-min-contribution
   TabAtkins: Last comment in the issue has a link to the change.
   fremy: I need to process it.
   astearns: Anyone else want a summary?
   Rossen: Let's get back tomorrow. I want to look as well b/c I spent time
           working on this issue. We had a change fixing some edge
           inconsistencies with this problem. We had to back it out because
           it seemed others were inconsistant.
   fantasai: We went with dholbert's solution over fremy's.
   astearns: There's a 2nd layout section Thursday morning. Let's add this then

Table flex items with main size less than preferred intrinsic width
-------------------------------------------------------------------
   github: https://github.com/w3c/csswg-drafts/issues/2442

   TabAtkins: If you have a table that's flex item, the flex sizing algo
              tells it what size to be--but that's can be smaller then
              the table's min size. What happens? Edge and FF only use
              table sizing algo. Chrome flexes the table, but I'm not
              sure if it flexes beyond the minimum size.
   TabAtkins: fremy says table should flex and overflow to it's min size.
              I agree.
   astearns: Anyone disagree that tables flexed to smaller than their
             minimum size should overflow?
   fantasai: It should function a min-size constraint.
   TabAtkins: Does that happen?
   fantasai: We shouldn't be like the flex item is smaller then it actually is.
             If the table has a minimum size it should be reflected in the
             handling of minimum sizes in the algo.
   TabAtkins: If it has a specified size, content of 200px but width of 10px.
              It'll be 200px but we don't go down a path to look at the
              contents.
   fantasai: The table has a minimum size that's not reflected in min-size
             property's value. Max of specified min-size and min size from
             table layout should be the used minimum size.
   TabAtkins: Yes, that makes sense.

   dbaron: And only for auto layout tables?
   fantasai: Yes.

   Rossen: If width is specified it's still a min-width
   cbiesinger: Flex considers an explicit width as a min-width?
   TabAtkins: At all times tables cannot shrink below their min-content size.
   cbiesinger: Can you put that in the spec somewhere?
   TabAtkins: Sure.
   TabAtkins: Between flexbox and table spec we'll put this somewhere.
   fantasai: Used min-width of a table should consider the content of the table
             and then we make sure flexbox hooks into that correctly.
   astearns: We only want flex algo to key off used min-width for tables.
   fantasai: No reason for it not to in general. We just need to make sure
             correct terms are in flexbox and that tables has that concept.
   astearns: Used min-width isn't a term?
   fantasai: It is, but we need to make sure tables spec uses it.
   astearns: Used means layout has happened.
   TabAtkins: This is a flex item.
   rune: You need min-width before you layout flex item.
   TabAtkins: Sure. Tables need to do layout earlier.
   fantasai: Just calc min-content width.

   astearns: Prop: define what used min width is for tables to include the
             min-content constraint and make sure the flex algo uses that.
   astearns: That's the approach we're taking. Let's have you all come up
             with proposed edits.
   cbiesinger: Anything else have the used min-width?
   fantasai: No. Nothing else has a used min-width that depends on random
             other information.
   astearns: Anything more on this?
   RESOLVED: Tables defines used min-size to fold in its min-content size
             where necessary (for 'table-layout: auto'); Flexbox ensures
             it is hooked up to this terminology when looking up an item’s
             minimum size.

Flexbox Level 2
===============

   fantasai: TabAtkins and I suggested we draft L2 where it's flexbox 1 +
             the current set of alignment properties with all their values.
             Flexbox 1 only has a subset of alignment.
   fantasai: It's L1 + aligning keywords + gap properties so people can
             talk about it as a thing.
   TabAtkins: Technically you can read alignment and sizing and figure it
              out but this would be convenient.
   fantasai: We'd have to dup some parts of the algo to define gaps properly,
             but most we can say refer to current Flexbox. We're getting very
             stable so end of the year I think we can fold in the entire text.

   astearns: Flexbox level 2 would mostly be a diff spec?
   TabAtkins: It shouldn't be a diff spec ultimately, just Flexbox 1 with
              some extra stuff.
   fantasai: Basically normative references into flexbox and alignment and
             some normative text on how it combines with maybe some quotes
             from the algo. Then in the future we'll fold in all the text.
   astearns: Sounds like it would be best as an ED
   TabAtkins: Yeah
   fantasai: Yeah. Once alignment goes to CR we should have a WD.
   TabAtkins: Sure
   astearns: Objections to an initial ED of Flexbox L2?
   RESOLVED: have an initial ED of Flexbox L2

[TTML discussion goes here; extracted out for cross-posting]

Overflow
========

overflow: clip
--------------
   github: https://github.com/w3c/csswg-drafts/issues/1971#issuecomment-377078084

   florian: Missed the telecon where we discussed. We recently resolved
            overflow:clip does not trigger BFC. I think it failed to
            considered some of the things that implies.
   florian: The motivation that triggered adding to spec was usage in
            combo with contain: paint so you can have contain: paint
            with text-overflow or resize property. These only apply to
            overflow not visible elements.
   florian: We don't want to have contain:paint trigger overflow:hidden
            because UA might use too many resources.

   florian: If overflow:clip does not create a BFC, are implemenations
            comfortable saying resize and text-overflow apply to elements
            that are overflow:clip?
   TabAtkins: During discussion before we couldn't come up with a reason
              you'd want overflow without scrolling, this is the reason.
              There are properties that depend on things being non-visible.
   florian: Resize.
   fantasai: I think it doesn't matter for resize.
   <fantasai> and I think that 'text-overflow' should never have keyed off
              of 'overflow'
   florian: I'm not saying should not apply. but if we're going with “it's
            not a BFC” we also have a bunch of properties that should
            change to “not visible or clip”.
   dbaron: There were use cases for the opposite.
   TabAtkins: This is the use case for this situation. We only came up with
              use cases for the other resolution. Something that acts like
              overflow:visible but it's clipped.
   florian: Not affecting margin collapsing.
   TabAtkins: Or sticky or scroll-snap.
   TabAtkins: This is a reason for the opposite where it's like hidden but
              doesn't scroll.
   dbaron: They can't apply for text-overflow partly because this is a
           purely paint time effect.
   florian: This is also a purely paint time.
   fantasai: True.

   dbaron: I guess those two could maybe be changed to not include the
           visible. Nothing is like this because we've put “overflow
           does not equal visible” across all our specs where that's
           not what we mean.
   fantasai: I think a lot that key off “overflow not visible” key off
             if it's a BFC.
   fantasai: I think a lot of things are keying off that. There's many
             effects that key off of that and we don't have to change
             those specs. There may be some that don't, though.
   florian: That we need to rename was mentioned. If we clarify that
            it doesn't apply to text-overflow and resize that solve
            my first concern.
   florian: Are we okay closing that sub topic?
   astearns: Additional concerns?
   florian: Assuming we don't find another problem we can clarify the
            previous resolution to mean text-overflow and resize refer
            to non-visible elements.
   fantasai: To rephrase Florian without negatives, text-overflow and
             resize apply to elements with 'overflow: clip' just as
             they apply to elements with 'overflow: hidden'

   florian: The second concern was about what overflow:clip means when
            applied to the document or body element and propagated to
            the viewport
   fantasai: Same way we translate visible to auto, we translate clip
             to auto.
   florian: That's good.

   astearns: Resolve on both?
   astearns: Prop: text-overflow and resize apply to elements with
             'overflow: clip' just as they apply to elements with
             'overflow: hidden'
   RESOLVED: text-overflow and resize apply to elements with
             'overflow: clip' just as they apply to elements with
             'overflow: hidden'
   astearns: Prop 2: when overflow:clip is propagated to the viewport
             it changes to overflow:hidden he same way visible is
             changed to auto
   RESOLVED: when overflow:clip is propagated to the viewport it
             changes to overflow:hidden the same way visible is
             changed to auto

   astearns: You're fine with the resolution?
   florian: Yes. I'm mildly skeptical, but not objecting.

logical longhands for overscroll-behavior
-----------------------------------------

   github: https://github.com/w3c/csswg-drafts/issues/2473

   majidvp: There's a resolution to add overscroll inline and block
            which is reasonable.
   florian: We don't have a resolution on this. We have it on similar.
   astearns: Overflow vs Overscroll. Oooh.
   astearns: Objections to adding block and inline longhands to
             overscroll-behavior?
   RESOLVED: add block and inline longhands to overscroll-behavior

Let 'overflow' accept two values
--------------------------------
   github: https://github.com/w3c/csswg-drafts/issues/2484

   Oriol: It only lets you set overflow-x and overflow-y. It would be
          more convenient if it accepted two values. Then there was
          the question is the order should be physical or logical.
          As an example background-position is x and y. It will
          prserve physical order. There's another issue looking to
          switch longhand and shorthand into physical order.
   florian: Other is issue #1282 which discussed adding logical
            keyword to all places currently phsycial.
   astearns: Separate from that switch, do we let overflow accept 2 values?

   astearns: Concern about changing this?
   astearns: Weird mistyped declarations may now have an effect?
   florian: I suggest we presume that's rare and if it's a problem we raise it
   florian: A more consistant system where they all have shorthands and
            they're physical.
   astearns: Prop: Allow overflow to have two value and for the ordering
             to be physical.
   iank: Which order?
   emilio: x and y.

   dbaron: Question: There are sets of values transformed into other values.
           If x is visible and y is scroll we make scroll into auto.
           Should those combos be syntatically valid for shorthand?
   myles: Related that this shorthand shouldn't allow new functionality
   dbaron: Transformation would still happen. I'm thinking a it would be
           nice if it rejected but it's not possible because serialization
           problem. Because then values could not serialize to shorthand.
   emilio: Happens in a lot of places.
   dbaron: I guess it's not really a serialization problem. Do we want the
           things that are not going to be valid in the end be parse errors?
   emilio: I think it would be weird if spec shorthand would yield different
           results.
   myles: You set the shorthand and it's rejected and that's different that
          if you set the 2 longhands.
   florian: You have a minifier and it takes the 2 longs and puts them to
            short and that's a parse error.

   astearns: I would prefer let you set the shorthand to whatever and
             letting it transform.
   florian: I don't think we gain by forbidding these.
   fantasai: If you serialize out computed values it's always valid anyway.
   florian: What do we gain by forbidding?
   dbaron: Reject things that don't makes sense.
   florian: Makes sense when you transform.
   dbaron: CSS tries to reject things that don't make sense.
   fantasai: Would be nice if a validation tool flagged this as a warning,
             regardless.
   astearns: Computed value shows something changed.
   fantasai: That always happens.

   emilio: [missed]
   fantasai: Tranforming em to pixel doesn't show you've got a problem in
             your style sheet.
   astearns: I'm not certain having a transform apply implies there's a
             problem in your stylesheet.

   fantasai: rachelandrew?
   rachelandrew: I don't have an opinion.
   florian: Stylesheet maintenance it's strange.
   myles: Have we never encountered this?
   fantasai: Almost for display but we made all meaningless combos invalid
             and got rid of the longhands.
   emilio: Outline style stuff which when you have hidden outline and the
           line-width becomes 0.
   astearns: Anyone have a concern with allowing whatever combo we specify?
             Anyone object to taking what we get and transform?
   astearns: Prop: Allow 2 values on the overflow property in physical x/y
             order in any existing values.

   myles: What a combo authors want with different keywords?
   astearns: hidden x auto in y.
   myles: So only one scroller.
   astearns: People use overflow x and y in various situations and it's just
             that it would be nice to let them use the shorthand for both.
   rune: If you have visible overflow in x and y you get visible.
   florian: Transformed to auto.
   myles: Hidden and auto are okay.
   astearns: Objections?
   RESOLVED: Allow 2 values on the overflow property in physical x/y order
             for any existing values.

   astearns: we're done for the day.

<RRSAgent> https://www.w3.org/2018/04/10-css-minutes.html
Received on Friday, 27 April 2018 21:29:43 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 April 2018 21:29:44 UTC