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

[CSSWG] Minutes San Francisco F2F 2016-05-09 Part III: Media Queries, Sizing, Flexbox, CSS Containment [mediaqueries] [css-step-sizing] [css-flexbox] [css-containment]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 24 May 2016 19:35:29 -0400
Message-ID: <CADhPm3siUOPPfgWEecHZGKAMPsr9c3ck1ueuomG=apf1qZ6dqw@mail.gmail.com>
To: www-style@w3.org
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

Media Queries

  - Discussion around syntax for overflow (scrolling vs paged) MQ,
    and possibly having a multi-value MQ.
  - Discussed difference between returning false and unknown
  - Discussed the need for a way to truly negate a MQ to create
    two complementary code blocks, since (given unknown being
    different from false) the current syntax doesn't give that


  - RESOLVED: Intrinsic sizes that don't require layout to
              recalculate are treated as definite.


  - The decision on how to handle percentages will wait on use cases.
  - The group discussed how to handle layout when there's a column
      multi-line flexbox that's floating and has a column wrap.
      - There's a fast and performant and clearly broken and useless
          approach done by Chrome or doing actual layout as done by
      - People were uncertain which approach was best and concerned
          that whatever is decided would still work years down the
      - TabAtkins wanted more time to think about a solution, so the
          discussion was tabled.

CSS Containment

  - RESOLVED: Publish FPWD of css-contain-1 after edits on overflow


Agenda: https://wiki.csswg.org/planning/san-francisco-2016#proposed-agenda-topics

Scribe: dauwhe

