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

[CSSWG] Minutes Sapporo F2F 2015-10-27 Part I: Polar Coordinates/Issues and Round Display [css-round-display]

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 23 Nov 2015 20:15:20 -0500
Message-ID: <CADhPm3uhryCoL2G1i71FhtkFUo0HHcsbN+4SnRqzqkggYQ_rog@mail.gmail.com>
To: www-style@w3.org
Polar Coordinates/Issues and Round Display
------------------------------------------

  - RESOLVED: Add polar-origin, independent property from
              transform-origin, issue open on whether it is
              referenced off the item or the containing block.
  - Discussed 'polar-anchor: auto' vs having a "100% doesn't cause
      overflow" keyword on 'polar-distance' percentage values;
      so far the idea is to drop 'auto' from 'polar-anchor' and
      define the new 'polar-distance' keyword (probably as 'contain');
      however there was recognized some difficulty in defining how
      exactly that might work in more complex geometrical areas.
  - RESOLVED: Drop polar-orientation, add values corresponding to
              the two keyword values as additions to rotation()
              function. Bikeshed names on ML; nice to align with
              SVG, but also need to not be too vague.
      - This may be revisited since there were concerns about
          changing transforms to suit this case.
  - There was a lot of disagreement in the room as to how
      device-radius should work. The crux of the argument was how to
      handle items that aren't perfectly round.
      - Conversation continued during the break, summarized here
          https://lists.w3.org/Archives/Public/www-style/2015Oct/0220.html ,
          including a potential solution using media queries.
      - Once the meeting reconvened, the group explored using either
          points or bounding boxes to test for visibility to achieve
          the desired effects.
      - This developed into a proposal for an "in display" media
          query that takes rectangle (cartesian) or polar points to
          allow for handling rectangular cases better.
      - Hyojin felt the last idea was worth writing up language for,
          which he'll start and ask for help if he needs it.
          - SteveZ had an ancillary idea of using device-radius-x/
              device-radius-y, where the radii are from the center
              of the device to the edge of the smallest ellipse that
              covers the screen. This approach is also worth
              exploring further since it seems to cover most simple
              cases.
      - It was also pointed out that viewport should be used instead
          of device for these cases.

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

Agenda: https://wiki.csswg.org/planning/tpac-2015#agenda

Present:
  Rossen Atanassov
  Tab Atkins
  Takao Baba
  David Baron
  Brian Birtles
  Bert Bos
  Tantek Çelik
  Junichi Chiba
  Dave Cramer
  John Daggett
  Daniel Glazman
  Dongwoo Joshua Im
  Koji Ishii
  Dean Jackson
  Brian Kardell (WebEx)
  Peter Linss
  Myles Maxfield
  Shinyu Murakami
  Simon Pieters
  Xidorn Quan
  Liam Quin
  Matt Rakow
  Florian Rivoal
  Andrey Rybka
  Hiroshi Sakakibara
  Simon Sapin
  Hyojin Song
  Alan Stearns
  Shane Stephens
  Johannes Wilm

Regrets:
  Adenilson Cavalcanti
  Dael Jackson

Scribe: Dino

Polar Coordinates/Issues and Round Display
==========================================

Polar-Origin Property
---------------------

  <jihye> http://www.w3.org/TR/css-round-display-1/
  hyojin: Two issues. First polar issues.
  hyojin: There's a proposed polar-origin property
  hyojin: The anchor point in CSS is typically top left, where as in
          polar it is center/center.
  hyojin: e.g. when you scale an element, it should resize from the
          center in all directions.

  Rossen: Is there a document we can look at?
  hyojin: No. just a proposal.
  Florian: We already have the existing transform-origin properties.
           If we can re-use that property rather than create a new
           one, it would be better.
  zcorpan: Is there a use case for using different origins for
           transform and polar if you're using both at the same
           time??

  Florian: Having a new polar-origin property that affects both
           polar-origin and transform-origin seems weird. Reusing
           transform-origin for both would be better.
  fantasai: Or keeping them completely separate.
  Florian: Yes.

  hyojin: I have a demo that I can maybe show.
  <Sangjo> https://www.dropbox.com/sh/zbdvmix6505fquo/AADaG2-U42PZWYOw0Btad7t0a?dl=0
  dino: The origin is center in transform origin.

