W3C home > Mailing lists > Public > www-style@w3.org > November 2012

[CSSWG] Minutes TPAC Mon 2012-10-29 AM II: Regions, Multicol

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 13 Nov 2012 22:50:20 -0800
Message-ID: <50A33F2C.7020507@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>


   - RESOLVED: Close issue 15186 in Regions, concerning handling arbitrary
               amounts of content in a region chain.
   - RESOLVED: bug 15824 - keep the current spec text, where regions all
               create stacking contexts for the stuff flowed into them.
   - Discussed issue of elements becoming regions; agreed to leave it open.
   - RESOLVED: Need to split the ICB concept into two parts, as necessary
               for the different things the ICB is currently used for.

Multi-column Layout

   Discussed rules for sizing "available-width == unknown", what that
   means, and whether various parts of the sizing pseudo-algorithm
   should be removed. No conclusion.

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


   <stearns> http://lists.w3.org/Archives/Public/www-style/2012Oct/0304.html
   stearns: First issue is box generation.
   stearns: I posted how I think this issue should be handled in the spec.
   stearns: I don't think box generation is required for CSS regions.
   stearns: The issue is how to handle more content than will fit in a fixed
            region chain.
   stearns: We've added auto-height regions and the regions processing model
            to address this.
   stearns: So handling more content in a region is the same as in any other
   stearns: So I'd like to close this issue.

   howcome: Examples?
   stearns: The very first example in the spec has an example - the last
            region is auto height and will just take the rest of the flow.

   howcome: What about pagination?
   stearns: No effect on printing - it'll break across pages just like a
            normal element.
   stearns: I got one response on the list from Anton saying it was reasonable.

   howcome: What dimensions does it expand?
   stearns: Same as an auto-height div.
   stearns: The email goes into what you can do with the last region - you
            can make it auto height, scrollable, overflow:visible; everything
            you can do with a normal element.
   TabAtkins: I'm satisfied that this concludes the issue - the last region
              in a chain is no longer restricted, and you can do everything
              you can do with a normal element.

   stearns: The issue as stated is that region chains can't handle a variable
            amount of content. At the time the issue was raised, this was
            true.  It's no longer.
   stearns: We could close this issue and let you raise further issues.

   fantasai: Can you have a region in the middle of the chain that's
             auto-height with a max-height, where it overflows to the
             next region in the chain?
   stearns: Yes, that's what the processing model now addresses.
   RESOLVED: Close issue 15186 in Regions, concerning handling arbitrary
             amounts of content in a region chain.

   Rossen: Can you swap css3-ui with something in the afternoon?
           I'm waiting for Tantek and Sylvain.

break-duration: calc(15 * 60s);

