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

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

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 26 Apr 2018 23:23:01 -0700
To: "www-style@w3.org" <www-style@w3.org>
Message-ID: <a13da408-7f2b-df22-ffdd-1f391bce557a@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.




   - 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.



   - 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.



   - 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'


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

Scribe: dael



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


   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


   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.



   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.



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


   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: 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


   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


   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,


   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 06:23:32 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 April 2018 06:23:32 UTC