W3C home > Mailing lists > Public > www-style@w3.org > November 2015

[CSSWG] Minutes Telecon 2015-11-11 [css-device-adapt] [css-snappoints] [css-round-display] [css-line-grid] [css-page]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 12 Nov 2015 05:25:40 -0500
Message-ID: <CADhPm3t+4BgTg=KOjvOC8pgusp-hfYgN40TAo8g9uN5ePu=+2Q@mail.gmail.com>
To: www-style@w3.org
New WD for Device Adaptation

  - RESOLVED: Publish new WD for Device Adaptation.

CSS Snap Points Path Forward

  - MaRakow, TabAtkins, and fantasai got a chance to speak and come
      to a consensus on how to fold the change in approach to snap
      points into the existing WD.
      - This change-over will occur over the next several weeks.
  - Once the new version is ready, the group will publish a last
      version of the old approach right before publishing the new
      approach, both as WDs.
      - This allows a good record of how the spec progressed without
          sending the wrong signal about the direction of the spec
          to implementors.

Round Display

  - There was support for the proposal of 2D rotation transform
      function for polar coordinates, though it was thought they
      should be named polar-angle and reverse-polar-angle or
      polar-reverse-angle to explicitly link them with the polar
      - An additional question was raised about how it would
          interact with animation, but it was decided that that
          interaction was dependent on if it's a computed value or a
          specified value.
  - RESOLVED: Accept the proposal for a 2D rotation transform
              function for polar coordinates and make it clear if
              it's a computed value or a specified value and make a
              note on the implication of that decision on animations.
  - RESOLVED: Accept the polar-origin changes.
  - The polar-origin proposal lead to a conversation about adding a
      center value to fixed and absolute positioning.
      - The conversation will continue on the mailing list.
      - If this change ends up happening, it may negate the need for

Page Floats

  - There wasn't telecon time for a full conversation, but it was
      suggested that the interested parties get on a separate call
      to work through the mailing list topics.
      - johanneswilm and Florian will work on organizing a call.

Match-Parent and Orthogonal Flows

  - RESOLVED: Line-grid will restart in the case of orthogonal flows
              between parent and child.

Additional Page Sizes

  - RESOLVED: Add JIS-B4 and JIS-B5 to page-floats.
  - Florian will summarize other page sizes that could be added to
      the spec in an e-mail.


Agenda: https://lists.w3.org/Archives/Public/www-style/2015Nov/0185.html

  Rossen Atanassov
  Dave Cramer
  Elika Etemad
  Tony Graham
  Jihye Hong
  Dael Jackson
  Brian Kardell
  Brad Kemper
  Peter Linss
  Myles Maxfield
  Simon Pieters
  Anton Prowse (IRC Only)
  Matt Rakow
  Florian Rivoal
  Simon Sapin
  Alan Stearns
  Lea Verou
  Greg Whitworth
  Johannes Wilm
  Steve Zilles

  David Baron
  Bert Bos
  Angelo Cano
  Adenilson Cavalcanti
  Alex Critchfield
  Simon Fraser
  Daniel Glazman
  Michael Miller
  Edward O'Connor
  Zhong Xu

  Scribe: dael

  Rossen: First thing, any extra items?
  <Florian> https://lists.w3.org/Archives/Public/www-style/2015Nov/0154.html
  Florian: I doubt we'll get to it, but it would be good to talk about
this (link above) this time or next.
  Rossen: This is the pre-wrap/pre-wrap-auto? We'll add it.
  Rossen: Any other topics?

WG Administrative Discussion


New WD for Device Adaptation

  <astearns> https://drafts.csswg.org/css-device-adapt/#changes
  Florian: I've been through the log. It's been a long time and
           there are substantive changes. I think we should publish
           a new WD. I've made a change section. If anyone wants
           issues logged before we publish it would be good, but I'd
           rather add issues and publish as-is because it's been a
           long time. What do people think?

  <astearns> +1 to new WD
  MaRakow: We had a side discussion about the two issues I raised.
           I'll add those as issues so we can move ahead with
           publishing a WD.
  Florian: Okay. Anything else people would like marked in the
  SteveZ: Good for me.
  Rossen: Sounds like everyone is okay with publishing. I'm also in
          favor of publishing with the added issues.

  RESOLVED: Publish new WD for Device Adaptation.

  Rossen: Who will help with the publication?
  Rossen: Are ChrisL or Bert on? No. Florian can you ping one of
          them to get it published?

  ACTION Florian to work with Chris or Bert on publication
  <trackbot> Created ACTION-743

