[CSSWG] Minutes Telecon 2016-06-22 [css-snappoints] [css-text-3] [css-round-display] [mediaqueries] [css-grid] [css-align] [css-inline]

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[CSSWG] Minutes Telecon 2016-06-22 [css-snappoints] [css-text-3] [css-round-display] [mediaqueries] [css-grid] [css-align] [css-inline]

Dael Jackson
=========================================
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.
=========================================


CSS WG Charter
--------------

  - astearns will input the dates he proposed on the private mailing
      list (available here:
https://lists.w3.org/Archives/Member/w3c-css-wg/2016AprJun/0251.html)

Scroll Snap Publication
-----------------------

  - RESOLVED: Publish CSS Scroll Snap

Line breaking opportunities at the boundary of a white-space:pre
  inline element
---------------------------------------------------------------------

  - RESOLVED: Line break opportunities should be controlled by the
      parent.

Round Display
-------------

  - The 'auto' value of offset-position will be written to mean do
      nothing to the position of the element.
  - 'contain' will be moved into offset-path as it's only relevant
      when there's an angle.
  - RESOLVED: Change the initial value of offset-rotation to 0deg.
  - jihye will move the offset-* properties into the Motion Path.

Edits that have been accepted and need WG approval for MQ
---------------------------------------------------------

  - RESOLVED: Rename update-frequency to update (issue #1).
  - RESOLVED: Rename normal to fast (issue #1).
  - RESOLVED: Move inverted colors to level 5 (issue #8).
  - RESOLVED: Move custom MQ to level 5 (issue #9).
  - RESOLVED: Publish a new WD of MQ4.

Grid Issues
-----------

  - A decision on what happens with grid line names when dropping
      tracks (Issue here: https://github.com/w3c/csswg-drafts/issues/172w)
      was deferred until next week to give people time to review.
  - RESOLVED: vertical-align: baseline means first baseline except
              for inline-blocks (due to CSS2.1 legacy)

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2016Jun/0151.html

Present:
  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Dave Cramer
  Alex Critchfield
  Simon Fraser
  Daniel Glazman
  Tony Graham
  Jihye Hong
  Joone Hur
  Dael Jackson
  Brad Kemper
  Ian Kilpatrick
  Chris Lilley
  Peter Linss
  Michael Miller
  Edward O'Connor
  Simon Pieters
  Anton Prowse
  Liam Quin
  Matt Rakow
  Florian Rivoal
  Alan Stearns
  Greg Whitworth
  Steve Zilles

Regrets:
  Tantek Çelik
  Ian Vollick

Scribe: dael

  Rossen: Let's get going.
  Rossen: As usual, let's start with a quick call for anything to
          add to the agenda.

CSS WG Charter
==============

  Rossen: There have been a few updates since last week.
  Rossen: The one remaining piece is going over the dates and
          finalizing.
  Rossen: There was an email started by astearns and there have been
          dates proposed and chatter. astearns can you summarize?
  astearns: I put together a straw man schedule I think we should
            put in the charter and then do what we can to meet those
            dates.
  astearns: The other thing that needs to go in is the list of
            things working on. TabAtkins gave me an automation that
            has about half the information. I'm hand-editing the
            rest and should be done today.

  Rossen: To the WG: has everyone had a chance to look at the
          proposed straw man dates from the private list?
  Florian: Just the part that lists REC right?
  astearns: Right. This is REC dates over the charter period.
  Florian: That seemed reasonable.
  Florian: I haven't looked at the rest. What do we say about things
           not listed as going to REC. Do we list them all or...?
  astearns: Current plan is have them in list of things working on,
            show current status, and not give dates for progression.
            plh thought that was okay.
  ChrisL: Deliverables and dates are separate sections.
  Florian: For a spec like CSS 3 UI which has been fairly
           implemented fairly tested but not fully we just don't say
           anything special?
  astearns: Correct. It doesn't mean we can't work on it.
  <Florian> then it looks all good to me

  Rossen: Again, to summarize. It sounds like our plan is to put the
          automated list of drafts in the scope section. Dates will
          be those astearns posted.
  Rossen: That will send a message the rest is in progress but don't
          have a clear idea of where it will land.
  Rossen: Is everyone okay with that?
  <ChrisL> +1
  <glazou> +1 to rossen
  hober: Sure.
  fantasai: My position is if people don't commit to testing nothing
            will get to REC so I'm skeptical of the dates.
  Rossen: That's okay.
  glazou: That's no different than the last 20 years. We've always
          had a testing problem.
  Florian: There is discussion in the AC forum about that. There's
           talks about if we can change the charter process to deal
           with that, but it's not changed yet.
  Rossen: Anything else anyone wants to bring up? Otherwise we can
          action astearns to make the edits.

  ACTION astearns make the edits to have your proposed rec dates in
         the charter
  <trackbot> Created ACTION-780

Scroll Snap Publication
=======================

  Rossen: Just a quick request for a resolution.
  Rossen: Anyone opposed to publishing CSS scroll snap?

  RESOLVED: Publish CSS scroll snap

  <MaRakow> yay :)
  ChrisL: fantasai are you using the automatic from bikeshed or does
          it need to queue?
  fantasai: It needs to be queued up. There's a short name change.
  ChrisL: You don't have to zip it, I can do it manually.
  fantasai: short name change is to css-scroll-snap
  <fantasai> css-snappoints -> css-scroll-snap
  <ChrisL> css-scroll-snap-1 ?
  <fantasai> yep
  Rossen: And we have a resolution on that and that editors are
          yourself, TabAtkins and MaRakow.
  fantasai: Yes.
  Rossen: Great. Let's get that to a more final WD and proceed.
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2016Jun/0020.html
             <- previous resolutions on name change, editorship, etc.
  <TabAtkins> ChrisL: If you run `bikeshed echidna --just-tar`,
              it'll prepare a TAR with all the TR fixes you need
              before publishing.
  <TabAtkins> ChrisL: In the folder you run it in.
  <ChrisL> cool
  <ChrisL> although, see my recent comments on bikeshed issues about
           that, still things to fix manually

Line breaking opportunities at the boundary of a white-space:pre
  inline element
=====================================================================

  <Florian> https://github.com/w3c/csswg-drafts/issues/189
  <Florian> <p>あいうえお<span style="white-space:pre">か</span>きくけこ</p>
  Florian: Here's the relevant bit of code.
  Florian: I've been through the spec and it doesn't say how it
           should work. If you didn't have the span you'd have a
           line break opportunity between all characters. We have
           the white-space:pre in there. Should you be able to break
           on element boundaries? All browsers except blink and the
           webkit family do.
  Florian: I suspect that's from another bug they have. But either
           way the spec doesn't say it's a bug and I think it is.
  Florian: On github we were leaning toward when white-space:pre is
           applied to an element the parent should determine.
  fantasai: It should be just like letter spacing where the spacing
            is given by the parent.
  Florian: I think so too. If everyone agrees can we put it in the
           spec?
  fantasai: I agree.

  Florian: I suspect we have the same issue about things like
           word-break, but I didn't check the spec.
  fantasai: Line break opportunities should be controlled by the
            parent. All of them.
  Florian: Makes sense to me.
  Rossen: Okay. Question. When you say parent do you mean block
          container parent or parent?
  <fantasai> by block container parent, you meant "containing block"
             :)
  fantasai: Parent of the boundary.
  Rossen: Okay.
  Rossen: Any objections?
  <bcampbell> I'm seeing this in the git issue, is that just me?
              "<p>あいうえお<span style="white-space:pre">か</span>きくけこ
              </p>"

  RESOLVED: Line break opportunities should be controlled by the
            parent.

  <dbaron> by "the parent" do we mean "the nearest common ancestor"?

CSS Round Display
=================

  <Rossen> https://lists.w3.org/Archives/Public/www-style/2016Jun/0126.html
  <jihye> https://github.com/w3c/csswg-drafts/issues/214
  jihye: I think it's better to see the github conversation. At San
         Francisco F2F there was a resolution to integrate polar
         positioning to motion path.
  <jihye> https://drafts.csswg.org/css-round-display/#positioning-content
  jihye: I wrote a draft to describe the resolution.
  jihye: Properties related to polar positioning were merged to
         motion path. It's not just about motion but becomes path
         positioning. There are some properties that changed the
         name. offset-path and the like.
  jihye: offset-path defines the path an element can move on. It's a
         merge of motion path and polar-angle. offset-distance is
         the positioned element along the path. offset-anchor is the
         origin of the element which comes from round display polar
         anchor. I have another suggestion for rotation that wasn't
         in resolution.

  jihye: There's 2 issues to discuss.
  jihye: First is about the need for offset-position. It is similar
         to polar origin.
  jihye: The path which the element is positioned along is specified
         by offset path property. When angle is given to offset-path
         it is a straight line with the degree of the angle.
  jihye: The start is the center of the containing block and end is
         the edge of the containing block.
  jihye: Initial position of the elements is the start point of the
         path. After defining the path like that we can use
         offset-position. I defined polar-position as specifying the
         initial position. For example when I define:
  <jihye> offset-path: 90deg;
  jihye: It means the path starts at the center and ends at the
         middle of the right-side edge.
  <jihye> offset-position: 0% 50%
  jihye: Then I add offset-position: 0% 50% the path starts at the
         middle of the left side edge and ends at the middle of the
         right side edge.
  * smfr needs to see pictures
  jihye: With this use case, do you think it's useful and defined
         properly?
  bradk: Several things aren't what I understood the resolution to
         be in San Francisco. Offset-position when discussed I
         agreed to because it had use independent of if you're
         moving along a path. We didn't say when using path it jumps
         to the center. The path is a position relative to where the
         element started. So if you use relpos or top it starts
         where ever it started.
  <fantasai> +1 to bradk
  bradk: If you did an angle you'd move from an angle. Not that it
         jumps to the beginning of the position.
  bradk: Instead of positioning the shape for the containing block
         you position the path's initial point to the element. That
         was it works to all the other positioning properties like
         top and offset and position: relative.
  <TabAtkins> And starting it in the center is just a matter of
              "offset-path: 45deg; offset-position: center;"

  fantasai: The auto value of offset-position was intended to be
            don't do anything special to the position of the
            element. If it was relpos it would be based on its
            position. If abspos it's from the calculation in 2.1 and
            left/right etc. properties. The position of the element
            and path is determined by the position. When it's not
            auto it moves according to offset-position.
  bradk: I don't think you need offset-position to come up with the
         origin. We described that you would start from where ever
         the position was. You don't need it for an origin point.
  Florian: There were two reasons why it was better that way. One
           being that the path itself will change depending on where
           you put the origin. If it's not center and goes to edge
           it's different points than center to the edge.
  bradk: And that's what offset-anchor was for.
  fantasai: You're mixing it up.
  bradk: You need an anchor for where align point to element.
  fantasai: The original proposal says where the path begins. From
            that point you go at an angle until you reach the edge.
            If you start center and go to edge length is 50%.
  fantasai: This applies even if the element is a 1x1px. The path
            will change depending on origin.
  fantasai: Where you attach element to path is the anchor.
  fantasai: Where the path is with respect to containing block is
            origin.
  bradk: If using offset:position.
  Florian: It doesn't just change the position, but also the shape.
  bradk: Why?
  Florian: If you say center and right you do it as center bottom.
  bradk: For a circle or whatever the only odd thing is the inset
         shape. For everything else you position the path the the
         point.
  fantasai: It changes what percentage means. 100% means all the
            way, 0% means stay. 100% changes depending on length of
            path and length depends the origin and end point.
  bradk: Shouldn't. Percentage should be of containing block
  fantasai: No of the path. If you do polar positioning and you want
            45 deg 100% should go as far as you want until the edge.
            That isn't how it's defined in the spec.
  <ChrisL> agree with fantasai, this is how it should work
  bradk: I'm talking about where the path is relative to the
         element. The distance part doesn't come into that expect
         you're picking a size for the path. You're taking a length
         along that path. As long as you have the length you can be
         positioned along it.

  jihye: When path is defined by angle it has to pass through the
         center point.
  bradk: Why?
  bradk: You pick where it starts based on element, pick an array,
         and determine your point along that. You need to know where
         it starts relative to the element itself.
  jihye: I agree. Path doesn't have to start at center. Path has to
         pass through the center of the containing block.
  bradk: No...
  fantasai: The auto values need to be fixed. I think everything
            else is fine.

  Florian: Another point of difference. offset-difference has
           optional contain keyword and the like. I think they
           should be on the path not the distance.
  fantasai: Yes.
  Florian: Because they define what the path is. 100% gets you 100%
           on the path. Right now the contain and the like keywords
           are attached to the distance. But since we decided to put
           the angle as a part of the path they should go together
           with the angle to define the path. And 100% means 100% of
           the path.
  jihye: I put contain on the offset-distance because when I first
         suggested it for polar the major use is the element is not
         overflowing from containing block.
  Florian: I'm not changing behavior, but which property. What we
           put it in is offset-path, not -distance. At least I
           think. Behavior is correct, it's which property it goes
           in.
  bradk: I'm not sure the advantage of one or the other.
  Florian: When offset-path isn't an angle what do the keywords mean
           on the distance. That's why they have to stay with angle.
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2016May/0233.html
  <fantasai> Florian: offset-path newly takes an angle plus a
             keyword (as yet
  <fantasai> undefined list, including contain).
  jihye: When offset-anchor is the center of the element and
         offset-distance is 100% then some part of the element can
         overflow from containing block. So when you put contain on
         offset-distance the overflowing part can come inside the
         containing block.
  Florian: But for offset-path let's say you have a circle or a
           polygon. And then on offset-distance you have the closest
           edge. What does that mean?
  Florian: I don't think it has a clear meaning. And I think the
           behavior is correct but only makes sense when there's an
           angle. That's why I think it should be with the angle.
           When you have it with and angle and percentage I think
           we're fine.
  bradk: Florian, I think I agree, but I guess you could shrink the
         path to be contain.
  TabAtkins: That's going way beyond the use cases. It's keeping a
             polar element from overflowing.
  bradk: But it would more or less. I think I agree it's just a part
         of path.
  Rossen: Going back to jihye...
  Rossen: Are you okay with that?
  jihye: Now I agree with Florian. I agree with contain keyword is
         meaningful when path has an angle value. I think contain
         should be moved to offset-path. I agree with that.
  Florian: And same with closest-side, etc.
  jihye: I agree.

  Rossen: Do you need a resolution from the WG or is this already
          covered?
  jihye: The offset-position I defined on the spec has to be changed
         or remain?
  bradk: The important thing on offset-position it shouldn't be
         required on path movement. You start the path on the
         element, not the containing block.
  Florian: I think we had agreed on that.
  Rossen: I'm trying to stop us before we open the can of worms.
  Florian: We're in the can already.

  fantasai: Offset-position always has a value and the initial is
            auto and it means do the things.
  <fantasai> that you would do if offset-position didn't exist.
  Rossen: And that's what we agreed already.
  <fantasai> yes
  TabAtkins: But the spec doesn't say that.
  Rossen: So it's editorial to make the changes.
  <fantasai> Right, the spec needs to be brought in line with the
             resolution.
  Florian: Yep. It's just auto stops doing the magic.
  <fantasai> It's not editorial, it's correcting the spec.
  Rossen: So the proposed path is jihye to take the clarifications
          into the spec. And that's it.
  <fantasai> It's not clarifications, it's fixes.
  <fantasai> Clarifications don't change behavior, this will. It
             will change the behavior to match the resolution.
  bradk: I'm still not clear on the auto magic.
  Rossen: Same as SF
  TabAtkins: Basically stop doing magic.

  jihye: I have 1 more topic. Initial value of offset-rotation
  jihye: Motion rotation means the path the element moves along.
         Initial value of auto is reasonable while element moves
         being rotated in direction of the path seems natural.
         offset-path could be for an element without motion. So in
         this case having initial rotation as 0deg is natural
  <fantasai> +1 to 0deg initial value
  jihye: I think 0deg is more proper than auto as the initial value
         for offset-rotation. Is it okay to change that?
  fantasai: I strongly agree.
  bradk: So do I. I think the only person who had it different is
         shans. We always had it so that if the property doesn't
         exist it matched and 0deg is that.

  TabAtkins: We should probably re-name auto to be more useful. Like
             follow or match. Don't need to discuss that now.
  bradk: There's another issue as to if we can use transforms, but
         that's a different day.

  Rossen: So proposed resolution is to change to 0deg as the initial
          value of offset-rotation.
  Florian: Isn't there a compat issue? It's changing the initial
           value of an existing property.
  TabAtkins: This isn't existing.
  Florian: It's called motion.
  bradk: That's separate and I don't think it's impl.
  TabAtkins: The motion properties aren't publicly impl. I think we
             have them a behind a flag. We have room to change.
  bradk: With a different property name there isn't an issue.
  TabAtkins: There's 0 compat issues
  Florian: caniuse.com says motion path is enabled in Chrome.
  ChrisL: That's in SVG.
  Florian: Alright.
  Rossen: I'll take TabAtkins's word.
  Rossen: Any objections to the resolution?

  RESOLVED: change to 0deg as the initial value of offset-rotation

  TabAtkins: Final bit. I thought we agreed to move these to motion
             path spec. I'd like to do that or resolve on it. It's
             the proper place for them to live.
  Rossen: I don't recall.
  Florian: I think we had one and added jihye as a co editor.
  Rossen: Okay. Who is editing motion path?
  jihye: shans
  bradk: What do we move?
  TabAtkins: All of them. They're transform based at the bottom.
  Florian: Yep.
  TabAtkins: They all get triggered into a transform in the
             transformation matrix.
  bradk: I guess, but offset-position doesn't have much to do with
         paths.
  fantasai: It doesn't belong in round display. We can argue on the
            rest later.
  <astearns> from the SF minutes: "The motion path spec will need to
             be renamed since it's more about path positioning than
             it is about motion."
  fantasai: shans agreed with the changes and we added jihye as the
            editor.
  ACTION: jihye to move offset- properties to motion-path spec
  <trackbot> Created ACTION-781

Edits that have been accepted and need WG approval for MQ
=========================================================

  <Rossen> https://drafts.csswg.org/mediaqueries/issues-wd-2016-01-26#issue-1
  <Rossen> https://drafts.csswg.org/mediaqueries/issues-wd-2016-01-26#issue-8
  <Rossen> https://drafts.csswg.org/mediaqueries/issues-wd-2016-01-26#issue-9

Issue #1
--------

  fantasai: There were some issues. 1 was rename update-frequency:
            normal to update: fast.
  fantasai: List seemed to find that okay.
  fantasai: Dunno if there are other opinions.
  <fantasai> https://drafts.csswg.org/mediaqueries/#update
  <fantasai> So, two changes: 1) rename update-frequence to update
             2) rename normal to fast
  Florian: I'm okay with the change, but I think there was a purpose
           to the naming. slow and fast doesn't give a reference
           point. When you have slow and normal it's quite clear.
           It's the usual thing and slow. But then again people can
           read the spec.
  Rossen: Okay. fantasai you want a resolution?
  fantasai: One to rename the property and one to rename the value
  Rossen: Property first. Objections?

  RESOLVED: Rename update-frequency to update (issue #1).

  Rossen: Objections on normal to fast?
  Florian: I prefer the other but don't object

  RESOLVED: Rename normal to fast (issue #1).

Issue #8
--------

  Rossen: Defer inverted colors is next.
  fantasai: Yeah. Discussed deferring it so we can do a proper
            evaluation for all the things needed to handle colors
            correctly since it's not clear that's sorted out.
            Proposal is to move this so we can cut down to
            everything stable and ship this summer.
  Florian: I think deferring is okay. This is an investigation we
           haven't done.
  Rossen: I'd agree on moving this to later. As an implementor of
          high contrast more time would be good.
  Rossen: Any objections to moving inverted colors to level 5?

  RESOLVED: Move inverted colors to level 5 (issue #8)

Issue #9
--------

  Rossen: Issue #9
  fantasai: This one isn't 100% baked so defer it to level 5.
  Florian: I'm okay with it. I think TabAtkins intended to move to
           houdini?
  TabAtkins: We'll move it where it needs to be. Doesn't matter.
  Rossen: Objections to move custom MQ to level 5?

  RESOLVED: Move custom MQ to level 5 (issue #9).

Publication
-----------

  Rossen: Any other MQ items?
  fantasai: There's some stuff for later, but I think we should
            publish a new WD and deal with the next set of issues in
            the next cycle.
  Rossen: That would be great. Anyone objecting?

  RESOLVED: Publish a new WD of MQ4.

  TabAtkins: I'll handle publication.
  <ChrisL> tab, mq4 is already in place and queued for publication
           tomorrow

Grid
====

What happens with grid line names when dropping tracks
------------------------------------------------------

  <Rossen> https://github.com/w3c/csswg-drafts/issues/172
  fantasai: We discussed...the question was with the auto-fit:
            repeat we dropped tracks that were empty after the
            layout. You collapse and give them 0 width and merge
            gutters. We made a proposed set of edits and what to
            resolve on this definition shift.
  fantasai: The collapse helps with the abspos items that need to
            define where they are if using lines. Also output of
            CSSOM is clear because it's just 0 width. In terms of
            determining positioning and gaps the gutters around
            collapsed tracks are collapsed to nothing. If you're in
            the middle of the grid they overlap. This gives the
            expected behavior.
  Rossen: Only end or beginning as well?
  fantasai: It's symmetric.
  fantasai: We wanted to define the correct behavior, not because we
            expect this to be common but it's quite likely we'll add
            a concept of collapsing tracks explicitly. Looking
            forward this hooks into how that would work.

  <fantasai> https://github.com/w3c/csswg-drafts/commit/ac370302681c2425777a57b8461281e1bd88afc8
  fantasai: That's the change set.
  Rossen: Any comment or feedback?
  Rossen: I don't hear anything. I'm personally behind on this, but
          I can comment on github. Are you looking for a particular
          outcome?
  fantasai: Resolution on the change.
  fantasai: We can defer a week
  Rossen: That would be great for us.
  TabAtkins: We just wrote it yesterday.
  Rossen: If you're okay to push a week let's do that.

Baseline alignment
------------------

  <fantasai> https://github.com/w3c/csswg-drafts/issues/195
  fantasai: Do you align to the first or last baseline? We say the
            first. In CSS 2.1 it has tables align to the first and
            inline blocks to the last. Other precedent is how
            baseline values work in flexbox which always uses the
            first. So grid will interpret first line is the baseline.
  Rossen: I'm in favor of keeping those in sync as much as can.
  Rossen: We do the same for inline tables as well?
  fantasai: Yes, that's the first row.
  Rossen: So I'm even in more favor.
  Rossen: Objections?

  RESOLVED: vertical-align: baseline means first baseline except for
            inline-blocks (due to CSS2.1 legacy)

  fantasai: Last one, #8, needs more work from TabAtkins and I. It
            needs to defer anyway.
  Rossen: In that case that's the top of the hour and the end of the
          agenda. Thank you everyone. We'll call it a day.
  Rossen: Thanks, bye