W3C home > Mailing lists > Public > www-style@w3.org > September 2016

[CSSWG] Minutes Telecon 2016-09-07 [css-round-display][motion-path][css-scroll-snap][css-grid][css21][css-flexbox][css-align][css-contain-1]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 7 Sep 2016 20:05:16 -0400
Message-ID: <CADhPm3s3uomT3mbLgZ06_cMZOmr6f3yT+514dx_6pkqDABOsrA@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.

Apply offset-path to specify the shape of progress element

  - There wasn't interest in creating a new pseudo-element at this
      time. Exploration should focus around custom elements and any
      problems in the implementation of SVG that is causing it not
      to be performant.

scroll-snap-padding vs snap-padding

  - This topic will be added to the TPAC agenda.

Grid Issues

  - RESOLVED: Keep the name grid-gap (issue #19).
  - astearns filed an issue to add an example documenting the
      difference between the space in grid-gap and a traditional
  - RESOLVED: Have percentages in grid-gap behave as percentages in
              tracks (issue #20).
  - RESOLVED: Keep auto-flow in the grid shorthand (issue #24).

Block-axis baselines reconsideration

  - Mats wasn't on the call, so this discussion will continue on the
      mailing list or github.

Baselines of empty boxes

  - RESOLVED: Have grid and flexbox keep saying that empty boxes
              have no baseline and they're synthesized with bottom
              border edge.

Layout containment should make an element containing block for
    absolute/fixed positioned elements

  - There was general agreement to accept the proposal, but
      TabAtkins needed to check with the implementor first.


Agenda: https://lists.w3.org/Archives/Public/www-style/2016Sep/0017.html

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Daniel Glazman
  Tony Graham
  Jihye Hong
  Dael Jackson
  Ian Kilpatrick
  Chris Lilley
  Peter Linss
  Thierry Michel
  Anton Prowse
  Liam Quin
  Matt Rakow
  Florian Rivoal
  Jen Simmons
  Geoffrey Sneddon
  Alan Stearns
  Greg Whitworth

  Simon Fraser
  Myles Maxfield
  Michael Miller
  Simon Pieters
  Steve Zilles

Scribe: dael

Apply offset-path to specify the shape of progress element

  astearns: We can get started and fiddle around with the agenda
            until fantasai arrives.
  astearns: Anything to add to the agenda?

  <astearns> https://github.com/w3c/csswg-drafts/issues/429
  jihye: I thought about how to do circular progress bar.
  <jihye> https://cloud.githubusercontent.com/assets/6636090/17996451/f54deeb8-6ba3-11e6-8727-91601976bb71.png
  jihye: Various shapes and watches and car dashboards use a
         circular progress bar. The link above is a picture of a car
  jihye: To implement that kind of bar there's 2 ways. SVG or
         border-radius. But these have poor performance for a smart
  jihye: There's requests to solve this from LG and other companies.
         We have a jquery to implement the circular progress
         component, as does Samsung. It would be better to have a
         standard. I have an idea about spec the shape of progress
         bar using ::path.
  jihye: It is used to change the shape of the progress element.
         When the pseudo element is applied the path from offset-
         path could decide the element.

  <jihye> https://cloud.githubusercontent.com/assets/6636090/17996464/0a102c94-6ba4-11e6-9891-30125e15fba6.png
  jihye: For an example: for ^ progress bar it could be spec like
  <jihye> https://www.irccloud.com/pastebin/s1ghFrZp/
  jihye: ^
  jihye: Actually, offset-path property spec the path the element
         can move. For ::path it spec how the progress path is drawn.
  jihye: Is it possible for offset-path works differently?

  TabAtkins: I think it's odd for offset-path and you're just using
             it because it lets you specify a thing. If we want to
             shape progress bars it should be separate property with
             similar syntax. Also, some of the existing properties
             like angle doesn't mean anything. It's just the basic
             shapes and path that do something meaningful. We should
             invent something new.
  <Florian> +1 to Tab.
  astearns: There are some details about a progress indicator that
            aren't handled by a shape. A circle could mean an entire
            circle that's measured with a wedge for progress. You
            have to spec the circumference or if it's the whole
            circle or just an arc.
  astearns: In your example the watch starts at North and the
            dashboard starts at Southwest which would have to be
  TabAtkins: With motion-path that's the start.

  TabAtkins: This could be just a custom element and you put in some
             SVG in your shadow DOM.
  Florian: I think jihye said there were performance issues with SVG.
  jihye: Yes, SVG has poor performance in smart watch. We need
         another approach.
  TabAtkins: I'd be surprised at not being able to do a circular
             path because smart phones do it well now. I would think
             it would be the implementation that has the problem.
             Rather fix the implementation than us carve a new
  bradk: Maybe the SVG rendering version.
  ChrisL: Yeah. Remember SVG was implemented on phones before smart
          phones, so I think it itself should be okay, but the impl
          could be optimized.

  astearns: Generally this is an instance of styling controls which
            is a long standing thing we've tried to work on and we
            haven't come up with anything. As far as I understand
            custom elements are the solution for now.
  <tantek> Indeed. Styling controls is still really difficult.
           Especially default controls.
  TabAtkins: Yeah, they are a somewhat solution
  <tantek> Agreed that Custom elements / web components are
           currently the best approach we have for stylable custom

  <jihye> https://msdn.microsoft.com/ko-kr/library/hh771827(v=vs.85).aspx
  jihye: There's is also ::-ms-field pseudo elements that work for
         Microsoft. It's for controlling animations of the
         indeterminate progress element. It can control how the
         indeterminate progress control is animated. Is this also
         considered to change the determinate element?
  jihye: I understand this is only applied to indeterminate progress
  Florian: I think the various pseudo elements browsers have is a
           swamp of incompatibility and we should try and not look...
  TabAtkins: Indeterminate is a pseudo class.
  Florian: That's not what she's referring to.
  TabAtkins: Oh! than that's unlikely to be spec
  Florian: And unlikely to be merged across browsers.
  <tantek> so I disagree with Florian on that
  <tantek> e.g. we have ::placeholder
  <tantek> we are growing compat and making progress
  <tantek> especially with new UI pseudos
  <tantek> I wholly reject the "swamp of incompat" categorization.
           If that's the case, please file test cases accordingly
           that demonstrate it.
  <Florian> tantek, OK, interesting to hear, I didn't know there was
            good progress on form control pseudo elements.
  <tantek> (aside: yes, UI pseudos are hard. that does not mean we
           are not making progress with them.)
  <tantek> (slow progress yes (on UI pseudos), but I think that's
           correct as it's a more conservative reliable approach)
  <tantek> (I think more UI pseudos is an area that could use
           prototyping/incubation before standardization)

  astearns: I certainly think that if we get another instance of
            custom styling on a bit of UI that everybody uses it's
            something we could talk about moving in natively, but it
            needs to be tried in custom element arena first.
  TabAtkins: Yeah.
  jihye: So can I proceed this idea for the new pseudo element or is
         this approach weird?
  astearns: I don't think weird, just premature.
  Florian: The use case isn't weird but the approach is.
  bradk: A different approach is to look at the need to stroke
         shapes be it for clip-path or shape-inside etc. It would be
         good to stroke those or put a border. And if you have a gap
         path that could represent the empty part of progress

  astearns: To sum up, We would not like to pursue the pseudo
            element at this time, we'd much rather go with custom
            element and SVG solution.
  jihye: Okay, thanks for the comments.
  Florian: At the same time, the use case is valid, so if you can ID
           something in SVG or custom elements other than bad
           implementation bringing that up to address it is
           worthwhile. If it's bad implementation it's worth raising
           to different people.

scroll-snap-padding vs snap-padding

  <astearns> https://github.com/w3c/csswg-drafts/issues/395
  fantasai: I think we should accept the proposal, MaRakow disagrees.
  MaRakow: One question is if other implementors have other input.
  Florian: I agree with fantasai and I don't fully understand your
           objection, but I think we need a whiteboard.
  TabAtkins: I'm mildly leaning toward MaRakow but more time in
             person with fantasai would be good.
  astearns: Let's get this on TPAC agenda.

Grid Items

Rename grid-gap to grid-gutter

  <astearns> https://github.com/w3c/csswg-drafts/issues/353
  fantasai: The grid-gutter argument is designers have been using
            that term for forever. For grid-gap it's that we have
            column-gap already and it's shorter and easier to spell
            for non-English speakers. That's where we're at. The
            commenter isn't happy with our argument so we've brought
            it to the group.
  <gregwhitworth> yeah, keep it consistent with column gap IMO
  <gregwhitworth> Jen/Rachel?
  <rachelandrew> keep it consistent with column-gap
  TabAtkins: I agree with fantasai.
  ChrisL: I agree it should stay as gap.
  Rossen: I agree.
  <tantek> also agree with fantasai. too late to rebikeshed this.
  <tantek> I'm going to assert that "gutter" is also an
           English-centric term. Do any designers based in
           non-English countries use "gutter"?

  astearns: Anyone disagree with fantasai?
  <bradk> Let's have column-gutter
  jensimmons: I'm torn. When I first saw it I had the same reaction
              and as I teach it I've used gutter a lot.
  jensimmons: I understand the one to be consistent. People should
              be using multi-col. I'm undecided. There's a lot of
              CSS that doesn't align with design.
  jensimmons: It is a big inconsistency with everybody.
  tantek: CSS has been inconsistent for a while. e.g. we've never
          had "leading" and never will.

  liam: We also have things like margins and child margins going on.
        Gutter and gap are not quite the same. I think we should
        have a note explaining the difference.
  <jensimmons> these are good reasons…. let’s document them & tell
               people about them
  ChrisL: That would be quite good. It would deal with the objections.
  * liam notes gutter also used for the binding-margin sometimes
  plinss: Gutter is only column usually whereas gap could be used
  <rachelandrew> I like the idea of documenting why this is so too.
  <liam> gutter also used for the binding-margin sometimes ]
  dauwhe: I'm noting what liam said is that gutter is the inside
          margin in a spread and it has sided-ness that gap doesn't.
  <ChrisL> in particular with a diagram showing how gap plus padding
           adds up to the gutter?

  astearns: bradk mentioned in IRC he'd like column-gutter.
  bradk: I'm not really serious about that. We can't change at this
  <tantek> would like see documentation on say "How to set a gutter"
  <tantek> that explains the components that could go into a gutter

  astearns: I'm swayed by the argument to be consistent and I like
            documenting that the gap isn't all of the gutter. What
            do you think about adding an example fantasai?
  fantasai: If someone can outline it I'm happy to add it. I don't
            quite understand.
  jensimmons: If column-gap didn't exist I'd lobby for gutter, but
              the ship has sailed. I think it's good to document and
              it's good to hear so we have a robust answer when
              people ask.

  astearns: Can I get a volunteer to work up an example that
            grid-gap isn't the whole gutter?
  Rossen: I don't think this is necessary for the spec to move
          forward. We've had this conversation before and we keep
          coming to the same conclusion. If examples need to be made
          I'd suggest that people who work with the community to do
          that, but I don't want to hold up the spec.
  <fantasai> +1 to Rossen
  <tantek> please file the request for example as a new editorial
  <TabAtkins> Yes, just file an issue plz
  Florian: Given that it keeps coming up, having an example saying
           this is a gap and this is gutter and they're different
           and it would help.
  <tantek> sounds like Florian just volunteered to file the
           editorial issue :D
  <jensimmons> I don’t think this idea that gaps and gutters might
               be different is the main reason / the only reason… I
               heard several good reasons. And don’t think that this
               one ‘reason’ has to be documented in the spec. It’d
               be better to several reasons — and maybe not in the
  <jensimmons> I agree that it should not hold up CR
  Rossen: That's great, make it and blog about it.
  fantasai: Rossen is saying it shouldn't hold up CR. We're not
            saying don't add the example. We're saying let's not get
            hung up on this and when there's an example I'll add it
            to the spec.
  <jensimmons> +1 fantasai
  <tantek> +1 should not hold up CR
  astearns: I agree. I'll make an issue.

Verification of percentage gutters

  <astearns> https://drafts.csswg.org/css-grid/issues-wd-20160519#issue-20
  fantasai: I want to make sure that everyone has the same
  Rossen: Percentage gaps, right?
  fantasai: Yep.
  Rossen: My recollection is we decided that for the purposes of
          intrinsic size percentages resolve to 0.
  fantasai: It resolves to 0 in one axis and a little different in
  TabAtkins: It acts like a track with a percentage.
  fantasai: And is empty.
  TabAtkins: Yep.
  Rossen: I think that sounds reasonable.
  astearns: Makes sense to me.

  Rossen: Do we specify percentages on gutters in the block
          direction resolve from the height? Correct?
  fantasai: Yeah that's like percentage track.
  Rossen: Okay, good. I'm fine with this. astearns?
  astearns: Yep. Fine with it.

  Rossen: We don't have a pending resolution for this right?
  fantasai: I don't think so. Let's just resolve all the things.
  Rossen: That's a great idea
  <fantasai> astearns, I need a resolution on the previous issue
  astearns: Resolution is to allow percentages in grid-gap and
            behave as <percentage> tracks.
  Rossen: From model POV they're empty tracks. For other layout they
          behave as a track.

  <svillar> sorry for chiming in but % in gaps it isn't the same as
            % in tracks, we cannot fallback to auto
  <svillar> for indefinite sizes
  astearns: There's a comment from svillar in IRC [reads]
  fantasai: That doesn't make sense. We just pretend it's empty.
            Auto has a meaning for empty tracks.
  fantasai: I don't see why that would be an issue.
  Rossen: I agree with fantasai. It should be the same.
  astearns: svillar are you on the call or just IRC?
  fantasai: I think IRC.

  <fantasai> ous issue as well
  <svillar> ah ok so "auto for empty tracks"
  <svillar> that makes sense
  <Rossen> svillar, that's correct
  astearns: Okay. He's getting it.

  astearns: So proposed resolution is have percentages in grid-gap
            behave as percentages in tracks.
  astearns: Objections?

  RESOLVED: Have percentages in grid-gap behave as percentages in

Rename grid-gap to grid-gutter

  RESOLVED: Keep the name grid-gap

'grid' shorthand 'auto-flow' keyword vs 'row/column'

  <astearns> https://github.com/w3c/csswg-drafts/issues/438
  fantasai: When we have a shorthand we take the value from the
            longhand and propagate down. When TabAtkins and I did
            grids with auto-flow rows we decided that instead of
            -row and -column we'd just use auto-flow. The row/column
            is implied by the position.
  fantasai: The difference the row/column creates is to change to
            automatic rows or columns instead of being the template.
            To make this more obvious we used auto-flow. This seemed
            clearer to us. There we a suggestion from Javier to use
            -row and -column. TabAtkins and I lean to not make the
            change, but we're bringing it to the group.

  fantasai: Did that make sense or do I need to explain again?
  astearns: That made about 60% sense.
  fantasai: General way the shorthand works is you put row values
            first and than a slash and than column values
  <fantasai> <row-values> / <column-values>
  fantasai: So when you have a grid template you have a fixed number
            of rows and columns. That creates an explicit grid.
  fantasai: When doing auto-flow and you generate as you create
            items, you want to be able to control the track sizes.
            That's the grid auto-columns. To assign those into the
            grid shorthand we need to show we're not going into
            template value. We're doing that with the auto-flow
            keyword with length etc. keywords are for the
            grid-column/row based on the slash.
  fantasai: If we used grid auto-flow we could use on of the
            keywords that are a value of that instead of auto-flow
  fantasai: We're impl the position and we're not emphasizing that
            the lengths are setting an auto thing not a template
            thing. That's why we added this keyword as a switch in
            the short hand that doesn't appear in the long hand.
  <TabAtkins> In other words, "20px 30px / column 30px" doesn't
              really indicate "columns are auto-flowing and get
              repeated as necessary"
  <TabAtkins> But "20px 30px / auto-flow 30px" does, or at least
              does it better.

  astearns: In the issue Javier said he doesn't have a strong
            opinion. Anyone else have a strong opinion?
  astearns: Giving silence I'm inclined that we keep auto-flow.
  astearns: Objections?

  RESOLVED: Keep auto-flow in the grid shorthand.

Block-axis baselines reconsideration

  <astearns> https://lists.w3.org/Archives/Public/www-style/2016Sep/0008.html
  fantasai: Mats disagreed with our resolution to say there's not
            baseline in the block axis. We can try and make that
            work, I think he's implemented. I don't know if anyone
            wants to add anything to that discussion, it's on
            www-style. I can try and make that work and we can
            decide if we want to go in that direction. Mats isn't
  astearns: Any possibility he'll be at TPAC?
  fantasai: Almost certainly not.
  astearns: Looks to me this needs more discussion. Anyone on the
            call have anything to add?
  astearns: Anything to do now, or move on?
  fantasai: Go to the next

Baselines of empty boxes

  <astearns> https://github.com/w3c/csswg-drafts/issues/439
  fantasai: There's a bunch on inconstancies in how empty box
            baselines are handled.
  fantasai: Tables are undefined in 2.1. Block containers for inline
            layout use bottom margin edge.
  fantasai: My vague suggestion is if a box is empty it doesn't
            have a baseline and the context sets one. The synthesis
            rules we set are different than the ones for inline
  astearns: So we don't change grid or flexbox, but add details to
  fantasai: Grid and flexbox say use bottom content edge because
            that's the closest we can get to the content. It might
            make more sense to be more consistent with block
            containers than try and do something no one implements
            and it's not consistent.

  Rossen: Didn't we agree we want to use border box edge?
  fantasai: Yeah. That's what I'm saying for flex and grid.

  Rossen: I'm reading your second comment on the issue and it makes
          sense. I support that.
  fantasai: That works. When I made the changes for the last
            resolution it ended up being a separate set of changes.
  Rossen: Does 2.1 or 2.2 spec that the inline formatting content
  fantasai: The margin-box.
  Rossen: Okay we're fine there.
  Rossen: For anything out of inline formatting context baseline is
          synthesized based on the border box. That should cover them.
  astearns: Where is that defined?
  Rossen: CSS align or individual specs if they decline from this
  fantasai: It'll be partly in inline and partly in grid and flex
            specs. Grid and flex will say an empty doesn't have a
            baseline and one is synthesized. I checked those changes
            in. It is a change from what was there.
  astearns: Fine with me Rossen is okay. Anyone have a concern?
  astearns: So have grid and flexbox keep saying that empty boxes
            have no baseline and they're synthesized with bottom
            border edge.
  astearns: Objections?

  RESOLVED: Have grid and flexbox keep saying that empty boxes have
            no baseline and they're synthesized with bottom border

  astearns: And CSS align and CSS inline edit to match what we
            defined here.
  astearns: Well, inline does as defined as 2.2.
  astearns: Anything more?
  fantasai: As far as I can tell no.

Layout containment should make an element containing block for
    absolute/fixed positioned elements

  <astearns> https://github.com/w3c/csswg-drafts/issues/404
  dbaron: I filed the issue, but Florian added it to the agenda.
  dbaron: I don't entirely understand Florian's comment. Basic issue
          is I was looking at something for layout containment and
          concluded we can't do the optimizations unless layout
          containment says that it creates a containing block for
          absolute & fixed elements.
  dbaron: If it's not you can have elements inside that are laid out
          relative to something that's an ancestor. Or partly to an
          ancestor and partly to something inside an element. So I
          think they should just be containing blocks.
  dbaron: Florian seems to think there's another solution?
  Florian: I think I misunderstood your point. I thought you said
           the child could influence something outside, but you're
           saying what's outside is influencing so I think you're
           right. I now agree with you.

  TabAtkins: I find the interpretation interesting. I didn't assume
             containment was a two way boundary. I thought nothing
             inside should affect outside. I didn't intend the other
             way. That said, I'm not opposed to it. I'd like to chat
             with ojan real quick, but I'm inclined to agree with
             you. I just want to check with our implementor.
  dbaron: Okay.
  astearns: Sounds like a good way forward. Other comments on this

  astearns: We're done with the agenda? Anything for 7 minutes?
  astearns: Alright. Just a reminder to add items to TPAC agenda.
  astearns: Thanks for calling in!
  <jensimmons> thank you!
  <rachelandrew> thanks :)
Received on Thursday, 8 September 2016 00:06:27 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:00 UTC