Re: Resolutions regarding fragments

On Wed, Feb 5, 2014 at 7:59 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> 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.
>

Okay, so the current situation is:
-- 'element': straightforward
-- 'box': a logical CSS thing, doesn't really have a shape, or if it does
it's not necessarily rectangular, 1 per element except where anonymous
boxes are present
-- 'fragment': each box splits into one or more fragments
-- 'content/padding/border/margin box': one per fragment, rectangular
Is that correct?

I believe there are a number of places that need to be converted from
element to box, and also a number of places that need to be converted from
box to fragment --- especially in CSS 2.1. Are we going to retrofit CSS
2.1? If not, I think it needs a big warning somewhere explaining how to do
the translation, especially for the parts of CSS 2.1 that haven't yet been
superceded by CSS3 modules.

Are we going to keep talking about the "position" and "size" of a box,
given it no longer has a real shape? If so, what exactly would that mean?


>
> >>   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".
>

Ah, I definitely didn't get that from the minutes. That sounds like a good
solution.

Rob
-- 
Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w