[CSSWG] Minutes Sydney F2F 2016-02-01 Part IV: Overflow [css-overflow]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.


  - fantasai introduced her and TabAtkins' work to trim down the
      overflow spec to just overflow-x and -y properties and to
      define ink and scrollable overflow.
  - RESOLVED: Hanging punctuation causes ink overflow.
      [Note: This discussion has since been reopened.
       See https://lists.w3.org/Archives/Public/www-style/2016Mar/0073.html]
  - RESOLVED: clip-path and masking do not affect scrollable bounds
      - esprehn will look into the compat for clip-path
  - RESOLVED: Spec the current behavior for nested transforms and
              add a note that this could be improved
  - RESOLVED: Drop border-box overflow concept (used for outlines);
              move it to UI 4 or Overflow 4
  - Discussed whether scrollable area should include margins on
      various elements. More testcases were wanted, and also author
  - A conversation about CSS containment and overflow:clip will be
      added to Tuesday's agenda.


Agenda: https://wiki.csswg.org/planning/sydney-2016

Scribe: gregwhitworth


  fantasai: Tab and I took the overflow module and trimmed it down
            to overflow-x and y properties.
  fantasai: We replaced a lot of issues with prose.
  fantasai: As we discussed in the past there is ink overflow and
            scrollable overflow.
  fantasai: The overflow-x and overflow-y props have the added clip
            value, everything else is pretty much what's in browsers
  fantasai: There is also a placeholder section for max-lines
  fantasai: We're going to go over these issues.
  dbaron: Why is max-lines in here instead of overflow 4?
  fantasai: It's probably going to get dropped... but we wanted to
            at least try to replace -webkit-line-clamp.

  astearns: This is a complete surprise to me, when did this happen?
  fantasai: I forgot we didn't check with the CSSWG, but Tab and I
            did talk with the editors.
  fantasai: We've wanted to look into this for years now: the
            overflow-x and -y properties have existed for about
            15 years in all browsers, and as yet have no spec.
  fantasai: Also we've been needing to refer to ink and scrollable
            overflow for while from other specs, and currently it
            sat in the overflow spec but that's all brainstorm level
            and we need implementation detail right now.
  fantasai: That's basically why we trimmed the spec down to only
            contain those two things so that we can solve these
            actual issues with the stuff that is implemented.
  florian: Also you didn't modify the spec.
  fantasai: Yes, we forked the spec and changed this stuff in a
            separate copy.
  fantasai: We did this a few days ago.
  astearns: Ok. But having notice before the meeting would have been

Hanging Punctuation

  fantasai: The first issue is whether hanging punctuation is ink
            or scrollable overflow.
  dbaron: What is hanging punctuation?
  dbaron: I know what it is conceptually, what is the purpose of
          the property?
  fantasai: It does not measure the glyph that is hanging outside of
            the line box.
  dbaron: Only if it's at the end of the line?
  fantasai: Yes.
  fantasai: I don't know what's correct, do you want it to clip or
            to scroll?
  SteveZ: Why would I not increase the size of the box so there is
          room for the hanging of the punctuation?
  plinss: I think it's just ink overflow.

  fantasai: The difference between ink and scollable overflow is:
            if I have a box with no margin/padding etc, everything
            outside the box gets clipped, but if it's scrollable
            overflow we allow you to scroll to see it.
            Ink overflow you can't scroll to see it, it just gets
  fantasai: E.g. box shadows, image backgrounds, etc) spill outside
            of the box but we don't increase the scrollable area
            so that you thatcan see them.

  fantasai: Is it the author's responsibilities to fix this issue?
  takao: At least the shadow does not expand the cursor, but hanging
         punctuation should expand the cursor.
  rattan: If you have hanging punctuation inside of something that
          is not scrollable, should you be able to see it or not?
  SteveZ: No.
  SteveZ: What I hear Takao saying is that the content box needs to
          make space for the hanging punctuation to make space for
          the cursor.
  SteveZ: It's not accessible that it requires a scroller to see it.

  rattan: When we compute scrollable bounds it can be impacted
          multiple things. Back to the questions, are hanging
          punctuation included in that calculation?
  SteveZ: The real question is why are you making it overflow?
  rattan: Because that's how it broke in this case.
  SteveZ: If I resize the window so I have to scroll anyways, then
          the hanging punctuation should be scrollable too, but if I
          turn on hanging punctuation you shouldn't need to scroll.
  fantasai: That's not how it works.
  plinss: Turning that on makes it say that hanging punctuation
          should not be included in calculation for content box.
  rattan: [reads from spec]
  plinss: By definition you're putting it outside of the box.
  fantasai: That is the definition of a hanging punctuation.

  rattan: If you have a float that has one line, no padding, no
          border, no margin in shrink to fit, what happens?
  rattan: If you add to that same example, you add overflow-x to
          that should you be able to see that comma or not (example
          is in that spec).
  plinss: Not necessarily.
  rattan: Then in that case, it's ink.
  rattan: However if this was considered the same as inline abspos
          element which is not considered for it's space, but it is
          considered for scrollable bounds so you would be able to
          scroll to it?
  florian: Based on your argument if you drop some of the text I
           think it should be scrollable.
  plinss: That makes it so that if you have a simple comma at the
          end you'll end up with a bad user experience where content
          is being scrollable. That's on the author.

  bert: I agree with Florian, by default it should be scrollable,
        maybe what SteveZ said that it should be part of the content.
  rattan: It would be if it was overflow: hidden
  florian: But you're asking for it to be hidden.
  fantasai: I'm fine making it scrollable, I don't care.
  SteveZ: If the padding is there would it still be scrollable?
  dbaron: Re-ask your question.
  <Bert> (if width is 'auto', it will not scroll.)
  SteveZ: If I turn on scrolling since the comma is hanging over the
          content box and I do have padding.
  dbaron: You won't get scrollbars because you don't have content
          that's extending outside of the padding box.
  SteveZ: What I don't want to do is turn on scrolling because I
          turned on hanging punctuation.
  SteveZ: When authors see the scrollbars they'll learn to add the

  tantek: Are we only talking about the hanging punctuation at the
          end of the line?
  fantasai: Both.
  tantek: How do you make the scrollbars go away is a common request
          from devs.
  tantek: Let's not make that worse.
  tantek: I'll just use negative text index.
  dbaron: This will not cause any more scrolling than negative text
          indent will.
  dbaron: It will only cause scrolling if the quote mark would have
          been partially hidden.
  tantek: And that would happen with negative text indent as well?
  dbaron: Yes.
  SteveZ: Not if you add padding.
  tantek: Not sure I believe that without a test case.
  tantek: It's very annoying.
  rattan: Is it more annoying than not seeing the content?
  tantek: Yes.
  rattan: Then it's ink.

  fantasai: I'm leaning towards scrollable overflow.
  plinss: Does shadow cause scrolling?
  fantasai: No.
  plinss: Hanging punctuation is similar.

  <zcorpan> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3851
            - i don't see a scrollbar here (negative text-indent
            outside padding box)

  plinss: I do not want to wrap or break text due to a comma
          overflowing, this is how it's done in page layout and the
          author should not have turned on this feature.
  plinss: Making the user scroll is also punishing the user.

  <fantasai> [Florian draws a CJK period glyph, where the period is
             in the bottom left corner of the em square]
  xidorn: In some forms the punctuation could take a small portion
          of the area, like in simplified Chinese it's at the bottom
          left corner. If we make it scrollable it could be very
  dbaron: I'm ok with just doing ink overflow then.
  florian: Can we do a hybrid thing where we measure the size of the
           glyph bounds?
  dbaron: No, no, no
  dbaron: In particular I'm not ok with that because glyph overflow
          is not scrolling overflow and that's very important.
  plinss: This is morally the same thing as a big swishy glyph
  florian: If you remove the punctuation you may not understand it;
           it isn't the same as text shadow.
  florian: Trying to handle the error case well should not get in
           the way of handling the correct case.

  RESOVLED: Hanging punctuation causes ink overflow


  fantasai: Next issue is about masking.
  fantasai: If you mask stuff that's overflowing do we clip it in
            regards to scrollable overflow?
  fantasai: If I have a div with overflow: auto, and I put an abspos
            div we'll put a scrollbar to allow you to see it.
  fantasai: What about masking?
  astearns: Masking can only partially occlude the content?

  esprehn: Are you saying that clipping impacts the scrollable area?
  dbaron: Yes, clip does and mask does not.
  Rossen: Probably for a good reason.
  florian: What for, I would assume they would be the same.
  dbaron: Clip has always been that way and it would be a lot of
          work to do that for mask.
  fantasai: *made a quick testcase*
  <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3852
  fantasai: It should reduce the scrollable area due to the clipping.
  dbaron: FF/Edge don't scroll, Chrome scrolls.
  Rossen: I think that matches 2.1.
  dbaron: Wait you think 2.1 defines that?
  esprehn: That was the one part that was specific.
  fantasai: [reads 2.1 spec]
            “Content that has been clipped does not cause overflow.”
  Rossen: For this case, FF/Edge works correct.
  esprehn: We have two implementations that don't.
  esprehn: We have to measure.
  fantasai: We have two implementations and a spec that agree.
  esprehn: I don't think we'll implement masking because it's too
  fantasai: I don't care, I just need an answer.

  astearns: There's a lot that you would have to define to determine
            the bounds of the mask would apply, etc.
  dbaron: The other question, do you take the bounding box of the
          mask before or after the intersection of the scrollable
  Rossen: We would have to implement masking within layout in order
          to take into account all of the children that are to be
  Rossen: *gives an example*
  fantasai: That's the question I'm asking.
  dbaron: I think we should, it may have been a mistake that clip
          does this. I think that both clip and mask should not
  dbaron: If you want to do it right, you have to keep scrollable
          region in sync with what mask and clip support, not just a
  <gregwhitworth> *draws another potential issue due to masking*
  dbaron: I just don't think it's worth going into all of this.

  fantasai: My inclination is to have clip path do the same as clip:
            as an author it would be confusing if I clip something
            and I still get a scrollbar.
  fantasai: With masking it's very difficult because you're you can
            mask with images etc.
  dbaron: Doing it with clip is very hard, and web authors do care
          about performance even if you don't.
  florian: Tantek as developer rel. which do they need more,
           scrollbars or performance?
  SteveZ: The authors will wonder why the scrollbars will be there.
  esprehn: Blink uses a very simple model, visual overflow or
           layout overflow, anything that is NOT css overflow is
           visual overflow. They're computed during paint.
  rossen: It's the same in our implementation.

  <zcorpan> 160050 resources in httparchive that have both
            overflow:scroll|auto and clip:rect( -- seems difficult
            to check which of these would regress by changing (i'm
            happy to dump this table if anyone wants to investigate

  smfr: My recollection is that webkit does clump visible overflow
        and the old style clip property, but I agree with dbaron
        that it's probably too expensive.
  smfr: I would also like to see someone else implement clip-path.
  dbaron: I believe we implement clip-path.
  smfr: Maybe it was masking.

  <esprehn> https://developer.mozilla.org/en/docs/Web/CSS/clip
  <esprehn> the example is scrollable in Safari and Chrome
  <esprehn> and not in Firefox
  esprehn: I posted the Mozilla example, it's scrollable in
           webkit/blink but not in firefox.
  <esprehn> doesn't look scrollable in Edge either.
  *everyone looks at MDN testcase*

  rossen: I heard almost all of the implementers not want to support
          mask and clip path in scrollable bounds
  astearns: Given that, there are two ways of going - put in this
            draft that there is a legacy capability.
  astearns: Or, since two of them follow the spec and two of them
            don't we could have in the new spec say that none of
            affects scrolling.
  SteveZ: It's clear that no bugs have been filed on this.
  esprehn: The clip path is used on 31%.
  <koji> https://www.chromestatus.com/metrics/css/popularity#clip
  zcorpan: It's on 160K resources from httparchive (which is live
  ojan: Either way it's way too high.
  ojan: We don't have a good way of measure it though.

  rossen: We need a resolution. After 28 minutes of discussion are
          we ready to resolve?
  rossen: We can take a straw poll or put it up for resolution that
          clip-path and masking do not effect scrolling.
  rossen: Who wants to have clip-path and masking to affect
          scrollable bounds?
  florian: Who cares?
  rossen: I'm just asking so that five or ten years from now we're
          sure that we're not just resolving for the sake of this.
  plinss: We should allow authors to declare random shapes and allow
          those shapes to affect scrollable bounds, maybe that's

  RESOLVED: Clip-path and masking do not affect scrollable bounds

  florian: Do we leave clip alone, or do we address this first?
  esprehn: I said that we care about this, we'll measure this and
           discuss it with the working group.
  ACTION esprehn: Look into compat for clip affecting scrollable

Nested transforms

  <Rossen> [fantasai draws a picture showing two nested, transformed
           boxes that end up affecting the scroll bounds]
  <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3853
  dbaron: We have a special pass for 3d transforms.
  florian: Is this the situation where we should use a 'should'
  florian: One behavior is better, but more costly.
  <smfr> the issue is with two nested transforms, e.g. rotations
  <smfr> 2 ways to implement overflow tracking:
  <smfr> 1. track an axis-aligned bounding box at each level, but
            that can lead to bounding box explosion (as demonstrated)
  <smfr> 2. track corner points through all rotations, and do
            bounding box computation once at the end
  <smfr> 2) is more accurate but more expensive

  gregwhitworth: Based on what tantek says, I don't think we should
                 allow for scrollbars in one UA and not another,
                 with no clear way to fix the scrollbar.
  fantasai: It has scrollbars because the height is calculated based
            on what's in flow. You can adjust the scale factors to
            get different effects. It's overflowing in FF.
  <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3854

  dbaron: So.... I have a different testcase
  <dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3855
  rossen: interop.

  rossen: So back to the issue.
  fantasai: What do you want in the spec?
  florian: We have a trade off between scroll bars and performance.
  fantasai: In all cases you're triggering scroll bars where stuff
            is still 100% visible.
  dbaron: It's way easier than the clip path situation.
  fantasai: How?
  smfr: I think it's fixable, but will any UA change?
  <dbaron> I think you'd just need to maintain a set of points and
           could probably cull a lot of them.
  zcorpan: I think there needs to be a really good reason to change
           away to something else when we have interop on this and
           no one is complaining
  <astearns> +1 to zcorpan's point
  <hober> zcorpan++
  dbaron: I wouldn't quite say no one complains
  dbaron: but still in favor of not changing.
  tantek: If better behavior is possible then I would suggest a
  fantasai: I suggest making it a note where we can state what it
            will do and say that the WG is open to other
            implementations trying it and us possibly changing the
  fantasai: I wouldn't recommend making a should on the cheaper
            thing, the should should be on the better thing.
  fantasai: Is there an RFC6919 term?
  plinss: Must but we know you won't?
  rossen: Let's do that.

  fantasai: This is a whole mess of issues regarding transforms
  fantasai: You may calculate it more precisely but...
  <hober> https://tools.ietf.org/html/rfc6919#section-1
  astearns: We would like to see suggestions for how all browsers
            could make improvements in lock step.
  rossen: That's exactly how I feel.
  astearns: We should encourage people to provide solutions, but
            let's not request breaking interop.
  fantasai: It's not hard to spec, but making it hard to implement.
  SteveZ: We need a compelling use case to make the implementors
          want to change.

  RESOLVED: Spec the current behavior for nested transforms and add
            a note that this could be improved

  <dbaron> (do we want the note to make Alan's point about improving
           in lockstep rather than breaking interop?)

  <fantasai> Sorry, I forgot to regen the spec. The previous issue's
             testcase was this one:

Border box overflow

  fantasai: Do we want to keep “border box overflow” in this level
            of the spec?
  rossen: Isn't the point of this spec just to define what we all do?
  dbaron: This is what we do for outline, and outline is very
          loosely defined.
  rossen: Basically that outline is not ink.
  dbaron: Most implementations do outlines around border boxes, that
          means the outline does not go around descendants whereas
          we (Gecko) union the descendants to outline all of them.
  rossen: What do you do for inline?
  dbaron: We do but we don't do the thing where we merge the lines.
  florian: IE does some complex shapes, but others don't. Other
           people recently said to leave it undefined.
  rossen: In other words, take this out of the spec.
  dbaron: yeah... uh...
  dbaron: Web devs want outline to be just an additional border, it
          would be nice to have a formal spec.
  dbaron: Yeah, I'm ok dropping this.
  florian: We can discuss it future versions.

  RESOLVED: Drop border-box overflow concept; move it to UI or
            Overflow 4

Scrollable area with abspos elements

  fantasai: There was another issue where the scrollable area with
            abspos elements.
  fantasai: Edge/Firefox don't include the margins of the scrollable
  fantasai: We think that is author hostile.
  fantasai: We want to present that issue to the working group.
  dbaron: You're saying margin box only for abspos?
  fantasai: The others include the margin box.
  dbaron: Only some of the time, we don't normally include the
          margin box in scrollable overflow, we scroll to the
          collapsed margin.
  dbaron: We did kind of agree to changing to what webkit does.
  <fantasai> Testcase:
  <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3857

  rossen: Was this found on broken content?
  rossen: This is for abspos?
  fantasai: Yes because we have interop.
  dbaron: I doubt that.
  fantasai: For inline content we take the line boxes.
  dbaron: No we take the border boxes.
  zcorpan: But it's interopable
  dbaron: But not on the margin boxes. I'm pretty sure if you have a
          large padding and border on a span, it will increase the
          scrollable area, but not the margin.
  dbaron: I'm interested to see what webkit does here.
  fantasai: Blink does border-box for inlines.
  <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3858

  dbaron: I would suggest more research is needed here.
  dbaron: I think it would be better to get the big picture here, to
          see how the implementations vary beyond just abspos.
  fantasai: What specifically?
  dbaron: Floats, relpos, blocks where the margins do collapse
          through to the scrollable area and vice versa,
  dbaron: and probably inline side margins as well,
  dbaron: and inline side margins on blocks and inlines.

  fantasai: My general thought though, is that we don't provide
            breathing space for an abspos.
  rossen: Kind of like an inline case.
  fantasai: I don't really care about the inline case.
  hober: Webkit matches FF/Edge on those testcases.
  rossen: So you're saying that one implementation is doing it wrong
          and you want all of the others to change?
  fantasai: At least that implementation allows breathing space and
            you can remove it if you want.
  dbaron: But there are other test cases that need to be done to
          ensure that we're getting a consistent end result.
  rossen: ok.
  rossen: Let's move on.

  rossen: Are you looking for a resolution?
  fantasai: It looks like people are wanting more test cases.
  zcorpan: It would be nice if we get feedback from web devs.

Does clip cause a bfc?

  fantasai: The one issue we have is whether or not 'clip' should
            cause a bfc.
  rossen: Which one?
  fantasai: Firefox does not create a bfc.
  rossen: I thought we discussed this.
  rossen: As soon as it becomes a bfc those margins won't collapse.
  fantasai: The margins don't have to be large.
  rossen: Also if you have floats within the bfc the inline content
          will be affected but it won't be visible,
  rossen: Which is the really weird case.

  ojan: Is any vendor interested in implementing this?
  florian: Yes there is a dependency by contain.
  ojan: And we think that dependency should be removed.
  ojan: I don't think we should add all these weird things in
        computed style.
  florian: If overflow is visible and you have containment, what
  florian: The reason we wanted it to change was something else
           depends on it, the text-overflow property.
  florian: If it's visible you can't have the ellipses effect.
  florian: That would cause the scrollable byte buffer would be
           created and that's a performance negative.
  florian: You need this to avoid that, or something.
  ojan: That is definitely a legitimate use case.
  florian: Also resize.
  ojan: I see...
  florian: There may be another solution.
  zcorpan: Then we could have those other things look at containment.
  zcorpan: I'm not sure which one is better on the implementor side.
  florian: Mozilla has a variant of overflow: clip without

  ojan: Do other implementors have thoughts on this?
  ojan: Is anyone thinking about impl this (I know Apple can't say
  ojan: Then the separate thing, should the containment spec depend
        on overflow clip or text-overflow/resize depend on CSS UI.
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2015Jul/0459.html
  <gregwhitworth> nevermind on the last 20 minutes of discussion

  <ojan> can we put up an issue to discuss (tomorrow) about this CSS
         containment + overflow:clip issue?
  <tantek> ojan put the issue as the first thing on
           and let's see how it goes
  <astearns> tantek, ojan - afternoon rather than morning, as
             there's probably no one that needs to call in for it
  <tantek> astearns: makes sense.
https://wiki.csswg.org/planning/sydney-2016#tuesday-pm then
  <ojan> astearns, tantek: thx. that's better for me since i can't
         be here in the morning. :)

Overflow style

  rossen: Anything else?
  fantasai: There's a thing on overflow-style, florian?
  florian: When you want the scrollbars to be overlay scrollbars, or
           auto-hiding scrollbars, should we support this and how
           should we support this?
  rossen: Just use the -ms-autohiding.
  florian: My only issue, is that you get the choice between space
           consuming or auto-hiding.
  esprehn: We have overlay which is in webkit and blink.
  florian: I like the ms one because it has fallback and you want
           them to cascade independently instead of having this on
  florian: I support the Microsoft behavior.
  <fantasai> Florian++

  esprehn: Why do you want to change all scrollbars on a page?
  esprehn: We have authors arguing that scroll bars taking up space.
  fantasai: We all agree with that.
  esprehn: They're the same person making this determination.
  * liam would hope that overlay scrollbars would come from the
         operating environment/context, and that people wouldn't
         want to experience alien scrollbars on random web pages
  philipwalton: I think you're saying the same thing.
  esprehn: Do they overlay?
  rossen: It's up to you.
  rossen: The styling should be different than making it a scroller
          or not.
  esprehn: You run the risk of the scrollbar covering up content.
  fantasai: If you're reserving space, why have them overlay?
  rbyers: It's for auto, you want to auto scroll and be transparent,
          but it overlaps.
  fantasai: That makes sense.
  florian: Auto reserve or something like that?
  fantasai: That would make more sense than the author guessing the

  smfr: overflow: overlay was a mistake.
  smfr: We would prefer not having scrollbar customization.
  rbyers: What about the idea that if it's auto, and the padding is
          auto set.
  esprehn: You want the overlay and you want padding to come in.
  rbyers: Should we have that?
  zcorpan: Would it make scrollbar not ugly?
  smfr: We did that already.
  esprehn: You have a scrollbar above it, the grid gets smaller when
           the scroll bar comes out and then goes back out when the
           scrollbar goes back. It's very hard to adjust.
  florian: This new feature, is that a value of overflow or
           something else?
  fantasai: I think overflow-style is good to handle this.
  rossen: What you're saying, is that every time you have overflow:
          auto you have extra padding.
  rbyers: If we don't break content.
  rossen: That would be worse.

  zcorpan: We should have overflow: scroll just not paint scrollbars
           when there is nothing to scroll.
  esprehn: That doesn't solve everything as the toolbar doesn't know
           the size of the scrollbar.
  <Bert> (I think I like zcorpan's idea. And can add 'overflow-y:
         scroll' to that toolbar area)
  [zcorpan was describing that 'overflow:sc']


Received on Sunday, 13 March 2016 12:39:11 UTC