Media Queries

  astearns: Let's get started.
  astearns: Overflow stuff isn't prepared yet, is there anything
  astearns: The other topic is flexbox, but we're waiting until 2:30.

  Florian: We can try to do MQs.
  Florian: One MQ thing is also about colors.
  Florian: Light-level media query?
  fantasai: We resolved to defer.
  Florian: Simon said that he might not like it at all.

  Florian: Since it's been in spec for a while, I'd like to hear the
  myles: First objection: fingerprinting
  myles: A website will know if I'm outside or inside.
  myles: Second is that it's an OS thing.
  myles: Third, OS has night mode that might interfere.
  Florian: For the 3rd thing, I don't think it would fight.
  Florian: Given the adjustments already made, are we in a mode that
           needs boosting?
  Florian: You have to take into account the display and the
  Florian: LCD would be different than e-ink
  Florian: so you can take into account OS stuff then.

  <fantasai> https://lists.w3.org/Archives/Public/www-style/2016Mar/0356.html
  <fantasai> resolution on deferring light-level ^
  fantasai: Here's the resolution... move light-level to next level
            of MQ.


  TabAtkins: Overflow
  fantasai: I had action item for proposal.
  fantasai: I'll try on the fly.
  fantasai: The questions were:
  fantasai: there's a block and inline axis
  fantasai: can be scrolled or clipped
  fantasai: block can be scrolled, paged, scrolled and paged.
  fantasai: We had overflow inline and overflow block
  fantasai: but you don't care about everything
  fantasai: so you'd have overflow and can just ask about block
  fantasai: or do separate query for inline
  fantasai: so syntax would be superset of keywords.
  overflow: scroll | page | scroll-page | none |
            scroll-inline | scroll-block | clip-inline | clip-block

  dbaron: Don't know what you mean by overflow-inline.
  dbaron: Does it have two different values but matches either?
  Florian: It doesn't have a value, it answers yes or no.
  dbaron: All the features have a value.
  dbaron: Just because a spec is written a certain way doesn't mean
          the concept isn't there.
  Florian: If you include undefined, then yes
  Florian: some MQs always return false.
  dbaron: Either they have a particular value or no value.
  dbaron: I'm not totally against, but it's a little weird.
  fantasai: Can you specify them together?
  fantasai: Is the syntax going to be (writes on whiteboard)
  fantasai: <block> | <inline>
  Florian: Less risk by having one value then combining.
  fantasai: That works for me.
  Florian: Scroll pages is the ??? one?
  Florian: We can spend forever on bikeshedding, but this makes sense.

  Rossen: If you want to constrain to match only block
  Rossen: then having it match scroll and not scroll.
  fantasai: You can say (overflow: scroll) and (overflow:
  Florian: Between multivalue MQ and separate overflow-inline MQ.
  Florian: Either way you type the same words,
  Florian: which one is easier for impl, for extensibility.
  fantasai: They're both easily extensible.
  Florian: Having two properties is less work.
  Florian: MQ so far don't have multivalue.
  Florian: You may need to change your code.
  Rossen: Sure.

  fantasai: (writes) overflow: scroll | page | scroll-page | none
  fantasai: scroll-inline | clip-inline
  fantasai: scroll-block | clip-block
  fantasai: I just want this first set to work because those are the
            common cases.
  Rossen: What is scroll-page.
  fantasai: You can scroll but get new pages on forced breaks.
  Florian: Or can break on infinite scroll.
  TabAtkins: The presentation case is good.
  astearns: Do we do the top box on this level, do the rest later?
  fantasai: That's ok.

  esprehn: Who has scroll-page?
  fantasai: Presto.
  esprehn: Scroll and page seem obvious, but the others...
  TabAtkins: We had at least one implementation that had behavior of
  hober: That impl won't be updated for MQ.
  TabAtkins: But we know it's been useful to someone.
  esprehn: We're trying to spec someone's experience. What about
  fantasai: They page.
  TabAtkins: The user agent is the one answering these questions.
             flipboard can do whatever it wants as a web app.
  Florian: The inline direction is relevant to our user agent
  Florian: both scroll-inline and clip-inline are used.
  esprehn: It seems bad to define all these things here.
  fantasai: This is about whether fragmented or not.
  esprehn: What if there's an expando triangle at the bottom.
  TabAtkins: Give us an existence proof.
  fantasai: If you can do that on any page, it's effectively scroll,
  fantasai: you're not fragmenting.
  esprehn: I want clip.
  dbaron: That's a scrolling UI.
  fantasai: There's a continuous scrollable area and you can view it.
  dbaron: You can look at the other part of the layout, but you're
          not changing the layout.
  fantasai: If you have paging, it changes layout, because you have
            to space content away from the breakpoint. That's

  Florian: For inline, scrolling and clipping we understand
  Florian: but we don't have inline fragmentation because we don't
           understand what it is.
  Florian: The rest are things sensible UA's want to do
  Florian: why exclude them?
  Florian: If your UA doesn't do them, just say no.
  <dbaron> I think some UAs may have had table printing code that
           did inline-direction fragmentation
  esprehn: I think there's a lot of dead stuff in css
  esprehn: like a monochrome display with only green.
  esprehn: There's a matrix one.
  TabAtkins: Some versions of lynx need that.

  Rossen: What is your main objection?
  esprehn: Every new print person will want more.
  esprehn: It's an enumeration of possible user experiences.
  dbaron: It's an enumeration of the way the content can be laid out
          in css.
  Florian: The things that are not defined in css are not in this
  hober: Can we add scroll-page but make it at risk?
  fantasai: Just say no,
  hober: As a reader of the spec, I'd like to know that no UA does
  fantasai: But there's a decent chance there are some UAs
  fantasai: I don't think at risk makes sense.
  Florian: By not implementing it you are implementing it.
  hober: Just spec as returns false :)

  esprehn: What UA can only display the initial viewport?
  Florian: Digital signage.
  TabAtkins: Digital signage is currently bad about this.
  Florian: If you know your UA doesn't show overflow, then you need
           to know this.
  shane: How many pages do you expect will show digital signage?
  TabAtkins: There's a news site that's designed for both--web and
  TabAtkins: content is the same,
  TabAtkins: their content is amenable to MQ.
  hober: My understanding of esprehn's point is hinging on that.
  plinss: If you don't parse it you're ok.
  dbaron: MQs are intended to be more speculative than other stuff
          in the platform.
  dbaron: "are you doing this familiar thing, or might you be new"
  esprehn: I wish my toaster supported css.

  astearns: This is not sounding productive.
  Florian: Are we ok with having this in spec and not implementing?
  esprehn: I object to the fact that the platform has stuff you
           shouldn't use as an author.
  esprehn: I have to wade through a lot of useless stuff.
  Florian: We've removed some useless ones already.
  TabAtkins: We should do better with examples and education.
  TabAtkins: We can do more than the maximally useful.
  astearns: Do block overflow now and inline later.
  Florian: We know what we want to write, and someone wants to
           implement, why wait?
  astearns: Do we split into levels? or do we put the whole proposal
  astearns: I don't care. Straw poll?
  fantasai: I want to keep scroll-page.

  dbaron: Should none be called clip?
  fantasai: None triggers falsiness.
  TabAtkins: That's how MQs work.

  astearns: A straw poll. A: overflow: scroll | page | scroll-page |

  jensimmons: So we're doing things that no one wants to do now?
  astearns: This allows implementation later.
  myles: If it never gets hit, how do you know it works?
  myles: That's a recipe for untested code.
  dbaron: You write a query that says "do you have the feature"
  dbaron: Everyone returns false.
  dbaron: Later you can use it.
  TabAtkins: We wouldn't write code today
  TabAtkins: but if anyone does do it, the ability to discriminate
             is useful
  TabAtkins: and we know it's been done in the past or niche.
  TabAtkins: So it's reasonable.
  Florian: You can return unknown instead of false
  Florian: but then there's problems with boolean logic.
  Florian: If you know you're not doing it then say false.
  plinss: It doesn't help now.
  gsnedders: What happens if you give an unknown keyword?
  TabAtkins: It stays as unknown.
  TabAtkins: If it gets to top level it becomes false.
  Florian: Overflow (not scroll-page) is the issue.
  gsnedders: ah.

  jensimmons: You're interested in the inline things?
  Florian: Yes.
  Florian: We haven't implemented yet but it's in the plan.
  Florian: We're also thinking about scroll-page.
  Florian: As dbaron says, these are not theoretical UI modes, they
           are css layout modes
  Florian: and we know how they work.
  Florian: This is stuff we do in css today.
  Florian: We know what these things do.
  Florian: Not all of them are implemented in mainstream things.

  bradk: If we have A, what is purpose of third line?
  Florian: I don't understand it either.
  fantasai: Third line if you want to explicitly query block axis.
  fantasai: If you're scrolling does this query return both axis.
  fantasai: there are few question:
  fantasai: is it block scroll, or both, or either?
  Florian: Didn't used to be a problem.
  fantasai: For scroll-page, if you query the media type about
            scroll, it should probably say yes.
  TabAtkins: Can always return true for scroll.
  fantasai: We do not page.
  TabAtkins: Requiring negative query for common cases is not good.
  fantasai: Scroll page ua would want to fall under scroll.
  TabAtkins: Let's not over-think. Match one thing or another.

  Rossen: Back to straw poll?
  astearns: Do everything at once, or split into levels?
  fantasai: Option C: keep spec as-is, with overflow-block and
            overflow-inline as separate.
  Florian: overflow-block is too verbose.
  bradk: I like the way it is, it's explicit about which direction.
  Florian: People stopped doing @media print, when they were talking
           about pagination.
  * gsnedders suspects most web developers will just keep using
              @media print…
  fantasai: We're breaking out paginated part of print, like for an
  TabAtkins: Webkit and chrome don't want to implement values they
             won't use in the future.
  esprehn: Because false and undefined are different, we'd still
           have to implement.
  fantasai: You'd still return false on tactile.
  esprehn: So your binary has to contain things you don't support.
  Florian: You will always have to do that with MQ.
  esprehn: That's why I'm objecting to shipping speculative stuff.
  Florian: They're both on my road map.
  plinss: If any UI shipped, would you implement the MQ?

  dbaron: The fact that the new boolean thing isn't right is a
  dbaron: It doesn't do what we want to do.
  dbaron: We want to make it possible to "if this matches, do stuff,
          if not do other stuff"
  dbaron: If it's unknown neither block run
  dbaron: People want "or else"
  dbaron: and the old MQs give you that, well it fails at a higher
  plinss: Let's put an else rule in MQ
  plinss: @else.
  hober: In a world where some browsers return unknown
  hober: you have to write rule so unknown ends up false.
  hober: Will be in practice indistinguishable.
  dbaron: Unknown and false behave the same
  dbaron: not unknown and false behave the same.
  dbaron: If you're using the not to be else.
  dbaron: Maybe MQ need a syntax for is this thing supported in MQ.

  gsnedders: Often you can make an assumption... more likely scroll
             than page
  gsnedders: it's probably going to be right.
  Florian: You write your non-conditional code for what is most
           probable and then test.
  dbaron: Having to write non-conditional code and then override is
          a huge pain.
  <fantasai> +1 to dbaron
  Florian: The problem with else.
  Florian: we need syntax that makes the else apply in things that
           don't support it.
  TabAtkins: This is something that doesn't transition well.

  jensimmons: Do we need to allow MQ in @support?
  jensimmons: If you support foo, then I'll ask some questions about
              whether foo is supported.
  gsnedders: It makes sense to treat MQ separately from @support
  dbaron: It's useful to have is a MQ supported so you can used and
          and or
  dbaron: is it supported AND is it true
  dbaron: you keep the unknown.
  jensimmons: What if they don't support the test and the feature?
  dbaron: Then it doesn't work.
  dbaron: Just like @supports.
  TabAtkins: We can explore that.
  gsnedders: Supports is better than @else.
  fantasai: We should make it easy to see if this is supported and
            true, or unsupported or false.
  Florian: Supported and true is good.
  fantasai: You need the opposite of supported and true.
  dbaron: you could have a function that captures the unknowns
  gsnedders: can we call it supports
  <jensimmons> Can you put a media query inside a feature query?
  <jensimmons> (currently)

  ACTION: TabAtkins to look into supports on MQ
  <trackbot> Created ACTION-770

  <dbaron> The function is, I think, known-and-true()