CSS Snap Points Path Forward

  Rossen: This was worked on extensively with conversations, so we
          need a follow-up.
  MaRakow: I had a telecon with TabAtkins and fantasai last week.
           They gave me a walk through of the technical changes. We
           discussed on there some changes and wording. As far as
           procedure goes, over the next couple of weeks we'll do a
           detailed review of the spec and pull them into the
           existing ED so we can isolate and identify items.
  MaRakow: There were a couple of issues, I think we were going to
           remove edges from snap-align and a couple of others, but
           that will happen over the next few weeks and we'll have a
           merged draft.
  Rossen: So it sounds like in a couple of weeks we can republish
          the merged draft?
  MaRakow: Sounds right.

  Rossen: Do we have anything we want to publish prior to have a
          good before/after?
  MaRakow: The spec has the Japan changes using the old syntax. We
           could publish that as the furthest progression of the old
           syntax. So before moving to the new terms this is as far
           as the old one went.
  Rossen: Is everyone okay with publishing a WD first and publish
          the merged draft including the new syntax?
  fantasai: Only if we're super clear with a message in the status
            with what the changes will be. I don't want implementors
            to think we're not going the new way and implement this
            other thing.
  MaRakow: That makes sense.
  <astearns> would rather wait until we have the draft set with
             everything we've agreed on.
  Florian: I'm okay with preserving a current state, but I'm worried
           about the signal. Can we save the draft on the side, work
           on the new one, and publish both in a row? That way we
           don't have a long piece of time with the old one.
  MaRakow: Main problem with delaying publishing updates is what
           will be up will be less up to date.
  Florian: It's a matter of signaling. If you update with something
           we no longer want that could be confusing.

  Rossen: What are the types of changes you have?
  MaRakow: I don't have full list, but it included removal of repeat
           syntax and some text. I can send the full list to the
           mailing list if that helps.
  Florian: If we do a gigantic warning that's probably fine.
  Rossen: So we can wait until the merged draft is ready and publish
          both drafts one after another. That would buy you safety
          if it takes longer, which I think worries some people. The
          other option is if you're committed to the short timeline,
          I doubt this will provoke too much implementor confusion.
  fantasai: It would be fairly easy to snapshot the draft right now,
            save it, and publish later.
  MaRakow: I can go with whatever the group recommends. I wanted to
           raise the potential of having the midpoint.
  Rossen: I think we agree it's important, it's all about timing.
  Rossen: We'll take the snapshot for now and then we'll publish the
          two specs one after another once you're ready.
  MaRakow: Sounds good.
  Rossen: Let's go with that. We'll resolve once you're ready with
          the new draft.

  MaRakow: Procedurally, who takes the snapshot?
  fantasai: Easiest way is for you to note the change set that
            corresponds to what you want as the snapshot. Then
            whoever publishes can pull down that change set and make
            it a WD to pass off to the staff.

  Rossen: Two topics on page floats are next on the agenda. These
          had the highest number of people wanting to talk about,
          but they'll take a while. The Round Display was brought by
          LG and they're in an awkward time zone. If fantasai and
          johanneswilm are okay, I'd rather do round display first.
  johanneswilm: Okay.

Round Display

