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

[CSSWG] Minutes Sydney F2F 2016-02-02 Part II: Round Display [css-round-display]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 23 Mar 2016 17:31:36 -0400
Message-ID: <CADhPm3vMBw7=BkNExR70GbasbfQSCYted+pSz8atu2ecdjZ5Ow@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.

Round Display

  - RESOLVED: Add radial-gradient <side> keywords to polar-distance.
              Mark issue for how to get e.g. from top left corner,
              100% of shortest side.
  - There was some uncertainty about how 'contain' should behave in
      relation to the previous resolution and in general. However,
      it was decided that decisions on if 'contain' should be a
      default behavior should wait on a final definition.
  - The existing proposals for addressing polar positioning and
      abspos were discussed, but there were still unanswered
      questions .
      - An outstanding concern that the mental model for this was
          the opposite of the mental model for the rest of CSS.
      - A proposal developed to drop polar-origin and instead use
          alignment to achieve the desired effect.
  - RESOLVED: Make the following changes:
              1. Remove 'polar' value of 'position'. Polar
                 positioning applies to absolute/fixed/static/sticky/
                 relative positioned elements
              2. Remove 'auto' value of 'polar-distance'. Initial
                 value is 0
              3. Add 'auto' value to 'polar-origin'. This means find
                 the origin using normal rules for absolute/fixed/
                 static/sticky/relative positioning.
              4. Make 'auto' initial value of 'polar-origin'
              5. Add an open issue as to whether top/right/bottom/
                 left properties are ignored or interpreted somehow
                 when 'polar-origin' is not 'auto'.
              NOTE: polar-origin doesn't apply to relatively-
                    positioned elements.
                    (Or mark an issue for making it apply somehow).

  - Joone presented a proposal for supporting 3d transforms in round
      display. However, there were two major issues with this
          1. Transforms aren't a positioning system. This proposal
             presumes that they are.
          2. Need use cases for what 3D polar coordinates.
  - However, there was agreement that it might be interesting to
      add functions for using polar-positioning-like syntax as an
      alternate way to express existing transforms.

  - The ability to support scrolling on a round display would best
      come from some of the scrolling work being done in Houdini.

  - Since most pages are not designed for round displays,
      browsers on such devices simulate a rectangular viewport
      by designating a fully-visible area of the display.
      For pages that are prepared to handle the constraints of
      working with a round display, it was suggested to add
      an @viewport switch for authors to opt into the full viewport.
  - RESOLVED: Publish new WD of Round Display, with
              polar positioning resolution incorporated (@viewport
              for next publication okay)

  - The discussion from Sapporo about device-radius was revisited;
      originally it had been concluded that the query would no
      longer return a radius, but instead return if you're visible
      or not.
      - There was concern from LG about complexity and
      - There was a suggestion that a qualitative query for
          "roundish" vs "squarish" would be useful, regardless.
      - Florian will write up a proposal for this new media query.


Agenda: https://wiki.csswg.org/planning/sydney-2016

Scribe: fantasai (with gregwhitworth scribing when fantasai spoke)

Round Display

  hyojin: I think if Web support various technology with display
          shape, a variety of products will adapt web-based platform
          OS in near future.
  hyojin: LG webOS is one of the platforms, and CSS Round Display is
          starting point in W3C.
  hyojin: Some polar issues.

Percentages of 'polar-distance' when origin is not the center of the
    containing block

  <astearns> https://lists.w3.org/Archives/Public/www-style/2016Jan/0152.html
  jihye: First issue is about percentage of polar distance when
         origin is not the center of the containing block.
  jihye: This issue was action item at Sapporo meeting.
  jihye: We need to define clearly about percentage of polar
         distance when origin is not center.
  jihye: When origin is not the center, the distance between the
         origin of polar coordinates and edge of the containing
         block varies according to the value of polar angle.
  jihye: With this method we have to assume that the shape of the
         containing block is inscribed circle for applying the
         method to round display.
  jihye: We also have to use polar positioning for rectangular
         containing block.
  jihye: But aligning elements here seems to be strange.
  jihye: Because if there are elements with elements with same
         percentage but different polar angle, they create an
         alignment in rectangular shape.
  jihye: This is not an appropriate polar positioning.
  jihye: We discussed about this problem and we got a reference of
  jihye: So I suggest to specify percentage with extra keywords, e.g.
  <jihye> polar-distance : [closet-side | farthest-side |
          closest-corner | farthest-corner]? <percentage>

  Florian: Looking at various use cases to see which is the correct
           definition of percent.
  Florian: Different use cases give different answers.
  Florian: Sometimes you want to follow the shape around you.
  Florian: Sometimes you actually want a circle.
  Florian: So having a choice among these four,
  Florian: allows different circles.
  Florian: And if you omit these keywords, then you do follow the
  Florian: So on each angle, 100% gets you to the edge.
  Florian: If you are in a rectangle, you move in a rectangle, get
           to the edge.
  Florian: Sometimes this is what you want.
  Florian: Sometimes this is what you want, but sometimes want to
           move in a circle.
  Florian: So having theses keywords, plus option to omit keyword,
  Florian: We get 5 behaviors instead of 1.
  Florian: Because I think one doesn't solve the use case.
  Florian: And we reuse familiar syntax.
  BradK: I can see how closest-side would be used. When would you
         use closest-corner or furthest-side? Seems like you'd get a
         lot of clipping.
  Florian: Would use if you are in a corner, use closest-side.
  fantasai: Seems problematic, because you want the shorter (?) side.
  Florian: If you're in a corner and use closest-side, result is the
           corner (0), then want farthest side.
  BradK: I think closest-side seems useful, unsure about the rest.
  Florian: Seems to be most useful, yes, but if borrowing
           radial-gradient(), just take the whole thing
  <fantasai> polar-distance: <side>? <percentage>
  jihye: I think this covers all cases developer would want.

  jihye: Can we define polar distance by this method?
  fantasai: It's a good direction to go in, I'm a little concerned.
  fantasai: If you have a point in the top left corner of a
            rectangle, and you want 100% to along the short side, I
            don't see how you would do this because closest-side
            would give you 0, but farthest-side would get you too far.
  Florian: It would take us away from radial-gradients, but maybe it
           should be closest non-zero side.
  Rossen: Definitely moving in right direction, might be some
          additions to it.
  Rossen: But mostly okay with this.
  Rossen: Any objections?

  RESOLVED: Add radial-gradient <side> keywords to polar-distance.
            Mark issue top left corner, asking 100% of shortest
            side, how to get that.

