W3C home > Mailing lists > Public > www-style@w3.org > February 2013

[CSSWG] Minutes Tucson F2F 2013-02-06 Wed AM II: multi-col shrink-to-fit

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 19 Feb 2013 21:17:38 -0800
Message-ID: <51245C72.2030100@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Fonts LC Plans
--------------

   - Plan for 6-week LC after this next WD cycle.

Multi-col Column Sizing Pseudo-algorithm
----------------------------------------

   - RESOLVED: Remove lines 3-10 of pseudo-algorithm in multicol,
               remove concept of available width and have pseudo-algorithm
               depend on used width (whose calculation is defined elsewhere
               by container layout modules), state that intrinsic sizes of
               multi-col elements is undefined in this level, add note
               pointing to where they will be defined (css3-sizing).

====== Full minutes below ======

Fonts LC Plans
--------------
Scribe: Bert

   jdaggett: What should the LC period be?
   jdaggett: It's a big spec
   jdaggett: 6 weeks? 2 months?
   fantasai: no more than 6 weeks
   fantasai: You can do a 2nd LC
   jdaggett: So plan for 2 LCs?
   fantasai: Can also offer an extension after a while.
   dbaron: And wait a bit after the deadline
   dbaron: because there will be late comments.
   glazou: Officially not obliged to respond after deadline.
   glazou: But in practice...
   jdaggett: So 6 weeks then
   jadggett: Aks Webapps, SVG and i18n for cooments
   fantasai: LC or WD first?
   jdaggett: First a WD.