2D rotation transform function for polar coordinates

  <jihye> https://lists.w3.org/Archives/Public/www-style/2015Oct/0177.html
  <jihye> https://drafts.csswg.org/css-round-display/#2d-rotation-transform-function
  jihye: There was discussion about the polar orientation property
         at TPAC. It was decided to achieve the effect by the rotate
         function with additional keywords.n
  <jihye> rotate() = rotate( <angle> | center | counter-center)
  jihye: Therefore I extended 2D rotation transform for polar
         coordinates. In most polar positioning cases elements are
         rotated on anchor point to origin point. So we need center
         and counter-center value.
  jihye: Center enables us to achieve the kind of positioning
         elements more easily than specifying an exact value. Also
         counter-center, which means center value + 180deg for when
         elements are positioned downward in the shape of a
         containing block.
  <jihye> http://anawhj.github.io/jRound/demo/facebook/circle.html
  jihye: In this use case [above link] there are several menu icons.
         The upper menus are rotated with center and lower are with
  <astearns> (demo does not work in FF, but does in Chrome)
  <gregwhitworth> @astearns strange, works in edge - makes me think
                  it's probably webkit related somehow

  jihye: Is this extension of rotate reasonable and are our keyword
         value names appropriate?
  <Florian> rotate() = rotate( <angle> | polar-angle |
            reverse-polar-angle )
  Florian: I think proposal is reasonable, but maybe change the
           names to what I have in IRC?

  <astearns> would the keywords also need to be added to
             https://drafts.csswg.org/css-transforms-2/#propdef-rotate ?
  <fantasai> astearns, no
  <fantasai> astearns, e.g. css-ruby extends 'display'
  <fantasai> astearns: so not necessary to fold in

  Rossen: What do others think? The proposal is add to rotate that
          takes polar and reverse-polar.
  Rossen: Your current function will take...it could be both
          polar-angle and reverse-polar-angle for the given angle?
  jihye: No, polar-angle and reverse-polar-angle can be used instead
         of angle value.
  Rossen: And the little icons like the like button in the demo, is
          that the icons you were referring to?
  jihye: Yes. Like and share are using counter-center which means
         reverse-polar-angle value.
  Florian: It does the same thing as typing an angle manually, but
           it picks the value from the computed value of the polar
           angle property so you don't have to manually sync.
  * fantasai would go with polar-angle/polar-reverse so they both
             start with polar-

  myles: If this is inside an animation, what do you expect to occur?
  myles: Is this function animatable and if so what is the behavior?
  jihye: When the rotation function has center value, then when the
         elements are moving on the edge of the circular shape, then
         always elements are rotated toward the center point of the
         containing block. So you don't have to manually adjust the
         angle of the rotation function.
  Rossen: So if you're animating from an angle to another angle...
  myles: Like if one side of the keyframe has center and the other
         an angle.
  Rossen: So since both are computable, you're animating from
          degrees to degrees.
  myles: The polar-angle value can also be animated. So you animated
         between things that can be animated? Or am I
  Florian: Wouldn't the behavior fall out of our existing rules?
  jihye: I didn't consider animating.
  myles: Regarding Florian's comment, I'm not sure we have existing
         behavior where we're animating between something we're also
         animating, so it may be worth considering that case.
  Rossen: That's something we should take as an issue if we accept
  <astearns> so change to polar-angle | reverse-polar-angle and add
             an issue about animating?

  Rossen: So, what do people think about the addition of polar-angle
          | reverse-polar-angle
  BradK: I like it.
  <astearns> I like it
  <Florian> +1
  fantasai: I think it makes sense. I would go with names that start
            with polar to make it clear the values come from the
            polar properties.
  Rossen: That makes sense. It sounds like we'll have to record an
          issue about if this is something that will be requiring
          special animation handling.
  fantasai: If you're animating polar, if it doesn't compute
            through, which I don't think it should, as you're
            animating polar-angle the transform will change. If it
            computes through you will probably...it won't work as
  fantasai: Animating between...that would work. If you don't
            compute through it will animate just fine. If you're
            animating between rotate: polar-angle and rotate: 0
  Florian: It doesn't sound unreasonable to animate between
           polar-angle and another of the keywords. But when you
           combine both, what happens? If you simultaneously
           animated the transform property from rotate a keyword to
           an angle and animating the polar-angle.
  <fantasai> Florian, this is the same problem as border-color.
  Rossen: If you're animating something to inherit and the inherited
          value is being animated, as long as the computed values
          resolve to animate-able it should work. Both center and
          counter-center are just two angles. I don't see how this
          is bringing something new to the way you would resolve
          your animation graph.
  Florian: I was hoping it wouldn't, but the previous discussion
           suggests that we may need to make it explicit.
  fantasai: We need to make it clear if they're computed values on
            their own or if they compute through. How they animate
            falls out from that. We had a similar issue with
            animating border and border-color.

  Rossen: Reasonable. How about accept the change to rotate and
          record an issue to make the interaction between the
          keywords and animations clear.
  Rossen: Is that okay?
  jihye: Yes.
  fantasai: I think the issue is make it clear if it's a computed
            value and we can make a note on the implication of that
            decision on animations. We need to make sure if they
            compute through to the value on the other property or not.
  fantasai: We probably want dbaron to look at that decision.
  Florian: We can record as an issue and move on.

  RESOLVED: Accept the proposal and make it clear if it's a computed
            value or a specified value and make a note on the
            implication of that decision on animations.

