headers
Anton Prowse | 1 Aug 2010 20:22

[CSS21] 10.6.1, 10.6.3 and 10.6.7 - editorial issues

10.6.7 ('Auto' heights for block formatting context roots) says:[1]

   # In addition, if the element has any floating descendants whose
   # bottom margin edge is below the bottom, then the height is increased
   # to include those edges. Only floats that are children of the element
   # itself or of descendants in the normal flow are taken into account,
   # e.g., floats inside absolutely positioned descendants or other
   # floats are not.

Issue 1:

s/below the bottom/below the bottom of the content area/

Issue 2:

The second sentence is clumsy and misses some important cases.  Floats
that are children of child inline-blocks, tables or inline-tables should
also be excluded.  The sentence needs replacing with

   | Only floats which are participate in this block formatting context
   | taken into account.

and the first sentence of the section modified as follows:

   | In certain cases (see the preceding sections), the height of an
   | element is computed as follows:

s/element/element that establishes a block formatting context/

It's possible, however, that 10.6.7 is being deliberately decoupled from
(Continue reading)

Permalink | Reply | 8 comments |
headers
Anton Prowse | 1 Aug 2010 20:28

[CSS21] Titles in Chapter 10 - trivial editorial issues

The following are titles in Chapter 10:

10.3.9 'Inline-block', non-replaced elements in normal flow
10.3.10 'Inline-block', replaced elements in normal flow
10.6.2 Inline replaced elements, block-level replaced elements in normal
flow, 'inline-block' replaced elements in normal flow and floating
replaced elements

There's no such thing as an out-of-flow inline-block, and so the
qualification "in normal flow" is unnecessary.

Also,

10.6.7 'Auto' heights for block formatting context roots

s/context roots/contexts/

There's no such thing as a block formatting context root in CSS21.
(Flow root is the corresponding CSS3 term.)

Cheers,
Anton Prowse
http://dev.moonhenge.net
Permalink | Reply | 4 comments |
headers
L. David Baron | 1 Aug 2010 21:40
Gravatar

Re: [CSS21] Titles in Chapter 10 - trivial editorial issues

On Sunday 2010-08-01 20:28 +0200, Anton Prowse wrote:
> 10.6.7 'Auto' heights for block formatting context roots
> 
> s/context roots/contexts/
> 
> There's no such thing as a block formatting context root in CSS21.
> (Flow root is the corresponding CSS3 term.)

Well, just because we don't define a term for the thing we want
doesn't mean we should use a different term.  A block formatting
context is not an element or box; if we don't have a term for
elements that establish new block formatting contexts we should
probably either write it out or add a defined term.

-David

--

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/
Permalink | Reply | 1 comment |
headers
Anton Prowse | 1 Aug 2010 21:54

Re: [CSS21] Titles in Chapter 10 - trivial editorial issues

L. David Baron wrote:
> On Sunday 2010-08-01 20:28 +0200, Anton Prowse wrote:
>> 10.6.7 'Auto' heights for block formatting context roots
>>
>> s/context roots/contexts/
>>
>> There's no such thing as a block formatting context root in CSS21.
>> (Flow root is the corresponding CSS3 term.)
> 
> Well, just because we don't define a term for the thing we want
> doesn't mean we should use a different term.  A block formatting
> context is not an element or box; if we don't have a term for
> elements that establish new block formatting contexts we should
> probably either write it out or add a defined term.

Sure, and I'd even written an alternative ("'Auto' heights for elements
establishing block formatting contexts") but I deleted it before
sending, because although using "elements" in the title is consistent
with the other titles in the section, I'm hoping we'll move from
elements to boxes as part of a global spring clean, but I couldn't think
  how the alternative title would be reworded satisfactorily if that
happens, so I wimped out of the idea. ;-)  I thought my suggestion was
reasonable for the time being, given the current standards of rigour in
this part of the spec.

But the fact is, as you say, that we probably do need a term for
elements that establish a block formatting context; and if we address
the elements vs boxes thing then there'll be even more need for one for
principal block boxes generated by elements that establish a block
formatting context, which is quite a mouthful!
(Continue reading)

Permalink | Reply | 0 comments |
headers
Anton Prowse | 1 Aug 2010 23:12

Re: [CSS21] Distinguishing block boxes, block containers, and block-level elements

Anton Prowse wrote:
> fantasai wrote:
>> CSS2.1 Issue 120
>>   http://wiki.csswg.org/spec/css2.1#issue-120
>>
>> The approach taken is to define existing terms more precisely, define a
>> couple of new terms, and use all of these terms more accurately 
>> throughout
>> the specification.

>>   | Block-level elements generate a principal block-level box that
>>   | contains descendant boxes and generated content and is also
>>   | the box involved in any positioning scheme.

>>   | Except for 'table' elements, which are described in a later chapter,
>>   | and replaced elements, the principal block-level box is also a
>>   | <dfn>block container box</dfn>.