Percentage sizing issues

  astearns: We're talking about percentages.
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2016May/0050.html
  fantasai: Bigger one is filed against grid and abspos.
  fantasai: The thing Christian and Igalia folks wanted answered
  fantasai: this is what we want to tackle first.
  fantasai: Everything else depends on this.
  TabAtkins: I can summarize;
  TabAtkins: resolving % on children when container size is
  TabAtkins: for float that shrink-wrap, if we have child 50%.
  TabAtkins: We will do normal shrink, then child will be 50%
             against that.
  dbaron: Intrinsic width is separate from layout.
  dbaron: Intrinsic width doesn't know %.
  dbaron: In layout you have input width, it takes that.
  dbaron: It's interoperable across lots of things.
  fantasai: It's undefined in 2.1.
  dbaron: shrink-wrap is undefined in 2.1.
  TabAtkins: Now it says % is never resolved, we want to change.

  fantasai: If you do same in height, then % are treated as auto.
  fantasai: If you have the same situation in height axis, that
            percentage is not resolved, is treated as auto.
  fantasai: So we have an inconsistency, how will we resolve?
  fantasai: Which parts of flex and grid do we make consistent with
            2.1 width.
  TabAtkins: These calculations happen separate from layout.
  TabAtkins: You need to run real layout to figure out height.
  cbiesinger: I like the principle.
  cbiesinger: Width calcs should require layout
  cbiesinger: for intrinsic size calcs.

  fantasai: In css 2.1 we didn't run into this.
  fantasai: Orthogonal flow breaks the assumption of width input
            height output
  fantasai: then you have to perform layout to find intrinsic size.
  fantasai: Grid and flex and multicol and writing modes allow
            switching of the axes.
  fantasai: That's the complication.
  fantasai: And we've tried to make flex and grid consistent.
  fantasai: Right now the axes are not consistent in block layout.

  ojan: To be fair, there are other ways in which flexbox treats
        height and width differently.
  Rossen: Not really.
  Rossen: If you assume all you have is flexbox.
  Rossen: Can we make it symmetric?
  Rossen: When you hit it, you are bound to do this measuring.
  Rossen: For flexbox and grid, their measuring should be symmetric.
  Rossen: How do you deal with block layout when there are flex or
          grid heights.
  Rossen: Is there a reason we need to change anything?
  Rossen: I don't think there's a need.
  dholbert: This is about percent on something that happens to be in
            a flex container.
  dbaron: Some of the issue is that sizing is attempting to define
          for block.

  TabAtkins: We can special-case as appropriate, but right now
             they're not correct.
  TabAtkins: If we do adopt this, right now we don't allow
             intrinsics to be definite.
  TabAtkins: If we correct for float and make a general principle.
  TabAtkins: Then min-sizing are definite.
  dbaron: Things for floats are true for abspos,
  dbaron: You need a mechanism for when things that were indefinite
          are definite.
  dbaron: Percentages inside table cells for example.
  TabAtkins: It's not hard to have in spec, in this case this length
             is indefinite.

  TabAtkins: Just trying to figure out what default should be.
  TabAtkins: If we define that intrinsic sizes are considered
             definite by default, then that fixes our issue.
  TabAtkins: We can then simply text in flexbox.
  Rossen: What would be a simple example?
  TabAtkins: Treat intrinsic sizes as definite when they don't rely
             on layout, by default.
  TabAtkins: Shrink wrapping would be definite for resolving
             intrinsic sizes on children.
  TabAtkins: If you say height: min-content that requires layout, so
             would be indefinite.
  astearns: Any objections?

  RESOLVED: Intrinsic sizes that don't require layout to recalculate
            are treated as definite.


