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

[CSSWG] Minutes Telecon 2016-12-21 [css-grid] [css-overflow] [cssom-view] [css-text-decor] [cssom] [css-color]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 21 Dec 2016 20:28:14 -0500
Message-ID: <CADhPm3vcLHbfAhsZi8OCT+kuQOuxt_qH4rimVTewkvNR=SUi=Q@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.
=========================================


Publishing next snapshot
------------------------

  - Will-change, Variables, and Flexbox were mentioned as specs that
      should move to a higher status in the 2016 snapshot.
  - ChrisL will prepare a list of specs not mentioned in the 2015
      snapshot to help the group discover any specs that should be
      included in 2016.

Grid Items
----------

  - The proposal on how to address stretching grid items in both
      directions is summarized in the github issue:
      https://github.com/w3c/csswg-drafts/issues/523 Anyone
      interested, especially from the design/webdev community, was
      asked to review before the next call (4 Jan).
  - Similarly, the proposal to correct the language around implied
      minimum size is summarized on github
(https://github.com/w3c/csswg-drafts/issues/283)
      and edited into the spec. A resolution will be sought on the
      next call.
  - RESOLVED: Accept proposal from TabAtkins and fantasai in
              https://github.com/w3c/csswg-drafts/issues/767

Color properties should use "used value" as "resolved value"
------------------------------------------------------------

  - RESOLVED: Make color properties return used value as resolved
              value.

Overflow: Consider support for overlay scrollbars
-------------------------------------------------

  - The topic will be added to the F2F agenda and was renamed to
      'Consider reserving space for scrollbars with some property'
      to avoid confusion.

New feature - scroll-boundary-behavior (an extension of
    -ms-scroll-chaining)
--------------------------------------------------------

  - There was general support in formally specifying this type of
      behavior, but it wasn't ready for a resolution.
  - The latching behavior done by webkit and Chrome should be added
      to the proposal or at least able to be done with the
      properties.
  - It was agreed that the name will need to be improved.
  - This will be added to the F2F agenda.

Should text-decoration-skip apply to overline and line-through?
---------------------------------------------------------------

  - RESOLVED: Ink skipping applies to overline and underline, but
              not line-throughs

===== FULL MINUTES BELOW ======

Agenda: https://lists.w3.org/Archives/Public/www-style/2016Dec/0073.html

Present:
  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Simon Fraser
  Tony Graham
  Dael Jackson
  Chris Lilley
  Peter Linss
  Michael Miller
  Florian Rivoal
  Jen Simmons
  Geoffrey Sneddon
  Alan Stearns
  Steve Zilles

Regrets:
  Bert Bos
  Tantek Çelik
  Dave Cramer
  Elika Etemad
  Daniel Glazman
  Anton Prowse

Scribe: dael

Publishing next snapshot
========================

  Rossen: Hello everyone.
  Rossen: First thing, any additional items?

  <ChrisL> https://drafts.csswg.org/css-2015/#css
  ChrisL: We said in the charter we'd publish a snap shot at end of
          2016. We haven't quite made it, but I think that's fine.
          Looking at current WD I think there's a few things we
          could move from stable but not much tested. will-change,
          maybe variables
  ChrisL: I wanted to kick of discussion. What makes this different
          from last snap shot?
  Rossen: I think variables is a good candidate. Not sure about
          will-change for other implementations.
  Rossen: Blink? Mozilla?
  Rossen: Who is implement will-change?
  smfr: Webkit.
  dbaron: Gecko as well.
  Rossen: That's good. Do you folks feel we can move this up to
          ready but not much tested?
  smfr: I think that's reasonable.
  <dbaron> fine with me
  Rossen: k

  ChrisL: I think flexbox could move out of the not fully tested.
  Rossen: Sure. I think flexbox is fairly interop.
  ChrisL: I think so.

  Rossen: I'm not sure on Grid. Did Mozilla release it non-prefixed?
  dbaron: It hasn't yet, but plan is to ship not far in the future.
  Rossen: But in 2016 it will not.
  jensimmons: It's march. Chrome I think is also March.
  <jensimmons> Grid is slated to ship in Firefox 52, in early March
               2017
  Rossen: So it's a bit early.

  ChrisL: CSS Speech, are we keeping that in?
  ChrisL: I think it dropped off the charter.
  Rossen: I believe we agreed to continue work on this at CSS a11y
          TF.
  Rossen: I'd prefer the updates to come from that TF since that's
          the purpose of it. Since Speech is fairly a11y targeted it
          would be good to make it there.
  ChrisL: So leave it in.

  dbaron: I think it's interesting to look through things that
          aren't listed here. It's a little hard to do mentally.
  Rossen: You mean for new modules added?
  dbaron: Yeah. I'm guessing there's a module floating around we
          think is stable and not listed because we forgot.
  ChrisL: I think you're right. I can go through the WD list and
          make a subset of things not listed.
  dbaron: Yeah. I don't remember what's in color 4 or selectors 4
          and if any of those should move up.
  ChrisL: Yeah. We should do a new draft of selectors 4 but that's
          separate. Okay. I'll kick of discussion by making the list
          of not listed things.
  ChrisL: It is hard to mentally do.
  Rossen: That would be great. Like round display is missing. Please
          also look at FX.
  <astearns> a list will be good to maintain for future snapshots as
             well
  Rossen: So you can take an action and then open an issue against
          the snapshot in github?
  ChrisL: Yes.

  ACTION ChrisL list all the specs not currently listed in snapshot
         2016
  <trackbot> Created ACTION-806

Grid Items
==========

  TabAtkins: Yes, I'll review them all real quick.

Stretching image grid items in both dimensions
----------------------------------------------

  TabAtkins: First is from Mats about stretching image grid in both
             dimensions. The spec was written where default
             stretches in both axes. For images that means you lose
             intrinsic dimensions. That's not expected behavior.
  TabAtkins: You could use start or end, but then you're at native
             size. Original suggestion was change behavior of
             stretch for replaced items so the stretch until one
             dimension his grid area. This was edited in, but after
             fantasai and I discussed we realized that the alignment
             properties would now be in charge of sizing and you
             then can't align the image in the dimension not filling
             the area.
  TabAtkins: That's clearly a bad solution. So the solution we
             proposed was to say 'normal' has different behavior on
             if the item has an intrinsic aspect ratio. If not it's
             stretch, if yes it's start.
  TabAtkins: So images are start, start.
  TabAtkins: If the image is potentially larger than the grid area
             you can use max width 100% and max height 100%. Then as
             sizing spec comes to it's own and exposes fill you can
             make small images fill a grid area.
  TabAtkins: Then you could have an image fill a grid area
             regardless if it's smaller or larger, maintains aspect
             ratio, and responds to align.
  TabAtkins: That's all written in the github issue.
  TabAtkins: Please review and let us know if you have opinions.
             Spec has been edited and we'll seek resolution in the
             future.
  Rossen: So next meeting is 4 Jan.
  Rossen: So this is mostly brought up as a call to action.

  Rossen: I went through your summary and it seems reasonable. Last
          time we discussed there was feedback from jensimmons and I
          think leaverou. I'd like to hear again from the design/
          webdev folks to see if they consider this normal in their
          view.
  TabAtkins: Yep.

  Florian: I have a question. I didn't deep dive in, but have you
           considered instead of a magic value, using the magic
           value on object fit?
  TabAtkins: That doesn't do what we want. Mainly, object-fit isn't
             a natural way to resize. It doesn't have the desired
             effect on box-shadow or filters.
  Florian: Okay.
  TabAtkins: Yeah. It's good for a number of features, but not as a
             generic.
  Florian: Alright, thanks.

Implied Minimum Size of Grid Items
----------------------------------

  Rossen: Then let's got the the next.
  TabAtkins: Implied min size. Started with a question about what we
             meant for a particular clause on auto min size. We
             clarified that.
  TabAtkins: Restarting.

  TabAtkins: Flexbox introduced automatic min size to prevent things
             from shrinking too small. It also prevents shrinking
             to 0.
  Rossen: Yeah, it was meant to keep things in natural size.
  TabAtkins: There's similar use cases in grid.
  TabAtkins: It works exactly the same. It references flex
             definition. It had an extra clause where if your grid
             area spans tracks your min shouldn't be bigger then
             that. That was clarification on what precise size it
             should be because you need min and max track sizing. We
             clarified that.
  TabAtkins: It meant to talk about max track sizing function in the
             actual size. That's the first bit.
  TabAtkins: Should be a small clarification.

  TabAtkins: Second is based on further discussion the auto min size
             was happening too often and was making things grow in
             unwarranted ways. We decided only cases where we want
             auto min size is when something can get shrunk too
             small. This maps to tracks with an auto size.
  TabAtkins: If an item spans one of these it should invoke
             automatic min size.
  TabAtkins: [reads definition]
  TabAtkins: We believe this correctly captures the intent and keeps
             things from growing too small, but doesn't accidentally
             activate it and make things too large in other cases.
             Review would be appreciated. It's edited into spec and
             the issue has a good breakdown.

  Rossen: I did go through...you're saying I have an item that spans
          3 columns. And they all have an auto min width. The middle
          track is auto, the others are 0.
  Rossen: At first the image size will be the min size of the image.
  Rossen: Then if I change the middle track from auto to be 1fr then
          all the sudden everything shrinks to 0?
  TabAtkins: No, using 1fr is the same as auto, min: 1fr.
  Rossen: So if I toggle between auto and fr in this case it will
          have no effect.
  TabAtkins: Yeah.
  Rossen: So if I make it a big size...
  TabAtkins: Or if you do min/max 0, 1fr.
  Rossen: And if the track has min-content?
  TabAtkins: It already has a similar effect. It will ask the item
             what the min size is.
  Rossen: And the item is spanning so it's contradiction to the
          track is all it's size.
  TabAtkins: I think so...we didn't touch that bit of the algorithm.
  Rossen: Okay. I think I'm fine with that.

  Rossen: So I think you're asking for review today and a CTA for
          everyone impl or interested to look at this issue and
          we'll revisit before F2F.
  TabAtkins: Yep.

Automatic minimum size clamping by grid area should transfer through
    aspect ratio
--------------------------------------------------------------------

  TabAtkins: Third is a fairly small issue. If you're in a situation
             where you care about auto min size. You have an image
             200px that spans 2 tracks that are min/max auto, 50px,
             auto, 50px.
  TabAtkins: We clamp the auto min size to that value because you've
             said no more than 100 px. So the image exactly fits.
  TabAtkins: Issue is in the older spec we didn't clamp the
             transferred size which sizes the height axis. So if
             width is a value you multiple through aspect ratio and
             get a preferred height. That wasn't getting clamped by
             this clause that limited to 100px.
  TabAtkins: So you would calculate transferred size by 200px. So we
             clarified that so all things surrounding auto sizing in
             both axis care about clamping.
  TabAtkins: At the end of the thread there's a clause to clarify.
  <jensimmons> I think I’ve encountered this bug, the one Tab is
               describing. It’s annoying.

  Rossen: Out of curiosity, aren't specified size and content size
          specified somewhere?
  TabAtkins: Yes. They're linked appropriately.
  TabAtkins: Read the quotes as being links.
  Rossen: That's fine.

  jensimmons: I've run into this bug so...yay, thank you! Let's fix
              it.
  Rossen: That is one thumbs up I'm hearing.
  Rossen: Anyone else?
  <rachelandrew> makes sense to me
  Rossen: Let's call for objections.

  RESOLVED: Accept proposal from TabAtkins and fantasai in
            https://github.com/w3c/csswg-drafts/issues/767

Color properties should use "used value" as "resolved value"
============================================================

  Florian: I didn't raise this, but I have dependencies. Color
           properties are not listed in CSSOM as properties that use
           used value. In all implementations when you have
           currentColor you get a numeric value, not the keyword.
  Florian: This isn't due to poor implementation. Everyone is
           already doing getComputedStyle for color properties as
           used value. If we change this it will unlock a pending
           test case.
  Rossen: What spec?
  Florian: CSSOM. There's a list of properties and a definition
           saying that it's used value in specific cases. Color
           isn't listed.

  ChrisL: [missed]
  Florian: xidorn checked.
  ChrisL: I asked if this is what impl already do.
  Rossen: Yes. It's defining the standard.
  ChrisL: Would any tests change because of that?
  Florian: None I'm looking at.

  TabAtkins: Makes sense to me. I don't like expanding resolved
             value, but matching implementation is good.
  <dbaron> This is really fallout from the change that makes
           currentcolor a computed value
  Rossen: I'm hearing a lot of thumbs up. Objections to making color
          properties return used value as resolved value?
  ChrisL: Does it have any effect on color 4 and color 3 errata?
  Rossen: I would assume only OM.
  Florian: Yes. Only OM. There's a separate issue about CSS 3 and 4
           saying different things about computed, but that's
           separate.

  RESOLVED: Make color properties return used value as resolved
            value.

Overflow: Consider support for overlay scrollbars
=================================================

  <Florian> https://github.com/w3c/csswg-drafts/issues/92#issuecomment-251727301
  Florian: I don't know if people remember, but we've discussed
           before.
  Florian: This comment summarizes where discussion went last time.
  Florian: Allowing authors to opt into variant behaviors with
           overflow: auto. You may want to reserve space on
           scrollbar. Or you may not want to if scrollbar is
           overlay. But if browser would need space you want to
           reserve it.
  Florian: We had 3 proposals. Does anyone else remember this?
  <gsnedders> remembers the discussion and remembers no conclusion
  Rossen: I remember the discussion and going through github I
          didn't see much since then.
  Florian: I think the conversation was just cut off on the last
           call. Having stagnated it could be interested to re-open.
  Florian: We had agreed on the behavior, but not syntax. The
           alternatives were a dedicated prop with 3 values or a
           long hand of the overflow with 3 values, or adding these
           additional values as switches to overflow.

  <dbaron> seems like this might be a good topic for a face-to-face
           meeting
  * smfr agrees with dbaron
  Florian: Are people ready to debate or is this too much off
           everyone's mind?
  smfr: Can we do it in Seattle?
  Florian: Sure, sure. I wanted to revive the debate.
  Rossen: I think there's plenty of interest so we should add it to
          the F2F.

  smfr: Can we object to the title of the issue? It confuses me
        every time.
  Florian: Do you have a suggestion?
  smfr: It's about reserving space for the scrollbar.
  Rossen: [changes the gitbub]
  Florian: So if anyone wants to refresh their mind before, the link
           I pasted is a good summary.

Intrinsic size of replaced elements incorrect
=============================================

  <dael> https://github.com/w3c/csswg-drafts/issues/794
  TabAtkins: Without fantasai I don't think we can talk about this.
  Rossen: This is similar to the first topic we did. I'm not sure
          this is separate.
  TabAtkins: It is.

New feature - scroll-boundary-behavior (an extension of
    -ms-scroll-chaining)
=======================================================

  TabAtkins: This was created by Majid.
  Rossen: I see zcorpan added it, but he's not on.
  TabAtkins: I can discuss it.
  Rossen: Do we want to try and resolve? Yeah. Let's take it.

  TabAtkins: MS has had an unspecified prop called
             -ms-scroll-chaining
  Rossen: It was specified, but not documented.
  TabAtkins: Unstandardized.
  TabAtkins: Controls if you're scrolling and hit top or bottom if
             the scroll intent escapes or is stuck inside.
  TabAtkins: There's a lot of app cases where if you're allowed to
             escape it's annoying. That's why MS did it and we
             thought it reasonable to standardize.
             scroll-boundary-behavior: propagate | contain | none
  TabAtkins: propagate allows you to escape. contain traps scroll
             and does things like the android bounce. none traps you
             but doesn't do any indication.
  TabAtkins: Majid suggests specing in CSSOM View. zcorpan agrees on
             functionality. We REALLY need better names. Propagate
             is hard to spell too.
  TabAtkins: Concept-wise does this group feel we should standardize?

  smfr: Webkit has the scroll latching to a scrollable area. You
        latch in a single gesture. During the latch you scroll a
        single thing. If you're at the bottom and you scroll again
        you go to the parent. So there's a difference between the
        middle and the beginning of a gesture. This behavior should
        distinguish or say only at the beginning.
  smfr: Second comment is if you do scroll none you have the ability
        to not let a user manipulate the page and that's bad
        behavior. This impinges on where browsers may want their own
        behavior that lets the user interact in ways they prefer.
        I'd like good use cases for the three values.
  TabAtkins: I can before the F2F have Majid draw up example use
             cases of apps that mess up if scrolls chain. We also do
             the latching so I think we need to define to allow or
             address that.
  smfr: There's on use case from FB for example where the chat
        widgets if you hit the bottom you don't want to propagate
        for the page. That's a good use for none.
  TabAtkins: I think they're mostly cases like that where it's a
             mostly independent widget.

  Rossen: In our case when we had the demand any time there was a
          list involved...one of the initial design concepts that
          were mostly in windows 8 apps was that general scroll of
          apps was horizontal and the content inside was in vertical
          lists. There was a handshake between the two to propagate
          between vertical & horizontal.
  Rossen: Having these complex behavior and not capture scroll was
          difficult. I believe we have a bunch of examples we can
          dig out for the F2F if we're not resolving now. We'd
          support standardizing this going forward.
  Rossen: I also don't like the name. scroll-contain sounds nice.
  TabAtkins: I like scroll-chain.
  Rossen: Unless you're an implementor it doesn't resonate as much.
  <smfr> scroll-contain sounds overflow-related

  Florian: You described the containment of scrolling to be going up
           the chain. Can this be used in the other direction where
           you have a map in the middle of a page and you scroll the
           map when you meant do the page?
  Rossen: This will make it hard. So assume you have a bunch of
          iframes. When you gesture to scroll down your page
          scrolling will stop in a number of ways. It will be very
          confusing. How do you compute the sum of your scroll bar.
          The aggregated scrollable areas of all scrollers? And what
          if some are scrolled already. Propagating down is complex.
  Florian: I'm not saying it should happen. I think it does happen.
  Rossen: I think it only happens if it's the last one...I'm not
          sure.
  Florian: I'll research the problem better before raising it.

  Rossen: Doesn't sound like we can resolve on this.
  Rossen: We'll revisit as a part of the scrolling discussions at
          the F2F.

Should text-decoration-skip apply to overline and line-through?
===============================================================

  koji: The proposal is to change text-decoration-skip to only apply
        to overline and line-through. Not strike-through. Webkit has
        this behavior. People on the issue seem to be on consensus.
  Florian: I think it makes sense. If you skip on strike through you
           mostly can't see the line.
  TabAtkins: Oh gosh yeah. I'm seeing the example image
             and...they're showing how you can't see a line through
             because it's obscured by the letter.
  TabAtkins: Saying overlines do skipping [missed]
  TabAtkins: Saying overlines doing skipping does make sense.
  koji: I think so.
  <leaverou> are there any use cases for skipping the line on
             line-through?

  Rossen: You said this is shipped by webkit?
  koji: Yes.
  smfr: Just underline.
  Florian: Why not overline?
  smfr: Because it's used on the web a million times more. Maybe we
        do overline. We do it, yeah.
  koji: So are you okay to resolve not to apply strike through?
  smfr: Yeah. It seems strike through should strike through all the
        glyphs.
  koji: Yes. And the specs say apply to overline.
  koji: smfr is fine to say apply to overline.
  Rossen: I'm hearing consensus. Anyone objecting?

  RESOLVED: Ink skipping applies to overline and underline, but not
            line-throughs

  Rossen: That's the end of today's topics and this year's phone
          calls unless anyone wants to bring a 4 minutes topic.
  Rossen: Any topics? Or should we adjourn.
  Rossen: Okay. Thank you all for calling. Happy holidays, happy new
          year, safe travels. We'll talk on Jan 4 and meeting Jan
          10. Thank you everyone!
Received on Thursday, 22 December 2016 01:29:13 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 22 December 2016 01:29:14 UTC