>>   | A block container box contains either
>>   | only block-level boxes or only inline-level boxes.
> 
> Hang on, what's a "block-level box"?  This is an important ambiguity.  I
> /think/ you intend it to be precisely a principal block-level box or an
> anonymous block-level box as described in 9.2.1.1 (Anonymous block boxes).
> 
> Note that you haven't really defined "block container box", although you
> have described its behaviour.  (I think perhaps these sorts of
> definition-by-behaviour-without-classification instances in the
> spec should be rewritten, since its usually unclear whether the /only/
> elements/boxes which are X are necessarily those mentioned when
(Continue reading)

Permalink | Reply | 2 comments |
headers
Anton Prowse | 1 Aug 2010 23:45

[CSS21] 9.2 Anonymous boxes

Several issues arise concerning anonymous block boxes.

9.2.1 (Block-level elements and block boxes) says:[1]

   # Block-level elements (except for display 'table' elements, which are
   # described in a later chapter) generate a principal block box that
   # contains either only block boxes or only inline boxes.

9.2.1.1 (Anonymous block boxes) says:[2]

   # In a document like this:
   #
   # <DIV>
   #   Some text
   #   <P>More text
   # </DIV>
   #
   # (and assuming the DIV and the P both have 'display: block'), the DIV
   # appears to have both inline content and block content. To make it
   # easier to define the formatting, we assume that there is an
   # anonymous block box around "Some text".
   #
   # In other words: if a block box (such as that generated for the DIV
   # above) has another block box or run-in box inside it (such as the P
   # above), then we force it to have only block boxes and run-in boxes
   # inside it.

OK. But we also have the following from 16.6.1 (The 'white-space'
processing model)[3] (which will likely be moved to Ch.9; see [4]):
(Continue reading)

Permalink | Reply | 8 comments |
headers
fantasai | 2 Aug 2010 00:15

Re: [CSS21] 9.2 Anonymous boxes

On 08/01/2010 02:45 PM, Anton Prowse wrote:
> Several issues arise concerning anonymous block boxes.
>
>
> 9.2.1 (Block-level elements and block boxes) says:[1]
>
> # Block-level elements (except for display 'table' elements, which are
> # described in a later chapter) generate a principal block box that
> # contains either only block boxes or only inline boxes.
>
> 9.2.1.1 (Anonymous block boxes) says:[2]
>
> # In a document like this:
> #
> # <DIV>
> # Some text
> # <P>More text
> # </DIV>
> #
> # (and assuming the DIV and the P both have 'display: block'), the DIV
> # appears to have both inline content and block content. To make it
> # easier to define the formatting, we assume that there is an
> # anonymous block box around "Some text".
> #
> # In other words: if a block box (such as that generated for the DIV
> # above) has another block box or run-in box inside it (such as the P
> # above), then we force it to have only block boxes and run-in boxes
> # inside it.
>
> OK. But we also have the following from 16.6.1 (The 'white-space'
(Continue reading)

Permalink | Reply | 5 comments |
headers
Peter Moulder | 2 Aug 2010 06:44
Favicon

Re: [CSS21] 10.6.1, 10.6.3 and 10.6.7 - editorial issues

On Sun, Aug 01, 2010 at 08:22:12PM +0200, Anton Prowse wrote:

> and the first sentence of the section modified as follows:
> 
>   | In certain cases (see the preceding sections), the height of an
>   | element is computed as follows:
> 
> s/element/element that establishes a block formatting context/

I agree that it would be helpful if readers could find out what cases those
"certain cases" are, though I would suggest doing so differently.

As for what those "certain cases" are, and how to determine that from the
spec:

  Note that "the preceding sections" means almost the whole of that chapter
  (and a reader wouldn't even be certain that it's restricted to that chapter).

  A search for `context' or `10.6.7' finds no earlier matches within the
  chapter (other than in the table of contents).  There are no name/id attrs
  within 10.6.7 other than to the 10.6.7 heading itself (#root-height); there
  are links to #root-height from sections 10.6.4 and 10.6.6 (and from nowhere
  else in the CSS spec other than cover.html; while a search for `10.6.7' finds
  matches only in visudet.html, cover.html and changes.html).

  Thus, I believe that the "certain cases" in question are determined by the
  three places in the spec that have a hyperlink to #root-height (outside of
  tables of contents), which are in sections 10.6.4 and 10.6.6.

  The exact rule for when 10.6.7 applies is a bit complex: assuming that
(Continue reading)

Permalink | Reply | 4 comments |
headers
fantasai | 2 Aug 2010 06:43

Re: [CSS21] Titles in Chapter 10 - trivial editorial issues

On 08/01/2010 11:28 AM, Anton Prowse wrote:
> The following are titles in Chapter 10:
>
> 10.3.9 'Inline-block', non-replaced elements in normal flow
> 10.3.10 'Inline-block', replaced elements in normal flow
> 10.6.2 Inline replaced elements, block-level replaced elements in normal
> flow, 'inline-block' replaced elements in normal flow and floating
> replaced elements
>
> There's no such thing as an out-of-flow inline-block, and so the
> qualification "in normal flow" is unnecessary.

But there are such things as elements with 'display: inline-block'
that are out-of-flow. Also, the title is not wrong. So I don't think
we should change this.

> Also,
>
> 10.6.7 'Auto' heights for block formatting context roots
>
> s/context roots/contexts/
>
> There's no such thing as a block formatting context root in CSS21.
> (Flow root is the corresponding CSS3 term.)

Agree with dbaron. If we need, to we should write it out.

~fantasai
(Continue reading)

Permalink | Reply | 1 comment |
headers
Boris Zbarsky | 2 Aug 2010 16:50
Picon
Favicon

Re: [CSS21] Titles in Chapter 10 - trivial editorial issues

On 8/2/10 12:43 AM, fantasai wrote:
> But there are such things as elements with 'display: inline-block'
> that are out-of-flow.

With _specified_ display inline-block, yes.  With computed, no.  I 
always assumed that 10.3 and 10.6 were talking about computed display 
values, since they don't make sense otherwise....

-Boris
Permalink | Reply | 0 comments |

Gmane