Percent Sizing

  <Rossen> https://drafts.csswg.org/css-flexbox-1/issues-cr-20160301#issue-1
  <fantasai> http://drafts.csswg.org/css-flexbox-1/issues-cr-20160301
  TabAtkins: This will be covered by general sizing behavior.
  astearns: Are we going to republish?
  dholbert: Should we reopen percent padding discussion?
  dholbert: Would be useful before we republish.
  dholbert: We have several more bugs this week.
  dholbert: Currently spec says browser decides.

  TabAtkins: If we want to start on this I have numbers.
  TabAtkins: People using percentage in margin or padding: .035%.
  TabAtkins: This is any usage, including usual hacks.
  dholbert: Most people using margin/padding are expecting
            traditional block behavior.
  TabAtkins: Nobody cares and we should do what is consistent.
  tantek: There's different opinions on what is simplest.
  dholbert: I want to change.
  dholbert: I want to see if Microsoft is still concerned.
  <Rossen> https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/padding-left/

  jensimmons: If this group that thinks it's a rare use case that
              people use percentage in margins, you're wrong.
  jensimmons: Every person using responsive web design uses this.
  jensimmons: Using best practices
  jensimmons: every single person is using percents in margins and
  TabAtkins: Our calculations were looking for percentage margin on
             a flex item.
  dbaron: A percentage of what.
  jensimmons: The relevant is what percentage of people using flex.
  ojan: It's 11%.
  ojan: The most useful thing would be examples.
  ojan: The question is does it resolve against width or height.

  tantek: If you were to use flex in responsive design, would you
          use percentage margin/padding?
  tantek: If the answer is yes, then I'd ask what your expectations
          would be.
  TabAtkins: Beyond bug reports asking for block behavior.
  tantek: There are lots more new authors, and simplifying model for
          them is more important than maintaining past behavior,
  shane: Support for responsive design is separate from backwards
  jensimmons: Are people going to need to use percent in flex?
  tantek: It's an orthogonal question.
  ojan: Maybe jen can come back with examples, and we can discuss.
  ojan: And it doesn't sound like MS has changed their behavior.

  astearns: Anything else for flex?
  TabAtkins: That's all we needed.

