Re: [css-round-display][mediaqueries] Change of a 'device-radius' prop desc

> On 07 Jul 2015, at 08:49, Hyojin Song <hyojin22.song@lge.com> wrote:

Hi. Sorry for the late response. I wanted to get back to you earlier on this topic.

> The css-round-display spec was slightly changed and I'm not sure whether two
> values could be specified in 'device-radius' media feature or not.

Based on the currently allowed syntax for media queries (http://dev.w3.org/csswg/mediaqueries/#mq-syntax), no, 2 values are not allowed.

We could extend it so that they are, but I am not sure it would really help. I think I prefer the single value syntax. It needed some clarifications, but with those clarification, it seems to me that it would have covered the use cases.

> Each
> values mean a horizontal radius and a vertical radius respectively, so that
> author can define an ellipse as a display shape with a pixel unit in the
> mediaqueries.

In my mind, there are 2 use cases for the device-radius media queries, and they are relatively similar:

1) you have one set of style rules that look good on a rectangular screen, and one that looks good on a rounded screen. If the screen is sufficiently rounded, you want to switch. This would be expressed like this:

@media (min-device-radius: 25%) {
  /*rules for somewhat rounded screens*/
}
@media {device-radius: 50%) {
  /*rules for fully rounded screens*/
}

Assuming we define % well, this would work with elliptical screens as well. If the screen is a "fully rounded rectangle", which is to say an ellipse, 50% would match it.

2) You have elements in the corners which would be obscured if the corners were rounded by a certain number of pixels or more, so you want to switch some style rules to move that content somewhere else if they are. For that, you would do:

@media (min-device-radius: 50px) {
  /* rules for moving content that would normally
     fall in the corners */
}

This would also apply with elliptical corners that have a 50px radius in one dimension and a 75px radius in the other, since we're using "min-". It would not for 50px/20px corners, but that's ok, since those hide less of the corner than a circular 50px corner.


In neither case 1) or 2), double values are needed to work with ellipses. In addition, it seems more complicated to make range evaluation work with double values, even though that is important.

However, I may very well be missing some important use cases that actually call for this syntax and warrant dealing with the complications. I think it would be very useful if you could share some example of situations where you would want to use the 2 value syntax. I do not only mean shape of screens that have elliptical corners, but examples of stylesheets that you would want to write, and could not do (or could not do well) unless you had the 2 value syntax.

> I think it might be reasonable to express more display shapes and is not
> complicated from the complexity point of view, but I'm not sure it could be
> allowed in the mediaqueries convention to define two strings as a media
> feature's value. The explanation of the 'device-radius' is in the spec
> document[1] under the property description, and I'd like to get comments
> about this topic.

Media queries do not describe the device, they test it. I think the different is subtle but important.

For example, with the right definition, a device-radius media query with a single value could even be used effectively against corner shapes that are not rounded at all. For example, if we define (min-device-radius:10px) to be true for any shape that obscures at least all the pixels that a 10px radius rounded corner would hide, then it would not only also match for a 10px/20px elliptical corner, but also for a diagonal cut of the corner starting (at least) 10px away horizontally and vertically from the corner point. (min-device-radius:10px) does not describe this shape, but it can still successfully test it.


 - Florian

> [1] http://dev.w3.org/csswg/css-round-display/#descdef-media-device-radius
> 
>

Received on Thursday, 16 July 2015 22:24:15 UTC