Scribe: fantasai

  Rossen: So, going back to the question & proposal -- feedback from
          the room?
  Rossen: With regards to having separate origin for polar
          coordinates and transform-origin?
  MaRakow: transform-origin only applies to transformable elements,
           but seems like polar-origin might also apply to inlines?
  fantasai: Positioned elements become blockified.
  dbaron: That would be easy to fix in any case.
  dbaron: So, is polar-origin that you want something that controls
          the positioning of the elements relative to the thing
          they're positioned in?
  dbaron: We had discussions about rotation of the polar-positioned
          elements, but this is about positioning of polar elements
          rather than rotation?
  hyojin: Just positioning elements.
  hyojin: You could use ...
  hyojin: When we want to animate, we should refer to the transform
          origin.
  hyojin: I should think more about this topic, it's very brief idea
          for now.

  dbaron: One other question is, the idea is you use the
          polar-origin property of the parent when you're
          positioning the polar items, or using their own polar-
          origin property, relative to size of the parent.
  hyojin: Relative to containing blocks... polar-origin would be if
          I usually center center, if some author could put a point
          in coordinate...
  [zcorpan requests the whiteboard to come into play]
  dbaron: polar-anchor is position in child, and polar-origin is
          position in the parent?
  TabAtkins: Yes, both defaulting to appropriate center.

  [hyojin draws diagrams:
    polar-origin diagram shows circle with dot in the middle, square
        along outside edge
    polar-anchor shows dot inside the square [positioned element]
  ]

  dbaron: That answers my first question.
  dbaron: Second question is, if you have two elements here,
  dbaron: containing block element, and positioned element,
  dbaron: when you're positioning the child, are you referencing the
          'polar-origin' value of the child or of the containing
          block?
  hyojin: I think the containing block.
  dbaron: Might be reasons to consider other things.

  Florian: Are there use cases for non-centered coordinates?
  TabAtkins: Totally. For example, positioning around an arc,
  TabAtkins: that surrounds one corner of the box.
  Florian: But then where do you position if your angle is pointing
           out?
  TabAtkins: Then you overflow.

  dbaron: Percentage values of polar distance are an interesting case.
  dbaron: They're relative from center to edge of containing block.
  TabAtkins: You'd clamp it to zero, then.
  dbaron: polar-distance needs to be clearer about what happens when
          the origin is not the center.

  ACTION hyojin: Clarify polar-distance percentages when origin is
         not the center
  <trackbot> Created ACTION-731

  Florian: We discussed, and maybe this is the next topic, having a
           flag value to polar distance where 100% puts anchor at
           the edge vs. 100% puts the element at the edge without
           overflow.
  fantasai: Wasn't that what the auto value of polar anchor was for?
  Florian: It would be somewhat unintuitive in this case if your
           origin is at the corner, since you would position
           yourself natively...
  TabAtkins: Yes, totally logical.

  Rossen: First question is, should this be separate from
          transform-origin.
  fantasai: I think so, because transform-origin would be used for
            rollover effects and other animations of the item in its
            positioned place.
  TabAtkins: I agree with fantasai.

  RESOLVED: Add polar-origin, independent property from
            transform-origin, issue open on whether it is referenced
            off the item or the containing block.