Polar Origin

  <Rossen> https://lists.w3.org/Archives/Public/www-style/2015Nov/0155.html
  <jihye> https://drafts.csswg.org/css-round-display/#polar-origin-property
  jihye: At TPAC it was resolve dot add polar-origin independent of
         transform origin. I updated round display.
  jihye: There was consideration of positioning elements with polar
         positioning and abspos.
  jihye: Before adding the polar-origin property the origin of polar
         coordinate was always the center point.
  jihye: For that reason we can't use...without polar-origin we
         can't use abspos with polar positioning. With polar-origin
         we can achieve the same effect as abspos. Polar positioning
         is then applied based on polar-origin.
  jihye: There may be a situation about adjusting the element's
         position horizontal or vertical after being positioned in
         polar coordinates. Do we need to apply abspos to elements
         in polar coordinates?

  <Florian> I don't think polar-origin should have any effect unless
            polar positioning is turned on. I don't think polar-
            origin should turn on polar positioning on its own.
  Florian: If I'm understanding correctly, I don't think I agree
           that polar-origin should turn polar position on. It
           should do nothing unless we're doing polar positioning.
  <fantasai> +1
  Florian: That seems like a simpler model. I saw the suggestion on
           the mailing list, but it confused me more.

  BradK: I think some of the thread was in response to my e-mail. I
         haven't had a chance to review the e-mail. My idea was
         polar would work within abspos or fixedpos. It would be
         more similar to top, right, bottom, left. They start as
         auto and when you set a value they position themselves.
         That's why I suggested one would be auto as a start and
         when you give it a value it positions according to polar-
         coordinates and you can use top, right, bottom, left.
  Florian: If we did that, I think polar-distance should have the
  BradK: It's either polar-distance or polar-origin. One being
         non-auto would be the trigger.

  Florian: I think we should think on that separately and add
           polar-origin non-magic now.
  BradK: I don't know if it's magic. It's more in keeping with other
         position properties.
  Florian: The wording wasn't good. But if we switch away is a
           different conversation than if we should have
           polar-origin. I think they're both worth discussing.
  BradK: Is polar-origin still needed if we have the polar
         properties as part of abspos?
  Florian: Ah. I see what you mean. Maaaayybe.
  Florian: So you're saying if we could use abspos it would be
           left/right instead of polar-origin?
  BradK: Yeah.
  Florian: That sounds confusing because you want polar-origin to
           default to the center.
  BradK: I think it would be by default horizontal center if you
         didn't have left/right. Or you have a center property which
         I've been wanting for a long time.
  Rossen: Value or property?
  BradK: Property. One that works like left and right, one that
         works like top and bottom.
  BradK: Or, in the example I gave, for horizontal center, you
         position the center of the positioned item with whatever
         you want in terms of percentage. The center could line up
         with the end of a slider.

  Rossen: Going back to the issue. Do we feel like we have enough to
          resolve now, or does this go back to the mailing list? It
          sounds like there's quite a few opinions and it sounds
          like a more general change of the actual model. I don't
          think we can resolve on a large change with only a subset
          of the WG and not much thinking.
  Rossen: I'd suggest we take this all back to the mailing list.
  Florian: So either we take everything back or resolve to add
           polar-origin with the understanding that BradK's
           suggestion may change the whole model and make it
  Rossen: That sounds reasonable.
  <fantasai> +1 to resolving on polar-origin and also on exploring
             Brad's proposal further
  Rossen: So accept the current model, resolve on polar-origin and
          continue the discussion on changing the model as per
          BradK's suggestion.
  jihye: Okay, we can discuss at mailing list.
  BradK: I'm okay accepting polar-origin for now with the
         understanding it might change if we move it into
         positioning properties.
  Rossen: So BradK's challenge will continue on the mailing list. As
          the polar-origin stands in the current model, anyone
          opposed to adding?

  RESOLVED: Accept the polar-origin changes.

  Rossen: We'll continue the other conversation on the mailing list.