Regions (continued)

   Alan: 3 issues left
   stearns: The draft currently says that Regions create their own stacking
            contexts. There's an issue on the draft that perhaps we shouldn't
            do that, and allow them to be non-stacking.
   stearns: My contention is that regions should behave more like the things
            that *do* create stacking contexts, like fixpos/flaots/etc,
            because we are taking content out of the flow and putting it
            somewhere else.
   stearns: Same justification for those applies to Regions.  Little case
            for interleaving content.
   dbaron: Floats actually create a pseudo-stacking context.
   antonp: I don't think authors like stacking contexts.
   hober: I think most authors don't know what a stacking context is, and
          when things interleave in weird ways, that's funky behavior.
   hober: Will probably result in performance issue, which we can avoid...
   hober: I don't think authors would interleave on purpose.
   antonp: The reason the funny painting model exists is because people
           had overflow they weren't expecting; floats and next paragraphs
           and etc.
   antonp: That's why text is painted after all background/borders/etc.
   antonp: Makes overlaps less painful.
   antonp: So it was historically because there was a lot of overflow,
           and impls thought it was better to see content.
   dbaron: I'm not sure it was that logical of a process.
   dbaron: There's a decent chunk that was Hixie and I interpreting a vague
           chunk of the spec, and coming up with the one precise definition
           that satisfied it, then wrote tests and got impls, and that was
   dbaron: Never really learned how much of that was intentional.
   dbaron: The spec never quite said that the backgrounds of the next
           paragraph drew under the text of the next paragraph, but you
           could infer it from a rule about floats, which was similar.

   dbaron: The thing I'm slightly worried about is...
   dbaron: You're talking a region being a stacking context?
   dbaron: Each region?
   stearns: Each region is a context for the fragment of the flow in it.
   dbaron: My problem is when people put regions close to each other to
           give the illusion of continuous flow
   TabAtkins: Like using them to make a "non-rectangular grid cell".
   dbaron: yeah.  But I think there might be weird issues now.
   stearns: That's only a problem if they break outside of the bounds of
            the region.
   dbaron: Not necessarily rare, with text slightly overflowing, etc.
   dbaron: Don't have a strong opinion, but I'm a little worried about
           that case.
   stearns: I'm not really sure what to say about that case.
   Rossen: No real opinion...

   Rossen: From the pov of having valid use-cases for where it's really
           interesting to have interleaving, we struggled to find such a
   Rossen: The one David is bringing up is somewhat valid for the content
           being laid out between the regions themselves.
   Rossen: It is more interesting to see how the rest of the content
           outside the regions interacts with the content inside.
   Rossen: This is why we'd prefer regions being their own stacking context.
   Rossen: So you don't have weird interleaving between parts of the regions.
   antonp: I buy that point.
   antonp: I'm kinda thinking, you got stuff flowing down the left, you got
           regions on the right, and you're directing flows through each,
           and if you've got a long word on the left it'll interleave with
           what's on the right.

   antonp: What about a pseudo-stacking context, so abspos doesn't have to
           be constrained by it?
   TabAtkins: I think that limiting abspos is actually an important part
              of it.
   szilles: This seems a bit like the problems of composition in SVG -
            they introduced groups to denote what things are part of
            "the same thing" versus a different thing.
   szilles: Conceivably one could introduce a similar property that groups
            things like that.
   TabAtkins: Like explicitly turning on stacking contexts without side
   szilles: No, other way around. Declaring that some stacking contexts are
            part of a group, so within that group they can interact, but
            they're still shielded from the rest of the group.

   Rossen: To add to this, it becomes more apparent once you bring content
           that's not quite in the same document into regions.
   Rossen: Then you have content from separate documents that can interleave.
   TabAtkins: You're talking about IE's addition that lets them flow iframes
              into a region flow?
   * hober runs screaming from the room (re: region flow sourced from <iframe>)
   Rossen: Yeah. You don't want an iframe to be interleaved with anything
   antonp: At the very least that says you want pseudo-stacking contexts.
           It doesn't necessarily talk about abspos.
   antonp: abspos is a weird beast.  But when people use it, they get
           frustrated that you can't choose where things are positioned from.
   antonp: By locking it into the region box, it seems you're taking away a
           little of the freedom they otherwise have.
   TabAtkins: There's a workaround - flow the abspos into *another* region
              chain, and flow-from it somewhere outside higher in the document.
   Bert: That loses the auto position, though.
   TabAtkins: If you're using the auto position, you probably don't need to
              worry about stacking context.

   Bert: Most of the time when I use regions, I started using columns,
         then found a weird case, and had to replace the columns with regions.
   Bert: That means that I'd like them to act like columns.
   glazou: [something about columns across pages, and how regions would work
            the same way maybe?]
   Bert: Point is that I'd like columns to act the same way as regions.
   stearns: So that's an argument for Steve's suggestion - the ability to
            group contexts together.

   dbaron: So you say that having flow-from on an element makes it a stacking
           context automatically?
   stearns: yes, that's part of the spec right now.
   stearns: I have been arguing both sides of the issue with my team for
            months now, and I think I've come down on the side of stacking
   stearns: Possibly with a future mechanism to aggregate stacking contexts.
   TabAtkins: I'm cool with that.  I just don't want automatic grouping,
              from a performance standpoint.
   stearns: Hyatt's doing some work with identical regions, which might be
            relevant there.
   stearns: So, are there any objections to keeping what the spec currently
   stearns: (I was arguing for the opposite position in my team, and I lost
            the argument)

   Bert: It doesn't sound quite right - it's like an implicit relpos, which
         limits what you can do with abspos.
   TabAtkins: I think that there are enough implicit positioning containments
              already that we can argue this is a general limitation of
              *abspos*, not of any individual other spec, and should be fixed
              in abspos properly, by letting you override what you're
              positioning relative to.
   antonp: Bear in mind that we're not just talking about positioning, but
           also painting.
   antonp: If in the future we're going to let you throw your positioning
           root around, you're also changing painting.
   TabAtkins: yeah, you're more or less moving it in the box tree.

   Bert: Another comparison is with shapes - if you can make two regions
         and flow between them, or put a shape on a single paragraph that
         duplicates the same size, why do those act differently?
   antonp: To be fair, you'll have different behavior anyway - the
           fragmentation is probably going to be different anyway.
   Rossen: Currently in shapes there's nothing talking about this.
   Rossen: In the multi-shapes section, we're allowing multi-shapes.
   Rossen: Like if you extract a shape from an image, and it creates two
   Rossen: The spec currently says its allowed, but doesn't define how it
   Rossen: Making a comparison based on that right now is a bit premature imo.
   Bert: maybe, but the examples I worked through often didn't matter -
         I could use multicol or regions, shapes or regions, they worked
         roughly equally well either way.
   Bert: So I thought that if they were so similar, they should perhaps
         all be the same.
   Bert: With their own possibilities, but the common elements should be
         the same.
   stearns: If we have stacking contexts, the only part that might be
            different is that content that overlaps at the boundaries
            might get painted over.
   stearns: That seems like a tiny edge-case for me. You generally avoid
   Bert: I was thinking about abspos, actually.
   Bert: But I'm not sure how important it really is.  I generally use
         abspos only as a last resort.
   stearns: It's certainly a limitation, and that's why I argued against
            it with my team.
   stearns: But finding use-cases where you want interleaved content...

   stearns: From another direction, in all the use-cases we looked at,
            when you *have* interleaving, you always *want* a stacking
            context to prevent that from interleaving accidentally.
   TabAtkins: So most interleaving is accidental and would benefit from
              stacking contexts, and the cases where it might be good
              are a corner-case, which might be best addressed in the
              future by a specialized property to group stacking contexts
   antonp: So are columns changing any?
   stearns: No.
   szilles: You'd need later to define that the stacking-context-grouping
            property auto-groups columns by default.
   arronei: Does it become a stacking context as soon as flow-from is set,
            even if it has no content?
   stearns: Yes, but then there's no content to be stacking-contexted.

   antonp: There was a comment from Hyatt about how content that flows
           through a region physically belong to the region.
   antonp: Is this true, or does the content just flow through the space
           of the region?
   stearns: I think that's relevant. If you're defining Regions to have
            stacking contexts, then it's the principle box of the Region
            that contains them, and the fragments of the flow are children
            of that in the box tree.
   antonp: Hyatt has said that would significantly complicate his
   stearns: He's gone back and forth on the issue.  Not sure where he is
            on the issue right now.

   Rossen: I'm having a little trouble understanding what "physically
           belongs to" means.
   Rossen: Our model so far is that content flows through the region,
           and the regions are little viewports through which you view
           the content.
   Rossen: As you interact with the region, you change how much content
           is in each region.
   Rossen: But that doesn't mean actually changing the content in the
   Rossen: That complicates region styling.
   Rossen: Region styling has proven to be complicated for that reason.

   TabAtkins: Wrong level of discussion.  Are the box-tree stuff from the
              flow children of the region's box?  Or are they independent
              and just happen to be rendered with a geometric restriction
              that makes them look like the same?
   Rossen: The former (though it's complicated).
   antonp: Makes sense - otherwise you get weird effects with things like
           a float "belonging" to another box entirely, which changes the
           rendering order.
   Bert: Is this similar to the relationship between lineboxes and inline
   TabAtkins: Yes, very similar.
   stearns: Especially given the connection with styling ::first-line.
            Same exact problem as region styling.
   stearns: So back to the issue at hand - stacking contexts.  Yay/nay?
   dbaron: I don't have strong opinions.  I don't think we have a strong
           performance reason to prefer full stacking context versus pseudo.
           But I'd have to ask roc about it.
   Rossen: I don't think performance is a strong reason to make a decision
           either way.
   TabAtkins: yeah, not strong, but an input.
   Rossen: Right.  I'm hearing, though, that some impls prefer it for
           performance reasons, and some don't care.
   RESOLVED: bug 15824 - keep the current spec text, where regions all
             create stacking contexts for the stuff flowed into them.
   howcome: [something along the lines of I'm not sure whether pseudo-stacking
             contexts would be good enough, rather than full stacking contexts]

   <stearns> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16858
   stearns: Should creation of regions from elements be disallowed?
   stearns: This came up about a year ago.
   stearns: I think there's a good reason to have this.
   stearns: It can inherit part of the structure of your document.
   stearns: Particularly for scripting/events.
   stearns: I think we should have the ability to flow it into css-created
            boxes, but we shouldn't disallow this.
   TabAtkins: This is completely the issue I was talking about yesterday,
              with changing over to dbaron's proposal.
   stearns: Actually, you were doing an either-or.  Either do dbaron's thing
            (no explicit region flow at all) or do Regions thing (explicit
            flow, with elements and such).  So I'd like to resolve that,
            *if* we do that latter, we can use elements.
   TabAtkins: I'm fine with that.
   TabAtkins: I'm not happy about being forced to use dummy elements, but
              it's better in my book than the alternatives, given the lack
              of dedicated pseudo-element creation right now.
   stearns: There's an example by implication in note 3 about how you don't
            necessarily have to use dummy elements.
   howcome: ...
   <dbaron> (Tab also said something unminuted after the "howcome: ...")
Scribe: divya
   TabAtkins: we don't need to handle eventing on pseudo-elements
   TabAtkins: if we end up going with current regions proposal there are
              a lot of things that won't work well and won't work accessibly
              if we just stick to pseudo elements
   <stearns> http://wiki.csswg.org/spec/css3-regions/regions-use-cases#converting-hard-breaks-to-named-flows
   TabAtkins: if we go with dbaron's proposal we will still have …
   howcome: if we need the DOM thing, then put up a proposal for that.
   glazou: you raised a problem then why don't you do it?
   howcome: I don't have dom issue.
   glazou: this is lower in priority.
   glazou: I am just saying people like regions given …
   howcome: I am never going to agree to a solution based on dummy html
            elements. You are not going to get my okay for that.
   TabAtkins: I use dummy html as wrappers all the time, it is going to be
              necessary sometimes.
   howcome: You are creating a separate structure next to content structure
   stearns: that visual structure in a lot of interesting pieces has to have
            a structure, you have to have nesting in child-parent rels
   stearns: one of the args against … is that you are reinventing html in css

   glazou: when you do TOCs and extract them, you do want elements.
   * fantasai suggests adopting XSLT as a solution this ;)
   <Bert> (HTML could add a <toc> element.)

   stearns: it is quite similar to what is being done in SHADOW DOM
   stearns: You have an insertion point that is an empty element in your
            shadow dom tree. That seems to be something people want as well.
            We are providing a similar facility.
   TabAtkins: the point of shadow dom is recognizing that you need dummy
              elements and taking them from the main flow.
   stearns: in MS you have two separate html documents you have content and
   howcome: I don't think you can make the argument that they are semantic
   howcome: we need representation of visual structure, we should not abuse
            html documents for that.
   SteveZ: I am sorry visual structure is semantic
   TabAtkins: philosophically opposed but not practically opposed
   <Bert> q+ to say using an external (XML) document for the visual structure
          is a different case again, and OK

   howcome: building on what you said, if we agree on going David's way we
            should do that.
   TabAtkins: within option b lets not screw around and allow that, as it
              is required for regions proposal to work well.
   howcome: it is not well defined if it requires html
   [lots of arguments]
   glazou: authors already use elements for layouts.
   glazou: they will continue to do it
   TabAtkins: my arg is that strictly speaking, what stearns suggests is
              an improvement over what we have right now.
   TabAtkins: you would have to explicitly break contents between the
              elements right now.
   TabAtkins: you have same divs sitting around, but you get better semantics
              with the content and more reliable styling.
   howcome: Things break as soon as you change the font size.
   dbaron: The "strictly better than right now" is assuming that people will
           do things in the same proportion to the rate they do them right
   dbaron: But having this ability will change the rate at which people do
           such things.

   <divya> fantasai would you like to take over
   <fantasai> not really :)
   <fantasai> but could if you want
   * divya has lost a few seconds
   * fantasai doesn't think anything was lost, it's all in the minutes
              from February ;P

   TabAtkins: if we are selecting columns you are using pseudo elements
   TabAtkins: there is no reason to cripple the alternative right now.
   TabAtkins: if we don't need it then stop caring about it.
   glazou: all specs rely on implementation in the long run, if we don't
           have 2 impl. then it would go away.
   SteveZ: people being forced to divide content to make it look like what
           it looks like.
   SteveZ: you have restructured it in a form that defeats accessible access
   SteveZ: you want to show content for different devices and you can't do it.
   SteveZ: html as a suitable lang to express viz structure, it is possible
           to explore restricting the use of regions to page templates and
           in that context require they be empty boxes
