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

Hello Florian,
I greatly appreciate your detailed comments. It's very helpful to me. Most
of the comments are reasonable and acceptable for us.
I will apply the comments into the css-round-display specification ASAP and
let you know the progress by inline comments soon.

If I have some questions regarding what you mentioned, I will send a thread
with the questions through the www-style mailing list, individually.
Thanks you once again for your splendid comments.

Best Regards,
Hyojin Song

-----Original Message-----
From: Florian Rivoal [mailto:florian@rivoal.net] 
Sent: Thursday, April 30, 2015 6:18 AM
To: Hyojin Song
Cc: www-style
Subject: 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, 6 May 2015 04:20:25 UTC