Revisiting 'contain' keyword in relation to the previous topic

  Florian: We currently have a 'contain' keyword adding to
           percentages for avoiding overflow,
  Florian: Without it, cause overflow.
  Florian: The 'contain' keyword modifies this to make 100% the
           point where you would just not overflow.
  Florian: I have nothing to say behavior difference.
  Florian: I have a worry about which is the two is the default.
  Florian: I'd rather have no keyword doing the 'contain' behavior,
  Florian: and add 'unsafe' to do overflow.

  BradK: I think we should revisit 'contain'.
  BradK: I don't think it's very effective at placing things where
         you want them.
  BradK: If you have a clock face with square numbers, the 6 will
         be really close to bottom,
  BradK: but something like 10, in order to contain the corner,
         will throw the center of the 10 closer to center of the
         dial than anything else.
  BradK: I think you really want the center of the numbers to all
         align along a circle, but you don't get that.
  Florian: Round the corners.
  fantasai: No BradK's right.
  BradK: That doesn't sound like a good general solution. Doesn't
         make it useful.

  BradK: Don't always want squares, either. E.g. a 3 is much
         narrower than 12.
  BradK: Would be better to have 100% means put center along the
         curve, then move in by half the height or something like

  BradK: The way it's spec right now, 100% without contain puts the
         center of the element along the path of the circular
         container, right?
  BradK: If you're dealing with numbers on a clock face, all the
         same, they're all the same height, so you can take half
         that height and move it back by that amount,
  BradK: And then it would be contained.
  BradK: That would be better than have corners poking in more than
         sides do.
  Florian: Height doesn't work in [???]
  BradK: If it was always half the height, and all the same height,
         then they would all move in by that amount.
  Florian: But that wouldn't be sufficient to avoid overflow.
  Florian: If wider than tall, half the height isn't enough to move
  SteveZ: [mumbles something]

  BradK: Don't have a perfect solution, but I think we need to think
         some more. Because the one we have right now isn't a great
  * fantasai agrees with BradK

  SteveZ: Instead of half the height, could do half the largest
  SteveZ: Has to be the same for all of them.
  Florian: We don't have that, though.
  * fantasai thinks shape-outside might be useful here.
  BradK: You'd have to have a fixed width, might have overflow
         because numbers wider than you anticipated....

  Florian: I think there is more work needed on definition of
  Florian: Also need to take into account whether or not we care
           about rounded corners,
  Florian: or shape-outside,
  Florian: or shape-inside.
  Florian: But assuming we have a 'contain' behavior, would rather
           it be the default.
  Florian: Regardless of how we define it.
  Florian: Maybe reserve judgment of that until we have a precise
  BradK: I don't feel strongly one way or another.
  BradK: Sometimes want one or the other.

  Florian: My concern is not that, but what happens if the user has
           a differently sized screen and author didn't think about
  Florian: If author didn't ask for overflow, let's not overflow.
  BradK: I think I'll reserve judgment until we had a better
         definition of 'contain'
  * fantasai agrees with BradK
  Florian: Okay, let's work on contain more until deciding whether
           it's the default.

