- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 13 Mar 2016 08:38:12 -0400
- 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.
=========================================
Overflow
--------
- 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
feedback.
- A conversation about CSS containment and overflow:clip will be
added to Tuesday's agenda.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/sydney-2016
Scribe: gregwhitworth
Overflow
========
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
today.
fantasai: There is also a placeholder section for max-lines
property.
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
helpful.
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
clipped.
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]
https://www.w3.org/TR/css-text-3/#hanging-punctuation-property
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
padding.
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.
*murmurs*
<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
confusing.
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
Masking
-------
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]
https://www.w3.org/TR/CSS21/visufx.html#clipping
“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
expensive.
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
bounds.
Rossen: We would have to implement masking within layout in order
to take into account all of the children that are to be
masked.
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
rectangle.
<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
it)
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
sites).
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
shape-inside.
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
bounds
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
should.
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
spec.
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:
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3856
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
areas.
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
happens?
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
containment.
ojan: Do other implementors have thoughts on this?
ojan: Is anyone thinking about impl this (I know Apple can't say
anything)
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
https://wiki.csswg.org/planning/sydney-2016#tuesday-am
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
overflow.
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
size.
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']
ADJOURNED.
Received on Sunday, 13 March 2016 12:39:11 UTC