W3C home > Mailing lists > Public > www-style@w3.org > July 2015

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

From: Alan Stearns <stearns@adobe.com>
Date: Wed, 8 Jul 2015 22:19:36 +0000
To: Florian Rivoal <florian@rivoal.net>, Soonbo Han <soonbo.han@lge.com>
CC: Hyojin Song <hyojin22.song@lge.com>, www-style <www-style@w3.org>
Message-ID: <7E4AE68B-B4A7-4DB3-8CA7-F7B3E860C41E@adobe.com>
On 7/6/15, 3:12 AM, "Florian Rivoal" <florian@rivoal.net> wrote:

>On 06 Jul 2015, at 07:50, Soonbo Han <soonbo.han@lge.com> wrote:
>> 
>>> -----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
>>> 
>>> 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.
>>> 
>> 
>> "border-boundary: parent" is intended that the border of an element is
>> circumscribed within that of its parent (possibly a round shape). [1] 
>>This
>> is similar to "border-boundary: display", but the border of the element 
>>is
>> bounded by that of its parent not by that of the display.
>
>Thank you for the clarification. This is what I expected, and it seems 
>reasonable.
>
>> If it uses the parent's shape-inside, it actually does nothing because 
>>the
>> element is already laid inside its parent as in [2].
>
>
>I think shape-inside is underspecified, and this is causing some 
>ambiguities.

I agree.

>
>As I understand it, the parent's shape-inside property affects the 
>positioning and length of the child element's line boxes, but does not 
>change the shape of the border. It is not clear to me whether it affects 
>the position of the border: in an example like [3], would the border line 
>up with the green line (content edge), the solid blue line 
>(shape-inside), or the dashed blue line (shape-padding)? The dashed blue 
>line in the figure you linked to [2] represents the shape-inside, but I 
>would expect the border in this situation to be the same rectangular 
>shape as usual, and that border-boundary:parent is what we would use to 
>shape the border.

As originally conceived, shape-inside does nothing to the border. The blue 
lines in figures 1 and 2 are merely showing the layout constraints added 
by shape-inside and shape-padding. I think changing the shape of the 
border should be limited to border-* properties.

>
>I think the shape-inside property needs clarifications, and that these 
>should be done with the possibilities offered by border-boundary in mind.
>
>> So I think that
>> referring to the border of the element's parent is more plausible.
>
>It seems to me that shape-inside should have a value that makes the 
>content fit the parent's  content edge adjusted to follow the border if 
>it is not a rectangle (either due to border-radius or to 
>border-boundary), and that when that's the case, border-boundary:parent 
>would follow make the border follow that as well.

The content-box value (described in shapes level 1) is the value you’re 
looking for. This constrains the content area to the inner edge of the 
border, however it’s shaped.

>
>This would effectively do what you described. But when there is a shape 
>inside, it should be taken into account somehow, if shape-inside does not 
>already do that.
>
>Regards,
>Florian Rivoal
>
>> [1] http://dev.w3.org/csswg/css-round-display/images/border_c.png

>> [2] http://dev.w3.org/csswg/css-shapes-2/images/shape-inside-content.png

>
>[3] http://dev.w3.org/csswg/css-shapes-2/images/rounded-rect-overflow.png

>
>
>



Received on Wednesday, 8 July 2015 22:20:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:18 UTC