polar positioning and abspos

  jihye: Next issue is polar positioning and abspos
  <astearns> https://lists.w3.org/Archives/Public/www-style/2016Jan/0134.html
  <hyojin> Also refer to this written by BradK yesterday:
  jihye: There was an idea of making polar-distance and polar-angle
         with abspos.
  jihye: So polar-position properties used with abspos,
  jihye: Use of polar positioning is changed.
  jihye: If polar-distance isn't auto, then can be polar-positioned.
  jihye: If any property among left/top/right/bottom isn't auto
         value, any of polar-* property is ignored
  Florian: polar positioning is activated if polar-distance
           properties are not auto and TLBR are auto.

  BradK: I've evolved my position on that based on the alignment spec.
  BradK: With alignment spec, you are using the TLBR to create a box
         that something can be centered in.
  BradK: So needing something to be non-auto doesn't really come in
         any more.
  BradK: Last email I wrote, detailed how it would work.
  BradK: If you start at top and work your way down, top part is
         least controversial.

  BradK: I think we agree that using position: absolute or
         position: fixed or position: relative would be good.
  BradK: Instead of having a separate polar positioning spec that's
         the same as absolute except that it pays attention to polar.
  BradK: The only really other thing different about polar
         positioning is that it centers things.
  BradK: If box alignment centers things, then we free up polar
         positioning to move things at an angle.
  BradK: You can decide to center something, move something at an
         angle, or not.
  Florian: So?
  BradK: Covers all the use cases.
  * fantasai thinks this makes sense, but isn't 100% clear because
             didn't catch up on this email thread.

  jihye: I think when we use polar positioning on some elements,
  jihye: We have to set origin point to define distance and angle.
  Florian: Question is do you do that automatically, or use
           alignment first and then?
  Florian: Should ?? be magic or manually?
  BradK: Manually with existing properties. Otherwise you have 2
         properties that by themselves that center.
  BradK: If you use position polar, same as using center alignment.
  BradK: If we have a way of centering, we have a way to make
         off-center with TLBR.
  BradK: We don't need a separate thing to make it center.
  BradK: To move it at an angle, you don't really need to have a
         concept of a center point or polar coordinates.
  BradK: You move the whole thing at that angle / distance.

  Florian: I'm a bit conflicted.
  Florian: On the one hand, I completely see how this works.
  Florian: On the other hand, the properties we have for doing the
  Florian: Are in a fairly different mental model than when we're
           doing in polar coordinates.
  Florian: I'm not sure it makes sense to author to mix these two.
  Florian: Alignment isn't something you think about when doing
           polar positioning.
  Florian: Not sure what I think.
  BradK: I think forcing person into different model is polar
         coordinates, very different from CSS coordinates in general.
  BradK: The effects are centering, and moving at an angle.
  BradK: Don't have to change the 0, 0 no longer top left left, now
         in the center.
  BradK: Don't have to think about that.
  BradK: Question is do I want centered or not?
  BradK: Independent thought of moving it at an angle.
  BradK: Cutting corner across a right angle.
  BradK: Could do same thing with TLBR properties.
  BradK: Don't have to change my mental model.
  BradK: Don't need to use left and top to move at a 45deg angle
         anymore, just use polar-angle and polar-distance.
  Florian: My assumption here is that even among the people who
           write CSS, more people have an intuitive understanding of
           polar coordinates that they learned in middle school than
           how CSS layout works.
  Florian: Not that people have advanced understanding of math, but
           that much they do.
  plinss: I think you're overestimating people.
  plinss: I think more people understand CSS than understand polar
  Florian: ...
  BradK: We went over this with radial gradients.
  BradK: 0deg is at top.
  BradK: Not changing the coordinate system,.
  BradK: Origin is still top left corner [?]

  fantasai: If I understand correctly, let's drop polar-origin and
            position things with alignment, then use that as your
            origin for moving with polar-distance.
  fantasai: I think there are use cases for that, and what happens
            if you want your origin to be something other than the
            center or the edge, that's really hard without the coords.
  fantasai: I think BradK has a great point though, and I think it's
            worth separating these things out.
  fantasai: I can see also how you would want to have a polar
  fantasai: You could make the initial value the polar origin be
            auto which would mean do your abspos layout like normal,
            and use the result as your origin.
  fantasai: If you then have polar origin set to a specific
            coordinate then that becomes where you start from.
  fantasai: You can then share polar-angle and polar-distance among
            all of the different layout models.
  fantasai: For relpos you would probably ignore the polar-origin
            property, but for fixed and abspos you would look at
  BradK: You would have two different ways for centering then.
  fantasai: I think there will always be many ways to center
            something though.
  fantasai: Centering in the future will be possible in many
            different ways which is ok.
  plinss: I like the proposal but I don't think it should just be
  <franremy> BradK Florian fantasai: Are there written examples of
             both proposals, to see which one is more compact? I
             fear the normal-css way might be too long to write, but
             I am not sure.

  BradK: After leaving alignment, I don't see the need for
         polar-origin, because you can just adjust the size of the
         box you're centering in [by using the offset properties].
  plinss: I like the idea fantasai is talking about
  plinss: But don't think it should be restricted to polar
  plinss: Why not change the origin in any other mode?
  fantasai: I don't understand, there is no origin in any other mode.
  fantasai: That's defined by the writing mode and the rectangle.
  fantasai: There's no numbers, so the align properties don't have
            lengths, cords etc - they're just keywords and you're
            working off of the rectangle.
  fantasai: It's not really an origin system.
  BradK: If you want center to be move dot the left, use the right
  plinss: Just because we don't have ability to set something.
  fantasai: I can you give a better example.

  plinss: I want to have a box where 1/3 of it is going to align on
          this point.
  plinss: Can't do that today.
  Florian: So you're asking for polar-origin + polar-anchor.
  Florian: So you say polar-anchor: 33%; polar-origin: <coordinate> ?
  plinss: I don't think we should restrict to polar positioning.
  Florian: I don't think I can agree or disagree so long as you're
           being this vague.

  BradK: That's what I was describing before in earlier emails.
  BradK: I did have the idea of polar origin, which I was calling
         'center', that could position things based on their center.
  BradK: You could' move this center with property, 'centerpoint' or
  BradK: Could position item based on any point in the item and any
         point in the containing block.
  BradK: Would get same effect of putting 1/3 of element to align
         with top center of CB, or whatever.

  Florian: General idea of what Brad and Peter are describing does
           sound reasonable to me.
  Florian: But not convinced until more concrete.
  Florian: Didn't like the concrete proposal of Brad earlier.
  Florian: Maybe a different proposal would be better.

  SteveZ: It's very similar to character alignment for images in
  SteveZ: In this case alignment to a baseline, but conceptually the
          same kind of idea.
  Florian: I think you're generalizing too much here :) But see
           where you're coming from.
  SteveZ: It's taking what an alignment point would mean in inline
          layout vs block layout.
  SteveZ: Still the same 1/3 in 2/3 down kind of point.
  Florian: I stand by my previous remark :)

  Rossen: What is the current favorite proposal?
  Florian: I think we have general agreement for making polar
           positioning work in absolute/relative/fixed.
  Florian: Don't have agreement on how to get to center.
  Florian: My favorite concrete proposal so far is fantasai's.
  Florian: But interested to see what Brad and plinss have to propose.

  jihye: I agree with generalizing polar origin.
  fantasai: I think, if we go with the proposal that I had, there is
            no new property. It could be renamed.
  BradK: Could be renamed. It's not necessarily polar.
  BradK: position-origin might be better.

  BradK: I was suggesting that this could even be a transform
  BradK: It doesn't even really need position, could just transform
         something with angle movement.
  BradK: Could stop having to change your mindset.
  BradK: Different than start point
  fantasai: You may want them to cascade separately.
  fantasai: If they have hover effects mixed in with layout, that
            makes it awkward for the author, transforms should just
            be a graphical thing on top.

  Florian: My proposal would be, 1. Resolve on what fantasai
           proposed earlier, with the understanding that we will
           explore generalizing it further.
  Florian: I think bradk and peter have some interesting ideas,
  Florian: But what fantasai proposed is a clear improvement over
           what we have so far,
  Florian: So I'd rather have that in the spec,
  Florian: and then improve from that.

  BradK: Do we have to call it polar-* ?
  Florian: I haven't seen an obviously better name proposal, so I
           think we should discuss that from a better starting
           point, from what fantasai proposed.
  Florian: This way reduce the problem space.
  Florian: And then make concrete steps from a concrete proposal.
  BradK: Sort of agreement on the list to have this be part of
         positioning anyway.
  Florian: Let's turn this into a concrete set of resolutions.
  Florian: I think what fantasai proposes is a clear step up from
           what we have so far, so let's take that step and then
           move forward from that.

  fantasai: To summarize:
  fantasai: Add the 'auto' values to polar origin
  fantasai: Apply the polar coordinates to all positioning schemes,
            not just 'static', and remove 'polar' value.
  fantasai: 'auto' on polar-origin, would the be the initial value
            and would have them do normal layout.
  fantasai: polar-distance initial value becomes 0, remove auto value.
  Florian: The definition of "how does polar origin work" in that
           model, if you are in anything but position bsolute/fixed,
           it does nothing
  Florian: If you are in position absolute/fixed, when polar-origin
           is non-auto, you do that instead of the traditional way
           of finding your position.
  Florian: I'm in favor of this proposal.

  BradK: What happens when you have align-self: center?
  Florian: If you're in abspos, self-align: center; justify-self:
           center; and polar-origin: auto
  Florian: Then you center through the alignment props
  Florian: If polar-origin is non-auto, you ignore align/justify
           self and instead do what polar-origin says to do.
  Florian: That's the model. And again, we can look into further
           generalizations, but the model currently described is this.

  jihye: When polar origin is not auto, what happens to the TBLR
  fantasai: We could ignore them, or we could use them to reduce the
            size of the box in which you're positioning in.
  BradK: Or could just pay attention to top and left.
  fantasai: no, no.
  fantasai: I don't like using only half of this set of 4 properties.

  Florian: So I propose we resolve on the proposal, and then mark an
           issue of what happens with top/bottom/left/right
  <fantasai> Proposed Resolution:
             1. Remove 'polar' value of 'position'. Polar
                positioning applies to absolute/fixed/static/sticky/
                relative positioned elements
             2. Remove 'auto' value of 'polar-distance'. Initial
                value is 0
             3. Add 'auto' value to 'polar-origin'. This means find
                the origin using normal rules for absolute/fixed/
                static/sticky/relative positioning.
             4. Make 'auto' initial value of 'polar-origin'
             5. Add an open issue as to whether top/right/bottom/
                left properties are ignored or interpreted somehow
                when 'polar-origin' is not 'auto'.

  Rossen: So current proposal is resolve on the proposed resolution
          above, points 1-5
  Rossen: Any objections?
  Bert: I'd like to propose a modification.
  Bert: I wonder if it isn't more intuitive to put the 'auto' on
        'polar-angle' instead of 'polar-origin'.
  fantasai: No, the auto value is on the origin because it allows
            all of the other layout modes to work.
  fantasai: *gives an example*
  fantasai: The distance and angle being auto doesn't make sense.
  fantasai: Once the origin is set by the default layout modes, then
            you can use distance and angle to position it.
  fantasai: In that case you can set it to center, or use the
            alignment props.
  fantasai: But you have to ask for it to be the center, but polar
            position will always work generically.
  fantasai: So the initial behavior has to be backwards compatible.
  fantasai: It's through a switch that makes the polar coordinate
            capabilities become possible.
  <BradK> Distance and angle can both be 0.
  Bert: I think I have a misunderstanding of what fantasai is
        proposing, I'll figure it out later.

  Rossen: Back to objections on proposed resolution?
  BradK: No objection.

  RESOLVED: Make the following changes:
            1. Remove 'polar' value of 'position'. Polar positioning
               applies to absolute/fixed/static/sticky/relative
               positioned elements
            2. Remove 'auto' value of 'polar-distance'. Initial
               value is 0
            3. Add 'auto' value to 'polar-origin'. This means find
               the origin using normal rules for absolute/fixed/
               static/sticky/relative positioning.
            4. Make 'auto' initial value of 'polar-origin'
            5. Add an open issue as to whether top/right/bottom/left
               properties are ignored or interpreted somehow when
               'polar-origin' is not 'auto'.
            NOTE: polar-origin doesn't apply to relpos. (Or mark an
                  issue for making it apply somehow).

