- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 20 Mar 2015 02:38:58 -0400
- 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-
sizing.
- 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.
===== FULL MINUTES BELOW ======
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
it.
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
is.
tantek: My understanding is that the top row should all be yellow
square
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
F2F.
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:
https://lists.w3.org/Archives/Public/www-style/2015Feb/0243.html
<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
element.
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
test.
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
doing.
fantasai: Are these embedded cases?
Florian: SVG in <img>
Florian: As far as we can tell Presto is doing the right thing
here.
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
right/wrong.
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
thing.
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
laptop.
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
it?
Florian: And it looks more than that.
dbaron: yeah...
dbaron: OK I'm not sure what's happening then. but I think it's
buggy.
<tantek> New test with fantasai suggested changes:
https://lists.w3.org/Archives/Public/www-style/2015Feb/0245.html
<tantek> File name box-sizing-replaced-element-002.html
tantek: I just sent the updated test that fantasai asked for to
www-style.
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
something.
Florian: I think Presto has reasonable behavior.
krit: This is something we should clarify with SVG the correct
behavior.
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
height?
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
viewBox.
tantek: We're trying to look at this from the point of view that
implementations are converging, so we'd like to follow
them.
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
specified.
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
on.
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
300x150?
<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
this.
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
ratio.
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
behavior.
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
widths.
<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
believe.
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
position:absolute).
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
divs.
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
together.
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
same.
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
transforms.
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