W3C home > Mailing lists > Public > www-style@w3.org > March 2015

[CSSWG] Minutes Sydney F2F 2015-02-11 Part I: CSS3-UI box-sizing, Interaction between Overflow, Positioning and Filters

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 20 Mar 2015 02:38:58 -0400
Message-ID: <CADhPm3vPbQMKd5M8e2c5ac8+6U1cUg0FNmhTxxtbtR3Q2dPs1Q@mail.gmail.com>
To: www-style@w3.org
CSS3-UI box-sizing

  - tantek brought several test cases to the group to figure out
      what the interoperable behavior to allow them to spec box-
  - RESOLVED: CSS 2.1 width computations use the content width.
              Patch CSS2.1 anywhere this is not clear.

Interaction between Overflow, Positioning and Filters

  - RESOLVED: Non-none values of filter induce a containing block
             for all positioned descendants.


  Agenda: https://wiki.csswg.org/planning/sydney-2015 (Wednesday)
  Scribe: heycam

CSS3-UI box-sizing

  <tantek> https://lists.w3.org/Archives/Public/www-style/2015Feb/0243.html
  <tantek> [css3-ui] box-sizing and replaced element intrinsic width
           and/or ratios
  <tantek> Regarding this issue: https://wiki.csswg.org/spec/css3-ui#issue-69
  tantek: The first email I posted a couple of test cases.
  tantek: Each has an HTML file and three SVG elements.

  tantek: The first one we should bring up is the replaced element
          test case.
  tantek: It shows what happens in three different cases of
          embedding SVG as an image that has intrinsic width and
          ratio, or just intrinsic width, or just intrinsic ratio
  tantek: and what happens when you apply the max-height property to
  tantek: Shows interaction of CSS 2.1 width computations and
          embedding replaced SVG element.
  tantek: I want to start with this example because it's all stuff
          that should "just work" across browsers, but we found
          differences that merit questions
  tantek: before we decide what box-sizing should do in these cases.

  [Florian projects replaced-element-001.html]
  tantek: In doing these tests we didn't find any differences
          between Blink and Safari.

  tantek: There are some interesting things going on here.
  tantek: I put the style rules that are taking place at the top
  tantek: that apply to each SVG element
  tantek: then the SVG markup inline so you can see what the source
  tantek: My understanding is that the top row should all be yellow
  tantek: 150x150 px.
  tantek: It looks like IE is doing the wrong thing there
  tantek: by not maintaining the aspect ratio.
  tantek: That's in the SVG file.

  tantek: First, I want to verify that that's correct and that it's
          a bug in IE.
  fantasai: So the specified width is 100px?
  tantek: No the intrinsic width is.
  fantasai: And the specified width is not specified?
  tantek: Correct.
  dbaron: And it has a viewBox such that it has an intrinsic ratio
          of 1:1?
  Florian: And there is max-height: 100px that shouldn't take effect.
  Florian: But if you look at IE it seems to be doing something.
  Florian: Both IE and safari are doing strange things on the bottom.

  tantek: I want to check with SVG people that these cases are buggy
          in the browsers.
  <tantek> https://lists.w3.org/Archives/Public/www-style/2015Feb/0243.html
  gregwhitworth: In Edge the top yellow one is fixed, the bottom one
                 is the same as Firefox/Presto
  Florian: So that confirms the IE cases I'm looking at are bugs.
  Florian: IE11.

  tantek: So latest IE11 and latest Safari are buggy in handling
          intrinsic ratio, but not intrinsic width/height
  tantek: and Chrome does the same as Safari, so Blink/WebKit must
          be the same.
  dbaron: Safari is buggy on the third case.
  heycam: We had a big discussion about SVG sizing last year at a
  heycam: I don't remember the details except that we resolved on
          Firefox's behavior modulo some corner cases.
  tantek: So Edge has these fixed, and I'm hoping that WebKit/Blink
          can fix the third sub-test.

  tantek: So this isn't the actual issue I want to discuss; just
          want to get a baseline about which behavior is correct.
  ed: I think the behavior on the left side (Firefox and Presto) is
      what we want.
  krit: People who are very familiar with this topic are not in this
        room so I would like to consult them.
  ACTION: Dirk to confirm that the Firefox/Presto behavior of this
          SVG sizing test is correct and get back to Tantek
  <trackbot> Created ACTION-87

  tantek: So we'll switch to box-sizing-replaced-element-001.html
  <tantek> second test here:
  <tantek> file name box-sizing-replaced-element-001.html
  <tantek> http://dev.w3.org/csswg/css-ui-3/#propdef-box-sizing

  tantek: What the box-sizing property allows you to do is change
          what width/height properties do.
  tantek: You can make them include the borders and padding of the
  tantek: So if you want to figure out the content width you would
          subtract the border/padding.
  tantek: Any questions about box-sizing:border-box?
  tantek: (default behavior is content-box)

  tantek: In this example, because box-sizing is set to border-box,
          now the 40px solid transparent border kicks in, and cuts
          out from the max-height.
  Florian: We still have an SVG file with an intrinsic width of 100
           and a viewBox ratio of 1:1.
  tantek: Identical SVG files to the previous test.
  tantek: The three subtests are in the same order as the previous

  dbaron: I think the Firefox behavior on the second subtest is
          clearly buggy.
  dbaron: I think we're applying to the box-sizing to the width that
          is coming from inside the SVG, which we should not be

  fantasai: Are these embedded cases?
  Florian: SVG in <img>
  Florian: As far as we can tell Presto is doing the right thing
  tantek: We think that is the desired result, so we want to check.
  dbaron: I agree.
  fantasai: Should be equivalent to max-height:110px?
  Florian: max-height:70px.
  tantek: On the first row we have IE and Safari agreeing on the
          wrong thing.
  tantek: So we just want to confirm our assumption on which is

  fantasai: One thing making it more confusing is that the content
            box height is different.
  fantasai: So if you put border:25px max-height:200px you should
            get the same result as the previous test.
  fantasai: The boundary of the width of the SVG is 100px, in the
            previous test you were above that, in this test you're
            below that.
  fantasai: So you're triggering different cases.
  fantasai: I think you should test in all cases above the trigger
            point, or all below the trigger point.
  fantasai: The behavior differences might be due to something other
            than max-height.
  tantek: So we changed just one property to see what happens.
  fantasai: The numbers you picked made it change more than one
  tantek: That was unintentional.
  fantasai: Change the border to 25px max-height to 200px
  fantasai: We should also test this situation, btw.

  gregwhitworth: Edge is matching Firefox here
  gregwhitworth: Chrome is doing the same as Firefox on my windows
  gregwhitworth: v40.
  gregwhitworth: So this may end up being an issue with them talking
                 to our compositor.
  gregwhitworth: Right now on windows, firefox / edge ie / chrome
                 have interop
  gregwhitworth: on the second case.
  <gregwhitworth> Windows SVG Test: http://imgur.com/xbHMI0r

  <dbaron> Filed Gecko bug https://bugzilla.mozilla.org/show_bug.cgi?id=1131812
  dbaron: In the second case I believe we have some code that
          extracts a width that's specified embedded in an SVG, and
          applies that to the sizing outer of the img element
  dbaron: because that's kind of how the sizing algorithm works.
  dbaron: So we're taking the width from the SVG, applying it to the
          img element, then applying box-sizing.
  Florian: So doing the same thing as if the SVG was embedded inline
           in the HTML?
  dbaron: Yes.
  Florian: If that were the case the box would be 20px wide wouldn't
  Florian: And it looks more than that.
  dbaron: yeah...
  dbaron: OK I'm not sure what's happening then. but I think it's

  <tantek> New test with fantasai suggested changes:
  <tantek> File name box-sizing-replaced-element-002.html
  tantek: I just sent the updated test that fantasai asked for to
  dbaron: This would be a lot easier if you emailed the individual
          files as attachments of the one email.

  tantek: So now this test has fewer effective changes as -001.html
  fantasai: So this test -002 now looks identical to the first test
            we looked at.
  gregwhitworth: IE Edge matches Firefox/Presto here.
  Florian: Which is the same as Safari except for the third case
  Florian: so it's just a bug in Safari.
  tantek: Which is why we wanted to show you without box-sizing, to
          show the WebKit's handling of intrinsic ratio is buggy.
  tantek: If we can agree here what behavior we want florian and I
          will specify it.
  Florian: Once box-sizing gets involved, if we don't apply min/max
           width/height it's not explicit, but still not ambiguous
  Florian: but with min/max-width/height, we need to specify
  Florian: I think Presto has reasonable behavior.

  krit: This is something we should clarify with SVG the correct
  Florian: What is missing on the SVG side?
  krit: At least consensus on how viewBox etc. should operate on an
        SVG in <img>.
  Florian: Is there anything other than SVG that can give an
           intrinsic width, ratio, but no height?
  Florian: The spec says if you have an intrinsic width, do this. if
           you have width and ratio, do this.
  tantek: CSS has explicit clauses for each of these cases.
  krit: This is with intrinsic width and ratio, but not intrinsic
  Florian: Yes.
  Florian: We haven't got to intrinsic height but no width yet.
  krit: OK then the left two browsers are right.

  cyril: In the cases where the square is a rectangle and not a
         square, do you know if there's a bug in the rendering of
         the SVG and the aspect ratio is not preserved...
  cyril: and the box is filled with the SVG content?
  dino: For all three we need a circle in the SVG to see whether the
        bottom one is being clipped or stretched.
  Florian: So can we use something other than SVG for testing here?
  tantek: No.
  dino: As krit is saying, it's not well defined. It also has its
        own rules for preserving aspect ratio internally inside its
  tantek: We're trying to look at this from the point of view that
          implementations are converging, so we'd like to follow
  dbaron: I think this is well defined now.
  tantek: in SVG?
  fantasai: I remember the SVG WG saying that it's totally clear, or
            that they would fix it.
  fantasai: So either that didn't happen or someone's confused.

  krit: In this case we also didn't discuss object-fit.
  Florian: That's not involved yet. but we will discuss that later.
  krit: That is the case for inline SVG. For <img> we haven't had
        the discussion yet.
  krit: We likely should have the same rules for inline and in <img>
  Florian: The way they start interacting with CSS is different.
  tantek: The width attribute in inline is not intrinsic but
  tantek: So that's very different for these sizing computations.
  <fantasai> width/height in an inline SVG is both specified and
             intrinsic size.
  <fantasai> SVG specifies that it's the intrinsic size, and CSS
             specifies that it's the specified style.

  <Tav> http://tavmjong.free.fr/SVG/SCHILLER/html
  Tav: These are some tests I made from a few years ago, with SVG
       sizing in img, iframe, etc.

  dbaron: What are we trying to accomplish right now?
  Florian: tantek and I have an idea on patching the spec that seems
           reasonable. we want to see if it matches reality and that
           others agree.
  Florian: If none of the browsers is doing the right then, then...
  dbaron: What are the questions about how to integrate box-sizing?
  Florian: As long as you don't involve max-height/width, it's easy.
  Florian: Once you have a bit of an algorithm and lots of rules for
           width height, it doesn't say which width height to work
  dbaron: I think that algorithm should be interpreted as working on
          content box sizes.
  dbaron: There might be other implementation bugs that are worth
          discussing separately.
  dbaron: I think the box-sizing spec update should be done because
          that's how it should work.
  fantasai: Is there any question in what you want to specify?
  Florian: Unless someone strongly believes a non-Presto behavior is
           right, no.
  fantasai: That's fine.
  tantek: We didn't expect this many bugs :-)
  dbaron: The SVG sizing stuff is pretty recently specced

  <TabAtkins> Just found out the <iframe src=foo.svg> sizes itself
              to the SVG's intrinsic dimensions, rather than 300x150
              like the spec says.
  <TabAtkins> WTF explicitly changing sizing rules without telling
              the WG about it.
  <TabAtkins> Sorry, *in Safari*.
  <TabAtkins> dino: ^^^ ???
  <fantasai> TabAtkins: Why do you think the spec says to make it
  <TabAtkins> fantasai: Because the spec doesn't specify where to
              take dimensions from for <iframe>?
  <fantasai> It's a replaced element.
  <fantasai> Just like an image.
  <fantasai> There is nothing in any spec that says <iframe> (as a
             tag) is style differently from <object> or <img>. No
             tag-specific behavior is specified anywhere.
  <hober> fantasai++

  <cyril> email sent with updated svg tests (including a circle),
          please consider the second email (the first one had a
          wrong radius value)
  <cyril> https://lists.w3.org/Archives/Public/www-style/2015Feb/0247.html
  gregwhitworth: On windows, the very first test is similarly buggy
                 in Firefox/Presto/IE.

  tantek: The concern is that we if we have bugwards compat on this
          purple case, that's worrisome, because we think Presto's
          behavior is correct.
  tantek: Presto is treating the intrinsic width all by itself, and
          because there's nothing in the dimensions that apply to
          the width computations at all, ...
  Florian: There is no constraint on the width.
  Florian: In the height dimension it shrinks down to 70.
  tantek: There's no intrinsic ratio, so they're computed separately.
  Florian: This purple subtest has no intrinsic ratio.

  ed: Do you have enough to go on here?
  tantek: Firefox sets the width to 47px, which is very odd.
  gregwhitworth: Since I don't know about SVG I'm completely ok with
  dbaron: The weird Firefox behavior is not related to box-sizing.
  dbaron: If I remove the box-sizing, remove the max-height, change
          the border, I get the same output.
  dbaron: This might be coming from default sizing not being
          300x150, for SVG
  dbaron: If you work through that long list of rules, the way
          max-height applies doesn't always preserve the intrinsic
  Florian: On the second one there's no intrinsic ratio.
  dbaron: Or doesn't always preserve the things you want.
  dbaron: If I change the max-height to height, you get the expected
  dbaron: I think there is something in the spec rules that gives
          the 47px result.
  fantasai: I think the only weird cases are when you're balancing
            conflicting requirements.
  Florian: But in this case we're not over constrained.

  fantasai: Let's resolve the behavior on we want, not on "what
            Presto does".
  SimonSapin: Is this looking at CSS 2.1?
  <SimonSapin> (as opposed to the CSS Images module)
  tantek: Yes, plus box-sizing.

  <tantek> https://wiki.csswg.org/spec/css3-ui#issue-69

  RESOLVED: We will patch the CSS 2.1 width computations to specify
            it uses content width, which is implied but not explicit
            (which we assume will get Presto's behavior).
  <fantasai> CSS2.1: “This property specifies the content width of
             boxes. ”
  <fantasai> CSS2.1 is very clear that it's talking about content

  <dbaron> FWIW, I can explain where the 47px comes from
  <fantasai> dbaron, go ahead, I'm very curious :)
  <dbaron> Without the max-height, the SVG should be 100px wide and
           150px tall, since the default size is 300px x 150px, and
           the SVG has a width=100 that overrides the 300. Then the
           max-height:150px with the box-sizing is equivalent to max-
           height: 70px... and when we apply the max-height, we
           scale the image down by its ratio, so the 150px -> 70px
           and 100px -> 47px (in the same ratio). So the bug is that
           we're incorrectly scaling down by ratio in that case, I

Interaction between Overflow, Positioning and Filters

  <roc> http://fiddle.jshell.net/mkud1Lnm/1/
  roc: This is basically a spec issue, as to what should be rendered.
  roc: Right now specs don't really say
  roc: and it's tricky to fix, there's no obvious way to fix it.
  roc: If you look at the fiddle, what we have is there's a div
       container with overflow hidden, but it could be any clipping.
  roc: It has a filter on it, in this case a blur,
  roc: and a couple of elements inside.
  roc: One of the elements is position:fixed (but also happens with
  roc: The positioned div is not supposed to be clipped by the
       element that has overflow:hidden
  roc: but it's in a filter and some of the content of the filtered
       image should be clipped, while some shouldn't.
  roc: It's really unclear how to render this example.
  <smfr> To me this is a pretty fundamental failure to spec the
         interactions between the clipping tree (which  follows
         containing block) and the z-order tree.

  roc: If you bring it up in Chrome or Firefox, you get a rendering
       where both of the elements are clipped.
  roc: In particular the yellow one is clipped to the
       overflow:hidden element, but technically it shouldn't be.
  roc: You can't say it's not clipped, since with the blur, some
       pixels have contributions from both the blur and the yellow
  roc: It's unclear what the visual result should be.
  roc: There's no way to preserve the behavior that one of these
       elements is clipped, one is not, but they're filtered
  roc: The problem does not arise for opacity, that's because
       opacity commutes with clipping.
  roc: If you clip then opacity, it's the same as opacity then clip.
  roc: Not true for general filters.
  roc: Because opacity commutes, you can push it down, and get the
       results you'd expect,
  roc: but with filters you can't.

  roc: What gecko and chrome are doing is rendering the contents to
       a buffer, applying the filter, then because the filtered
       element is in overflow:hidden, we clip the filtered result.
  roc: The question is what to spec:
  roc: try to explain that behavior, or we introduce some
       restrictions on the interactions between filters and
       overflow:hidden and positioning,
  roc: so that it's well defined.

  roc: Is the problem clear?
  roc: We could directly specify what Chrome/Firefox are doing, and
       one way to do that would be to say that overflow clips ---
       right now overflow:hidden clips every descendant for which it
       is a containing block.
  roc: We could say it clips every descendant for which it's a
       containing block plus it clips all descendants of elements
       that have a filter.
  roc: That's option #0 (I didn't put that in my email).
  roc: Option #1 from my email is that filter is like transform,
       becomes a containing block for positioned elements
  roc: so they can't escape from the filter.
  roc: So the current definition of overflow:hidden would mean it
       applies to them.
  roc: Option #2 is you could say the filter doesn't affect the
       positioned descendant, it can escape the filter.
  roc: So filters only apply to things for which the filtered
       element is the containing block.
  dino: So the yellow element would not be filtered?
  roc: Yes.

  Tav: I'm a little confused. the way I think about it, if you take
       something that's being filtered -- if you have an image and
       you move/animate it, you don't want to see side effects.
  dino: Simon prefers filtering winning over the overflow.
  dino: So stacking context is more important overflow
  dino: So not the choice where yellow div is not filtered.
  roc: I'm for option #1.
  roc: If we can make filters a container for positioned descendants
  roc: there's some web compat risk, not a whole lot.

  heycam: Would you often want positioned things inside filtered
          elements? maybe not.
  dino: Simon says it sucks opacity and filters are not treated the
  roc: It does kind of suck.
  roc: I don't have any alternative to that.

  dino: With blending, we don't have the same issue?
  roc: No, because blending commutes with clipping.
  roc: If you have an opacity:0 pixel, blending can't turn that into
       something that is not opacity:0.
  krit: Not yet.
  roc: If we add all the porter duff modes then it would be an issue.
  roc: We could change blend modes now, to force the same behavior.
  roc: That would guard us in the future.
  Tav: Option #1 makes sense to me.

  dino: I agree with making blending operate the same, and doing
        that now.
  roc: We've been talking about adding an escape hatch for
  roc: So transforms are not a positioning container.
  roc: If we do that we could have keyword on transforms.
  krit: All blend modes we implement use src-over compositing.
  krit: I don't think we want to combine blend modes with other
        compositing modes.
  roc: If we introduce other compositing modes, will it be in
       mix-blend-mode or a different property?
  nikos: Suggested to be in a separate property.
  roc: In that case we don't need to add restrictions for
       mix-blend-mode now,
  roc: so that new property would need to create a container for
       positioned elements.
  roc: So we won't change mix-blend-mode behavior, but will do it
       for filters.
  heycam: You could restrict this filter behavior for only some
          predefined filter keywords.
  <smfr> heycam: ick, what if you animate between them?
  roc: I don't feel like we want to do something that complicated
  smfr: Indeed, the position of elements could change when you
        change the filter behavior.

  RESOLVED: Non-none values of filter induce a containing block for
            all positioned descendants.

  ACTION: Erik to make non-none values of filter induce a containing
          block for all positioned descendants
  <trackbot> Created ACTION-88

  -- 15 min break --

Canceling and interrupting transitions

  dbaron: let's postpone until after lunch
Received on Friday, 20 March 2015 06:39:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:52 UTC