Running layout to compute intrinsic sizes in the width axis

  TabAtkins: There's one more.
  TabAtkins: Running layout to compute intrinsic sizes in the width
  TabAtkins: Two chrome implementations have run into this;
  TabAtkins: have a column multi-line flexbox
  TabAtkins: that you're floating,
  TabAtkins: it has column wrap.
  TabAtkins: To find width of column wrap flexbox you need to do
             real layout
  TabAtkins: and that's problematic.
  TabAtkins: Edge does this correctly.
  TabAtkins: Chrome does not.
  TabAtkins: So things are clearly broken from authoring perspective
  TabAtkins: but it's performant and consistent.
  gregwhitworth: We brought this up two years ago.
  gregwhitworth: In some cases you do want to do actual layout.
  gregwhitworth: I think it's worth taking the effort to do it in
                 performant manner.
  TabAtkins: So performant easy stupid one? or the harder one that's
  esprehn: Doesn't servo do this in parallel?
  esprehn: So they would object.

  fantasai: This problem exists for a lot a things in css
  dbaron: Only things from the past few years.
  fantasai: Orthogonal flows have existed for awhile
  TabAtkins: The similar examples that work are multicol
  TabAtkins: but flex can have different widths in column wrap.
  fantasai: But you need to know how many columns in multicol,
            so it's the same problem.
  iank: This is if auto-width.
  <fantasai> First draft of CSS Writing Modes was published in 2012.
             It said that logical heights are sized to fit the

  Rossen: Where are you going with this?
  Rossen: Are you proposing we allow layout-based measuring?
  TabAtkins: Yes, otherwise you can't float a multi-col flexbox
  TabAtkins: If other browsers are not willing to do it...
  <SimonSapin> Yes this is all a big problem for Servo and I don’t
               know what to do about it :(
  plinss: It doesn't matter if you're performant if you're always
          delivering the wrong answer.
  ojan: I feel torn. There's the obviously correct one... in chrome
        we won't be able to do this anytime soon.
  cbiesinger: We are considering a rewrite of our layout engine.
  ojan: But this is two years away.

  dbaron: A few years ago, intrinsic width was a rather clean concept.
  fantasai: That no one understood.
  dbaron: There was some architectural sense to it.
  dbaron: I'm concerned about what's been happening to it
  dbaron: and how it's tying web tech to current implementations.
  dbaron: Like how Servo has something that works with stuff two
          years ago, but not current stuff.
  dbaron: Especially as it aligns with how processors are evolving.
  Florian: The number of cores is stagnating.
  esprehn: This isn't the right forum to discuss if Servo is the
           right thing.

  Florian: But doing this doesn't invalidate Servo.
  Florian: We shouldn't make everything parallelize-able even at the
           expense of author expectations.
  dbaron: Servo parallelizes that breaks up the tree.
  dbaron: Start at top, pass info to leaves, return other info up.
  dbaron: There's a cost to passes.
  dbaron: Pass one moves information
  dbaron: pass two is the layout
  dbaron: more passes are costly.
  SimonSapin: What dbaron just said.
  SimonSapin: In some cases we already need to sequentialize layout,
              like floats and counters.
  SimonSapin: Doing intrinsic width requiring layout is probably not
              impossible without throwing it all away.
  SimonSapin: I don't know yet how complex this will be.

  TabAtkins: We might allow the JS plugin for sizing to rely on
  iank: This is a houdini topic.
  plinss: There are a lot of other layout problems that css hasn't
          done yet
  plinss: and they mostly fall into this category
  plinss: and if we cut this off now, it's very short-sighted.

  TabAtkins: IE is ok, we're torn, Servo doesn't like it but can
             slow-path it.
  TabAtkins: Authors 100% have a preferred behavior.
  dauwhe: And w3c has principles to answer this question.

  astearns: Is there a gecko consideration?
  dholbert: It will take some work
  <TabAtkins> Test case:
  <TabAtkins> ^^^ if the dark green expands to fill under both lime
              boxes, you do layout to calculate intrinsic sizes

  plinss: Authors will always be able to blow things up.
  dbaron: We also want web performance to be predictable.
  plinss: I remember when it took 30 seconds to resize 4 levels
          of nested tables.
  plinss: If we're not giving authors what they need, what are we
  plinss: The authors expectation is to do the right thing.
  shane: Yes.
  plinss: They're giving a bullshit answer for performance.

  gregwhitworth: 99% don't know the predictability that you know
                 because you work on the engines.
  dbaron: And floats were defined for something other than what
          people are using them for.
  gregwhitworth: Had we addressed this two years ago... IE11 laid
                 out floats to get size.

  gregwhitworth: I do want to back what plinss said.
  gregwhitworth: In case of conflict, consider users over authors
                 over implementors over specifiers over theoretical
  dbaron: There was no consensus for layout, and there was consensus
          for doing what we knew how to do.
  gregwhitworth: Can we start, though? I know there's a burden of
                 work. But for the authors and the platform, we need
                 to do this in performant ways.
  fantasai: This is even more clear than the float case.
  dbaron: I think this is a rewrite the layout engine thing.
  dbaron: We don't have the resources to do this.
  dbaron: There might be other ways to fix the broken behavior.

  <TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4177
  (looking at test case link above)
  <shane> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4179
          <-- content occlusion

  TabAtkins: The spec mandates edge's behavior
  TabAtkins: so do we leave it alone, or do the stupid fast thing?
  dbaron: The way I'd look at describing an intrinsic width
          mechanism to do this
  dbaron: a column wrapped flexbox is an orthogonal flow.
  dbaron: So if you have one of those things floating, you compute
          intrinsic heights, then do width as output.
  cbiesinger: Blink doesn't deal with that, doesn't need height
              until layout.
  dbaron: I think that's looking at it backwards.
  dholbert: In the test, there's a set width and height on the flex
  dholbert: If it was text you'd have to do layout.
  dbaron: That depends on what heights or widths are specified.
  dbaron: If there are few enough, you're not going to get a
          sensible layout anyway.
  gregwhitworth: What do you mean?
  dbaron: You're not going to like the results.
  gregwhitworth: You're assuming everything is auto.
  dbaron: Right.

  dbaron: Part of the problem that led us into this is not treating
          the orthogonal flexbox as orthogonal.
  TabAtkins: Possibly.
  dbaron: I think some of that weird behavior is from the same
  TabAtkins: The weirdest behavior is to avoid t-shaped documents;
  TabAtkins: like auto height of 100vh for mixed direction things.
  TabAtkins: A column flex box should not have those fix-up things
             that apply
  TabAtkins: to text.
  TabAtkins: There might be some stuff from orthogonal flows we
             could import
  TabAtkins: but the general case won't give us good results.
  dbaron: 'cause that's the way they flow
  dbaron: Flexbox today has so many patches to get good results.

  <dholbert> FWIW, here's a testcase with no specified heights on
             the items, and with multiple lines of text in each:
  <dholbert> Edge gets that "correct" (per authors' expectations) --
             no overflow ^

  fantasai: I don't understand what you mean by “act like orthogonal
  TabAtkins: They do height first, then width.
  cbiesinger: This is different because it's doubly orthogonal.
  dbaron: It's two layers of orthogonal nesting.
  dbaron: Getting orthogonal stuff only makes sense with widths.
  fantasai: It won't wrap unless there's a constraint on the
  fantasai: In the case of writing modes, we impose the 100vh rather
            than calculating as max content
  fantasai: but column wrap flex uses max content.
  dbaron: The problem is not that you want width on layout, but you
          want the auto size calc for column wrapping flexbox in
          that dimension
  dbaron: rather than in the other way.
  gregwhitworth: However you want to solve it is fine.
  dbaron: I would really like intrinsic widths to be not dependent
          on layout
  dbaron: and I think there are good ways to do that;
  dbaron: except for floats
  dbaron: except for block formatting contexts that contain floats
          and texts.
  TabAtkins: I'd be happy to defer
  TabAtkins: until we can prepare some ideas.
  TabAtkins: I don't want to put dbaron on the spot right now.
  TabAtkins: I want more time to think.
  dbaron: OK.

  astearns: The original question is do we want to do anything
            before we publish flex
  astearns: and the answer is no, we publish.
  astearns: So let's take a break
  astearns: we do need some topics from tue and wed.

  <break duration="NaN">

Scribe: fantasai

CSS Containment

  Florian: Why don't we have a public working draft?
  TabAtkins: We were waiting on layout and ?, but I'm cool with that.
  dbaron: I have an open bug.
  dbaron: On the title of the spec.
  dbaron: Should be level 1 rather than level 3.
  TabAtkins: There's also an open issue about overflow: clip
  TabAtkins: Can I publish a WD of css-contain-1?

  RESOLVED: Publish FPWD of css-contain-1 after edits on overflow

  <dbaron> BTW, the reason I noticed the level being 3 rather than 1
           was that we submitted *tests* for the spec, and Shepherd
           complained that they weren't associated with the spec!
  <dbaron> (And that one bug report was based on having it on for
           nightly & aurora but off for beta & release.)

Control Characters

  <dbaron> gregwhitworth, fwiw, we have one bug report on visible
           control characters,

  TabAtkins: So, on control chars.... we lost the data
  TabAtkins: It was on Emil's server, but then he shut it down and
             it's gone.......
  gregwhitworth: {///}
  gregwhitworth: We're not surprised people are running into problems.
  gregwhitworth: That's why we wanted to announce and do a
                 coordinated PR push.
  gregwhitworth: And why we want everyone to have it behind a flag,
                 so that we can coordinate a release.
Received on Tuesday, 24 May 2016 23:36:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:45 UTC