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

[CSSWG] Minutes Telecon 2018-03-28 [css-grid] [cssom] [css-overflow] [typed-om-1] [css-images-4]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 28 Mar 2018 20:41:52 -0400
Message-ID: <CADhPm3uGXpKkjunF9vL6aLW-5mfewFyfFc9ohtPUwJCupQjkpA@mail.gmail.com>
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.

Test Suite

  - An issue was created to make progress improving the test suite
      documentation. Everyone is encouraged to review and contribute
      on the thread: https://github.com/w3c/csswg-drafts/issues/2438

CSS Grid

  - RESOLVED: Serialization of the repeat() MUST use the repeat
              syntax. (Issue #2427)

CSS Overflow

  -  RESOLVED: 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. (Issue

Typed OM

  - RESOLVED: If you attempt to get a computedStyleMap() or use a
              computedStyleMap() on an element not in the document it
              throws. (Houdini Issue #659)
  - RESOLVED: Style maps of elements moved between documents throw.
              (Houdini Issue #659)

CSS Images

  - RESOLVED: Clear gradient color stops with two locations for
              shipping. (Issue #2439)


Agenda: https://lists.w3.org/Archives/Public/www-style/2018Mar/0044.html

  Rossen Atanassov
  Tab Atkins
  David Baron
  Amelia Bellamy-Royds
  Garrett Berg
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Benjamin De Cock
  Elika Etemad
  Simon Fraser
  Tony Graham
  Dael Jackson
  Vlad Levantovsky
  Chris Lilley
  Peter Linss
  Thierry Michel
  Michael Miller
  Liam Quin
  François Remy
  Melanie Richards
  Alan Stearns
  Lea Verou
  Eric Willigers

  Manuel Rego
  Florian Rivoal
  Greg Whitworth

Scribe: dael

Agenda & F2F Planning

  Rossen: Let's go ahead and get going
  Rossen: 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.
  Rossen: 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
  Rossen: Okay. Please look at issue 2438 from tantek and engage to
          help prepare test suite talks.
  tantek: I'd like it on F2F agenda
  Rossen: Go for it.

  Rossen: Other topics?
  [Unminuted F2F Planning]

CSS Grid

Disallow repeat() syntax in grid-template-rows/columns resolved values
  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?
  Rossen: Edge supports serialization of repeat() by using repeat
          syntax and computed values inside.
  Rossen: FF, Webkit, and Chrome serialize as a list of computed
  Rossen: Question from TabAtkins and fantasai was just tell us which
          you want, we don't care.
  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.
  <Rossen> https://wptest.center/#/nsrrq1
  Rossen: Test case inside the issue ^ serialization is okay, but if
          the repeat >2, really big, in Chrome if you use 5000 you get
          100 columns and it drops. Firefox is between.
  Rossen: Having to parse this many is harder. Finally, this isn't
          new. gradient-repeat() has the same challenge but we're not
          serializing a list.
  Rossen: Our opinion is preserve the repeat syntax and have others
          catch up.
  Rossen: Looking for other opinions.

  <leaverou> What if the number to repeat by is a var()?
  <fantasai> leaverou, it's the used value that gets returned by gCS
  <leaverou> Oh right

  AmeliaBR: What if author has spec columns that could be collapse?
  AmeliaBR: If the author has literally specified multiple columns
            without using repeat syntax but they could be collapsed
            using repeat would you serialize that using repeat?
  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 argue keep
            as specified 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.

  Rossen: Any other opinions?
  Rossen: If not, can we resolve?
  Rossen: Objections to keeping repeat syntax as is currently in the
          spec and open bugs for other implementations to do that?
  frremy: Spec is a may. So there is no implementation bug to file
          unless it's a must.
  Rossen: Ah ha. Good point frremy. I didn't realize this was a may.
  Rossen: 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.

  RESOLVED: Serialization of the repeat() MUST use the repeat syntax.

CSS Overflow

Is the box a scroll container if only one of 'overflow-x' or
    'overflow-y' is 'clip'?
  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.
  fantasai: 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.
  fantasai: Clip didn't spec how to compute. In general it was
            supposed to not trigger a scroll container.
  fantasai: 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: 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 auto or hidden.
  <fantasai> https://github.com/w3c/csswg-drafts/commit/1d1a8e9caf4333518620e32f2a8b08ec3efdfa13
  fantasai: Changeset^
  fantasai: 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 separate
            discussion on if a BFC.

  Rossen: We should take these one at a time. Thought they're related
          I think we can resolve independently.
  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
  Rossen: 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.
  Rossen: If clip is intended to be render time only
  Rossen: 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 predictable but then you have
          overflowing visibly content to the left 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 implement.
  Rossen: 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 the 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.
  TabAtkins: If we want to restrict geometry clip is hidden with 0
             ability to scroll. We have to decide.
  fantasai: Or we make it effect layout 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 appropriately.
  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 specified. 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 the only one that implemented?
  dbaron: I think so. Other implementations did hidden in terms of
  Rossen: If this is back compat with a not compatible feature 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.
  fantasai: Has a bit more effect on stuff now then in the past. In
            the past it meant you have slightly different performance
            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 but clips paining.
  Rossen: If you don't have floats and a div with
          overflow-clip:vertical and a bunch of text with at the end a
          div with a huge negative bottom margin. It overflows.
  Rossen: 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 descenders outside bounds are clipped.

  frremy: We have 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.

  TabAtkins: 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
  Rossen: And we shouldn't ask people to do that with clip or clip
          path? How many other ways do we have for clipping?
  Rossen: 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
  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
  Rossen: Sounds like most people feel like overflow:clip 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
  Rossen: Would people object to this as a resolution?
  <fantasai> +1

  RESOLVED: 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 terminology 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 resolution 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
  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?

Typed OM

What does computedStyleMap() do on elements that are in documents
    with no browsing context?
  github: https://github.com/w3c/css-houdini-drafts/issues/659

  TabAtkins: If anybody has strong opinions I'm happy to go with it.
             You grab a computedStyleMap. 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 move the element to another document
             and you query the computedStyle. 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 style map. Everyone but Edge
          returns initial values. We try to do more and try to compute
          the cascade on that sub tree in the ether.
  Rossen: 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 element is removed any attempt
             to get or set throws.
  TabAtkins: That's easier for everybody.
  Rossen: I support that. Makes it a lot more predictable.
  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
  TabAtkins: If you attempt to get a computedStyleMap or use a
             computedStyleMap() on an element not in the document it
  Rossen: Objections?

  RESOLVED: If you attempt to get a computedStyleMap() or use a
            computedStyleMap() on an element not in the document it

  TabAtkins: Sub issue if you grab a computedStyleMap() while in doc a
             and it moves to document b do you get a value?
  TabAtkins: I think the style map just reflects the value in the new
  TabAtkins: 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?
  TabAtkins: Those problems make me lean throw here as well.
  Rossen: Not sure. This is equivalent to grabbing a style sheet from
          one doc and inserting to a new doc. You would expect
          everything will return values...
  TabAtkins: That's fine because it's immutable permanent 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.
  TabAtkins: I'm fine with putting in a doc check.
  Rossen: That or we can...we can keep referential integrity and
          re-calculate everything. So you still have the live object
          but a new topography 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 computedStyleMap() 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.
  TabAtkins: You're still producing style values from the old.
  Rossen: I'm fine more restrictive for now and if compelling use
          cases arise 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?

  RESOLVED: 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.

CSS Images

Clear gradient color stops with two locations for shipping
  github: https://github.com/w3c/csswg-drafts/issues/2439

  leaverou: Two weeks ago we cleared conic gradient for shipping.
            Turns out many conic gradients in the wild were using the
            two locations. It's been in the draft for 6 years. Chrome
            implemented it a year ago because it was in many demos.
  leaverou: Dev that implemented asked if he can ship it as well.
            Chrome implemented 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.
  TabAtkins: Not sure
  ChrisL: Can you find out?
  <fantasai> I thought we resolved on that in Tokyo?
  <fantasai> ChrisL,

  ChrisL: 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 trivial extension.
  Rossen: Hearing some support. Other opinions? Especially from Chrome
          folks who are shipping?
  TabAtkins: I'm fine with shipping I agree it's minor feature very
  <tantek> we have tests?
  <leaverou> tantek: we don't have tests for ANYTHING about gradients!
  <tantek> SMH
  <tantek> so now we're agreeing to ship features based on demoware?
  <AmeliaBR> It's basically adopt
  <tantek> just WD right?
  <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: Objections to color stops are extended into their
          consecutive color stops?
  leaverou: Color stops with two positions.
  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.

  RESOLVED: Clear gradient color stops with two locations for shipping.

  Rossen: We're at top of hour. We couldn't get to display or value
          issues, those will push to next week.
  Rossen: I'll miss next week so see you in Berlin!
Received on Thursday, 29 March 2018 00:42:49 UTC

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