Scribe: TabAtkins
   howcome: I think the page template proposal is much more sensible in
            that regard.
   szilles: In that case regions would end up with addressable things -
            we'd get CSSOM access to them.
   stearns: The OM stuff is in a separate spec entirely - the pseudo spec
            Daniel and I are doing.
   szilles: The main reason for this is exactly what Tab said - from a
            practical viewpoint, elements work today, and they're eventable/
            scriptable/etc. This needs to be there for a lot of use-cases.
   szilles: If you're paginating a complex structure, you don't know what
            the use-cases are today, and we won't know what they are until
            we see them in the wild.
   szilles: You can come up with a few simple rules, but they don't
            generalize right now.

   <Zakim> Bert, you wanted to compare regions with columns and to say using
           an external (XML) document for the visual structure is a different
           case again, and OK
   Bert: Two remarks.
   Bert: I've been waiting for regions for 15+ years.
   Bert: If we're waiting for events to be defined on them, cool, let's do
         that.  If it takes a year, okay.
   Bert: going back to an example from Alan was using an external document
         to define the regions. This seems fine to me as well, as long as
         those extra element are clearly marked as being in a document which
         is defined as being for layout, not meaning.
   stearns: Certainly something MS has been working on - content in one doc
            and visual structure in the other - and we've been doing
            experiments with Shadow DOM, with similar effects.
   stearns: Either way, they're separated from the meaningful HTML.
   * sylvaing "CSS Regions: they work in practice but fail in theory"

   glazou: I was speaking at the Paris Web Conf last week.
   glazou: I demoed Regions and other things, and people came to the end
           of my talk.
   glazou: they said pseudos were bad because screen-readers don't read pseudos.
   TabAtkins: I think they misunderstand. The real content will still be
              in the DOM, in a single element.
   stearns: By the time you get to the reader, you're not looking quite at
            the DOM.
   TabAtkins: Not quite - they vary.  You usually get an accessibility tree,
              which is an expanded version of the DOM.
   howcome: If pseudos don't work, then why don't multicol work?  They're
            pseudos too.
   dbaron: There's a long-standing problem with people trying to put
           *content* into the pseudos, rather than in the document.
