<scribe> Scribenick: dael
<Vlad> no noise here as well
Rossen_: One more minute and then
we'll get going
... Let's go ahead and get going
... Usual item number one, any extra agenda items?
Vlad: I sent a digression topic
Rossen_: I didn't see it.
Vlad: I sent to working group
Rossen_: Yes, yes. Also a
reminder to add agenda + to the F2F topics. Don't be surprised
if we add stuff to the wiki.
... Anything before we give Vlad he floor?
<tantek> https://github.com/w3c/csswg-drafts/issues/2438
tantek: 2 weeks ago I brought up the problem with the state of the test documentation. If folks want to look, feel free to comment on the issue. I don't think we need to discuss on call
Rossen_: Okay. Please look at isue 2438 from tantek and engage to help prepare test suite talks.
tantek: I'd like it on F2F agenda
Rossen_: Go for it.
... Other topics?
<Rossen_> dael, no need to minute this
Vlad: There's 28 participates for F2F, 15 marked the dinner column. I want to make sure we have the right numbers.
<leaverou_> ChrisL and I are in for dinner, not sure if we checked that column
github: https://github.com/w3c/csswg-drafts/issues/2427
Rossen_: Summary: there was a
question about hey we are seeing a couple of ways repeat() is
being serialized, why can't we have one?
... Edge supports serialization of repeat() by using repeat
syntax and computed values inside.
... FF, Webkit, and Chrome serialize as a list of computed
values.
... Question from TabAtkins and fantasai was just tell us which
you want, we don't care.
<leaverou_> What if the number to repeat by is a var()?
<Rossen_> https://wptest.center/#/nsrrq1
Rossen_: Seems Igalia is pushing for simpliest which is not use repeat() syntax and they asked MS to voice our thoughts. My position is having repeat() serialize as a list is more difficult for editors and script to handle. Test case inside the issue serialization is okay, but if the repeat >2 in chome if you use 5000 you get 100 columns and it drops. FF is between
<fantasai> leaverou_, it's the used value that gets returned by gCS
<leaverou_> Oh right
Rossen_: Having to parse this
many is harder. Finally, this isn't new. grandant-repeat() has
the same challenge but we're not serializing a list.
... Our opinion is preserve the repeat syntax and have others
catch up.
... Looking for other opinions.
AmeliaBR: What if author has spec
columns that could be collapse?
... If the author has literally specified multiple coluns
without using repeat syntax but they could be collapsed using
repeat would you serialize that using repleat?
Rossen_: Not really. That's like saying if we have width 10px why not serialize as calc(10px). I don't believe shorter is the goal here.
AmeliaBR: Just so long as there's a clear definition. You agrue keep as spec by author
Rossen_: Right. Roundtrip of repeat serializes as repeat, not a bunch of values.
<Rossen_> grid-template-columns: repeat(2000, 100px);
Rossen_: In the test case from
Igalia you have the repeat syntax that looks okay, but if you
try this ^ the serialization is crazy.
... Any other opinions?
... If not, can we resolve?
... Objections to keeping repeat syntax as is currently in the
spec and open bugs for other impl to do that?
frremy: Spec is a may. So there is no implementation bug to file unless it's a must.
Rossen_: A ha. good point frremy.
I didn't realize this was a may.
... Objections to specifying the repeat() syntax serialization
as a must?
<AmeliaBR> +1 to interop!
TabAtkins: Yes, we should spec one way or the other as a must.
Rossen_: I'm not hearing objections.
RESOLUTION: serialization of the repeat() MUST use the repeat syntax
github: https://github.com/w3c/csswg-drafts/issues/1971#issuecomment-370692229
Rossen_: florian sent regrets. can someone else take it?
fantasai: There's several issues
here. Main one is that we wanted to figure out what various
values of overflow compute to when you set...set x axis but not
y.
... Before we introduced clip any value that's not visible in
one axis causes the other axis compute to auto so you have a
scroll container in both axes.
... Clip didn't spec how to compute. In general it was supposed
to not trigger a scroll container.
... Combo of clip in one axis and visible in the other seems to
be valid and should not cause visible to compute to auto
<fantasai> https://github.com/w3c/csswg-drafts/commit/1d1a8e9caf4333518620e32f2a8b08ec3efdfa13
fantasai: We updated computed
value field. That's the first request. Current text says if one
axis is not visible or clip then any axis that's visible or
clip computes to atuo or hidden
... Changeset^
... That raised the question of but clip creates a BFC and
visible doesn't, what happens when it's overflow:visible in one
axis and clip in the other. That caused a sep discussion on if
a BFC.
Rossen_: WE should take these one at a time. Thought they're related I think we can resolve independantly.
dbaron: Bigger issue is should clip create BFC and the other thing falls out.
Rossen_: Correct. fwiw I think we
had this discussion in the past and every time we do a full
circle and at the end we convince ourselves that not having it
be a BFC becomes complex for implementation.
... At least what I recall is are how floats that start before
the element with a clip and extend past the clip region, how
are they effected in terms of flow.
... If clip is intended to be render time only
effect...nevermind.
... The interaction between floats that start before clipping
elements or those on the side are hairy if overflow:clip is not
BFC. If it is BFC it's predicatble but then you have
overflowing visibly content to the lefft or right and because
BFCs allow floats next to them you have overlapping content
with floats.
<dbaron> I didn't actually follow that... and I actually don't remember having this discussion before.
Rossen_: Every time we have this
discussion I recall us coming back to the BFC one makes the
most sense if we have to impl.
... I'm happy to discuss one more time if people think we can
arrive at a different resolution.
TabAtkins: I think it's clear if
there's a bfc creating context it's scroll. For clip it's just
a matter of what hte intent of the value is. If as dbaron says
clip is supposed to be like visible but without painting
outside the bounds that's fine. Geometry will project out but
it does what we're asking for here.
... If we want to restirct geometry clip is hidden with 0
ability to scroll. We have to decide.
fantasai: Or we make it effect alyout by truncating the float.
TabAtkins: That's a new concept that I'd prefer not to add.
<AmeliaBR> Floats affecting layout outside of the container but not painting outside the container sounds super confusing.
dbaron: The two things we described extend existing concepts and don't require huge changes. If we create one of those concepts we may decide to make the other in the future so we should name appropraitely.
TabAtkins: IN that case, on naming issue, perhaps we can plan for visible-clip and hidden-clip to suggest they're same as base...wait...doesn't make sense.
Rossen_: What was the motivation use case here?
TabAtkins: I presume dbaron can explain the visible unscrollable
dbaron: It's what css2.0 spec. The hidden creating a scroll container and bfc was new to 2.1. It's what the WG rec recommended for a decade.
Rossen_: and you're only impl?
dbaron: I think so. Other impl did hidden in terms of scrolling.
Rossen_: If this is back compat with not compat reature should we decide?
dbaron: I don't think that's why it was added to spec.
Rossen_: Was it used anywhere?
dbaron: Internally. not externally.
fantasai: I think idea was to not
have some of the hidden side effects like a scroll
container.
... Has a bit more effect on stuff now then in the past. In the
past it meant you have slightly different perf considerations.
Sometimes certain user events can scroll a hidden thing.
Currently if you turn something into a scroll container it
catches things like scroll snap
Rossen_: This is a large topic. I think this is perfect for whiteboard between sessions thing and convince ourselves one way or another. And then hopefully we have florian. Should we table?
TabAtkins: I'm fine right now resolving clip is the visible but doesn't paint outside the bounds thing. I can see use cases for it as fantasai describes. Doesn't disturb margin or capture scroll snaps.
Rossen_: Margin collapsing and everything else?
TabAtkins: Same as visibility.
Rossen_: Visibility:hidden takes layout space.
TabAtkins: This will too
Rossen_: No, it says you stop at the bounds of your container. Which means if you have a whole bunch of floats or 0 height divs with negative margins that effect after clip but they're overflowing, do you take that into account?
TabAtkins: I'm not willing to spec something that clips geometry. I'd be happy with the it's like visible buy clips paining
Rossen_: If you don't have floats
and a div with overflow-clip:veritical and a bunc hof text with
at the end a div with a huge negative bottom margin. It
overflows.
... After the clip the div isn't visible nor is the content. Is
the negative margin in effect?
TabAtkins: Full geometry. Exactly like visibility:hidden but you extend the geometry
dbaron: I'm not sure visibility:hidden is greatest analogy, but it's purely a paint time effect. Layout is the same as overflow:visible but descendors outside bounds are clipped
frremy: We haave requests for overflow:hidden but have position sticky work and I think this fixes that.
TabAtkins: That's good. Another
thing scroll containers block. Nice use case.
... I'm seeing good reasoning for a purely paint time clipping.
You'll have weird looking stuff sometimes, but that's going to
be rare. If you don't want that use overflow:hidden
Rossen_: And we shouldn't ask
people to do that with clip or clip path? How many other ways
do we have for clipping?
... This was the intent of css clip in 2.1
TabAtkins: Good point.
dbaron: Clip in 2.1 was only for abspos. We can't change that due to compat.
Rossen_: I don't think we can
undo the things in the past. What we can do is narrow down this
issue and see if we can get consensus
... Sounds like most people feel like overflow:cip is a paint
time only operation and we shouldn't require that a element
with overflow as clip in either direction be a BFC. The note in
the spec would be yes geometry and everything else works as it
does before and if geometry overflow it will have side
effects.
<fantasai> +1
Rossen_: Would people object to this as a resolution?
RESOLUTION: overflow:clip is a paint time only operation and we shouldn't require that an element with overflow as clip in either direction be a BFC nor a scroll port.
<TabAtkins> Yeah, not seeing why we shouldn't just use clip-path here. Need to recall what the syntax is of just clipping to border box.
Rossen_: Now if overflow computes to clip in one direction or visible in the other. If we have overflow...I'm confused if we need a resolution. If you have overflow auto or scroll in one direction the other is hidden by default. If you have clip in one direction the other is visible.
TabAtkins: We need a resolution because we have termonoloy that talks about this.
Rossen_: What would you want to call this?
TabAtkins: Dunno
fantasai: I'm confused that we need. If we have the reoslution we need to resolve on the changes in the issue.
TabAtkins: We have various specs that have behavior when overflow is non-visible, but it means when it causes a scroll container. So clip now falls into visible so we need specs to refer to a term.
Rossen_: Can we replace to overflow computes to scrollable or non-scrollable?
fantasai: It's editorial. We don't need a resolution.
TabAtkins: Yeah. But we need to do it.
Rossen_: No more resolutions needed and we can move on?
github: https://github.com/w3c/css-houdini-drafts/issues/659
TabAtkins: If anybody has strong opinions I"m happy to go with it. You gab a ComputedStyle map. It has changes to the underlying element. What happens if the element isn't in the document? What happens if you grab the map off of something and then moves the element to another document and you query the computed style. What's it reflecting?
Rossen_: For the first one, what
happens on an element that is not connected to the current
document but is constructed from script and you ask for a
styleMap. Everyone but Edge returns initial values. We try to
do more and try to compute the cascade on that sub tree in the
ether.
... I don't think this is great. We do see some interop issues,
but not huge. We went to some effort to represent the cascade
style and we'd prefer not to
TabAtkins: If you try to get a
style map off of something in the document I'm happy to say it
throws. If you have a computedStyleMap and the lement is
removed any attemt ot get or set throws.
... That's easier for everybody.
Rossen_: I support that. Makes it a lot more predicatble.
TabAtkins: Let's resolve on that.
Rossen_: Proposal: computedStyleMap is a live object that returns all expected values when attached to main markup and throws otherwise
TabAtkins: If you attempt to get a computedStyleMap or use a computedStyleMap on an element not in the document it throws
Rossen_: Obj?
RESOLUTION: If you attempt to get a computedStyleMap or use a computedStyleMap on an element not in the document it throws
TabAtkins: Sub issue if you grab
a computed style map while in doc a and it moves to document b
do you get a value?
... I think the style map just reflects the value in the new
document.
... Issue is what is the document providence of the objects
returned. Different documents have different globals. Would
computedStyleMap from old doc still work? Or return typedOM
values from old or new doc?
... Those problems make me lean throw here as well.
Rossen_: Not sure. This is eq. to grabbing a style sheet from one doc and intesting to a new doc. You would expect everything will return values...
TabAtkins: That's fine because it's immutable perm. strings. This is using an old object. If you say is this style map part of doc a it's [missed]
Rossen_: Because it's mutable it's a problem.
TabAtkins: Yes.
... I'm fine with putting in a doc check.
Rossen_: That or we can...we can keep referential integrity and re-calc everything. So you still have the live object but a new topogaphy on it.
TabAtkins: The obvious way to
define what global the produced elements are from is the global
of the method you call to create. So get on computerStyleMap so
your unit values are from the old document. That falls out and
might be okay, but it's a weird mix of values from different
docs.
... You're still producing style values from the old.
Rossen_: I'm fine more restrictive for now and if compelling use cases arrise and extend life time we'll deal then.
TabAtkins: Yeah. And solution is to call getComputedStyleMap on the new. So throw now and relax later if we need to?
Rossen_: Yeah.
TabAtkins: Check for previous resolution can also check if it's in the same document as the map cares about.
Rossen_: Other opinions or objections?
RESOLUTION: style maps of elements moved between documents throw
Rossen_: So if element moved or created in the ether or moved and you try and use it it throws. Only time where you can take the element out, put it back in the same document, that'll work?
TabAtkins: Yes unless you call middle of append steps. Yes. Moving elements within doc has no negative effect.
Rossen_: That's what I wanted to point out.
github: https://github.com/w3c/csswg-drafts/issues/2439
leaverou: Two weeks ago we
cleared conic gradient for shipping. Turns out many conic
gradient in the wild were using the two locatiosn. It's been in
the draft for 6 years. Chrome impl a year ago because it was in
many demos
... Dev that impl asked if he can ship it as well. Chrome impl
a year ago. I don't see why not.
ChrisL: I think it's an obvious good thing.
leaverou: It's what I said in issue.
ChrisL: Question for chrome folks. THere's a question in the spec as to if fixup applies before or after layout. I don't think that effects this issue.
leaverou: I don't see why depend on layout
ChrisL: There's an issue that says it might
<fantasai> I thought we resolved on that in Tokyo?
TabAtkins: Not sure
ChrisL: Can you find out?
... IN general I support this.
<AmeliaBR> +1, this is a very useful syntax (especially when using variables in gradients), doesn't involve any new rendering code, only computed value changes.
ChrisL: People are using it and it's a trvial extension.
Rossen_: Hearing some support. Other opinions? Esp from Chrome folks who are shipping?
TabAtkins: I'm fine with shipping I agree it's minor feature very useful.
<tantek> we have tests?
<fantasai> ChrisL, https://lists.w3.org/Archives/Public/www-style/2017May/0051.html
<leaverou> tantek: we don't have tests for ANYTHING about gradients!
<tantek> SMH
Rossen_: Objections to color stops are extended into their consecutive color stops?
leaverou: Color stops with two positions
<tantek> so now we're agreeing to ship features based on demoware?
<AmeliaBR> It's basically adopt https://drafts.csswg.org/css-images-4/#color-stop-syntax
<leaverou> Color stops with two positions are expanded to two consecutive color stops with the same color
frremy: This is in spec we just have to say fine to ship
leaverou: Yes.
Rossen_: I heard no objections.
RESOLUTION: clear gradient color stops with two locations for shipping
<tantek> just WD right?
Rossen_: We're at top of hour. We
couldn't get to display or value issues, those will push to
next week.
... I'll miss next week so see you in Berlin!
<ChrisL> just wd, which is why we needed a clear to ship. would not be needed for CR
<tantek> yeah prototypes are good enough for WD
<Rossen_> trackbot, end meeting
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/test/tests/ Default Present: Rossen_, bdc, rego, dael, rachelandrew, Florian, antenna, ericwilligers, fantasai, alex_antennahouse, antonp, dauwhe, tgraham, smfr, lajava, bradk, tmichel, tantek, leaverou, Chris_, melanierichards, liam, :), birtles, plinss, nainar, myles, TabAtkins, astearns, gsnedders, dbaron, Chris, present, Vlad, tgraham``, krit, Amelia, AmeliaBR, fremy, tgraham`, xidorn, shane, franremy, dino, garrett, bkardell_, jensimmons, ChrisL, frremy Present: Rossen_ bdc rego dael rachelandrew Florian antenna ericwilligers fantasai alex_antennahouse antonp dauwhe tgraham smfr lajava bradk tmichel tantek leaverou Chris_ melanierichards liam :) birtles plinss nainar myles TabAtkins astearns gsnedders dbaron Chris present Vlad tgraham`` krit Amelia AmeliaBR fremy tgraham` xidorn shane franremy dino garrett bkardell_ jensimmons ChrisL frremy Found ScribeNick: dael Inferring Scribes: dael WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 28 Mar 2018 People with action items: WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]