W3C home > Mailing lists > Public > www-style@w3.org > February 2014

RE: Resolutions regarding fragments

From: Pavel Curtis <pavelc@microsoft.com>
Date: Thu, 6 Feb 2014 02:36:37 +0000
To: Pavel Curtis <pavelc@microsoft.com>, Tab Atkins Jr. <jackalmage@gmail.com>, Robert O'Callahan <robert@ocallahan.org>
CC: www-style <www-style@w3.org>
Message-ID: <C342B3C9477E3948B81B9CAC81724611550280CD@TK5EX14MBXC292.redmond.corp.microsoft.com>
Sigh.  In reading my message now, I see in the quote from the minutes that they did.  Nevermind...

-----Original Message-----
From: Pavel Curtis [mailto:pavelc@microsoft.com] 
Sent: Wednesday, February 5, 2014 6:32 PM
To: Tab Atkins Jr.; Robert O'Callahan
Cc: www-style
Subject: RE: Resolutions regarding fragments

Did the WG consider using the terms 'content rectangle', 'padding rectangle', etc. for the problematic foursome?

	Pavel

-----Original Message-----
From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
Sent: Wednesday, February 5, 2014 3:41 PM
To: Robert O'Callahan
Cc: www-style
Subject: Re: Resolutions regarding fragments

On Tue, Feb 4, 2014 at 12:02 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
> 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?

Yes.

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

2.1'll be the big project.  We can at least start with the more modern specs and retrofit them - Flexbox already has some element/box confusion that needs fixing, so we can use it as a testbed for clearing up box/fragment confusion as well.

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

We really shouldn't.  This'll take some time and effort to rewrite, unfortunately.

~TJ

Received on Thursday, 6 February 2014 02:37:38 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:18 UTC