Multi-col Column Sizing Pseudo-algorithm
----------------------------------------
Scribe: fantasai, jdaggett, & dbaron

   SimonSapin: Discussed multicol at TPAC
   SimonSapin: Problem with pseudo-algorithm, which has concept of unknown
               available width, and I don't think it makes sense
   SimonSapin: Don't see a situation in which that happens
   SimonSapin: After long discussion with Håkon and Bert, f2f and email,
               still don't have a resolution
   SimonSapin: Underlying issue is that from what I understand from Bert's
               explanation,
   SimonSapin: this condition is triggered when you calculate intrinsic
               sizes of a multicol element
   SimonSapin: The issue then is that we have two definitions of this
   SimonSapin: One in sizing, one in box
   SimonSapin: But whichever we pick, neither of them defines available
               width == unknown

   Bert: Multicol relies only on level 2
   Bert: And CSS2.1 doesn't define shrink-to-fit in many cases
   Bert: So cases where it's shrink-to-fit are undefined
   Bert: Multicol cannot defined actual size of columns because it relies
         on shrink-to-fit algorithm
   Bert: And multicol doesn't want to define it either
   Bert: need a sizing algo ot define shrink-to-fit
   fantasai: it would make sense for multicol to say that in a shrink-to-fit
             situation, the number of columns and width are undefined
   fantasai: ... and then deal with that in a later module
   szilles: Could add a note pointing to where the definition might appear,
            or a suggested strategy
   dbaron: I would rather partially define it than say it's undefined
   Bert: It defines what the final width if you have both number of columns
         and column width
   Bert: If either one is missing, then can't calculate

   fantasai: shrink-to-fit in CSS 2.1 tries to calculate the size incorporating
             the widest size it can take, the narrowest size it can take,
             and the available size
   fantasai: Saying the multicol is exactly the column-width times column-count
             violates that formula
   fantasai: the narrowest a multi-column element can take ... drops columns
             rather than overflowing
   fantasai: ... when the window is narrow... so you stay within the
             containing block
   fantasai: The formula that says you multiply the width by the column
             count violates the shrink-to-fit formula.
   Bert: If you set the column width and column count, that's what you should get
   fantasai: But you don't get that

   <SimonSapin> http://dev.w3.org/csswg/css3-multicol/#pseudo-algorithm
   <SimonSapin> lines 5~8
   bert: discussing col-width and number of columns
   simon: bert is talking
   bert: 8 possible cases
   bert: this alg is trying to compactly specify this
   simon: so you're saying in the case of mult-col with width this alg applies?
   bert and simon talking about 2.1 vs. this alg
   simon: this is contradiction with 2.1 alg
   <SimonSapin> http://www.w3.org/TR/CSS21/visudet.html#float-width
                "The shrink-to-fit width is:
                 min(max(preferred minimum width, available width),
                     preferred width)."
   <SimonSapin> Floats: "If 'width' is computed as 'auto', the used value
                is the "shrink-to-fit" width. "

   dbaron: other specs shouldn't talk about shrink to fit
   dbaron: they should talk about preferred intrinsic width and minimum
           intrinsic width
   dbaron: They should talk about preferred minimum width and minimum width,
           which are the inputs to shrink-to-fit
   fantasai: i agree with dbaron
   fantasai: they can use shrink to fit but they shouldn't define it
   dbaron: shrink-to-fit is simply
           max(minimum intrinsic width, min(preferred intrinsic width, available width)).
           That's it.  Everything else should define the intrinsic widths.

   Bert: so min intrinsic should be column-count * column-width
   <Bert> (lines 05-08 effectively say that the min intrinsic width is
          N * W + (N - 1) * gap)
   fantasai: But it shouldn't be, because it won't overflow if it's smaller
             than that.
   fantasai: ... since a multicol can be narrower than that without overflow
   bert: the user says I want that width, so that's the min width
   dbaron: There are cases where it is appropriate for a minimum width to
           be something other than the smallest without overflow.
   fantasai: You can't define table layout sensibly if you define it some
             other way
   dbaron: We could decide that it's better for the minimum intrinsic width
           to use or ignore column count
   dbaron: Doesn't have to be strictly in terms of what causes overflow,
           because that's a primitive and incorrect definition
   bert: dbaron is correct but that's what we did in multi-col
   simon: so the multi-col is defining min-width
   bert: yes, should mention that...
   Simon: I see no relationship between what's written and defining minimum
          intrinsic width

   simon: so what is max-width?
   dbaron: In case where column width and column-count are both specified,
           max-content should include both of them
   dbaron: More interesting if some aren't specified
   fantasai: tab and I worked through some examples for flexbox
   fantasai: since we use these concepts everywhere
   http://dev.w3.org/csswg/css3-sizing/#multicol-intrinsic
   fantasai: and we wrote a spec for that, which is not consistent with
             what multicol sys
   stevez: section 19-23 talks about behavior

   jdaggett: Seems like multiple specs are involved; should there be an
             action on Bert, fantasai, Simon, dbaron to decide what should
             happen where?
   fantasai: I think the problem is we've brought this up at every
             face-to-face and there's no agreement.
   fantasai: happens repeatedly at f2f
   fantasai: Maybe would help if dbaron got involved?
   SteveZ: Is the disagreement only on min? clear what preferred is.
   simon: can we agree that multi-col should not define min-content or
          max-content widths?
   simon and bert discussing which spec should define this

   <SteveZ> lines 19-23 define what happens when all three of available-space,
            column-count and column-width are specified. This section clearly
            states that column width is preserved (as much as possible) and
            columns are eliminated (up to the last column). This suggests
            that the min-intrinsic-width should also be defined without regard
            to the column count; that is, it should be the width of 1 column

   Bert: The sizing spec would then have to define every type of box,
         and thus never be done.
   fantasai: sizing spec would define concepts and define sizing for css 2.1
             types and multicol, and new layout types would define min content
             and max content widths for itself
   fantasai discussing size vs. box specs
   fantasai: but multicol is already in CR
   Bert: I agree with that, but multicol cannot completely define things
         without knowing intrinsic widths of what's inside

   stevez: if i have a col width, then that is the min intrinsic width?
   fantasai: Multicol can assume that the things inside the columns have
             preferred intrinsic and minimum widths
   fantasai: yes
   fantasai: multi-col is tricky
   fantasai: sizing dealt with what happens when the containing block varies
   fantasai: and we put results into the definition
   fantasai discussing relation with table sizing alg
   fantasai: figuring out the rules for preferred and minimum intrinsic
             widths was an experimental process of seeing how its layout
             rules behave at different widths

   szilles: So special thing wrt multicol is that the optimal width is
            neither minimum nor the maximum
   stevez discussing details of multi-col alg
   fantasai: You almost never get exactly the column-width you asked for.
   szilles: Wrt getting 2.1 shrink-to-fit, there's no harm in throwing away
            the column count
   szilles: and doing the right thing to get the smallest value
   stevez: don't see the harm in throwing away column count
   fantasai: that would make it fit as the screen size changes
   bert: that's the author's choice
   fantasai: If you include column-count in minimum intrinsic width,
             you'll get overflow when a multicol happens to be in a float,
             but not in normal flow.
   fantasai: for an in-flow block you don't get what you ask for
   fantasai: So we should do the same thing for floats, and not include
             column-count in the minimum intrinsic width.
   <dbaron> I think fantasai is correct that column-count shouldn't factor
            into minimum intrinsic widths for multicols.
   <fantasai> dbaron, well, it should if column-width is not specified,
              because then you don't drop columns...
   <fantasai> dbaron, but if both are specified, yes

   stevez: calc min width, then apply 19-23
   bert: that could have been a choice
   bert: it's easier to use what multi-col does now
   stevez: this is the argument if what you want is overflow
   fantasai: I don't think we should overflow by default in some cases
             when the normal behavior is not to overflow.
   fantasai stevez bert discussing details of the multi-col algorithm

   Bert: This case isn't the important one, could go either way, tho would
         prefer not to change it
   glazou: simon is not happy with one of the specs, we have to solve
   Bert: Interesting cases are the next two
   simon: Issue is with concept of unknown available width in the
          multicol module
   SimonSapin: I'm objecting to the way it's done in multicol right now
    Steve: the results or the way it's specified?
   simon: how it's specified
   fantasai: i don't like the results
   dbaron: i agree with both objections, how it's specified and the results

   dbaron: I'm not happy with removing intrinsic width stuff from multicol,
           but it seems like the only way out is to remove instrinsic width
           details from multi-col
   simon and bert discuss dependencies of algorithm in different specs
   sizing solves all?
   fantasai: remove from multi-col and work on in sizing
   fantasai: it's an early WD so we can incorporate other layout models
   fantasai: that's what's needed
   bert resisting
   fantasai: I want to take the fixes that were proposed by simon
   simon: the changes from TPAC leaves some things undefined, to be defined
          by sizing
   Simon: Changes I proposed were to remove all the parts of multicol
          algorithm related to "unknown available width"
   bert resisting
   stevez: to be clear, you're saying remove 5-8 and width alg in sizing?
   Simon: I want to remove the idea that available width can be unknown.
   dbaron: There is and should be no concept of "unknown available width".
   discussion of where available width is
   dbaron and bert discussing widths some more
   and so on and so on...

   dbaron: Everything about width depending on content should be encapsulated
           in min-content/max-content width, and there's no concept of
           unknown available width
   repeat while (true) discuss width;
   discussion of unknown available width
   dbaron: the rules for preferred and minimum intrinsic widths don't deal
           with a concept of available width
   dbaron: the rules for intrinsic width calculation should be separate
           from that algorithm, and there should be no concept of "unknown
           available width"

   SimonSapin: Where multicol says "available width", it should say "used width"
   SteveZ: Can we resolve to switch multicol from an 8-part algorithm to
           4-part algorithm?
   bert: now we're making things more undefined
   simon: yes
   <sylvaing> CSS: now with more undefined

   glazou: the discussion is going in circles
   stevez: throw out the cause of the disagreement and procede
   stevez: not ideal but practical for proceeding with the CR
   discussions of scope of multi-col pseudo-alg
   bert resisting

   fantasai: Scope of the pseudo-algorithm should be to calculate the number
             and width of the columns
   fantasai: It should take as input a used width (calculated by the various
             layout algorithms as appropriate), column-count, and column-width
   Bert: That's what it does already
   fantasai: No, it tries to calculate a width in some cases
   fantasai: it should not do that.
   SimonSapin: This algorithm does 2 things. I am proposing to move one half
               into sizing or another module
   SimonSapin: These two things are really different, and confusing to do
               them both with the same algorithm

   bert: might well be but how do we keep track
   bert: why not do in multi-col?
   stevez: doesn't seem to make sense to do in multi-col
   dbaron: any layout type can define these independently
   dbaron: I don't see any reason to pull it out of this module except that
           the definition in css3-multicol is unreasonable.
   simon: could have in multi-col but hard to get right before CR
   rossen: sizing defines intrinsic sizing?
   bert: yes but can't define for all layout types
   simon: that's another issue
   bert: sizing alg can only do that for known layout types
   fantasai: they can use the terminology from sizing
   stevez: we haven't finished sizing yet
   stevez: so trying to define what multi-col does doesn't make sense
   dbaron: I think the multicol intrinsic sizing rules are simple enough
           that you can use the 2.1 terminology without any problems I think
   bert resisting
   fantasai: But (1) it's going to take a lot of work to get this right,
             and (2) the people working on it are not considering interaction
             with other layout modules.
   fantasai: makes more sense to tackle them together in sizing
   bert thinking
   <dbaron> SteveZ: can we import the text from css3-sizing into multicol?
   fantasai: Not stable enough yet for a CR-level module.
   fantasai: We can incorporate it into level 2 of multicol.
   stevez: the text in sizing wouldn't work to replace 5-8?
   fantasai: wouldn't do the same thing

   fantasai: might need to add more concepts to deal with both tables and floats
   bert: I could try rewriting this in terms of preferred intrinsic sizes
         defined in 2.1
   fantasai: better to file comments on the sizing spec
   fantasai: need to understand what the sizing spec is trying to solve
   bert: not sure that this fits the bill
   fantasai: Might need to have e.g. separate concept of preferred size vs.
             max-content size for multicol elements
   glazou: need to wrap up

   stevez: we're arguing over whether there's something in the multi-col
           spec that talks about intrinsic width
   fantasai: that's not a good idea
   bert: should ask implementors whether that's okay
   glazou: what's the plan?
   fantasai: remove 3-10 in the multi-col algorithm
   fantasai: then remove the concept of available width
   fantasai: define in terms of used width
   fantasai: then it becomes an issue on sizing
   fantasai: accept or reject?
   bert thinking
   bert: we have to ask some people first
   bert: not objecting but if we remove it's a pity
   stevez proposing a and b points to add to multi-col
   stevez: a is intrinsic size is not defined in multi-col
   stevez: b is to add a note that it'll be defined in sizing (or some
             other non-normative place)
   stevez: this is editorial so we can update
   bert: ok, so I'll propose new text

   RESOLVED: Remove lines 3-10 of pseudo-algorithm in multicol,
             remove concept of available width and have pseudo-algorithm
             depend on used width (whose calculation is defined elsewhere
             by container layout modules), state that intrinsic sizes of
             multi-col elements is undefined in this level, add note
             pointing to where they will be defined
   Bert: I'm not sure who'd do the actual editing, but Håkon has generally
         asked me to write the text for this section.
   ACTION Bert: Propose text for the resolution above
   <trackbot> Created ACTION-539

<br type=昼飯>
Received on Wednesday, 20 February 2013 05:18:14 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:06 GMT