Re: Resolutions regarding fragments

On Tue, Feb 4, 2014 at 2:51 AM, Robert O'Callahan <robert@ocallahan.org> wrote:
> I do not understand this:
>>
>>   dbaron: 4 wrenches:  content box, padding box, border box, margin box
>>   dbaron: could use * edge, * rectangle
>>   SimonSapin: * area
>>   fantasai: area already has an incompatible definition, and these terms
>>             are used consistently all throughout our specs
>>   RESOLVED: Don't use "element", "box", or "fragment" in new terms that
>>             aren't elements, boxes, or fragments.  Where possible,
>>             convert old terminology accordingly as well.
>
>
> How was dbaron's issue resolved?

Yeah, it wasn't.  Note that the resolution covers *new* terms, and
says to convert old terms *where possible*.  We hadn't come up with
any good names for content/etc-box, so it stays as it is for now.

>>   RESOLVED: border-radius should get sliced across fragments, maintaining
>>             unfragmented geometry.
>
> How does this work when fragments have different widths? E.g. suppose the
> top-right border-radius curve is sliced so some of it ends up in the second
> fragment, which has a much smaller width than the first fragment. Does the
> remaining part of the border-radius curve keep the same horizontal offset
> and sort of disappear, or does it track the right edge of the fragment? The
> latter approach means you can get a collision between the two border corners
> if the second fragment is very narrow.

Hm, did that not get minuted?  There was definitely discussion about
this, but it might have fallen to the wayside.  The decision is to
scale the geometry with the width.  This maintains the same "shape".

~TJ

Received on Tuesday, 4 February 2014 19:00:06 UTC