Polar-anchor
------------

  <hyojin> https://lists.w3.org/Archives/Public/www-style/2015Sep/0234.html
  <hyojin> https://lists.w3.org/Archives/Public/www-style/2015Oct/0087.html
  hyojin: Next is polar-anchor.
  hyojin: Current proposal is to prevent overflow on the display
          with 'auto', but alternative is modifying polar-distance
          with a special value.
  hyojin: I'm wondering whether polar-anchor is still necessary.
  hyojin: Two issues open here.

  <Florian> "polar-distance: 100%" vs "polar-distance: 100%
            no-overflow"
  <fantasai>   Florian, I'd suggest s/no-overflow/contain/ :)

  dbaron: polar-anchor still seems likely to be useful, even just to
          set two anchor points.
  astearns: That seems reasonable, but I'd like a stronger use case
            than preventing overflow here.
  [Florian explains how the 'auto' value works on polar-anchor -- it
      automatically chooses the anchor based on the polar angle]
  Florian: The problem with this is that it can shift you in weird
           ways .
  Florian: polar-anchor:auto, at least as it has been described so
           far, moves the anchor around the edge of the positioned
           element. While doing this does allow controlling how far
           out the element goes, it also shifts the element
           laterally, since the anchor point is no longer at or
           aligned with the center. There are other ways to possibly
           define polar-anchor:auto, but that's what we've had on
           the table so far I believe.
  Florian: The no-overflow keyword does not have this problem.
  Florian: This does not answer the question of whether polar-angle
           without 'auto' is also useful.
  hyojin: polar-origin is in the containing block
  hyojin: polar-anchor is in the target element
  hyojin: I think there should be two points, define each.
  Florian: The model makes sense to me. The argument from astearns
           is whether this is needed.

  Rossen: You will always have two points.
  Rossen: The question is whether you can change on or the other
          from the default that we choose.
  fantasai: I can think of maybe the thing you're positioning is a
            box with contents that are not even, e.g. an icon and a
            label. You want to position the center of the icon, not
            including the label.
  [dbaron draws a case on the board: a circle with a long rectangle
      just above the center, and a small box just under the center]
  dbaron: If you don't know the sizes of these items, you want to
          position them so that they don't overlap, need to choose
          the bottom point on the top time and the top point on the
          bottom point. Center won't work.
  <astearns> I'm convinced by the two use-cases above that setting
             polar-anchor could be useful.

  Florian: We seem to be agreeing that 'auto' is not needed on
           polar-anchor, and a no-overflow value on polar-distance
           would be better.
  Florian: We agree on what it does, but how it works is tricky.
  Florian: In particular, if we only want to make it work with
           rounded corners, but if we want to take into account
           shape-outside on the positioned element and shape-inside
           on the containing block, this gets tricky.
  Florian: A human can do it, but algorithm much harder.
  Florian: If your containing block is a star...
  Florian: Or arbitrary shapes, how do you deal with that? Do we
           even try?
  Florian: In regards to a watch face, it's rounded but neither
           circular nor elliptical, it's pretty common.
  Florian: Traditional watch design has such curves.
  Florian: We probably want a no-overflow property should work with
           these as well.

  Florian: Do we need to go further and work with non-convex shapes?
  TabAtkins: If you design a non-convex screen and expect it to do
             anything useful?
  Bert: I want to design a jigsaw puzzle! :D
  Florian: We need to try to write out definition and see.
  TabAtkins: I'm not convinced we need to worry about this.

  fantasai: I would change name of 'no-overflow' to 'contain'.
  Florian: Sure
  Rossen: Okay?

  hyojin: We will gather use cases for polar-anchor.
  hyojin: What is the best option of defining polar-distance's
          second value?
  hyojin: Previous idea as polar-center or outer or inner?
  fantasai: I would call it 'contain', like radial gradients.
  Florian: polar-distance: <distance>; or polar-distance: <distance>
           contain;

  ACTION hyojin: work on polar-distance: contain; keyword proposal
  <trackbot> Created ACTION-732

polar-orientation
-----------------

  <jihye> http://www.w3.org/TR/2011/WD-css3-images-20110908/#radial-gradients
  <hyojin> polar-orientation:
https://lists.w3.org/Archives/Public/www-style/2015Oct/0199.html
  <jihye> https://lists.w3.org/Archives/Public/www-style/2015Oct/0177.html
  <hyojin> polar orientation sample app:
http://anawhj.github.io/jRound/demo/polar/rotate.html

  hyojin: polar-orientation is to distinguish between center and
          counter-center
  hyojin: Proposal was to replace with rotate/transform,
  hyojin: But I think it's useful to have center and counter-center.

  Florian: I think the behavior we want, to turn and rotate
           positioned elements as a function of its polar angle,
           that makes sense.
  Florian: But we raised two issues on the last time we talked about
           this, one is does it need to be a special property or is
           this a special keyword on rotate()?
  Florian: Or maybe it should be separate because polar-origin.
  fantasai: I don't think it should be separate. You can have
            separate keywords if you want to, but there's no reason
            to have a separate property that I can tell at the moment.

  fantasai: For example, we could have transform: rotate(polar-center);
  fantasai: And if you want the same thing for transforms later
            (because I don't think this is important), then you can
            have transform: rotate(transform-center);
  fantasai: Is there any reason why this wouldn't work?
  Florian: If you do transform: rotate(polar-center); it rotates
           around which origin?
  Florian: What if the polar-anchor and transform-origin are not the
           same?
  fantasai: Is that what you really want? I'm not convinced.

  Florian: Second thing we raised during telecon is based on the
           example.
  Florian: The example didn't use polar-center all around the watch
           face. On the bottom half it used counter-center, and
           center on the top half.
  Florian: Having to choose between these seems a little bit
           problematic, since the goal of these values is to be
           automatic.
  Florian: If you need to adjust based on the angle anyway, might as
           well just do the math.
  fantasai: So you're suggesting there should be a third auto-center
            value.
  Florian: I think we should rethink the set of values.
  Florian: Do you ever want counter-center if you're positioned at
           the top?
  Florian: Lets have values for the use cases.

  <astearns> https://drafts.fxtf.org/motion-1/#motion-rotation
  Bert: The motion-path property has the same three values.
  Bert: It has center, called auto.
  Bert: Also has reverse,
  Bert: And also has angle, which you can use for 0deg.
  Bert: That corresponds exactly to the polar-orientation property,
        though different naming.
  Bert: Seem to need these three values.
  fantasai: We should keep the names consistent...
  fantasai: Though I'm not sure in which direction :)
  * birtles notes that naming is based on SVG which uses auto,
            auto-reverse, or <number>:
            http://www.w3.org/TR/SVG/animate.html#RotateAttribute

  Rossen: So what's next?
  Florian: I would like to hear from rest of WG what they think of
           the auto-center keyword idea.
  Florian: If we look at use cases and see the values, I'm pretty
           sure these two will be part of it. If anything else is
           needed, we could also add later.

  <Sangjo> http://anawhj.github.io/jRound/demo/facebook/circle.html
  [hyojin projects example]
  <hyojin> CSS Round Display Demo: http://anawhj.github.io/jRound/demo/

  Bert: If you used no-overflow, it would not work nicely like this.
  Florian: I'm okay with deferring a request for new values until
           later.
  Rossen: Yours sounds like a superset, so can always add more.

  RESOLVED: Drop polar-orientation, add values corresponding to the
            two keyword values as additions to rotation() function.
            Bikeshed names on ML; nice to align with SVG, but also
            need to not be too vague.

  * glazou would like to congratulate LG for their very effective
           and process-respectful participation into the CSS WG;
           sincerely.
  * fantasai agrees with that

device-radius
-------------

  hyojin: Next topic is device-radius:
  <hyojin> device-radius regarding percentages issue:
           https://lists.w3.org/Archives/Public/www-style/2015Oct/0193.html
  hyojin: Florian and Tab were discussing this topic, it was a
          little bit difficult.
  Florian: I didn't explain well, and you didn't understand what I
           meant wrt inequalities...
  TabAtkins: I will object to anything where lengths and percentages
             are not comparable,
  TabAtkins: and to anything where inequalities are not defined
             among these.
  Florian: In my proposal, length and percentage are comparable per
           axis.
  Florian: Wrt inequalities, you're not necessarily in an ordered
           space. A zigzag corner is not more, less, or equally
           rounded to a corner.
  TabAtkins: Which is why I would object to it. Must be ordered.
             Must define inequality.
  Florian: Some things don't match inequality or non-inequality is
           okay.
  TabAtkins: No it's not.

  [Florian draws a circle within a square (square is 200px wide)]
  Florian: I don't think anyone disagrees that this matches
           device-radius: 100px and also device-radius: 50%
  Florian: What if it's elliptical?
  Florian: Tab says you must evaluate always against a single axis,
           either width or height.
  Florian: But in this example (200px x 400px rectangle, portrait)
  Florian: I think this should not match device-radius: 100px or
           device-radius: 200px, because these would match a circle,
           and this is not a circle.
  Florian: But it would match device-radius: 50%;
  Florian: So no non-circular ellipse would ever match a length.
  Florian: But you can still do calc math meaningfully.
  [Florian adjusts the curve so that there's a 10px length of
      straight edge on each side (less than 50% curve)]
  Florian: This shape would match device-radius: calc(50%-5px)
  Florian: Mixing percentage and length works. Separately per axis,
           but they work.
  <jchiba> https://www.dropbox.com/s/8dj6ao4rurp5hdq/round-display-oval.jpg?dl=0
  <jchiba> https://www.dropbox.com/s/t3pkq6syhvhzr9g/round-display-oval-weird-corners.jpg?dl=0

  dbaron: So device-radius is rounding of the entire screen,
          regardless of its size?
  Florian: Yes.
  dbaron: Sounds more like device-corner-radius.
  <glazou> +1 to what dbaron said
  TabAtkins: Yes.
  Florian: If you have one corner 10px and another corner 50px, then
           it wouldn't match device-radius: 10px anyway.
  Florian: Any screen shape.
  [Florian draws weird corners]
  Florian: Any screen shape that does not cross this line
           (designated by device-radius) matches max-device-radius:
           50%

  TabAtkins: I don't want to do this.
  TabAtkins: It breaks inequality algebra,
  TabAtkins: and there isn't a use case.
  TabAtkins: I think we will need to support either round or beveled
             corners.
  TabAtkins: Figuring out rounded-corner-ish thing it would be in an
             ideal world.
  TabAtkins: Just do an equality based on that that does normal math.
  Florian: I don't expect us to handle weird shapes, but the way
           you're saying this works then it's very confusing.
  Florian: If you have one corner that's rounded, then it doesn't
           match 10px and doesn't match 0px.
  dbaron: I think the case we'll run into those, but might run into
          non-elliptical rounded screens.
  Florian: Egg shape is reasonable.
  Florian: leaf-shaped one is reasonable (top right and bottom left
           corners rounded, other two sharp)
  TabAtkins: leaf-shaped one is impossible to design for anyway.
  Florian: What query would match that?
  TabAtkins: device-radius: 100%
  <jchiba> https://www.dropbox.com/s/gkyix2nx0on1uqp/round-display-variation.jpg?dl=0
  <jchiba> * Free-form display (2):
http://image.itmedia.co.jp/l/im/news/articles/1406/18/l_yuo_sharp.jpg

  Rossen: What are we changing based on this query anyway?
  TabAtkins: Basically, it's how much do we avoid corners.
  Rossen: Can we just do three keywords?
  fantasai: No, I don't think so, because you want to know how much
            corner you have. It's a scale, so it should be a number,
            Different designs will have different thresholds they
            care about.
  fantasai: I really don't think keywords will cut it. It should be
            a number.
  fantasai: It can be a conservative number, so that you get the
            answer that represents the largest space that's
            definitely on the screen.

  Florian: There are two issues here -- one is curves that are not
           quite elliptical.
  Florian: Another is if different corners are different.
  Florian: Example --
  Florian: If corners are slightly rounded, I might be okay in my
           design. But as it gets bigger, we might get to a point
           where I need to re-evaluate my design.
  Florian: You can evaluate a perfect ellipse, you can use that as a
           judge: if my design fits in that ellipse, I'm okay.
  Florian: If it doesn't, then I need to change my design.
  Florian: For different-shaped corners, well maybe we need four
           media queries. But the single one should give the most
           conservative answer.
  Florian: That's how I would use my media query, as I explained it.

  TabAtkins: There's a point at which we'll need to just return a
             path via JS.
  [something about keywords?]
  TabAtkins: e.g. luminosity, we didn't expose lumens.
  fantasai: That's totally different. the threshold you care about
            depends a *lot* on the design, whereas for lumens you
            only need a few thresholds to choose high-contrast or
            nighttime theme.

  glazou: I think in the CSSWG we have tried many times to restrict
          ourselves to something too simple, and then later we find
          we need to handle the more complicated cases. let's not
          reject anything as totally forever out-of-scope.
  [Tab argues that three keywords for square, round, and kinda round
      is sufficient for all uses]
  [Florian argues that his proposal is perfectly simple for authors
      to use]
  [Both of them argue back and forth.]
  <glazou> I also think we should not reject, and do this as simple
           in L1 and expandable to a future L2
  [Tab gets upset that his points aren't minuted]
  <TabAtkins> TabAtkins: All of this is too complicated. Very
              unlikely that an author can reasonably work with "I
              need to do something if the screen is more than 5%
              rounded", esp since shapes can't *accurately* be
              boiled down to an ellipse anyway.
  <TabAtkins> TabAtkins: We have 3 semantic layout categories, I
              think: square (normal), round (use polar), and rounded-
              rectangle (avoid the corners).
  <TabAtkins> TabAtkins: And we can expose the full shape via a JS
              API so you can do smart/complicated things if you care
              that much (which is reasonable).

  zcorpan: What I wanted to say, a way to get a number is to use the
           radius of the biggest corner.
  zcorpan: And if it's oval shaped, you use the line that goes from
           the center to the edge.
  Rossen: So this is still in favor of numbers, not keywords.
  zcorpan: Yes, using a number.
  Florian: Question about this. If you say biggest corner, don't you
           want to switch biggest vs. smallest depending on whether
           you're checking greater-than or lesser-than?
  * glazou agrees with Florian
  zcorpan: The point of this media query is being able to tell how
           close to the corner you can put stuff
  zcorpan: Whether you use smaller than or greater than, I don't see
           why you would want to smallest corner.
  zcorpan: If you use the smallest corner, then you will put stuff
           that is hidden in the bigger corner. You should always
           use the biggest corner.
  Rossen: It might not be at the edge.
  zcorpan: It will still be visible.
  zcorpan: If you want more accuracy then use the JS API.

  fantasai: It's important imo that greater-than and less-than
            operate on the same numbers, because authors should be
            able to say @media (device-radius > A) { ... } and
            @media (device-radius < A) {... } and catch all cases.
  Florian: I partly disagree with this.
  Florian: I agree that they should work on the same thing, but I
           think there are also screen shapes that will be neither
           less nor equal nor greater than this.
  Florian: Star-shaped screen [...]

  <dbaron> I think MQ4 does make Florian's concept more practical
           than it was in MQ3 syntax, but it would still be a common
           author pitfall.
  <dbaron> I wonder if it would be worth trying to use the time more
           effectively to understand each other even at the cost of
           not having every sentence minuted?

  zcorpan: For a corner that is not a circle or an ellipse, you
           pretend that it is a circle or ellipse, and you use the
           distance from the center to the edge.
  Florian: If a rounded circularly 30px corner would do this ...?
  Florian: Then any shape that starts here and ends at the same
           point would match?
  zcorpan: No.
  zcorpan: What shape are you interested in?
  zcorpan: Takes the smallest distance.
  zcorpan: Nothing will be hidden, that's fine.
  [Florian draws an inverse curve]
  zcorpan: I suppose you use an ellipse or a circle that fits inside.
  zcorpan: So if you want a star shape, or whatever,
  zcorpan: you use the circle that fits inside.
  Florian: I believe your definition and mine are identical.
  Florian: You compare the the shape of the screen, find the largest
           ellipse that would fit within it, and use that.
  Florian: ...
  fantasai: I think it's a reasonable model for comparison, but the
            information you've given the author in the star case
  fantasai: is that you have a 200px wide screen with a 25px rounded
            corners, not a 25px radius circle.

  Florian: This definition makes sense for [...]
  Florian: ...
  Florian: The arbitrary shapes bit isn't the point, it's just what
           falls out.

  <jchiba> https://www.dropbox.com/s/gnt82gfn3mq5vd2/round-display-variation-radius.jpg?dl=0
  [Rossen takes a point of order.]

  <br end=10:59>

  [During the break, conversation continued between Shane, Florian,
      Tab, David Baron, and Simon Pieters. David wrote a summary of
      this conversation available here:
      https://lists.w3.org/Archives/Public/www-style/2015Oct/0220.html]

Scribe: dauwhe

  Rossen: Going back to the discussion.
  SimonSapin: (shows complex shape on screen)
  <jchiba> https://www.dropbox.com/s/dce7ho80zrqh5ur/round-display-variation-added-in-break.jpg?dl=0
  SimonSapin: In this Nintendo case, content is designed for this
              device.
  SimonSapin: Does this device has brother that shows arbitrary
              content.
  Florian: It's a Nintendo device, these things have brothers.
  glazou: Everything is provided by 3rd parties,
  SimonSapin: Does 3rd party software expect to show content on
              parts of the screen.
  <glazou> Usually 3rd party providers don't control the device
           characteristics.

  Rossen: Is the question should we handle this type of display?
  SimonSapin: How much are random websites expected to adapt to
              arbitrary screens?
  Rossen: As much as authors care.
  plinss: This is a job for shapes and exclusions.
  <skk> I think, in future, the web tech should deal with such
        device. Dealing with such will broaden the use of web. But
        currently, it takes too much time, and technically, we think
        about lots of things. So another place might be better to
        discuss this topic.

  shane: We had a discussion during break.
  MaRakow: There should be clear instruction in script that shape is
           complex, that you'll need more than CSS.
  glazou: Thinking out loud...
  glazou: Having an SVG shape in the doc tree and referring to
          selector inside of a media query...
  glazou: This is doable in future.
  glazou: We should not reject that immediately.
  glazou: It may not be implementable right now, but is valid
          solution.
  Rossen: We're not doing anything to prevent it.


  TabAtkins: A breakout discussion... can I put an element in a
             location without having it excluded by the screen?
  TabAtkins: Here's a point. Is it inside the screen or not? With a
             few addressing schemes... cartesian, polar, etc.
  TabAtkins: Is this point 100% 0 in screen? Media query true or
             false.
  fantasai: That's an interesting direction.
  fantasai: Points are dimensionless,
  fantasai: so use offsets.
  <fantasai> https://drafts.csswg.org/css-shapes/#supported-basic-shapes
             I would use the inset() syntax instead of points.
  TabAtkins: You need more than boxes.
  TabAtkins: Points get you 90% and are super-trivial.
  TabAtkins: Do this as level one,
  TabAtkins: expand to use path at this location.
  fantasai: It's simple for implementor, but
  fantasai: it's hard for author; they need to work in areas.
  fantasai: Using points to get areas is hard from an authoring
            perspective.
  fantasai: You need to put lots of points to see if it's a curve or
            a notch etc.
  TabAtkins: No it's not.
  TabAtkins: It's not sufficient to say I can put a rectangular box
             here.
  fantasai: It's better if we let them put the assumption into the
            syntax.
  TabAtkins: We want it to be easy to author; arbitrary shapes are
             difficult.
  <fantasai> I'm not saying that we should not do paths for
             arbitrary shapes at some point.
  <fantasai> But starting with a point is not author-friendly

  Florian: I agree with Tab you want arbitrary shapes.
  Florian: But a box as bounding box of arbitrary shape is more
           useful than point.
  Florian: The point approach will break on unexpected shapes.
  Florian: Box fails in a better way.
  * tantek tends to agree with Florian on this
  <tantek> making it easier for the author to get something reliable
           tends to be good design
  TabAtkins: I'm fine with boxes, especially if they're optional.
  fantasai: We should reuse inset syntax from shapes module
  <tantek> reusing syntax++
  dbaron: Is that rounded boxes?
  fantasai: It's an optional argument.
  fantasai: It gives users less new syntax to use.
  dbaron: We want to specify points in multiple coordinate systems.
  dbaron: As polar, as percentage, as pixels across the box.
  dbaron: Does that work with inset?
  TabAtkins: Yes, but has polar anchor problems.

  <fantasai> https://drafts.csswg.org/css-shapes/#supported-basic-shapes
  fantasai: Circle has a positioning syntax.
  fantasai: Shapes syntax does everything you want.
  fantasai: We can pick a necessary subset of this, like circles and
            inset rectangles,
  fantasai: Then authors don't have to learn multiple syntaxes.
  TabAtkins: Inset is off of the reference rectangle, bounding box
             of the screen.
  TabAtkins: I want to put an x in corner, you need to do big offsets.
  TabAtkins: It's simpler to do 20x20 box.

  zcorpan: If we only do points, we can pretend it's a rectangle.
  zcorpan: For a 20x20 box in corner, query lower left corner.
  zcorpan: That gives you same info.
  Florian: Your box might be mostly obscured.

  dbaron: We should action someone to write a proposal.
  Rossen: Good idea.
  TabAtkins: We're disagreeing on what the proposal should be.

  SteveZ: You have to know which corner you're asking for.
  SteveZ: If you're going for upper right, use upper right corner of
          rectangle, tells you most of what rectangle would be.
  Florian: The bounding box solves correctly, the point doesn't.
  TabAtkins: I don't care about this crazy screen.
  Florian: The bounding box is more robust in error cases.
  TabAtkins: As soon as we go to square, we get complex behavior
             with polar.
  TabAtkins: Points will be slightly less useful,
  TabAtkins: but referencing scheme is simple.
  TabAtkins: Keep MQ as simple as possible.
  TabAtkins: This is already above my threshold.

  Bert: Listening to the conversation about rectangles.
  Bert: You want to ask is that rectangle visible.
  Bert: You put 20x20 box in a corner,
  Bert: You don't need to know the shape, only if the box is visible.
  Bert: You get true or false.
  SteveZ: That's fantasai's proposal
  SteveZ: It's still iterative, so you have to keep sampling into
          you get true.
  TabAtkins: Or switch to JS.
  Florian: Or use polar coordinates with contain.
  fantasai: Most layouts won't be this simple
  fantasai: You need to have some idea of what layout you're in.
  fantasai: You don't get reasonable results by using that in square.
  Florian: Then you can use shape-inside:display.
  TabAtkins: It's harder to use different addressing schemes with
             Bert's proposals.
  fantasai: This is fine for lots of complex cases.
  fantasai: It's harder for simple cases... is this thing square?
  fantasai: You can't ask that simply
  fantasai: For ellipse or circle or rectangle.
  TabAtkins: You need a version for yea/nay on rectangle.
  fantasai: The advantage of rounded rectangles gives you common
            cases.

  Florian: I'm not sure... are you proposing circle/rectangle?
  fantasai: I'm suggesting what Bert did.
  fantasai: Rectangles get you a lot of the way.
  TabAtkins: Then you can't do polar coordinates.
  fantasai: You could do points and rectangles.
  fantasai: You get is this visible very quickly.
  TabAtkins: That sounds fine.
  TabAtkins: Rectangles using cartesion,
  TabAtkins: points with whatever.
  fantasai: Then we can add more shapes; we have a functional
            notation.
  TabAtkins: Are people ok with that?

  Rossen: Can you summarize?
  TabAtkins: An "is visible" media query that takes rectangle
            (cartesian) or polar point
  TabAtkins: and is either true or false.
  TabAtkins: It's a slight complication of what we agreed on.
  TabAtkins: It solves rectangular cases better.
  Rossen: Ok.

  fantasai: Inset would also be useful.
  fantasai: If I go inset by 5px do I clear all the screen boundaries.
  Florian: This solves much better than everything else, "can I put
           this in the corner"
  Florian: Therefore I'm in favor.
  Rossen: Anything else?
  Florian: What it doesn't solve is having a very different design
           on round.
  TabAtkins: Sure it does, try lots of points to show it's round.
  Rossen: If it becomes a prime use case we'll deal.

  zcorpan: It shouldn't be "is visible", which implies it wouldn't
           be visible if scrolled.
  Florian: "fits in screen"
  <dbaron> "in display"?

  hyojin: Is this enough for you to go write spec
  TabAtkins: I can help.
  Florian: You should get help.
  hyojin: I think this is reasonable technology.
  hyojin: If I have some trouble I will ask for help.
  Rossen: Sounds great.

  <MaRakow> positioning of the shape in question is relative to AABB
            of the display?

  SteveZ: Responding to florian:
  SteveZ: Since you can already get bounding rectangle in MQ,
  SteveZ: querying for ellipse, major and minor axis that covers
          shape,
  SteveZ: take the intersection of those two as defining points in
          the area.
  SteveZ: Then you can discover if circle or ellipse,
  SteveZ: just like border radius.
  SteveZ: Those two values would give you most of the shapes we care
          about.
  SteveZ: You would have to do calculations.
  Florian: Every single definition of device radius is doable in JS
  Florian: It's not convenient to write that JS, but its possible.
  SteveZ: With the four values you can do everything.
  SteveZ: Four values, not infinite :)
  fantasai: That's very simple.
  fantasai: I think this is cool.
  fantasai: Let's write proposals, but let's investigate Steve's
            idea,
  fantasai: which is good for reasonable cases.

  Rossen: Can you summarize in an email and send to list?
  dbaron: I sent summary of break discussion to list.
  Rossen: OK. Let's move on.
  <fantasai> Steve's proposal is, roughly, device-radius-x/
             device-radius-y, where the radii are from the center of
             the device to the edge of the smallest ellipse that
             covers the screen
  <fantasai> (This is different from device-corner-radius-x/y, which
             are just defining the curve of the corners.)

  Bert: One question:
  Bert: Should we talk about viewport instead of device?
  Bert: It might not be the same.
  TabAtkins: Yes.
  Bert: Viewport is enough, you don't need device.
  TabAtkins: Device is irrelevant.

  dino: The resolution we made before, dropping polar orientation,
  dino: adding more grammars to rotate().
  Florian: Yes, that's correct.
  dino: I don't like changing transforms for this use case.
  dino: we can move on, but want to discuss later
  <MaRakow> +1 to dino
Received on Tuesday, 24 November 2015 01:16:20 UTC

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