Re: [css-round-display] Request for first review the css-round-display

> On 19 Mar 2015, at 09:58, Hyojin Song <hyojin22.song@lge.com> wrote:
> 
> Hello all,
> Good evening in Korea. :)
> 
> I'm Hyojin Song working for LG Electronics. I presented the
> css-round-display at last Sydney f2f meeting. I'd like to discuss this spec
> in the css mailing list. You can see the specification and the polyfill as
> follows:
> 
> - Spec: http://dev.w3.org/csswg/css-round-display/

Hi,

First, let me apologize for not replying earlier to this mail. I wanted to look into this since you published the first draft, but unfortunately I was not able to prioritize answering until now. Overall, as I said previously, I think you are on the right track, and that what you are proposing are useful additions to CSS. But of course, the devil is in the details, so let's dive in.

Some of my comments are editorial, but some are substantial. They are not listed in order of importance, but rather in order of reading the specification top to bottom. There's quite a few of them, so you should probably record them somewhere, for example as issues in the spec.

1) In several places, you write "We also propose to add [...]" or "We propose to extend [...]", but it would be better to write "This specification adds [...]" or "This specification extends [...]". Even if it's still a draft, the specification is meant to be read as a part of CSS defined by the Working Group, not a proposal to the working group. Similarly, "This will allow web authors to [...]" is probably better phrased as "This allows web authors to [...]".

2) In section 3 (http://dev.w3.org/csswg/css-round-display/#extending-media-queries), you say "Media Queries define [...] tailored for different media types". "media types" has a specific meaning, and is something we are generally trying to deprecate. It would be better to say "tailored for different environments".

3) Instead of Media Queries 3 [[MEDIAQ]], you should probably refer to Media Queries 4 [[MEDIAQUERIES]]

4) The following sentence is correct:
  "This media feature accepts optional 'min-' or 'max-'
   prefixes to express 'greater or equal to' and 'smaller
   or equal to' contstriants."

However, this is already implied by defining the device-radius media feature as a range media feature as you have done, so it would be better to turn this sentence into a note, to make it clear that it is explaining how range media features work, rather than trying to define a behavior specific to device-radius.

5) "By the mechanism of media queries, if the value of the device-radius media feature is less than or equal to 49%, 'rectangle-clock.css' is applied. If it is 50%, 'round-clock.css' is applied."

This sentence looks like it should be part of the example above it, but it appears in the main text. Please adjust the markup to include it in the example.

6) The device-radius descdef table has an "initial value" entry, but media features don't have an initial value. You can remove this line

7) What happens when different corners have a different radius? For example, the top left and bottom right have a radius of 100px, but the top right and bottom left have a radius of 250px.

My expectation would be that device-radius is always false, but min- (resp. max-) refer to the smallest (resp. biggest) radius:
* device-radius: 100px ==> false
* device-radius: 250px ==> false
* min-device-radius: 99px ==> true
* min-device-radius: 100px ==> true
* min-device-radius: 101px ==> false
* min-device-radius: 250px ==> false
* max-device-radius: 100px ==> false
* max-device-radius: 249px ==> false
* max-device-radius: 250px ==> true
* max-device-radius: 251px ==> true

Either way, you need to define this.

8) What happens if the corner is neither rounded nor rectangular? For example, if it is beveled. My expectation would be that device-radius would be 0, but you need to define that.

9) what happens if the corner is rounded, but elliptically rather than circularly (i.e. the horizontal radius is different from the vertical one)?
My expectation would be that device-radius is always false (at least when expressed in px, see point 10 and 11 for %), but min- (resp. max-) refer to the smallest (resp. biggest) radius. This too needs to be defined.

10) "Percentage: Refer to corresponding dimension of the display"
Corresponding how?
If I have a 400px by 800px display, and rounded corners with a radius of 200px, does device-radius:50% or device-radius:25% match? As above, I would expect neither to match, but min-device-radius:25% and max-device-radius:50% would. This too needs to be defined.