Scribe: dbaron
   dbaron: ... ...
   TabAtkins: If that's a problem then we also need to throw away flexbox
              and grid for the same reason.
   TabAtkins: If people have learned that putting content in pseudos in bad,
              they'll interpret what you say as the same bad thing.
   TabAtkins: I think their concern is actually mistaken.
   <antonp> +1
   glazou: Let's take a flow that ...
   glazou: The voice reader should say "moving from one column to ..."
   ?: why?
   TabAtkins: Regions encourages you to have a semantically-whole piece
              of your content even if it's split visually.
   TabAtkins: Accessibility could be better in general when display order
              is different from source order.
   glazou: I was just reporting what I heard

Scribe: TabAtkins
   stearns: Unless anyone has something to continue in this discussion,
            I'd like to close it.  Leave the issue in the spec and continue
   <Bert> As long as "leaving the issue in the spec" doesn't mean:
          "we'll ask at every meeting until there's a meeting with so few
          people that we can officially decide to do it anyway."

   stearns: The next thing is quick.
   stearns: I think it was resolved yesterday.
   stearns: How the regions specification defines the first region box as
            the ICB of the named flow.
   stearns: I wasn't sure if that was exactly necessary, but in the discussion
            yesterday about paged media and the talk about first page and
            ICB and such...
   stearns: I think regions just needs to follow what is going on in pages.
   TabAtkins: I think arronei thought up a name for the concept you need:
              "fragmentation containing block".  For the concepts you need
              to pull from the ICB, without the *full* assortment of baggage
              from it.
   <fantasai> fragmentaining block!
   * sylvaing fragmentaining block party!
   * divya now occurring @ Saint Clair 3A
   TabAtkins: So we need to define exactly what parts of the current ICB
              concept need to be pulled out into FCB, because non-initial
              pages/regions/etc need them.  Then write that down and
              reference it in Page and Regions.
   RESOLVED: What Tab said immediately above about ICB/FCB