Polar properties as CSS transforms function

  joone: I wanted to extend this idea to 3D transforms
  (Joone showing a presentation)
  joone: Here is proposal
         transform: polar(angle, distance)
         transform: polar-origin(percentage|length, oercentage|length)
         transform: polar-anchor(percentage|legnth, percentage|legnth)
  joone: No changes, just use existing properties as transform
  joone: If you use transform function.
  joone: We can move the element in the containing block like this.
  joone: If you use polar-origin
  joone: you can move the green block like this.
  joone: If you use polar-anchor can do this.
  joone: If you use polar anchor, use polar origin together.
  joone: Could extend this idea to 3D transforms.
  joone: Use polar3d function.
  * fantasai thinks joone is confused how the cascade works
  joone: 3 parameters are polar3d(r, theta, phi)
  joone: Place elements in 3d space like this.
  joone: Can also use polar-origin3d and polar-anchor3d functions.
  joone: polar-origin3d(r,theta,phi)
         polar-anchor3d(50%, 50%, alpha, beta)
  (joone's diagram has alpha and theta be the angles of the element
     with respect to the ray from the origin)
  joone: This is the initial idea. Might be some issues with this
  joone: 3D function and transform.
  joone: That's it!
  <dbaron> Is the idea that these are equivalent to translate/
           translate3d transforms?

  Florian: I would split my feedback on 2 aspects.
  Florian: One being transform and one being 3d.
  Florian: Earlier today fantasai explained why doing positioning
           with transforms cascades badly, want to do transforms on
  Florian: So because of that I don't think we should be doing this
           with transforms.

  Florian: Whether or not we can do in 3D can discuss separately
  Florian: For 3D side of things, I don't think there is any
           particular difficulty in understanding how the math works.
  Florian: But I want to see use cases before diving into it.
  Florian: This is solve-able, but wouldn't work on it without use
  Florian: 2D without transforms is what we resolved on previously.
  Florian: 3D maybe, but why?
  Florian: Would like more convincing use cases.
  Florian: Without that I think it's complication without

  dbaron: I guess I didn't even understand what the proposal was.
  dbaron: Are these translations? Are they translate + rotate?
  joone: Internally we use translate and rotate functions.
  joone: I want web developers to be able to just use polar
  dbaron: I looked at transform polar3d(r, theta, phi). What is that
  dbaron: Is it a translation? Is there some rotation, too?
  joone: No rotation, just move.
  dino: If it's a translation, why isn't it a translation?
  dbaron: I can understand wanting to express translate as polar
          coordinates, but if so, would want translate in the name.

  dino: Can you go back to the other slide?
  dino: Example in 2d.
  dino: The thing I don't understand, maybe it's because I haven't
        been listening well enough, but...
  dino: We start there, then next slide...
  dino: We've changed the positioning completely of the element.
  dino: There's this implied translate to the middle of its
        containing block.
  dino: Which is really confusing, because nothing else does that in
        a transform.
  dino: Polar angle and polar distance, initial value is located in
        the middle of containing block.
  dino: Sure, but no other transform needs to know what its
        containing block is.

  hober: What are the arguments to the function here that would be
         the identity transform?
  dino: What would you do if you wanted to keep something where it
  dino: I think I can see there's a use case for adding polar
        transform functions that simplifying the case of moving
        something a position rotating it, translating back out, etc.
  dino: But don't like that this function completely changes
        transforms completely.
  dino: If you do translate(0,0) nothing changes. If you do rotate(0)
        nothing changes.
  dino: But here polar(0,0) completely changes where the element is.

  Florian: This is a conversion into transforms from what the polar
           positioning model was before we made the resolution 15
           minutes ago.
  Florian: Polar positioning in the old model had a jump-to-center
  Florian: but we just changed that.
  dino: Transforms isn't the way to magically change the positioning
        of an element.
  <dbaron> I agree with dino.
  Florian: Without using transforms.
  Florian: What we just discussed dealt with that.
  <franremy> The point of having a conversion from polar to
             cartesian transforms is useful, if you want to animate
             smoothly, like an animation of a satellite around a 3d
  Florian: And as fantasai explained, not good to use transforms for
  Florian: For 3D polar positioning, we need use cases.

  fantasai: So here's the big issues...
  fantasai: 2 major confusions here:
  fantasai: One of them of which - you don't seem to know how the
            cascade works as you're overriding the transforms.
  fantasai: The second one is that, transforms are NOT a positioning
            system, it's about shifting relative positioning system.
  fantasai: That goes back to what Ted was saying, you need an
            identity transform - if you 0 out everything it needs to
            do nothing.
  fantasai: When you add 1 to that it starts to do something - but
            we need that identity transform.
  fantasai: We can add polar transforms which is basically syntactic
            sugar to other transforms.
  Florian: If we want to work with transforms, then it needs to work
           the way she just said.
  Florian: If we want 3D positioning, then I want to see use cases
  Florian: And these two things are separate.
  dino: Florian made 3 points
  dino: and fantasai described them better
  dino: The points were
  dino: 1. Transforms aren't a positioning system.
  dino: 2. It would be interesting to examine functions for doing
           polar-like transforms that are shorthands for polar
  dino: 3. and he wants use cases for what you want 3D polar
           coordinates for
  Florian: If we want to do transforms, as fantasai described, then
           we don't need major use cases because it's syntactic
  Florian: If we need a 3D positioning system, then we need to
           understand why are we working on this hard topic.

