- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 23 Nov 2015 20:15:20 -0500
- 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