23:51:01 RRSAgent has joined #css 23:51:01 logging to http://www.w3.org/2015/10/26-css-irc 23:51:05 shigeya has joined #css 23:51:20 skk has joined #css 23:51:27 rrsagent, this meeting spans midnight 23:51:52 hitsujiwool has joined #css 23:51:55 shigemi has joined #css 23:53:17 xidorn has joined #css 23:53:58 kurosawa has joined #css 23:54:04 MaRakow has joined #CSS 23:54:43 dino has joined #css 23:54:45 Bert1 has joined #css 23:57:56 usuij has joined #css 23:59:07 jchiba has joined #css 23:59:29 myles has joined #css 23:59:59 kokabe has joined #css 00:01:02 Florian has joined #css 00:01:04 nulltask has joined #css 00:01:38 katashin has joined #css 00:02:20 bkardell_ has joined #css 00:02:54 Zakim, remind us at 6am to tell you to go home 00:02:54 You can go home any time you like, Rossen 00:04:35 murakami has joined #css 00:05:13 katashin has left #css 00:05:47 katashin has joined #css 00:06:48 dyamada has joined #css 00:07:48 tfuji has joined #css 00:07:50 dbaron has joined #css 00:08:01 glazou has joined #css 00:08:31 ScribeNick: dino 00:08:50 brady_duga has joined #css 00:08:53 Topic: Polar coordinates/issues and Round Display 00:09:37 Bobby has joined #css 00:09:45 hyojin: Two issues. First polar issues. 00:09:58 hyojin: proposed polar-origin property 00:10:22 hyojin: anchor point in CSS is typically top left, where as in polar is it center/center 00:11:07 hyojin: e.g. when you scale an element, it should resize from the center in all directions. 00:11:24 Rossen: is there a document we can look at? 00:11:34 hyojin: no. just a proposal. 00:12:06 http://www.w3.org/TR/css-round-display-1/ 00:12:08 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. 00:12:57 SimonSapin: is it worth having separate properties for transform and polar origins? 00:13:19 s/SimonSapin/zcorpan/ 00:13:26 https://www.dropbox.com/sh/zbdvmix6505fquo/AADaG2-U42PZWYOw0Btad7t0a?dl=0 00:13:29 oops! 00:13:49 hyojin: I have a demo that I can maybe show. 00:13:59 atai has joined #css 00:14:02 stakagi has joined #css 00:15:09 s/is it worth having separate properties for transform and polar origins/is there a use case for using different origins for transform and polar if you're using both at the same time?/ 00:15:24 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/ 00:15:56 dino: the origin is center in transform origin 00:15:58 ScribeNick: fantasai 00:16:20 Rossen: So, going back to the question & proposal -- feedback from the room? 00:16:30 Rossen: wrt having separate origin for polar coordinates and transform-origin 00:16:47 yubo_ has joined #css 00:17:15 rakow: transform-origin only applies to transformable elements, but seems like polar-origin might also apply to inlines? 00:17:27 fantasai: positioned elements become blockified 00:17:31 dbaron: that would be easy to fix in any case 00:17:58 dbaron: So, is polar-origin that you want something that controls the positioning of the elements relative to the thing they're positioned in? 00:18:14 dbaron: We had discussions about rotation of the polar-positioned elements, but this is about positioning of polar elements rather than rotation? 00:18:20 ?: Just positioning elements 00:18:23 ?: you could use ... 00:18:34 ?: when we want to animate, shoudl refer to the transform origin 00:18:42 ?: I shoudl think more about this topic, it's very brief idea for now 00:18:47 s/?/hyojin/ 00:19:14 dbaron: One other question is, the idea is you use the polar-origin property of the parent when you're positionng the polar items, or using their own polar origin property, relative to size of the parent 00:19:18 ? 00:19:21 glazou has joined #css 00:19:41 hyojin: Relative to containing blocks... polar-origin would be if I usually center center, if some author could put a point in coordinate 00:19:56 zcorpan requests the whiteboard to come into play 00:19:58 karl has joined #css 00:20:13 dbaron: polar-anchor is position in child, and polar-origin is position in the parent? 00:20:21 TabAtkins: yes, both defaulting to appropriate center 00:21:12 hyojin draws diagrams: 00:21:27 polar-origin diagram shows circle with dot in the middle, square along outside edge 00:21:40 polar-anchor shows dot inside the square [positoined element] 00:21:44 dbaron: That answers my first qustion 00:21:59 dbaron: Second question is, if you have two elements here 00:22:04 dbaron: containing block element, and positioned element 00:22:40 dbaron: when you're positioning the child, are you referencing the 'polar-origin' value of the child or of the containing block? 00:22:47 hyojin: I think the containing block 00:22:54 dbaron: Might be reasons to consider other things 00:23:07 Florian: Are there use cases for non-centered coords? 00:23:15 TabAtkins: Totally. E.g. positioning around an arc 00:23:26 TabAtkins: that surrounds one corner of the box 00:23:35 Florian: But then where do you position it? 00:23:40 TabAtkins: then you overflow 00:24:05 dbaron: Percentage values of polar distance are an interesting case 00:24:11 dbaron: They're relative from center to edge of containing block 00:24:20 TabAtkins: you'd clamp it to zero, then 00:24:36 dbaron: polar-distance needs to be clearer about what happens when the origin is not the center 00:24:46 ACTION hyojin: Clarify polar-distance percentages when origin is not the center 00:24:47 Created ACTION-731 - Clarify polar-distance percentages when origin is not the center [on Hyojin Song - due 2015-11-03]. 00:25:31 myles has joined #css 00:25:42 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 00:25:48 fantasai: Wasn't that what the auto value of polar anchor was for? 00:26:02 plh has joined #css 00:26:31 Florian: It would be somewhat unintuitive in this case if your origin is at the corner, since you would position yourself neatively... 00:26:38 TabAtkins: Yes, totally logical 00:26:50 Rossen: First question is, should this be separate from tranform-origin 00:27:24 fantasai: I think so, because transform-origin would be used for rollover effects and other animations of the item in its positioned place 00:27:28 TabAtkins: agree with fantasai 00:27:28 https://lists.w3.org/Archives/Public/www-style/2015Sep/0234.html 00:28:20 RESOLVED: Add polar-origin, independent property from transform-origin, issue open on whether it is referenced off the item or the containing block 00:28:35 hyojin: Next is polar-anchor 00:29:00 hyojin: Current proposal is to prevent overflow on the display with 'auto', but alternative is modifying polar-distance with special value 00:29:15 hyojin: I'm wondering whether polar-anchor is still necesary 00:29:39 hyojin: Two issues open here. 00:29:47 "polar-distance: 100%" vs "polar-distance: 100% no-overflow" 00:30:21 dbaron: polar-anchor still seems likely to be useful, even just to set two anchor points 00:30:42 Florian, I'd suggest s/no-overflow/contain/ :) 00:30:51 https://lists.w3.org/Archives/Public/www-style/2015Oct/0087.html 00:30:58 astearns: That seems reasonable, but I'd like a stronger use case than preventing overflow here 00:31:38 Florian explains how the auto value works on polar-anchor -- it automatically chooses the anchor based on the polar angle 00:32:08 Florian: The problem with this is that it can shift you in weird ways [florian pls clarify] 00:32:19 Florian: The no-overflow keyword does not have this problem 00:32:31 Florian: This does not answer the question of whether polar-angle without 'auto' is also useful 00:32:38 hyojin: Polar origin is in the containing block 00:32:43 hyojin: polar-anchor is in the target element 00:32:52 hyojin: I think there should be two points, define each 00:33:07 Florian: The model makes sense to me. The argument from Alan is whether this is needed 00:33:17 Rossen: You will always have two points. 00:33:29 Rossen: The question is whether you can change on or the other from the default that we choose 00:34:11 asdfasdf has joined #css 00:35:04 fantasai: I can think of mayb 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 00:35:30 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 00:35:59 dbaron: if you don't know the sizes of these items, you want to positoin them so that they don't ovelap, need to choose the bottom point on the top itme and the top point on the bottom point. Center won't work 00:36:15 adenilson has joined #css 00:36:36 Florian: We seem to be agreeing that 'auto' is not needed on polar-anchor, and a no-overlfow value on polar-distance would be better. 00:36:45 Florian: We agree on what it does, but how it works is tricky 00:37:02 I'm convinced by the two use-cases above that setting polar-anchor could be useful 00:37:24 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 contianing block, this gets tricky 00:37:31 Florian: human can do it, but algorithm much harder 00:37:42 Florian: if your contianing block is a star... 00:37:49 yeonsoo has joined #css 00:37:55 Florian: Or arbitrary shapes, how do you deal with that? Do we even try? 00:38:12 Florian: wrt watch face, rounded but neither circular nor elliptical, it's pretty common 00:38:18 Florian: Traditional watch design has such curves 00:38:27 Florian: We probably wnat no-overflow property should work with these as well 00:38:39 Florian: Do we need to go further and work with non-convex shapes? 00:38:50 TabAtkins: If you design a non-convex screen and expect it to do anything useful? 00:39:03 Bert: I want to design a jigsaw puzzle! :D 00:39:23 Florian: Need to try to write out definition and see 00:39:27 TabAtkins: Not convinced we need to worry about this. 00:39:43 fantasai: I would change name of 'no-overflow' to 'contain' 00:39:45 Florian: Sure 00:40:16 Rossen: Okay? 00:40:26 hyojin: We will gather use cases for polar-anchor 00:40:39 hyojin: What is the best option of defining polar-distance's second value? 00:40:50 hyojin: Previous ida as polar-center or outer or inner? 00:41:10 fantasai: I would call it 'contain', like radial gradients 00:41:23 Florian: polar-distance: ; or polar-distance: contain; 00:41:24 lisongfeng has joined #css 00:42:09 ACTION hyojin: work on polar-distance: contain; keyword proposal 00:42:10 Created ACTION-732 - Work on polar-distance: contain; keyword proposal [on Hyojin Song - due 2015-11-03]. 00:42:18 hyojin: polar-orientation 00:42:21 http://www.w3.org/TR/2011/WD-css3-images-20110908/#radial-gradients 00:42:28 hyojin: polar-orientation is to distinguish between center and counter-center 00:42:45 hyojin: Proposal was to replace with rotate/transform 00:42:57 hyojin: But useful to have center and counter-center 00:43:09 Florian: I think the behavior we want, to turn and rotate positioned elements as a function of its polar angle, that makes sense 00:43:32 Florian: But we raised two issues on the last tiem we talked about this, one is does it need to be a special property or is this a special keyword on rotate()? 00:43:40 polar-orientation: https://lists.w3.org/Archives/Public/www-style/2015Oct/0199.html 00:44:08 Florian: Or maybe it should be separate because polar-origin 00:44:10 https://lists.w3.org/Archives/Public/www-style/2015Oct/0177.html 00:44:40 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. 00:44:52 fantasai: For example, we could have transform: rotate(polar-center); 00:45:19 fantasai: And if you want the same thing for transforms (because I don't think this is important), then you can have transform: rotate(transform-center); 00:45:32 s/transforms/transforms later/ 00:45:52 fantasai: Is there any reason why this wouldn't work? 00:46:21 Florian: If you do transform: rotate(polar-center); it rotates around which origin? 00:46:43 Florian: What if the polar-anchor and transform-origin are not the same? 00:46:54 fantasai: Is that what you really want? I'm not convinced. 00:47:14 Florian: Second thing we raised during telecon is based on the example 00:47:36 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 00:47:57 polar orientation sample app: http://anawhj.github.io/jRound/demo/polar/rotate.html 00:48:01 Florian: Having to choose between these seems a little bit problematic, since hte goal of these values is to be automatic 00:48:18 Florian: If you need to adjust based on the angle anyway, might as well just do the math. 00:48:30 fantasai: So you're suggesting there should be a third auto-center value 00:48:48 Florian: I think we should rethink the set of values 00:48:58 Florian: Do you ever wnat counter-center if you're positioned at the top? 00:50:30 Florian: Lets have values for the use cases. 00:50:49 Bert: The motion-path property has the same three values 00:51:02 Bert: It has center, called auto. 00:51:08 Bert: Also has reverse, 00:51:13 Bert: and also has angle, which you can use for 0deg 00:51:25 Bert: Corresponds exactly to the polar-orientation property, though different naming 00:51:32 Bert: Seem to need these three values 00:51:34 https://drafts.fxtf.org/motion-1/#motion-rotation 00:51:41 fantasai: We should keep the names consistent... 00:51:49 fantasai: Though I'm not sure in which direction :) 00:52:28 Rossen: So what's next? 00:52:42 Florian: would like to hear from rest of WG what they think of the auto-center keyword idea 00:52:42 http://anawhj.github.io/jRound/demo/facebook/circle.html 00:53:49 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, could also add later 00:55:00 hyojin projects example 00:55:16 Bert: If you used no-overflow, it would not work nicely like this 00:55:31 Florian: I'm okay with deferring a request for new values until later 00:55:39 Rossen: Yours sounds like a superset, so can always add more 00:58:00 CSS Round Display Demo: http://anawhj.github.io/jRound/demo/ 00:58:05 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. 00:58:12 hiro__ has joined #css 00:58:22 hyojin: Next topic is device-radius 00:58:37 device-radius regarding percentages issue: https://lists.w3.org/Archives/Public/www-style/2015Oct/0193.html 00:59:02 hyojin: Florian and Tab were discussing this topic, it was a little bit difficult 00:59:15 sam has joined #css 00:59:20 Florian: I didn't explain well, and you didn't understand what I meant wrt inequalities... 00:59:47 TabAtkins: I will object to anything where lengths and percentages are not comparable 00:59:57 TabAtkins: and to anything where inequalities are not defined among these 01:00:09 Florian: In my proposal, length and percentage are comparable per axis 01:00:30 Florian: Wrt inequalities, you're not necessarily in an ordered spaced. A zigzag corner is not more, less, or equally rounded to a corner 01:00:53 TabAtkins: Which is why I would object to it. Must be ordered. Must define inequality 01:01:11 Florian: Some things don't match inequality or non-inequality is okay 01:01:14 TabAtkins: No it's not 01:02:11 Florian draws a circle within a square 01:02:38 Florian: I don't think anyone disagrees that this matches device-radius: 100px and also device-radius: 50% 01:02:43 (square is 200px wide) 01:02:51 Florian: What if it's rectangular? 01:03:30 Florian: Tab says you must evaluate always against a single axis, either width or height. 01:03:50 Florian: But in this example (200px x 400px rectangle, portrait) 01:04:12 Florian: I think this should not match device-radius: 200px or device-radius: 400px, becaus these would match a circle, and this is not a circle. 01:04:31 Florian: but it would match device-radius: 50%; 01:04:43 s/200px or device-radius: 400px/100px or device-radius: 200px/ 01:04:53 Florian: So no non-circlular ellips would ever match a length. 01:05:02 Florian: but you can still do calc math meaningfully 01:05:49 Florian adjusts the curve so that there's a 10px length of straight edge on each side (less than 50% curve) 01:06:09 Florian: This shape would match device-radius: calc(50%-10px) 01:06:18 Florian: Mixing percentage and length works. Separately per axis, but they work 01:06:39 s/10px/5px/ 01:06:55 ish 01:07:39 https://www.dropbox.com/s/8dj6ao4rurp5hdq/round-display-oval.jpg?dl=0 01:07:56 dbaron: So device-radius is rounding of the entire screen, regardless of its size 01:08:07 Florian: yes 01:08:12 anssik has joined #css 01:08:15 dbaron: Sounds more like device-corner-radius. 01:08:15 +1 to what dbaron said 01:08:17 TabAtkins: yes 01:08:45 Florian: If you have one corner 10px and another corner 50px, then it wouldn't match device-radius: 10px anyway 01:09:00 Florian: Any screen shape. 01:09:02 yeonsoo___ has joined #css 01:09:10 Florian draws weird corners 01:09:39 Florian: Any screen shape that does not cross this line (designated by device-radius) matches max-device-radius: 50% 01:10:04 TabAtkins: I don't want to do this 01:10:11 TabAtkins: It breaks inequality algebra 01:10:16 TabAtkins: and there isn't a use case 01:10:27 TabAtkins: I think we will need to support either round or beveled corners 01:10:37 https://www.dropbox.com/s/t3pkq6syhvhzr9g/round-display-oval-weird-corners.jpg?dl=0 01:10:39 TabAtkins: Figuring out rounded corner ish thing it would be in an ideal world 01:10:50 TabAtkins: Just do an equality based on that that does normal math 01:11:09 Florian: I don't expect us to handle weird shapes, but the way you're saying this works then it's very confusing 01:11:10 hellojintae has joined #css 01:11:23 Florian: If you have one corner that's rounded, then it doesn't match 10px and doesn't match 0px 01:12:05 dbaron: I think the case we'll run into those, but might run into non-elliptical rounded screens 01:12:09 Florian: egg shape is reasonable 01:12:37 Florian: leaf-shaped one is reasonable (top right and bottom left corners rounded, other two sharp) 01:12:46 shoko has joined #css 01:13:10 TabAtkins: leaf-shaped one is imposible to design for anyway 01:13:39 Florian: What query would match that? 01:13:42 TabAtkins: device-radius: 100% 01:13:53 Rossen: What are we changing based on this query anyway? 01:14:10 TabAtkins: basically, it's how much do we avoid corners. 01:14:33 murakami_ has joined #css 01:14:44 https://www.dropbox.com/s/gkyix2nx0on1uqp/round-display-variation.jpg?dl=0 01:15:10 Rossen: Can we just do three keywords? 01:15:30 fantasai: No, I don't think so, because you wnat to know how much corner you have , it's a scale, so shoudl be a number 01:15:37 different designs will have different thresholds they carea bout 01:16:18 fantasai: I really don't think keywords will cut it. It should be a number. 01:16:54 fantasai: Can be a conservative number, so that you get the answer that represents the largest space that's definitely on the screen. 01:17:09 Florian: There are two issues here -- one is curves that are not quite elliptical 01:17:15 Florian: another is if different corners are different 01:17:23 Florian: Example -- 01:17:44 Florian: If corners are slightly rounded, I might be okay in my design. But as it gets bigger, might get to a point where I need to re-evaluate my design. 01:18:01 Florian: You can evaluate a perfect ellipse, you can use that as a judge: if my design fits in that ellipse, I'm okay. 01:18:36 Florian: If it doesn't, then I need to change my design 01:19:08 Florian: For differnet-shaped corners,well maybe we need four media queries. But the single one should give the most conservative answer. 01:19:23 Florian: That's how I would use my media query, as I explained it 01:20:13 TabAtkins: There's a point at which we'll need to just return a path via JS 01:20:29 TabAtkins: e.g. luminosity, we didn't expose lumens. 01:20:37 http://w3cmemes.tumblr.com/image/131987363392 01:22:15 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 01:23:49 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 01:23:56 http://giphy.com/gifs/stephen-colbert-late-night-comedy-central-LFlT04CTtrwc 01:24:08 Tab argues that three keywords for square, round, and kinda round is sufficient for all uses 01:24:22 Florian argues that his proposal is perfectly simple for authors to use 01:24:27 both of them argue back and forth. 01:24:32 I also think we should not reject, and do this as simple in L1 and expandable to a future L2 01:24:33 Tab gets upset that his points aren't minuted 01:24:46 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. 01:24:58 q+ 01:25:03 hwlee has joined #css 01:25:08 TabAtkins: We have 3 semantic layout categories, I think: square (normal), round (use polar), and rounded-rect (avoid the corners). 01:25:08 q+ 01:25:19 * Free-form display (2): http://image.itmedia.co.jp/l/im/news/articles/1406/18/l_yuo_sharp.jpg 01:25:26 q+ 01:25:52 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). 01:26:35 zcorpan: What I wanted to say, a way to get a number is to use the radius of the biggest corner. 01:26:47 zcorpan: An if it's oval shaped, you use the line that goes from the center to the edge 01:26:57 Rossen: So this is stil lin favor of numbers, not keywords 01:27:02 zcorpan: Yes, using a number 01:27:32 Florian: Question about this. I fyou say biggest corner, don't you want to switch biggest vs. smallest depending on whether you're checking greater-than or lesser-than? 01:28:08 zcorpan: The point of this media query is being able to tell how close to the corner you can put stuff 01:28:23 zcorpan: Whether you use smaller than or greater than, I don't see why you would want to smallest corner. 01:28:40 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. 01:28:47 Rossen: It might not be at the edge 01:28:53 zcorpan: It will still be visible. 01:29:13 zcorpan: If you want more accuracy then us the JS API 01:29:42 tripu has joined #css 01:30:30 fantasai: It's important imo that greater-than and less-than operate o nthe same numbers, because authors should be able to say @media (device-radius > A) { ... } and @media (device-radius < A) {... } and catch all cases. 01:30:35 Florian: I disagree with this. 01:30:57 s/disagree/partly disagree/ 01:31:17 Florian: I agree that they should work on the same thing, but I think there are also screen shapes that will be niether less nor equal nor greater than this. 01:31:30 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. 01:31:36 Florian: Star-shaped screen [...] 01:31:55 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? 01:32:11 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. 01:32:21 q+ 01:32:29 Florian: If a rounded circularly 30px corner would do this ...? 01:32:38 Florian: Then any shape that starts hereand ends at the same point would match? 01:32:45 zcorpan: No. 01:32:50 zcorpan: What shape are you interested in? 01:33:33 zcorpan takes the smallest distance. 01:33:44 zcorpan: Nothing will be hidden, that's fine. 01:33:54 Florian draws an inverse curve 01:34:04 zcorpan: I suppose you use an ellipse or a circle that fits inside. 01:34:12 zcorpan: So if you wnat a sar shape, or whatever 01:34:27 zcorpan: you use the circle that fits inside 01:34:30 fwtnb_ has joined #css 01:34:33 Florian: I believe your definition and mine are identical 01:34:57 Florian: You compare the the shape of the screen, find the largest ellipse that would fit within it, and use that. 01:35:20 Florian: ... 01:35:50 q- 01:36:26 fantasai: I think it's a reasonable model for comparison, but the information you've given the author in th estar case 01:36:42 fantasai: is that you have a 200px wide screen with a 25px rounded corners, not a 25px radius circle 01:37:12 Florian: This definition makes sense for [...] 01:37:14 Florian: ... 01:37:23 Florian: The arbitrary shapes bit isn't the point, it's just what falls out. 01:37:37 https://www.dropbox.com/s/gnt82gfn3mq5vd2/round-display-variation-radius.jpg?dl=0 01:38:11 Rossen takes a point of order. 01:38:11 q? 01:38:56
01:41:45 AndreyR has joined #css 01:41:59 dauwhe has joined #css 01:46:43 jihye has joined #css 01:52:14 Masa has joined #css 01:57:25 jh has joined #css 01:58:20 myles has joined #css 01:59:16 stakagi has joined #css 02:03:12 hitsujiwool has joined #css 02:03:16 nulltask has joined #css 02:07:04 ymasao has joined #css 02:08:08 dauwhe has joined #css 02:08:58 tantek has joined #css 02:10:43 yasuraoka has joined #css 02:10:43 scribenick: dauwhe 02:10:52 Topic: fragmentation 02:11:05 jchiba has joined #css 02:11:06 Topic: Round display media queries 02:11:08 jdaggett has joined #css 02:11:28 Rossen: going back to the discussion 02:11:42 murakami has joined #css 02:12:00 SimonSapin: (shows complex shape on screen) 02:12:08 ... content is designed for this device 02:12:17 SimonSapin: In this nintendo case, there's a lot of content that is optimized for this device. 02:12:19 ... does this device has brother that shows arbitrary content 02:12:32 Florian: it's a nintendo device, these things have brothers 02:13:01 https://www.dropbox.com/s/dce7ho80zrqh5ur/round-display-variation-added-in-break.jpg?dl=0 02:13:01 shigemi has joined #css 02:13:08 glazou: everything is provided by third parties, 02:13:26 SimonSapin: does 3rd party software expected to show content on parts of the screen 02:13:37 Rossen: is the q should we handle this type of display? 02:14:04 present+ tantek 02:14:05 usually 3rd party providers don't control the device characteristics 02:14:15 SimonSapin: how much are random websites expected to adapt to arbitrary screeens 02:14:17 dyamada has joined #css 02:14:20 Rossen: as much as authors care 02:14:29 kurosawa has joined #css 02:14:33 plinns: this is a job for shapes and exclusions 02:14:49 s/plinns/plinss 02:14:57 shane: we had discussion during break 02:15:30 Matt: should be clear instruction in script that shape is complex, that you'll need more than CSS 02:15:45 glazou: thinking out loud 02:16:01 ... having svg shape in doc tree and referring to selector in r side o media query 02:16:06 https://drafts.csswg.org/css-shapes/#supported-basic-shapes 02:16:06 ... this is doable in future 02:16:13 ... we should not reject immediately 02:16:20 dbaron -- https://drafts.csswg.org/css-shapes/#supported-basic-shapes I would use the inset() syntax instead of points. 02:16:31 ... it may not be implementatble right now, but is valid solution 02:16:36 q 02:16:39 Rossen: we're not doing anything to prevent it 02:16:41 q? 02:16:44 q? 02:16:49 ack MaRakow 02:16:51 ack MaRakow 02:16:51 ack SimonSapin 02:16:52 s/Matt:/MaRakow/ 02:16:53 ack shane 02:16:57 ack SimonSapin 02:17:15 TabAtkins: breakout discussion... can I put an element in a location without having it exluded by the screen 02:17:35