New type of pseudo-class to support scrolling in rounded viewports

  Rossen: Next is pseudo-class issue
  jihye: The latest smart phone from LG and Samsung use scrolling
         animation like this one.
  [jihye shows off an email subject line list, where the middle item
      of the 3 visible is larger and shifted left]
  jihye: There are several problems here.
  jihye: One is that if the list item sizes are the same as the
         containing block there is some overflow.
  jihye: If the list item size is same as inner circle of containing
         block, there can be unused spaces.
  jihye: So recent smart phones use scrolling like this.
  jihye: Dynamic scrolling and scaling of list items.

  jihye: To implement this kind of scrolling animations on the Web,
  jihye: This is implemented by JS.
  jihye: It takes a lot of calculation, like exact position of
         elements while scrolling,
  jihye: and doing some scrolling animations.
  jihye: So to solve this problem we suggest new pseudo-class.
  jihye: We suggest regional pseudo class to handle this problem.
  jihye: Can select an element in a specific area.
  jihye: When the new type of pseudo-class is :region(
  jihye: When element in the list matches with center point of
         containing block, you can select :region(center).
  jihye: When element matches with top edge of containing block then
         select the element.
  jihye: When you specify an element with region(center) that kind
         of element scaling bigger than the other elements then
         maybe you can deal with the dynamic scrolling I showed you
  jihye: But I think this not quite perfect solution for dynamic
  jihye: Because layout doesn't change when scrolling animations.
  jihye: This is just one idea for dynamic scrolling/aligning of

  jihye: What do you think about this idea? Do you have some other
         solution for scrolling in round display?
  astearns: Is Rick anywhere near?
  astearns: The Houdini scrolling stuff might help here.
  <dbaron> layout-dependent selectors seem unlikely to work
  Florian: I am extremely skeptical that a selector depending on
           layout and scrolling can work.
  Florian: Since you can do it in JS, doing it in Houdini-powered JS
           would make it faster.
  Florian: It would be nice to have a declarative way to say that,
           but I have no idea.
  Florian: Maybe Bert has an idea, he's good at that.

  Rossen: First comment, is that "region" in CSS and reusing name is
  Rossen: But as some experimental work with shape inside.
  Rossen: Also kind of suggests that, reinforcing Florian's point
          here, automatically scrolling mechanisms is quite
          difficult other than approximate rectangles.
  Rossen: When the shapes become more exotic this problem becomes
          not even solvable.
  Rossen: Especially if you have disjoint shapes.
  Rossen: Not to say we should stop thinking about this.
  Rossen: It is an issue.
  Rossen: If the script based solution works, that's already really
  Rossen: In Houdini we will try to make that more efficient...
  Florian: Houdini is important here, works on desktop, not so much
           on watch.
  astearns: I suggest taking this specific issue to the github
            issues on Houdini as a use case,
  astearns: And say that let's try to make our scrolling stuff help
            make this more efficient.

  Bert: Wrt :current/:past/:future pseudo elements.
  Bert: Can see what was coming and what's past.
  Bert: That's the first idea I had with this.
  Bert: Scrolling also has this. So maybe with pseudo-classes can do
  Bert: Just to remind people that we have something in Selectors 4
        that might fit this.
  <astearns> Perhaps it shouldn't be layout changes based on
             position within the round display, but transforms (
             scale as you get to the middle...)

  <hyojin> I modified that the revision of CSS Round Display as last

Robustness of CSS on non-rectangular displays

  Florian: So, next one is robustness of CSS on non-rectangular
  Florian: If you ignore bugs and stuff, if you take an unstyled
           document, or to which only the UA stylehseet has been
  Florian: We've never had a situation where doing this would result
           in invisible overflowing clipped content.
  Florian: With shaped displays, we do, because corners get clipped.
  Florian: Starting with invisible content from which the author has
           to work from is bad.
  Florian: The author cannot be expected to anticipate all the
           devices in the world,
  Florian: and make their page work in all of them.

  Florian: I think we should find a way to have the default
           situation for a web page to not clip and hide content on
           round displays.
  Florian: Should we apply shape-inside by default?
  Florian: But that's tough because we don't even know how
           shape-inside works precisely enough
  Florian: What I think he's suggesting is that by default the
           device manufacturer or provider of UA for that device
  Florian: Would make a viewport that does not cover the entire
           screen, but is either entirely contained or something
           that overflows it so little that you don't lose much.

  Rossen: So we already have the concept in most implementations of
          physical viewport and layout viewport.
  Rossen: What I'm hearing is that we should allow sizing of the
          layout viewport from the host level.
  Florian: ???
  Rossen: Currently layout and device viewport is completely
  Rossen: not target-able by content script style anything.
  Rossen: This would be the first requirement that allows
          programmatic access to the layout viewport.

  Florian: Recommendation would be, ask the UA to start with a
           layout viewport that is smaller than the screen,
  Florian: and sized smartly to not overflow at all or too much,
  Florian: and to give either through <meta> or @viewport, allow
           author to opt into the full screen.
  Florian: If you're asking for it, fair to let you deal with the

  Rossen: If a manufacturer of such a device is using a web view or
          any other way to host web platform,
  Rossen: How is what you're saying different from resizing overall
          host container.
  Florian: The difference is matter of initial setting, and allowing
           author to opt into the full viewport.
  Florian: I'm not strongly defending this solution, just presenting
  Florian: People should design for devices everywhere generally,
           and then tailor to specific devices.
  Florian: Impossible to do this for round displays if we just use
           the entire circle as the display for the page.

  fantasai: The key thing is being able to opt into the full display.
  Rossen: At the app level it's fine.
  Florian: I'm not concerned about app level, for content targeted
           to the watch. I'm thinking about content not targeted at
           anything in particular that needs to work.
  Rossen: So you have a round display, and by default you don't want
          to clip.

  Rossen: As Brad says, putting a square peg in a round hole
  Rossen: At some point you want the user...
  Florian: Opt-in is for the author, not user.
  Florian: If you display any web page not authored for a watch,
           should display just fine on the watch.
  Rossen: Agree with the general statement.
  Rossen: Don't understand the solution.
  Florian: If the author does nothing, the UA should provide a
           layout viewport smaller than the screen.
  Florian: There is no clipping.
  Florian: If the author is ready to deal with shaped screen,
  Florian: Can ask for viewport that covers the entire screen,
  Florian: and be prepared to deal with the clipping.

  Rossen: As long as its the on/off switch, it's palatable at least
          to me.
  Rossen: I'd be more reserved if we go the next stop, which and
          through this media feature do a whole bunch of things to
          viewport sizing.
  Florian: Don't want to do shaping of viewport with this.
  Florian: Just opt in/out of the viewport fitting in the circle.
  Florian: Would like to tag this into the Device Adaptation spec.

  plinss: Why aren't we doing shape-inside by default?
  Florian: Well, we don't exactly know what that does.
  Florian: Also if you have less content than the screen, fine. What
           if you have more content than the screen?
  fantasai: We don't have a solution for that.
  Florian: In 15 years maybe, you can do that, but need a solution
           for now.

  Bert: About the smaller viewport, could be maybe a little bit
        bigger have margins on the scrolable area.
  Florian: I don't think we have to be overly strict, can let device
           manufacturer be smart about that.
  Rossen: Not necessarily a new problem, at least in Windows Table
          mode, number of reasons why you'd want to constrain the
          viewport of the browsers for different UIs and impinging
          elements that are either part of the browser chrome or
          extension of it.
  Rossen: This is just the same problem.
  Rossen: Impinging items are part of actual display.
  Rossen: @viewport works just fine.

  Rossen: Anything else on this?
  Florian: If we agree that's the way forward, someone needs to take
           an action to figure out concrete syntax for this and put
           in either round display or device adaptation spec.
  Rossen: Start with round display and move to device adaptation?
  Florian: With regards to time constraints on my side, would rather
           we actioned LG to write it, and I'm happy to review.

  ACTION: hyojin add @viewport switch for opting into full round
          display size as viewport
  <trackbot> Created ACTION-751


  [discussing new WD publication now]

  RESOLVED: Publish new WD of Round Display, with polar positioning
            resolution incorporated (@viewport for next publication


  Florian: If you remember in Sapporo we revisited the media query
           and sort of concluded on a proposed MQ that no longer
           measures roundness of corners,
  Florian: but instead queries whether a certain box sized and
           position in a certain way would be in the visible area of
           the screen or not.
  Florian: I don't think the spec has evolved since then.
  <hyojin> The summary about it written by David Baron:
  Florian: I think the spec still has what we had before that.
  Florian: I think we need to revisit that entire discussion,
           because there are two things that you want to query.
  Florian: If you're wondering if something will be visible or not,
           that's a good answer.
  Florian: But there's a qualitative question as well.
  Florian: There's also, am I on a round screen? In that case maybe
           I want round buttons and a round layout etc.
  Florian: But if I'm on a square display, maybe want more
           rectangular look and feel.
  Florian: So the question is, do we need to revisit conclusion in
  Florian: Or do we need two media queries, one for whether area is
           visible, and whether the shape is roundish or squarish?

  Rossen: Wrt resolution from Sapporo, what happened?
  hyojin: corner-radius query to check that, also is-visible MQ is
          strong, but seems very complex.
  hyojin: LG prefers a simpler solution.
  hyojin: In consideration of extensibility, we should make this
          media query extensible.
  hyojin: I would prefer to keep current media query.
  hyojin: and rename to corner-radius.
  hyojin: Address others in next level.
  Florian: I'm sympathetic, but skeptical.
  Florian: It doesn't really answer questions for ...
  Florian: We have a syntax but don't have a clear idea what it means.
  Florian: We discussed and came up with is-visible.
  Florian: But that doesn't answer whether it's round or not.
  Florian: I'm okay to have "am I round" query in L1 and is-visible
           in L2.
  [missed last few sentences]

  Rossen: You can check is-visible with IntersectionObservers
  Rossen: If you have an element and know if it's within the bounds
          of a scroller.
  Rossen: Similar to a mutation observer.
  Rossen: If the thing you're observing intersects a scrolling
          viewport, we can ...
  dbaron: I'm a little worried about the IntersectionObserver analogy.
  dbaron: I don't think it deals with partially-visible in the way
          you want.
  dbaron: For the use cases of intersection observer, partially
          visible is often okay and you want to be notified that
          you're visible.
  dbaron: But these use cases you care if you're completely visible.
  dbaron: But need to check before concluding that intersection
          observer is the right thing.

  Florian: That leaves us the question of how do we make query of
           "am I round"
  Florian: I don't think corner-radius is the right MQ.
  fantasai: But what does round mean?
  fantasai: For answering the qualitative question of screen
            round/square is a device MQ possibly.
  fantasai: It doesn't answer the question of if my corners are
  fantasai: You can have a watch that has a rounded corners but it's
            still a square, so you want to know that it's round but
            it's not a circle.
  fantasai: Having just "am I round" is not enough.
  <franremy> +1

  Rossen: What about the negation of that?
  Rossen: Am I rectangular?
  fantasai: We did discuss a JS API that gives you a path that
            allows you to do what you need.
  fantasai: Can build whatever logic you need on top of that.
  zcorpan: Last time we discussed, a screen shape that's almost
           rectangular with corners a bit cut off, should probably
           be considered rectangular.
  fantasai: What if that cuts off the "close" button, which is
            usually in the upper right corner? Need to know that
            the corner is clipped.
  Florian: Maybe a non-boolean query.
  Florian: But if we had a 'device-shape' MQ that has 'curved' and
  Florian: Let the device manufacturer opt in to roundish or
           squarish designs.

  <BradK> Why not just allow overscrolling the round viewport to see
          things that would get clipped by default?
  <fantasai> BradK, I think that's an excellent solution to the
             previous issue; and I think that's in fact what some of
             the watches do.

  Rossen: Remind me the use case?
  Florian: If you look at the UIs for such watches,
  Florian: They look round,
  Florian: Not just to avoid corners,
  Florian: But everything's round, let's be round, round buttons etc.
  Florian: But we can't make an MQ that only answers yes when
           perfect circle.

  <tantek> I'd like to see photos/screenshots to such "UIs for such
  <fantasai> ask jihye to show you
  <tantek> like if you have these readily available and have seen
           them, please upload/email to www-style
  <tantek> so we can refer to them
  <jihye> http://anawhj.github.io/jRound/demo/weather/index.html
  <tantek> even better, perhaps we need a "watch-ui-examples" page
           on the wiki

  joone: I implemented device radius on Android.
  joone: Only one API that returns this information,
  joone: I think we need first talk to the platform team,
  joone: in MS or Apple or Google.
  joone: Making the API to return the device shape.
  joone: Before can make the media query API.
  Florian: The Android API returns "am I a circle or not."
  Rossen: Which works perfectly for... circles.

  hyojin: We're also positive to specify just rectangle and round as
          the values, but I don't know how to define the media
          feature syntax in Media Queries.
  Florian: Something like @media (shape: rectanglish|circlish)
  Florian: I'm not very excited about this, but don't have a better
  Rossen: I think we have two proposals.
  Rossen: One is a binary switch.
  Rossen: Tells you whether or not rectangular.
  Rossen: Other one is actually get a shape.
  <heycam> An alternative might be for the author to declare the
           unsafe area around the page, and then the device can know
           whether any important content would be clipped out. This
           could be useful for the "square display with rounded
           corners" case.
  <joone> Here is the code for getting display shape information
          from Android Wear:

  fantasai: I think there's three things that would be useful.
  fantasai: 1. Have a JS API that provides the screen shape.
  fantasai: That will allow you to build any logic for any MQ you
  fantasai: The two things that can work together are corner radius
            and corner shape, the radius would tell you the smallest
            number the cutoff and the shape would say the shape,
            square, round or weird.
  Rossen: Seem to have nothing approaching consensus.
  SteveZ: We need a solution for people to do something different
          for the round case.

  Florian: Authors are interested in "am I round".
  Florian: OS can answer am I a circle.
  Florian: So this is implementable and useful.
  Florian: We need to make the definition fuzzy enough.
  Florian: That when egg-shaped screens start existing.
  Florian: and OSes can be asked about it.
  Florian: An egg-shaped screen can describe themselves as round.
  Florian: But this is implementable, usable, pragmatic, overly
           simplistic, but not a terrible starting point.
  Florian: Device manufacturers that ship non-circular devices can
           adjust their Android...

  Rossen: Still no conclusion.
  SteveZ: Agree. Need an action to write up a proposal
  ACTION Florian: make proposal for round display media query
  <trackbot> Created ACTION-752
Received on Wednesday, 23 March 2016 21:32:34 UTC

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