- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Wed, 5 Feb 2014 09:02:25 +1300
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: www-style <www-style@w3.org>
- Message-ID: <CAOp6jLYbjtGSQyv7LNYYi5r6T6942SBFnW-xHBNo7VyAGe0Zsw@mail.gmail.com>
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
Received on Tuesday, 4 February 2014 20:02:53 UTC