Page Floats

  Rossen: Which topic do you think we can do in 10 minutes?
  fantasai: I don't think we can do either. There's a lot going on
            in that thread that's really interesting. I don't think
            solving them will work yet.
  johanneswilm: If we don't have anything else, I think we could say
                something about inline-start.
  Rossen: We have enough things on the agenda. Those topics were
          brought up by the most people. If you're okay to continue
          on the mailing list we can postpone the page floats topics
          for a week. It's up to you.
  johanneswilm: It's fine to take them up next week if we continue
                on the mailing list.
  Rossen: Continue on the mailing list for the time being.
  Florian: For the page floats. The subject is large enough we may
           want a separate call since it could take an entire
           conference call.
  johanneswilm: Agreed.
  Rossen: Agreed. I think a number of people will want to
          participate. If johanneswilm and Florian, you can
          coordinate, we can get on the phone and get it out of the
  johanneswilm: I can try and coordinate with Florian.
  <gregwhitworth> Can you include me Johannes as well

Match-Parent and Orthogonal Flows

  Rossen: 3 topics left. line-grid, css-page, and the pre-wrap topic
          brought up at the beginning of the call. Florian, which
          can we do in 7 minutes?
  Florian: line-grid
  <Rossen> http://lists.w3.org/Archives/Public/www-style/2015Oct/0233.html

  fantasai: I think you're right we create new grid.
  <astearns> Makes sense to me.
  Rossen: With my implementor hat restarting the grid makes the most
          sense. When we do have subgrids in the grid module, if the
          subgrids have orthogonal flows I wouldn't want to match.
  Rossen: Objections?

  RESOLVED: Line-grid will restart in the case of orthogonal flows
            between parent and child.

Additional Page Sizes

  <Rossen> http://lists.w3.org/Archives/Public/www-style/2015Oct/0234.html
  Florian: We have two values of the size property/descriptor. The
           sizes can be B4 or B5. These are ISO sizes which are
           different from JIS sizes. Japan uses JIS sizes and they
           are one of the few places that use the B sizes frequently.
           I don't believe many people use ISO B sizes. Japan uses B
           sizes for paper, it would be good to actually use it.
  Florian: I propose to add JIS-B4 and JIS-B5. There's a whole bunch
           more we could support, such as A6. But since we already
           have the B values, adding JIS version would save a lot of
  Rossen: Sounds reasonable to me.
  <dauwhe> Prince has quite a long list of supported sizes:

  Rossen: The current spec has B4 and B5. Are you proposing to add
          JIS-B4 or also rename the existing?
  Florian: Minimum is to add JIS-B4 AND JIS-B5. We could also add
           ISO-B4 and ISO-B5 which alias to B4 and B5 since they're
           already there. I don't care strongly between those
           options. I think the original proposal was to add the ISO
           but as long as we have JIS I'm good.
  Rossen: I'm in favor of the minimal change of just adding JIS-B4
          and JIS-B5 and leaving B4 and B5 as they are. Other
  dauwhe: That minimal change sounds reasonable to me.
  Rossen: Any objections?

  RESOLVED: Add JIS-B4 and JIS-B5 to page-floats.

  fantasai: I'm happy to add the changes, but Florian can just add
  ACTION Florian add JIS-B4 and JIS-B5 values to the page spec.
  <trackbot> Created ACTION-744

  Rossen: Looking through, are all the listed editors active?
  plinss: Melinda isn't active.
  <dauwhe> https://drafts.csswg.org/css-page/
  Florian: The editor changes are done in the ED.
  Rossen: Okay, great.

  Florian: In the 12 sec left, in a future version of the spec we
           should consider a more robust list. All editors that care
           about print have a longer list. More things would make
  Rossen: It would be great if you can summarize those in an e-mail.

  Rossen: That's the top of the hour. Thank you everyone.
Received on Thursday, 12 November 2015 10:26:39 UTC

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