Multi-column Sizing

   <dbaron> http://dev.w3.org/csswg/css3-multicol/#pseudo-algorithm
   fantasai: The proposal is to replace the "available width" and "shrink-to-fit"
             variables with just "used width".
   fantasai: And remove lines 3-10 of the pseudo-algo and just swap out
             refs for "used width".
   fantasai: Where used width is defined by referenced formulas.
   howcome: We presume when used width is handled, so we're shuffling where
            things are done.
   howcome: So it's a simplification of multicol, and it doesn't make a
            compliant impl non-compliant, so I don't have a problem with it.
   howcome: [something about min and max width]
   fantasai: That's contained in "used width".  It's the result of all
             the computations about what the width is going to be.
   howcome: It seems you've been wanting to have a discussion about min-width
            in this spec, but maybe I'm wrong.

   SimonSapin: When is the available width unknown?
   SimonSapin: The spec has one example - in floats.
   SimonSapin: but that's no longer unknown, and it's defined in Sizing.
   howcome: So no other changes, just these removals/swaps?  No additional

   Bert: I'm not completely clear on what the change is.
   fantasai: The available width is always known.
   dbaron: You're removing the stuff about shrink-to-fit into Sizing, so
           for the purpose of this spec, available width is always known.
   fantasai: Right, because this spec isn't defining things well enough,
             and we shouldn't be dealing with this stuff in this CR right now.
   SimonSapin: In 2.1, what we call available width is based on containing
               block, but in here it's not the same.
   howcome: Right, that's confusing.

   Rossen: Another is the "used width", which in 2.1 terms is the final
           width, can still change here afterwards.
   Rossen: If you came in with width:auto and have a column-count, it
           can still change here.
   Rossen: So you're either going to have a complete used-width spec
           somewhere else, and thus yank out these two usages.
   Rossen: or redefine shrink-to-fit elsewhere and don't call it used width here.
   fantasai: The sizing spec defines the used width (in conjunction with 2.1).
   fantasai: The purpose of this algo is not to figure out the width of
             the element, but to figure out how many columns and how wide
             they are.
   fantasai: So we can assume that we've already figured out the width.
   Bert: but you need that information to figure out the width.
   TabAtkins: Right, you do use that in Sizing to figure out the width.
   Bert: So all that happens *before* you figure out the intrinsic size.

   fantasai: It's more complicated. [summarizes the shrink-to-fit algo in Sizing]
   fantasai: So this formula in multicol is technically wrong - it overflows
             when unnecessary in some cases.
   howcome: It's not *wrong*, but it might not be what you want.
   <fantasai> http://dev.w3.org/csswg/css3-sizing/
   TabAtkins: Lines 5-8 aren't great. Sizing defines a slightly better
              definition that doesn't overflow as often.
   fantasai: Because this definition is a bit complicated, I don't think
             this CR (multicol) is the right place to deal with this.

   glazou: We brought this up weeks ago, and deferred it to the f2f to
           resolve on it.
   howcome: I agree we should kill lines 9-10.
   howcome: I don't think we need to remove lines 3-4, seems like useful
   howcome: 5-8 gives *a* definition, even if it's not ideal.
   TabAtkins: We should kill it if we know we have a better definition,
              which we do in Sizing.
   dbaron: The definition in 19-23 is more complicated - you don't want
           to get a different result from 5-8 as from 19-23, once you get
           a definite width.
   <fantasai> The point is, that this pseudo-algorithm should restrict
              itself to determining the number and width of the columns,
              because the rules for sizing a multi-col are not clear,
              not interoperable, and not agreed-upon

   Bert: But that's in a float situation. I asked for column count and width,
         shouldn't I get it?
   TabAtkins: Floats don't overflow their containing block unless absolutely
              necessary.  Our better definition tweaks things if necessary
              to maintain that invariant.
   SimonSapin: Importantly, what does "unknown width" actually mean?
   dbaron: You could interpret it as two different things, one is "you are
           currently doing preferred / minimum intrinsic width calculation",
           the other is "that, plus you have a shrink-to-fit width or any sort".
   dbaron: I think Simon's proposal is taking the first.
   <dbaron> I think

   glazou: It seems that some work has to be done on this in any way,
           because some definitions are missing or unclear.
   fantasai: Yes.  So we should not be leaving these in the spec.  We
             should pull them out and let Sizing define it.
   dbaron: I think we should take the proposal, and raise further issues
           as they come up.
   glazou: Straw poll, 6 for, 1 against, many abstain/undecided
   glazou: Those who are undecided, can you trust the group?
   <fantasai> The proposal is, remove lines 3-10 in the pseudo-algorithm,
              use the term "used-width' rather than "available-width",
              and define in css3-multicol that "used-width" is undefined;
              work on it in css3-sizing
   Rossen: There seems to be some conflicting terminology.  It seems to
           be complicated.
   Rossen: I'm interested in resolving this in favor of Sizing.  I just
           want to minimize damage on this spec.
   glazou: Okay, so discuss before tomorrow evening, and we will resolve.
           Otherwise, deferred.

<dbaron> lunch break until 2pm
Received on Wednesday, 14 November 2012 06:53:38 GMT

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