11) What happens with elliptical corners where the horizontal and vertical radius are equal in percentages?
For example, a completely rounded 400px by 800px device would have 200px horizontal radius and 400px horizontal radius in each corner, which in percentages, would be 50% radius both horizontally and vertically. I would expect
device-radius:50% to match.

12) "The example below shows how [...]", "On the other hand, the example below [...]" please include such sentences inside the example. Also, the figures of example 2 and 3 are outside the example, please include them inside. Also, example 2 and 3 seem to be separate parts of a single example, so you should probably group them together in one example

13) The watch images after example 4 should be inside example 4.

14) I am not sure I understand how "border-boundary: parent" works. Is it to be used to fit the border inside the parent element's shape inside? If yes, I think you need to explain this better, and explicitly mention shape-inside (and probably shape-padding as well). If it means something else, could you explain what? I think using the parent's shape-inside is useful, so if that's not what your value does, then we should add one more value for that.

15) I think you also need to give more details about how border-boundary works when the border is not uniform (different border styles, width, or colors for top/right/bottom/left borders).

16) You also need to define whether border-boundary is a purely visual effect, or whether it affects layout, and if so, how. (I don't think it should, but I have not thought about this in depth.)

17) "The polar-angle property specifies the angle from the X-axis". Is 0 left or right? do we count clockwise or counter-clockwise? I suggest consistency with angles in linear gradients (0 is up, then counting clockwise).

18) The possible values of 'polar-angle' and 'polar-distance' are specified as "[ <length> | <percentage> ]?". That should be "<length> | <percentage>".

19) "When the position property on an element is set to 'polar', its children use the polar coordinates."
Why do you set this on the parent rather than on the children? If you do that, I am not sure what the computed value of the the position property is on the children.

I would suggest setting position: polar on the children, and defining that the element which establishes the polar coordinate system is its containing block, where the containing block of a polar positioned element is defined the same way as the containing block of a containing block of an absolute element. This means we could also add "position: fixed polar", which would do the same as polar, but with the viewport as the containing block.

20) polar-angle percentages are "relative to radius of circle". What does that mean? I could understand 0 = 0%, 360deg = 100%.

21) "The polar-distance property specifies the distance from the center of the parent." If you do as I suggest in 19, then this would be from the center of the containing block.

22) polar-distance percentages are "relative to radius of circle". What circle?
I suggest that:

* 0% means that the center of the element is at the center of it's containing block

* 100% means the smallest distance in the polar-angle direction at which the margin edge of the element taking border-radius into account (or the shape outside if there is one) touches the content edge of its containing block taking border-radius into account (or the shape inside if there is one). If at 0% it already touches or overflows, then 100% = 0%.

* Other percentages are a linear interpolation based on 0% and 100%

This definition has the advantage that you don't need to do "polar-distance: calc(100% - /*radius of the element*/)" to avoid overflowing, and that it works regardless of whether the containing block is circular or not.

However, maybe we want to follow a circle (or an eclipse) even when the containing block isn't one, so we could add keywords to toggle between the behavior described above, and a variants of it that stay round. For example, you could specify the shape you want to follow instead of the content-edge of the containing block like this:

polar-distance: 100% circle; /* largest circle inscribed in the containing block */
polar-distance: 100% ellipse; /* largest ellipse inscribed in the containing block */

23) polar-angle and polar-distance have animatable: no. I think it should be yes.

24) We may also want to add a polar-origin property, taking <position> values (see http://dev.w3.org/csswg/css-backgrounds-3/#position) with an initial value of "center". On the containing block, this would establish the origin of the polar coordinates, and on the polar-positioned element, the point inside the element which should be aligned with the origin when polar-distance is 0. This can probably be a level 2 feature.

That's all I have for now, I hope that helps.

 - Florian

Received on Wednesday, 29 April 2015 21:18:03 UTC